On Mon, Jun 02, 2008 at 03:04:55PM +0000, Clint Adams wrote: > On Mon, Jun 02, 2008 at 11:58:59AM +0100, Stephane Chazelas wrote: > > Another strange requirement that I see no shell implements even > > posh, is that if a builtin (such as "[" or "echo" or ":") is not > > found in $PATH, its invocation should fail!?! > > Could you point me to that in the standard?
This is so weird that I'm suspecting that either I misinterpret it or I missed something. Here is the text, please tell me if you understand it differently: http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_09_01_01 SUS> Command Search and Execution SUS> SUS>If a simple command results in a command name and an optional list of SUS>arguments, the following actions shall be performed: SUS> SUS> 1. If the command name does not contain any slashes, the first successful SUS> step in the following sequence shall occur: SUS> SUS> a. If the command name matches the name of a special built-in SUS> utility, that special built-in utility shall be invoked. SUS> SUS> b. If the command name matches the name of a function known to this SUS> shell, the function shall be invoked as described in Function SUS> Definition Command. If the implementation has provided a standard SUS> utility in the form of a function, it shall not be recognized at SUS> this point. It shall be invoked in conjunction with the path SUS> search in step 1d. SUS> SUS> c. If the command name matches the name of a utility listed in the SUS> following table, that utility shall be invoked. SUS> SUS> alias false jobs read wait SUS> bg fc kill true SUS> cd fg newgrp umask SUS> command getopts pwd unalias SUS> SUS> SUS> d. Otherwise, the command shall be searched for using the PATH SUS> environment variable as described in the Base Definitions volume SUS> of IEEE Std 1003.1-2001, Chapter 8, Environment Variables: SUS> SUS> i. If the search is successful: SUS> SUS> a. If the system has implemented the utility as a regular SUS> built-in or as a shell function, it shall be invoked at SUS> this point in the path search. SUS> SUS> b. Otherwise, the shell executes the utility in a separate SUS> utility environment (see Shell Execution Environment) SUS> with actions equivalent to calling the execve() function SUS> as defined in the System Interfaces volume of SUS> IEEE Std 1003.1-2001 with the path argument set to the SUS> pathname resulting from the search, arg0 set to the SUS> command name, and the remaining arguments set to the SUS> operands, if any. SUS> SUS> If the execve() function fails due to an error SUS> equivalent to the [ENOEXEC] error defined in the System SUS> Interfaces volume of IEEE Std 1003.1-2001, the shell SUS> shall execute a command equivalent to having a shell SUS> invoked with the pathname resulting from the search as SUS> its first operand, with any remaining arguments passed SUS> to the new shell, except that the value of "$0" in the SUS> new shell may be set to the command name. If the SUS> executable file is not a text file, the shell may bypass SUS> this command execution. In this case, it shall write an SUS> error message, and shall return an exit status of 126. SUS> SUS> Once a utility has been searched for and found (either as a SUS> result of this specific search or as part of an unspecified SUS> shell start-up activity), an implementation may remember its SUS> location and need not search for the utility again unless the SUS> PATH variable has been the subject of an assignment. If the SUS> remembered location fails for a subsequent invocation, the SUS> shell shall repeat the search to find the new location for SUS> the utility, if any. SUS> SUS> ii. If the search is unsuccessful, the command shall fail with SUS> an exit status of 127 and the shell shall write an error SUS> message. Given that I've never seen a /bin/: (as : is built in every shell), that would imply that ":" would never work. regards, Stéphane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
