Poul-Henning Kamp writes:
> In message <[EMAIL PROTECTED]>, Ben Smithurs
> t writes:
> >Poul-Henning Kamp wrote:
> >
> >> I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
> >> is bogus. It looks like something which happened "because we can" more
> >> than something which has a legitimate need.
> >You think adding a hack to every program to support "-" to mean
> >stdout/stdin is better?
> The majority of these programs could be handled by adding knowledge
> of "-" as a magic filename to fopen(3).
Ugh. So what happens when you *really* want to read a filed called
"-"? Adding magic characters to low-level calls is a bad idea.
I believe /dev/fd originated in Unix v8 (or maybe plan 9) to provide a
uniform mechanism to get a class of process-internal objects where
they can be manipulated by shell scripts. If that's the case, it's
provenance is impeccable.
> At the same time I would really love if we implemented "|.*" to mean
> "do an popen(3)" instead.
Again, putting magic character recognition in a low-level call is a
bad idea. Worse yet, this kind of thing is really useful in shells
(which don't generally have the ability to manipulate fd's). Consider
trying to use that syntax in the shell?
Which is why modern shells that implement this kind of thing use a
different syntax. Of course, they depend on something like /dev/fd or
named pipes to provide this feature.
> But of course, this is bikeshed material...
Most certainly. If you really want to make C programming look like
Perl programming, could you do it by adding new library calls, instead
of changing the semantics of existing ones?
<mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
