Mine is straightforward, and represents the requirements based on what is discoverable about a particular file name once found. If by 'hash code' you mean 'code that does the path search', then yes, the Bourne shell is doing a variant of the usually slower 'exec() first and recover' method. If it's searching path when the shell execs and constructing a table of files with their X bit set in each directory, indexed by a hash of the file name, and using those references even if PATH is changed by the script or user, then I don't see that as consistent with the text. In a message dated 11/23/2016 1:22:30 P.M. Eastern Standard Time, [email protected] writes:
Shware Systems <[email protected]> wrote: > It's confusing to me too. > My understanding is: > From the shell's perspective an 'executable file' is any readable non-directory file where the appropriate X or R bit is set in permissions. > It's up to the loader to determine whether it looks like code suitable for the current processor, if the X bit is set, and if it doesn't or just the R bit is set a subshell is forked to try and run the contents as a script. > Whether the shell as a privileged app uses dlopen() or another platform provided interface to examine the file's content, if just the X bit is set, is not specified. > If it does look like code, then the forked subshell calls exec() on the file instead. > As written it looks like first file found, script or code, has priority, whether by hard or symbolic link, on a fast local drive or from a dismally slow server. > No favoring code over script, iow. Favoring built-ins over externals is a different topic. > There's leeway if the X bit is set the subshell can try exec() first and recover if that fails to process it as a script, depending on failure type, but if it's attempting either type of load that stops a path walk, even if a file that could load successfully is in a later directory on the path. > If the attempt fails due to ENOMEM or wrong processor type for the code sort of circumstance it's a 126 'can't load' error. > If the name is found but no X or R bit in the right place, then the file is skipped and the name is appended to the next path element to try again. > If all path elements are tried and no file with valid permissions is found, then you get a 127 'not found' return code. > > That's how I expand that first sentence into a flowchart, anyways. The only grey area is if a device reports 'not ready' or 'media not accessible' where a cached, not hashed, directory says it's available for a load attempt, whether this should be a 126 abort or try more prefixes situation. Your text seems to confuse things even more. The Bourne Shell does what is in the standard text, but the standard text does not describe an algorithm but leaves the exact algorithm open. The Bourne Shell runs the hash code to find the executable in the main shell code and that code returns an index in the PATH array. Later, after the shell did fork, it uses this index to rebuild the related path for the executable. Then it calls exec() and this may fail, e.g. because the binariy refers to a firretent processor type. As a result, there is no attempt to seach further on in the PATH to find a potantially better match. Jörg -- EMail:[email protected] (home) Jörg Schilling D-13353 Berlin [email protected] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
