Re: PR/43639 CVS commit: src/bin/sh

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/43639; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
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>
     Message-ID:  <20160504084501.9E8D87AA9F%mollari.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,
 	PATH=named-pipe-directory:$PATH
 	. pipe-file-name			# no '/' in that name
 would not have worked.
 
 Now
 	. 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...
 
 kre