Re: when does PATH search stop?
"Schwarz, Konrad" wrote: > > > Well, that is what POSIX requires, so the "modern shells" you cite > > > cannot be compliant. > > > > If you believe this, please explain it. > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01, > 1. e. If the execl() function fails due to an error equivalent to the > [ENOEXEC] error defined in the System Interfaces volume of POSIX.1-2008, the > shell shall execute a command equivalent to having a shell invoked with the > pathname resulting from the search as its first operand, with any remaining > arguments passed to the new shell, except that the value of "$0" in the new > shell may be set to the command name. If the executable file is not a text > file, the shell may bypass this command execution. In this case, it shall > write an error message, and shall return an exit status of 126. You could make replies much easier if you did limit your line length to 79 chars. A line with 587 characters is close to unreadable. But i see this: If the executable file is not a text file, the shell may bypass this command execution. which explicitly permits the named behavior. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
RE: when does PATH search stop?
> -Original Message- > From: Joerg Schilling [mailto:joerg.schill...@fokus.fraunhofer.de] > > > Modern shells tend to open the file and to check whether it > contains > > > an excutable header for a wrong architecture. > > > > Well, that is what POSIX requires, so the "modern shells" you cite > > cannot be compliant. > > If you believe this, please explain it. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01, 1. e. If the execl() function fails due to an error equivalent to the [ENOEXEC] error defined in the System Interfaces volume of POSIX.1-2008, the shell shall execute a command equivalent to having a shell invoked with the pathname resulting from the search as its first operand, with any remaining arguments passed to the new shell, except that the value of "$0" in the new shell may be set to the command name. If the executable file is not a text file, the shell may bypass this command execution. In this case, it shall write an error message, and shall return an exit status of 126.
Re: when does PATH search stop?
That was one of my questions, does "acceptable", just concerns the contents, or name as well. Sounds like for you, it is "obvious" that it's not about the name. Well, I disagree that it is obvious. And the definition of "obvious" by the way, is not "obvious to some small selected group of experts", it is "obvious to anybody skilled in the art", like, in this case, since in all respected universities, the course of BS in Comp Science, includes compiler construction, then for any graduate from such, it should be "obvious". That should be the criterion for "obvious", not that you Geoff, who you may be one of the best experts in the world, thinks it is "obvious". I am sorry, but that is my opinion. From: Geoff Clare To: austin-group-l@opengroup.org Sent: Thursday, November 24, 2016 2:31 AM Subject: Re: when does PATH search stop? Mark Galeck wrote, on 24 Nov 2016: > > >There is no precise definition of "acceptable" > > Yes currently there isn't , but it would be easy to make such a > definition, simply, for various failure errno numbers (which are > enumerated in the standard), say "acceptable", "not acceptable", or > perhaps "unspecified". > I really don't see the need for the standard to spell this out in such detail. When it says "a regular file acceptable as a new process image file", it should be obvious that it means the file contents can be used by exec*() to create a new process image. The only error numbers listed for exec*() that relate to file contents are EINVAL and ENOEXEC. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: when does PATH search stop?
"Schwarz, Konrad" wrote: > > Modern shells tend to open the file and to check whether it contains an > > excutable header for a wrong architecture. > > Well, that is what POSIX requires, so the "modern shells" you cite > cannot be compliant. If you believe this, please explain it. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
RE: when does PATH search stop?
> -Original Message- > From: Joerg Schilling [mailto:joerg.schill...@fokus.fraunhofer.de] > Sent: Thursday, November 24, 2016 1:05 PM > To: Schwarz, Konrad (CT RDA ITP SES-DE); g...@opengroup.org; austin- > grou...@opengroup.org > Subject: Re: when does PATH search stop? > > "Schwarz, Konrad" wrote: > > > > However, I would argue that non-directory files that have the > > > executable bit set but that cannot be loaded by exec*() are mis- > > > configured -- perhaps this needs to be stated somewhere. > > > > Upon further reflection, the above is wrong: the POSIX shell will > > attempt to run any file that cannot be loaded by exec*() as a script > > in a sub-shell. The result of the sub-shell is taken as the new $?. > > This is what happened in the 1970s at a time when a different CPU > architecture was highly improbable. > > Modern shells tend to open the file and to check whether it contains an > excutable header for a wrong architecture. Well, that is what POSIX requires, so the "modern shells" you cite cannot be compliant.
Re: when does PATH search stop?
Wayne Pollock wrote: > > On Nov 24, 2016, at 7:04 AM, Joerg Schilling > > wrote: > > Modern shells tend to open the file and to check whether it contains an > > excutable header for a wrong architecture. > > That cannot be a good idea: some systems allow exec to support multiple > architectures and multiple executable formats. For example, Linux has > "binfmt" support that can "exec" DOS, .net, Java, Win32 (wine), and indeed > arbitrary file formats as long as a suitable runtime has been defined and is > available. It is too much to expect the shell to be able to determine if > some regular file with the execute bit set is currently going to exec without > error. Installing a new binfmt may also cause a different file to be found > on a path search. That is at least confusing for the user, and at worst a > security issue. > > I like a simple rule: a path search execs the first regular file with execute > permission for the current user, or the first regular file otherwise (which > will fail of course), or "command not found" results. (Actually I prefer a > simpler rule: the first regular file found with that name is used, and if it > fails for any reason, that is easy to understand and to fix.) Looks like you missunderstood things No shell prevents executing binaries, but some shells check the content _after_ ENOEXEC but _before_ interpreting the file as a script. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: when does PATH search stop?
"Schwarz, Konrad" wrote: > > However, I would argue that non-directory files that have the > > executable bit set but that cannot be loaded by exec*() are mis- > > configured -- perhaps this needs to be stated somewhere. > > Upon further reflection, the above is wrong: the POSIX shell > will attempt to run any file that cannot be loaded by exec*() > as a script in a sub-shell. The result of the sub-shell > is taken as the new $?. This is what happened in the 1970s at a time when a different CPU architecture was highly improbable. Modern shells tend to open the file and to check whether it contains an excutable header for a wrong architecture. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
RE: when does PATH search stop?
> -Original Message- > From: Schwarz, Konrad (CT RDA ITP SES-DE) > Sent: Thursday, November 24, 2016 12:26 PM > To: 'Geoff Clare'; austin-group-l@opengroup.org > Subject: RE: when does PATH search stop? > > > -Original Message- > > From: Geoff Clare [mailto:g...@opengroup.org] > > Sent: Thursday, November 24, 2016 11:32 AM > > To: austin-group-l@opengroup.org > > Subject: Re: when does PATH search stop? > > > > Mark Galeck wrote, on 24 Nov 2016: > > > > > > >There is no precise definition of "acceptable" > > > > > > Yes currently there isn't , but it would be easy to make such a > > > definition, simply, for various failure errno numbers (which are > > > enumerated in the standard), say "acceptable", "not acceptable", or > > > perhaps "unspecified". > > My understanding of the problem is that some shells seem to base their > decision only on a file's executable permission bits and not whether > the file can actually be loaded by exec*(). > > However, I would argue that non-directory files that have the > executable bit set but that cannot be loaded by exec*() are mis- > configured -- perhaps this needs to be stated somewhere. Upon further reflection, the above is wrong: the POSIX shell will attempt to run any file that cannot be loaded by exec*() as a script in a sub-shell. The result of the sub-shell is taken as the new $?. Hence, a file is executable by the shell iff the appropriate executable permission bits are set.
RE: when does PATH search stop?
> -Original Message- > From: Geoff Clare [mailto:g...@opengroup.org] > Sent: Thursday, November 24, 2016 11:32 AM > To: austin-group-l@opengroup.org > Subject: Re: when does PATH search stop? > > Mark Galeck wrote, on 24 Nov 2016: > > > > >There is no precise definition of "acceptable" > > > > Yes currently there isn't , but it would be easy to make such a > > definition, simply, for various failure errno numbers (which are > > enumerated in the standard), say "acceptable", "not acceptable", or > > perhaps "unspecified". > > > > I really don't see the need for the standard to spell this out in such > detail. > > When it says "a regular file acceptable as a new process image file", > it should be obvious that it means the file contents can be used by > exec*() to create a new process image. The only error numbers listed > for exec*() that relate to file contents are EINVAL and ENOEXEC. My understanding of the problem is that some shells seem to base their decision only on a file's executable permission bits and not whether the file can actually be loaded by exec*(). However, I would argue that non-directory files that have the executable bit set but that cannot be loaded by exec*() are mis-configured -- perhaps this needs to be stated somewhere.
Re: when does PATH search stop?
Mark Galeck wrote, on 24 Nov 2016: > > >There is no precise definition of "acceptable" > > Yes currently there isn't , but it would be easy to make such a > definition, simply, for various failure errno numbers (which are > enumerated in the standard), say "acceptable", "not acceptable", or > perhaps "unspecified". > I really don't see the need for the standard to spell this out in such detail. When it says "a regular file acceptable as a new process image file", it should be obvious that it means the file contents can be used by exec*() to create a new process image. The only error numbers listed for exec*() that relate to file contents are EINVAL and ENOEXEC. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: when does PATH search stop?
shwares...@aol.com wrote: > 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. You did not write something different than I did this is why I was confused to read that you have been confused. BTW: The Bourne Shell resets all existing hashes in case that PATH is changed. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: when does PATH search stop?
yes, the easy definition is acceptable does not produce any errors at all, no exceptions, when sufficient machine resources are available. This is not precise as to the metadata necessary to indicate which resources there needs to be sufficient amounts of, and which parts of a file are code or data. The standard only requires a serial port capable of supporting the general terminal interface and a file system be provided as non-RAM resources. Everything else is optional, and other standards define which metadata needs to be accommodated during the linking phases for those options. The file system can consist of only a RAM disk too, populated at boot from an otherwise hidden ROM with the standard utilities and data files they use, so even a hard drive is not required. Neither is a clock, as this can be emulated in software. I expect Issue 8 to only require as an additional 'device' a graphics page buffer, to support Unicode compositing. It's in quotes because something like this can be emulated in RAM also, so no additional hardware will be necessary. On Thursday, November 24, 2016 Mark Galeck wrote: >There is no precise definition of "acceptable" Yes currently there isn't , but it would be easy to make such a definition, simply, for various failure errno numbers (which are enumerated in the standard), say "acceptable", "not acceptable", or perhaps "unspecified".
Re: when does PATH search stop?
Mark Galeck wrote: > >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. > > > > Is that a problem in the standard, that in the definition of Executable File: > > "A regular file acceptable as a new process image file by the equivalent of > the exec family (...)" The background needs to be known: The standard does not intend to make existing implementations illegal. BTW: The checks done while doing the path search in the shell catch all cases except the ENOEXEC case. Even ENOEXEC may just indicate: "This is a shell script". Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: when does PATH search stop?
>There is no precise definition of "acceptable" Yes currently there isn't , but it would be easy to make such a definition, simply, for various failure errno numbers (which are enumerated in the standard), say "acceptable", "not acceptable", or perhaps "unspecified".
Re: when does PATH search stop?
There is no precise definition of "acceptable", effectively. It's tied into the requirements specific processors or platforms have on where code and data can be placed in memory, which is outside C's and POSIX's scope. Most systems elect to localize all the (gory) details of creating an acceptable file in a separate linker application, using a metadata format like OMF or ELF as source, not put it in the C or other compilers. In a message dated 11/23/2016 8:06:58 P.M. Eastern Standard Time, mark_gal...@pacbell.net writes: >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. Is that a problem in the standard, that in the definition of Executable File: "A regular file acceptable as a new process image file by the equivalent of the exec family (...)" "acceptable" is not precisely defined? Should I report this?
Re: when does PATH search stop?
Yes, that's what's in XBD 3. The phrasing in XCU 2 should be "application file named by the command token" more than "executable file" so scripts aren't excluded, imo, as applications are scripts or code. Any file can have its X bit set, though. It's up to the loader exec() uses, internal or host provided, to determine if the contents are actual code or not. It's an administrative issue if scripts and code are marked with the X bit, or just code. A script does not need it's X bit set, it just has to be readable. The shell has to cope with all 4 possibilities: code with RxX, code with -xX, script with Rx-, and script with RxX; where x is don't care about W bit. Second point is not a contradiction, 126 is for 'found but can't load', which can apply to scripts also if there's insufficient RAM to fork the subshell, as a pseudo-load; 127 is for 'can't find to load'. As to the errors mentioned, that's lumped into "depending on failure type". I was trying to keep it short so didn't put up a roster of all the possibilities. Stuff like ENAMETOOLONG or ELOOP is can't find, so search continues, ENOMEM would be can't load, so search stops. A race condition between cached data and a failing device could be construed as either, so is grey area. Some may prefer search continues, so a backup directory later on path can satisfy the search, some may prefer it gets reported and search stops. In a message dated 11/23/2016 7:59:05 P.M. Eastern Standard Time, mark_gal...@pacbell.net writes: >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. I beg your pardon, but the standard defines 'executable file' differently: A regular file acceptable as a new process image file by the equivalent of the exec family of functions This cannot possibly merely mean any of the conditions that you can figure out by 'stat', like the ones you mention. If that were so, the standard would not mention the exec... functions at all, it would just say, check the stat bits so-and-so. >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. Now you seem to be contradicting yourself from what I quoted previously - now you seem to say, that 'executable' does involve actually trying to exec...(). About the "only grey area" - what if the exec... function fails with ELOOP ? ENAMETOOLONG ? ENOMEM ? Do we continue the PATH search or do we error? I checked ELOOP, both bash and dash, continue the search.
Re: when does PATH search stop?
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, joerg.schill...@fokus.fraunhofer.de writes: Shware Systems 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:jo...@schily.net (home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
Re: when does PATH search stop?
>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. Is that a problem in the standard, that in the definition of Executable File: "A regular file acceptable as a new process image file by the equivalent of the exec family (...)" "acceptable" is not precisely defined? Should I report this?
Re: when does PATH search stop?
>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. I beg your pardon, but the standard defines 'executable file' differently: A regular file acceptable as a new process image file by the equivalent of the exec family of functions This cannot possibly merely mean any of the conditions that you can figure out by 'stat', like the ones you mention. If that were so, the standard would not mention the exec... functions at all, it would just say, check the stat bits so-and-so. >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. Now you seem to be contradicting yourself from what I quoted previously - now you seem to say, that 'executable' does involve actually trying to exec...(). About the "only grey area" - what if the exec... function fails with ELOOP ? ENAMETOOLONG ? ENOMEM ? Do we continue the PATH search or do we error? I checked ELOOP, both bash and dash, continue the search.
Re: when does PATH search stop?
Shware Systems 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 priveleged 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:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
Re: when does PATH search stop?
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 priveleged 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. On Wednesday, November 23, 2016 Mark Galeck wrote: I am sorry, this is confusing to me. > "The list shall be searched from beginning to end, applying the filename to > each prefix, until an executable file with the specified name and appropriate > execution permissions is found". >Shells without PATH hashing usually just test all possible PATHs by calling exec() and stop when they reached the end of the PATH list or when the exec() succeeded. The error code is usually the last encountered error. Why would this be compatible with the standard? The standard clearly says, that not only must a file be an executable, which means " A regular file acceptable as a new process image file by the equivalent of the exec family of functions" but also, to have appropriate permissions for the user. >The Bourne Shell introduced a PATH hash mechanism and behaves a bit different: >It checks all possible path names via stat() and remembers the first path name that is not a directory and that is executable for the shell user. The later is checked by calling EUID access(), in modern systems this is: faccessat(AT_FDCWD, name, X_OK, AT_EACCESS) >This method has a minor problem: it cannot detect whether a binary file containes executable code for a different CPU platform. So if you have such a file in your PATH before the expected binary, the expected binary will not be found. >As you see, this is still compatible with the standard text ;-) Why does this have anything to do with PATH hashing? Why is this method compatible? As you point out yourself, it merely checks permissions (by faccessat), but it does not check that the file is "executable" (acceptable for exec...() ), so why would it be compatible? What is the precise meaning of "acceptable"? That under some circumstances, it is possible for an exec... function to succeed on this file? What if the file fails, but with a different name, it might succeed - is it "acceptable"?
Re: when does PATH search stop?
I am sorry, this is confusing to me. > "The list shall be searched from beginning to end, applying the filename to > each prefix, until an executable file with the specified name and appropriate > execution permissions is found". >Shells without PATH hashing usually just test all possible PATHs by calling exec() and stop when they reached the end of the PATH list or when the exec() succeeded. The error code is usually the last encountered error. Why would this be compatible with the standard? The standard clearly says, that not only must a file be an executable, which means " A regular file acceptable as a new process image file by the equivalent of the exec family of functions" but also, to have appropriate permissions for the user. >The Bourne Shell introduced a PATH hash mechanism and behaves a bit different: >It checks all possible path names via stat() and remembers the first path name that is not a directory and that is executable for the shell user. The later is checked by calling EUID access(), in modern systems this is: faccessat(AT_FDCWD, name, X_OK, AT_EACCESS) >This method has a minor problem: it cannot detect whether a binary file containes executable code for a different CPU platform. So if you have such a file in your PATH before the expected binary, the expected binary will not be found. >As you see, this is still compatible with the standard text ;-) Why does this have anything to do with PATH hashing? Why is this method compatible? As you point out yourself, it merely checks permissions (by faccessat), but it does not check that the file is "executable" (acceptable for exec...() ), so why would it be compatible? What is the precise meaning of "acceptable"? That under some circumstances, it is possible for an exec... function to succeed on this file? What if the file fails, but with a different name, it might succeed - is it "acceptable"?
Re: when does PATH search stop?
Mark Galeck wrote: > Hello, > the shell standard section on Command Search and Execution, says > command shall be searched for using the PATH environment variable as > described in XBD Environment Variables > and that section says the value of PATH is split into a list and > "The list shall be searched from beginning to end, applying the filename to > each prefix, until an executable file with the specified name and appropriate > execution permissions is found". Shells without PATH hashing usually just test all possible PATHs by calling exec() and stop when they reached the end of the PATH list or when the exec() succeeded. The error code is usually the last encountered error. The Bourne Shell introduced a PATH hash mechanism and behaves a bit different: It checks all possible path names via stat() and remembers the first path name that is not a directory and that is executable for the shell user. The later is checked by calling EUID access(), in modern systems this is: faccessat(AT_FDCWD, name, X_OK, AT_EACCESS) This method has a minor problem: it cannot detect whether a binary file containes executable code for a different CPU platform. So if you have such a file in your PATH before the expected binary, the expected binary will not be found. As you see, this is still compatible with the standard text ;-) Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
Re: when does PATH search stop?
Yes, thank you, alternative 3, I was wrong.
Re: when does PATH search stop?
On 11/21/16 11:32 PM, Mark Galeck wrote: > "The list shall be searched from beginning to end, applying the filename to > each prefix, until an executable file with the specified name and > appropriate execution permissions is found". > > Well, that is not how both dash and bash behave. They do not search until > an exec file with appropriate permissions is found. They stop when a > regular file or a symlink is found. Then, if that does not refer to an > executable with correct permissions, they do not continue but issue an error. > That's not quite true. If bash searches for a name using $PATH, it will prefer a file with the execute bits set even if there is a file without the execute bits set earlier in the $PATH. It will report a non-executable error only there is no other file found via the $PATH search. You can test this by creating a file named 'ls' in, say, $HOME/bin, adding $HOME/bin to the beginning of $PATH, and running `bash -c 'ls''. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
when does PATH search stop?
Hello, the shell standard section on Command Search and Execution, says command shall be searched for using the PATH environment variable as described in XBD Environment Variables and that section says the value of PATH is split into a list and "The list shall be searched from beginning to end, applying the filename to each prefix, until an executable file with the specified name and appropriate execution permissions is found". Well, that is not how both dash and bash behave. They do not search until an exec file with appropriate permissions is found. They stop when a regular file or a symlink is found. Then, if that does not refer to an executable with correct permissions, they do not continue but issue an error. Is the standard wrong, are bash and dash wrong or am I wrong? Thank you, Mark
