On Jan 6, 2004, at 12:17 PM, [EMAIL PROTECTED] wrote: [..]
[..]It just dawned on me that I may not be using the correct terminology since "pipe" and "STDIN" probably imply much more than I mean for them to convey.
This is a good angst point to raise.
Technically STDIN|STDOUT|STDERR denote merely 'file descriptors' that will be opened by the shell in compliance with how the shell saw the voodoo passed to it. Normally they will be implemented as a 'pipe' unless we do something else with them, at which they may be implemented as a 'closed fd'.... 8-)
One can implement Pipes that are not the first three fd's in the _iobuf[] - and yes, one can get into massed weirdness when screwing around at that level. So the way to think about the problem is that the first three fd's "stdin|stdout|stderr" will be implemented at pipes, and as such are a proper subset of the set of Pipes. We tend to speak in terms of 'pipe fittings' because we think of them in terms of say
ps -ef | grep foo | egrep -v grep | awk '{print $2}'
which we on the perl side of the line could have implemented with say perl's "popen()" approach of say
open(PS, "ps $ps_args |") or die "unable to popen(ps $ps_args): $!";
while(<PS>)
{
# your proc grovelling here...
}
close(PS);But for some reason, I'd hazzard to say that about 99%
of us fail to set a $SIG{'PIPE'} handler to deal with
the prospects of the pipe breaking.... because, well
most of the time we just do not care. Even MORE SO
when it is stdin|stdout|stderr ...So the converse of your kvetch is of course,
Gosh, now that I feel at home writing pipe fittings,
when, where and how would I really want to be building
my own pipes and/or popen() types of tricks?well for that there is perldoc perlipc for everything else, there is ioctl().... 8-)
ciao drieux
---
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
