Re: standards/42828: Almquist shell always evaluates the contents of ${ENV} even if non-interactive

[Richard Hansen <rhansen%bbn.com@localhost>]

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

From: Richard Hansen <rhansen%bbn.com@localhost>
To: Richard Hansen <rhansen%bbn.com@localhost>, Robert Elz 
<kre%munnari.OZ.AU@localhost>, 
 gnats-bugs%NetBSD.org@localhost, standards-manager%NetBSD.org@localhost, 
 netbsd-bugs%NetBSD.org@localhost, david%l8s.co.uk@localhost
Cc: 
Subject: Re: standards/42828: Almquist shell always evaluates the contents
 of ${ENV} even if non-interactive
Date: Wed, 24 Feb 2010 17:20:56 -0500

 David Laight wrote:
 > Actually, for non-special builtins, posix requires that the builtin version 
 > only be used if the one that would be executed when $PATH is searched 
 > would be the systems 'standard' version.
 
 I'm not 100% sure that's true...  I stared at the "Command Search and 
 Execution" section [1] for a while (it's not easy to grok!) and came 
 away with the impression that if the system had echo as a regular 
 built-in, the built-in would be invoked instead of ~/bin/echo even if 
 ~/bin was first in PATH.
 
 Here's how I interpret the logic:
    1.  'echo' doesn't contain any slashes, so rule 1. applies
    2.  echo is not a special built-in, so rule 1.a. doesn't apply
    3.  there is no function named echo, so rule 1.b. doesn't apply
    4.  echo is not in the exception list, so 1.c. doesn't apply
    5.  rule 1.d. applies and the PATH is searched for echo
    6.  echo is in the PATH (in ~/bin), so rule 1.d.i. applies
    7.  echo is implemented as a regular built-in, so rule 1.d.i.a. 
 applies and the built-in version is invoked
 
 I hope I'm misunderstanding POSIX because I'd prefer the algorithm you 
 described.
 
 On a related note:  It's unclear what POSIX says should happen if a user 
 defines a function whose name matches the name of a regular built-in 
 (e.g., 'cd' or 'echo').  Specifically, rule 1.b. is awkward:  Either the 
 shell must be able to distinguish implementation-provided functions from 
 user-defined functions (my interpretation) or it's undefined which one 
 wins (rule 1.d.i.a. doesn't break ties between regular built-ins and 
 shell functions).
 
 [1] 
 
<http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01>
 
 -Richard