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 b
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 PAT
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
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
>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 t
>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 equivalen
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.
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 o
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 acc
>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".
10 matches
Mail list logo
