On Wed, Nov 28, 2007 at 05:31:16PM -0500, Adam Katz wrote:
> Two bits of extraneous code to remove:
>
> lines 30-33:
> 30 case $PATH in
> 31 *::) : "not *DIR:" ;;
> 32 *:) PATH="$PATH:" ;;
> 33 esac
>
> Unless this is for some weird nonstandard bourne implementation, the
> argument "not *DIR:" to the colon (:) builtin on line 31 is ignored, and
> the whole purpose of the entire case statement, that of ensuring a
> trailing colon, is unnecessary, as the tokenizer works fine when the last
> token has no delimiter (e.g. "for i in 1 2 3; do echo $i; done" writes
> three lines, as does "IFS=:; for i in 1:2:3; do echo $i; done" ... you
> do not need "1:2:3:" to properly parse the last token "3").
I think if you look again you'll find that the case statement ensures
that $PATH will either end in no colons or two colons. This is probably
for the reason you suggest: that 1:2:3: will not be regarded as
containing an empty element.
> lines 47-49:
> 47 if [ -z "$ELEMENT" ]; then
> 48 ELEMENT=.
> 49 fi
>
> I've never heard of somebody's path including an empty string; this only
> triggers on a path like PATH="/usr/local/bin:'':/usr/bin." I think
> this is another misunderstanding of Bourne shell tokenization. The only
> other application I can see for this would be if Bourne interpreted a
> PATH="/usr/local/bin::/usr/bin" as having the tokens '/usr/local/bin'
> and '' and '/usr/bin' (which it does not), in which case there would be
> an empty token, but why should that be interpreted as the current
> directory?
An empty string in PATH is interpreted as ".". Therefore
/usr/local/bin::/usr/bin is practically equivalent to
/usr/local/bin:.:/usr/bin
> In the event there IS an empty string in handed to the loop on line 46,
> nothing will happen unless the argument ("$PROGRAM") happens to exist as
> a file in / with executable permissions (assuming you remove lines
> 47-49, otherwise it searches the current directory).
I believe this is the intent.
> If you really want to be able to handle a corner case like that, add a
> third test to line 57 (line 43 on my patched version) to test for
> '[ -n "$ELEMENT" ]' (sans single-quotes). This goes third so that it is
> never used except in these rare corner cases (due to short circuiting).
I'm not sure how rare this is. Any further thoughts?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
