On Thu, 14 Sep 2000, Ben Smithurst wrote:

> 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?  It seems to be that saying "/dev/stdin" when
> you mean stdin is better than saying "-" and hoping the application
> handles that correctly.  Of course many programs will read stdin by
> default, and write stdout by default, but that doesn't help when you
> want to read more than one file, one of which is stdin.
> > If anything I would propose we ditch it...
> And break loads of scripts at the same time?

        I recently ran into revelant problem with /dev/stdout, while
working on some software under linux that expected /dev/stdout as an
argument instead of using stdout.

        Using the device file breaks, if the process is suid to a non-root
user.  This is because it cannot open /dev/stdout, which is owned by your
UID and not the EUID of the process to which the device was passed.  My
solution was to add the "-" hack and use the existing open descriptor.

        Still, I don't think /dev/stdout and friends are such bad things
that they should be abandoned.  They are present in other OS's and it does
help avoid making named pipes and the such when you need the behavior the
special devices provide.  I think it would simple create minor poratability
issues for third party software.

[ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to