NetBSD-Bugs archive

[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 <>
     Message-ID:  <>
   |   >  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.
 	. named-pipe-directory/pipe-file-name
 doesn't either.
 If a change is to be made, should it be made to both cases, or just one
 of them?
 Either way - that info ought be in the (purported) future PR that
 requests this change...

Home | Main Index | Thread Index | Old Index