strictly posix shell mode ?
Yakov
extensions above posix and make shell strictly posix-compliant
(without any additions).
I found '--posix' flag of bash, but it's something different:
it doesn't seem to disable bash-specific extensions. It
"Changes the behavior of bash where the default operation *differs*
from the POSIX". For example, the ((...)) construct is still
interpreted
with --posix.
So, is there "restrict to posix" flag to bash/ksg/zsh ? (I don't have
ash)
Thanks
Yakov
Jordan Abel
Why do you want this? As long as your script doesn't use extensions,
it'll run just fine with or without them enabled. ...or are you trying
to test your script for posix-compliance by trial and error? don't do
that. that's not the way to write a good script.
Kaz Kylheku
> Why do you want this? As long as your script doesn't use extensions,
> it'll run just fine with or without them enabled. ...or are you trying
> to test your script for posix-compliance by trial and error? don't do
> that. that's not the way to write a good script.
Right! Real Programmers don't need any diagnostics whatsoever. They cat
something from the tty into a file, and it not only runs, but is 100%
standard-conforming. And they are exempt from ever running tools to
find problems in other people's code.
Stephane CHAZELAS
There's no such thing as *a* strictly POSIX shell. POSIX allows
many different behaviors for the shell, and tells the *script*
writer to not rely on this or that behavior of a shell as it is
/unspecified/.
posh (Policy-compliant Ordinary SHell, based on pdksh) is an
attempt at writing a shell with as few extensions as possible.
That's probably the closest you can get for your requirement.
If your script works ok with ksh88, pdksh, ksh93, bash, and zsh
is sh mode and the sh from the *BSDs (ash based POSIX shells),
then it may not be POSIX conformant, but you should be safe (as
far as portability to POSIX shells is concerned as those are
basically the only existing POSIX shell implementations).
--
Stéphane
Jordan Abel
Trial and error isn't the right way to find it.
What if your script uses a _command_ that's not in posix?
Barry Margolin
Jordan Abel <ran...@random.yi.org> wrote:
What's the better way to confirm that a script only uses POSIX shell
features?
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Stephane CHAZELAS
[...]
>> Trial and error isn't the right way to find it.
>
> What's the better way to confirm that a script only uses POSIX shell
> features?
That's not the right question to ask, I'd say.
What's the best way to confirm that a script is POSIX. POSIX
specifies both the shell behavior and also (and actually more
that) how a script should be written. (the script is refered to
as "an application" in POSIX).
I think the only way is to read the POSIX/SUS specification,
and to double check the script with that in hand.
--
Stéphane
Yakov
> 2006-11-1, 13:14(-08), Yakov:
> > I'm looking for the flag (in bash or ksh or zsh) that disables all
> > extensions above posix and make shell strictly posix-compliant
> > (without any additions).
> >
> > I found '--posix' flag of bash, but it's something different:
> > it doesn't seem to disable bash-specific extensions. It
> > "Changes the behavior of bash where the default operation *differs*
> > from the POSIX". For example, the ((...)) construct is still
> > interpreted
> > with --posix.
> >
> > So, is there "restrict to posix" flag to bash/ksg/zsh ? (I don't have
> > ash)
> [...]
>
> attempt at writing a shell with as few extensions as possible.
> That's probably the closest you can get for your requirement.
posh turns out to be the true answer to my question.
Thanks Stéphane, you did it again.
Yakov
Barry Margolin
Stephane CHAZELAS <this.a...@is.invalid> wrote:
And is that the same answer you'd give if someone asked how to check
whether your program has some other type of bug? Just double check it
by reading it?
We can tell all the people writing debuggers, test scripts, checkout
compilers, etc. not to bother, we've been going at this the wrong way
all these years.
Stephane CHAZELAS
[....]
>> That's not the right question to ask, I'd say.
>>
>> What's the best way to confirm that a script is POSIX. POSIX
>> specifies both the shell behavior and also (and actually more
>> that) how a script should be written. (the script is refered to
>> as "an application" in POSIX).
>>
>> I think the only way is to read the POSIX/SUS specification,
>> and to double check the script with that in hand.
>
> And is that the same answer you'd give if someone asked how to check
> whether your program has some other type of bug? Just double check it
> by reading it?
I never said that. What I meant is that there was no tool
available to verify the conformance of a script to POSIX or SUS.
And writing such a tool would reveal a complicate task, given
that the shell syntax is not very rigorous, that it is
an interpreted language (can't use a lint type tool, you need to
execute the script to verify it), that the POSIX and SUS
specifications are subject to interpretations and have plenty of
blur/dark areas.
> We can tell all the people writing debuggers, test scripts, checkout
> compilers, etc. not to bother, we've been going at this the wrong way
> all these years.
--
Stéphane
Kaz Kylheku
But if a program is written to do this, then it is "trial and error".
It's all clear to me now.
Kaz Kylheku
Stephane CHAZELAS wrote:
> 2006-11-02, 08:25(-05), Barry Margolin:
> [....]
> >> That's not the right question to ask, I'd say.
> >>
> >> What's the best way to confirm that a script is POSIX. POSIX
> >> specifies both the shell behavior and also (and actually more
> >> that) how a script should be written. (the script is refered to
> >> as "an application" in POSIX).
> >>
> >> I think the only way is to read the POSIX/SUS specification,
> >> and to double check the script with that in hand.
> >
> > And is that the same answer you'd give if someone asked how to check
> > whether your program has some other type of bug? Just double check it
> > by reading it?
>
> I never said that. What I meant is that there was no tool
> available to verify the conformance of a script to POSIX or SUS.
> And writing such a tool would reveal a complicate task, given
> that the shell syntax is not very rigorous, that it is
> an interpreted language (can't use a lint type tool, you need to
> execute the script to verify it), that the POSIX and SUS
> specifications are subject to interpretations and have plenty of
> blur/dark areas.
None of these arguments consitute an irrefutable objection against
developing or using a tool which catches a subset of all possible
errors.
In the abstract, the output of a checker is a tri-state value: program
bad/nonconforming, program good/conforming, or undecided. The undecided
state exists because of the dynamic aspects of the language: showing
that a program is free of errors runs into the halting problem.
However, just because the "undecided" output exists does not mean that
a checker is incapable of providing value to the developer.
Jordan Abel
Kaz Kylheku wrote:
> None of these arguments consitute an irrefutable objection against
> developing or using a tool which catches a subset of all possible
> errors.
>
> In the abstract, the output of a checker is a tri-state value: program
> bad/nonconforming, program good/conforming, or undecided. The undecided
> state exists because of the dynamic aspects of the language: showing
> that a program is free of errors runs into the halting problem.
>
> However, just because the "undecided" output exists does not mean that
> a checker is incapable of providing value to the developer.
However, _just a shell_ that handles the posix syntax with no extensions
does not have a "program good/conforming" output - it's either bad or
undecided. Which is the same set of outputs you get with trial and error
on any posix-conforming system. I don't see there being much percentage
in slightly widening the subset of inputs with "bad" output without
providing any way to guarantee conformance.