 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So check this out: Apparently piping works on Windoze.
I knew redirecting the three standard handles works on Windoze, but I
had no idea you could actually pipe data directly from one program to
another. I thought only Unix could do that particular trick.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> So check this out: Apparently piping works on Windoze.
>
> I knew redirecting the three standard handles works on Windoze, but I
> had no idea you could actually pipe data directly from one program to
> another. I thought only Unix could do that particular trick.
Welcome to world of PC's. IIRC piping worked even on MS-DOS (eg. type
autoexec.bat|more).
-Aero
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Eero Ahonen wrote:
> Invisible wrote:
>> So check this out: Apparently piping works on Windoze.
>>
>> I knew redirecting the three standard handles works on Windoze, but I
>> had no idea you could actually pipe data directly from one program to
>> another. I thought only Unix could do that particular trick.
>
> Welcome to world of PC's. IIRC piping worked even on MS-DOS (eg. type
> autoexec.bat|more).
Yep. Been there since forever.
--
Inoculatte: To take coffee intravenously when you are running late.
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawaz org<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Eero Ahonen wrote:
> Welcome to world of PC's. IIRC piping worked even on MS-DOS (eg. type
> autoexec.bat|more).
Under DOS, since only one thing ran at a time, this didn't actually
"pipe" the data. It was just a shortcut for
type autoexec.bat >tempfile
more <tempfile
You had to wait for the first program to finish, and you had to have
enough disk space, before the second would start.
Pretty much every MS OS since Win3 at least has had actual pipes, tho. I
think the command.com under Win3 still used the tempfile stuff, but the
OS had a "make a pipe" call in it.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Eero Ahonen wrote:
> > Welcome to world of PC's. IIRC piping worked even on MS-DOS (eg. type
> > autoexec.bat|more).
> Under DOS, since only one thing ran at a time, this didn't actually
> "pipe" the data. It was just a shortcut for
> type autoexec.bat >tempfile
> more <tempfile
Yes. The difference is whether a program can programmatically create
pipes or not. For example in unix systems (and probably in Windows as
well) a program can create a named pipe, after which it can write data
to it, and then another program can read the data from it. It works like
a data queue between programs. In fact, more than one program can write
to the pipe (although if two programs do so at the same time, it's not
guaranteed in which order the data will come out).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Yes. The difference is whether a program can programmatically create
> pipes or not. For example in unix systems (and probably in Windows as
> well) a program can create a named pipe, after which it can write data
> to it, and then another program can read the data from it. It works like
> a data queue between programs. In fact, more than one program can write
> to the pipe (although if two programs do so at the same time, it's not
> guaranteed in which order the data will come out).
However Windows named pipes aren't part of the filesystem. Unix's mkfifo is
*very* useful.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> For example in unix systems (and probably in Windows as
> well) a program can create a named pipe,
Yep. And Windows has different kinds of "pipes" as well, in addition to
the usual stream-of-bytes stuff. I'm talking about message queues and
stuff like that. Windows uses named pipes for all kinds of things, like
talking to the graphics system, over the network, etc etc.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> However Windows named pipes aren't part of the filesystem.
Yes they are. You just have to use \\?\.... syntax to get at them. Why
do you think they're *named* pipes?
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Yes they are. You just have to use \\?\.... syntax to get at them. Why
> do you think they're *named* pipes?
Most programs I have tried don't work with that syntax. I think it only
works if you use the Windows API directly, and not stuff like fopen...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Most programs I have tried don't work with that syntax. I think it only
> works if you use the Windows API directly, and not stuff like fopen...
Not surprisingly, if you use the UNIX interface libraries to access
Windows juju, no, it might not work. That whole "lowest common
denominator" type thing doesn't really work anywhere once you get
sophisticated about things. :-)
But yes, I have used named pipes in Unix before, and they can be
surprisingly handy for some things. Kind of annoying in that (at least
back then) the locking/exclusion semantics made things difficult.
Difficult enough I wound up writing a socket listener instead and
replaced the I/O stuff with libraries to talk to the sockets.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> But yes, I have used named pipes in Unix before, and they can be
> surprisingly handy for some things. Kind of annoying in that (at least
> back then) the locking/exclusion semantics made things difficult.
> Difficult enough I wound up writing a socket listener instead and
> replaced the I/O stuff with libraries to talk to the sockets.
I don't know why, but somehow you always succeed in doing two things:
1) Whenever someone belittles Windows, especially on its API and its
capabilities, for example by saying that Windows does not support this
or that, you almost always have a counter-argument ready, telling that
Windows *does* support it. (And even if the support is extremely hard
for a regular user to use, while the same feature in eg. linux is rather
simple to use, you still manage to make it *sound* like it's a completely
trivial thing to do in Windows as well, even if it really isn't.)
2) Whenever someone exalts unix in general or linux in particular, and
this is something which is absolutely undeniable, you often aknowledge
it, but *still* manage to somehow find something negative about it, making
it sound less useful. (While I'm not doubting your honesty, it often is
something which is rather difficult to verify in a few minutes, especially
for someone who is not thoroughly acquainted with the internal workings of
unix/linux/posix, which sometimes just feels too convenient.)
I'm not saying that what you are saying is not true. I just sometimes
get the feeling that you make things sound more positive or negative than
they really are, on purpose.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Not surprisingly, if you use the UNIX interface libraries to access
> Windows juju, no, it might not work. That whole "lowest common
> denominator" type thing doesn't really work anywhere once you get
> sophisticated about things. :-)
That's not the Unix interface. open() is POSIX, I would be surprised if it
worked at all on Windows. But fopen() is standard C, and I would guess on
Windows it's implemented using CreateFile, not open.
Most open-source command-line tools don't work with any \\Windows\Crap. I
once tried to access the CDROM drive as raw blocks on Windows, and only one
tool (a port of dd) succeeded at reading from "\\.\Cdrom0". I don't care if
they use UNIX interfaces or what. All I care is that they don't work, and
they would with a plain old Unix fifo.
Something I think is interesting on Unix, even though I have never really
done it:
Download a .iso using BitTorrent. Burn it to a real CD. Delete the .iso to
save hard disk space. You can still keep seeding the torrent by
reconfiguring the torrent client to read from /dev/cdrom instead of
~/whatever.iso. Do *that* in Windows!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> 1) Whenever someone belittles Windows, especially on its API and its
> capabilities, for example by saying that Windows does not support this
> or that, you almost always have a counter-argument ready, telling that
> Windows *does* support it.
Well, oddly enough, when I say in public that Linux can't do something
it can, I usually get corrected also. :-)
> (And even if the support is extremely hard
> for a regular user to use, while the same feature in eg. linux is rather
> simple to use, you still manage to make it *sound* like it's a completely
> trivial thing to do in Windows as well, even if it really isn't.)
It's not hard to use named pipes or the "odd syntax" names if you know
about them and use (for example) man(2) level calls instead of man(3)
level calls.
> 2) Whenever someone exalts unix in general or linux in particular, and
> this is something which is absolutely undeniable, you often aknowledge
> it, but *still* manage to somehow find something negative about it, making
> it sound less useful. (While I'm not doubting your honesty, it often is
> something which is rather difficult to verify in a few minutes, especially
> for someone who is not thoroughly acquainted with the internal workings of
> unix/linux/posix, which sometimes just feels too convenient.)
I've done a lot of work with UNIX, usually on server type stuff. Before
that, my server type stuff was all done on mainframes, where lots of
attention was paid to getting things right in corner cases UNIX
traditionally doesn't (or didn't) address. So yeah, I often mention
problems I run into.
I've done more user-level stuff in Windows, usually using the MS servers
that come with it and are thus nicely integrated et al, so I don't have
to worry about the crap parts. I suspect if I'd done more system-level
high-reliability work in Windows, I'd have just as many war stories
about that too.
I think I'm pretty fair at mentioning stupidities in Windows, too, yes?
It's not like I deny Windows has its warts.
The Windows API is way, way more complex than the UNIX APIs, even
discounting legacy stuff. Most people don't ever actually learn it in
any sort of organized way, in part because (as far as I know) there
isn't any way to just sit down and read the API. There's no man(2)
equivalent you can just spend a week reading. So I correct
misconceptions, is all.
> I'm not saying that what you are saying is not true. I just sometimes
> get the feeling that you make things sound more positive or negative than
> they really are, on purpose.
I guess sometimes I just feel it needs some balance. :-) Besides, it
would be boring if we all just agreed with everything. ;-)
But yeah, I guess when someone says "UNIX is great because it has X that
Windows doesn't", my first reaction is indeed to say "Windows has X, and
UNIX's X has limitations that have bitten me in the past." Mainly
because UNIX in general tends to target the "90% correct is good enough"
market, and I strive for excellence in my programs, and I learned to
program on a machine where a crash produced about a ream of print-out so
you could track down what went wrong.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> That's not the Unix interface. open() is POSIX, I would be surprised if it
> worked at all on Windows. But fopen() is standard C, and I would guess on
> Windows it's implemented using CreateFile, not open.
I think it depends on the library, yes. :-) Certainly open() works on
every Windows C compiler I've used. It's not any more native than
fopen() is, tho.
> Most open-source command-line tools don't work with any \\Windows\Crap. I
> once tried to access the CDROM drive as raw blocks on Windows, and only one
> tool (a port of dd) succeeded at reading from "\\.\Cdrom0". I don't care if
> they use UNIX interfaces or what. All I care is that they don't work, and
> they would with a plain old Unix fifo.
Depending what you're doing with them, yes. For plain old reading and
writing, sure, that stuff works better under UNIX. It's certainly easier
if you're used to unix-style programming.
On the other hand, try doing something like copying a file, including
all the attributes (permissions, auditing, encryption, etc) and
everything else, with a unix-style program. There's a reason Windows is
more complicated - it really does do more stuff.
> reconfiguring the torrent client to read from /dev/cdrom instead of
> ~/whatever.iso. Do *that* in Windows!
I don't think that would work in Windows, AFAIK. Does /dev/cdrom really
stop reading under Linux when you get to the end of the data? I'll have
to give that a go. :-)
No, Windows is definitely not as device-agnostic as UNIX is. Doing funky
stuff really requires you to know what kind of device you're talking to
in Windows more than Linux. It's not absolute, but it's certainly more
problematic.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> But yes, I have used named pipes in Unix before, and they can be
>> surprisingly handy for some things. Kind of annoying in that (at least
>> back then) the locking/exclusion semantics made things difficult.
>> Difficult enough I wound up writing a socket listener instead and
>> replaced the I/O stuff with libraries to talk to the sockets.
>
> I don't know why, but somehow you always succeed in doing two things:
>
> 1) Whenever someone belittles Windows, especially on its API and its
> capabilities, for example by saying that Windows does not support this
> or that, you almost always have a counter-argument ready, telling that
> Windows *does* support it. (And even if the support is extremely hard
> for a regular user to use, while the same feature in eg. linux is rather
> simple to use, you still manage to make it *sound* like it's a completely
> trivial thing to do in Windows as well, even if it really isn't.)
>
> 2) Whenever someone exalts unix in general or linux in particular, and
> this is something which is absolutely undeniable, you often aknowledge
> it, but *still* manage to somehow find something negative about it, making
> it sound less useful. (While I'm not doubting your honesty, it often is
> something which is rather difficult to verify in a few minutes, especially
> for someone who is not thoroughly acquainted with the internal workings of
> unix/linux/posix, which sometimes just feels too convenient.)
>
> I'm not saying that what you are saying is not true. I just sometimes
> get the feeling that you make things sound more positive or negative than
> they really are, on purpose.
>
So, he does this in other conversations too, not just ones on economics? lol
--
void main () {
If Schrödingers_cat is alive or version > 98 {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> So, he does this in other conversations too, not just ones on economics?
And programming languages. ;-)
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> I don't care if
> they use UNIX interfaces or what. All I care is that they don't work, and
> they would with a plain old Unix fifo.
Oh, and BTW, I saw on a MS blog (while searching for something else)
that someone complained they couldn't open "\\?\GLOBALSPACE\..." in
.NET. The answer was "Yes, .NET checks for paths that start that way on
purpose and refuses to open them because it isn't portable."
WTF? This is Microsoft. :-)
So, yeah, even .NET won't let you read from shadow copies without
dropping down into C or something.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Eero Ahonen <aer### [at] removethiszbxtnetinvalid> wrote:
> Invisible wrote:
> > So check this out: Apparently piping works on Windoze.
> >
> > I knew redirecting the three standard handles works on Windoze, but I
> > had no idea you could actually pipe data directly from one program to
> > another. I thought only Unix could do that particular trick.
>
> Welcome to world of PC's. IIRC piping worked even on MS-DOS (eg. type
> autoexec.bat|more).
Yes, that's the only pipe I used on DOS. After all, what good is a pipe when
you don't have grep, sed and the whole gang?...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Oh, and BTW, I saw on a MS blog (while searching for something else)
> that someone complained they couldn't open "\\?\GLOBALSPACE\..." in
> .NET. The answer was "Yes, .NET checks for paths that start that way on
> purpose and refuses to open them because it isn't portable."
WTF indeed! o_O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Windows *does* support it. (And even if the support is extremely hard
> for a regular user to use, while the same feature in eg. linux is rather
> simple to use, you still manage to make it *sound* like it's a completely
> trivial thing to do in Windows as well, even if it really isn't.)
Actually, I think I've realized what's going on here.
I've used enough different systems that incidental awkwardness doesn't
bother me. Weird syntax and clunky that's annoying to work around isn't
a problem for me any more. Fundamental breakage that can't be avoided
is a problem for me, because I tend to run into this sort of thing a lot
in the kinds of stuff I do. The stuff I do needs to be correct when it's
working, even tho I don't always design things for 100% uptime.
So the fact that you need to use some OS-specific call to create a
volume shadow copy and what you wind up with is some weird string like
\\?\globalnamespace\vss\{12318-847-randomguid-381}
as the root directory (and you need more OS-specific calls to get to it)
doesn't bother me nearly as much as (say) the inability to make a
consistent backup of a running UNIX file system because it's changing
between the time you stat the file and the time you open it.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
