"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() functi
> -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 ci
quot;. 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, 201
"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
--
EM
> -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 s
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
> architect
"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 atte
> -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
> -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
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
> per
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
> slowe
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 d
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 n
>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".
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
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
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.
>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
>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
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
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
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
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
Yes, thank you, alternative 3, I was wrong.
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 n
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,
26 matches
Mail list logo
