[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: PR/43639 CVS commit: src/bin/sh
The following reply was made to PR bin/43639; it has been noted by GNATS.
From: Robert Elz <kre%munnari.OZ.AU@localhost>
Subject: Re: PR/43639 CVS commit: src/bin/sh
Date: Thu, 05 May 2016 00:43:49 +0700
Date: Wed, 4 May 2016 08:45:01 +0000 (UTC)
From: David Holland <dholland-bugs%netbsd.org@localhost>
| > PR bin/43639 - check that a file being read by the '.' command
| > is a regular file, even when it is given as a full pathname.
| out of a general sense of mischief:
Sorry, to get your badge for mischievousness you will need to try harder!
| should it be allowed to be a named pipe?
Perhaps. I received the same (approximate) message via private mail.
Personally I also wondered about allowing /dev/null (well!) and perhaps
more rationally /dev/tty - except that wllowing either of those would
probably mean allowing all char type devices (I cannot see much utility
in allowing ". block-dev".)
For any of this, a PR requesting a change, and saying why it is needed
would probably be the way to start.
I fixed the PR (which only actually requested that directories not be
subject to '.' commands - which along with block devices, are the two
that are clearly useless) the way I did to make the "pathname given"
and the "no path in the filename, search $PATH) cases behave the same.
The "even when" words in the commit message were meant to (at least)
hint at that.
That is, from before this fix,
. pipe-file-name # no '/' in that name
would not have worked.
If a change is to be made, should it be made to both cases, or just one
Either way - that info ought be in the (purported) future PR that
requests this change...
Main Index |
Thread Index |