A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=767
==
Reported By:dwheeler
Assigned To:ajosey
Date:Wed, 24 May 2017 20:51:25 +0200
From:Joerg Schilling
Message-ID: <5925d62d.mr6gk0tc0ybr6h6k%joerg.schill...@fokus.fraunhofer.de>
| The problem would be if there is deviating behavior only between the shells
| that are closer to POSIX and yash/posh, it may b
Robert Elz wrote:
> To get away from the dick waving "my shell is bigger than yours"
> discussions for a minute ...
>
> In note 3745 attached to http://austingroupbugs.net/view.php?id=767
> Joerg Schilling proposes making a list of shells to use to help
> guide what can be regarded as "standard"
To get away from the dick waving "my shell is bigger than yours"
discussions for a minute ...
In note 3745 attached to http://austingroupbugs.net/view.php?id=767
Joerg Schilling proposes making a list of shells to use to help
guide what can be regarded as "standard" for the purposes of compliance.
Date:Wed, 24 May 2017 15:40:07 +0200
From:Joerg Schilling
Message-ID: <59258d37.h5t6p4p9cd52ubz7%joerg.schill...@fokus.fraunhofer.de>
| If you later assign a value to that variable, the "export FOO"
| command just sets up the export property but does not put the
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=767
==
Reported By:dwheeler
Assigned To:ajosey
Stephane CHAZELAS wrote:
> > > > $ ./sh -o posix -c 'a=1; { a=2; } < /dev/null; echo "$a"'
> > > > 1
> > > >
> > > > Again 2 required by POSIX.
> >
> > Do you have a pointer to the POSIX text that forbids a subshell in this
> > case
> > when stdin is redirected?
> [...]
>
> I don't know if you
On 5/24/17 11:40 AM, Stephane CHAZELAS wrote:
> 2017-05-24 17:21:33 +0200, Joerg Schilling:
>> Do you have a pointer to the POSIX text that forbids a subshell in this case
>> when stdin is redirected?
> [...]
>
> I don't know if you'll find some text that *explicitly* forbids
> it to run in a su
Stephane CHAZELAS wrote:
> 2017-05-24 17:15:25 +0200, Joerg Schilling:
> > Stephane CHAZELAS wrote:
> [...]
> > > $ a=1 ./sh -o posix -c 'a=2; printenv a'
> > > 1
> > >
> > > POSIX requires 2 to be output there (assuming printenv a command
> > > to print the value of a given environment variable
2017-05-24 17:21:33 +0200, Joerg Schilling:
> Joerg Schilling wrote:
>
> > I did not change the Bourne Shell behavior as I believe that the
> > export behavior is compatibile with POSIX and as this behavior is more
> > useful
> > than what other shells do.
> >
> > > $ ./sh -o posix -c 'a=1; {
On Wed, May 24, 2017 at 8:15 AM, Joerg Schilling
wrote:
>> $ a=1 ./sh -o posix -c 'a=2; printenv a'
>> 1
>>
>> POSIX requires 2 to be output there (assuming printenv a command
>> to print the value of a given environment variable).
>
> Do you have a pointer to the related text?
I write scripts ev
2017-05-24 17:15:25 +0200, Joerg Schilling:
> Stephane CHAZELAS wrote:
[...]
> > $ a=1 ./sh -o posix -c 'a=2; printenv a'
> > 1
> >
> > POSIX requires 2 to be output there (assuming printenv a command
> > to print the value of a given environment variable).
>
> Do you have a pointer to the relate
Stephane CHAZELAS wrote:
> > > ZSH_EMULATION=sh CONFIG_SHELL=/usr/bin/zsh /usr/bin/zsh ./configure
> >
> > Ok this is what I get:
> >
> > ZSH_EMULATION=sh CONFIG_SHELL=/usr/bin/zsh /usr/bin/zsh ./configure
> > ./configure:777: no matches found: conftest*
> > creating cache ./config.cache
>
Joerg Schilling wrote:
> I did not change the Bourne Shell behavior as I believe that the
> export behavior is compatibile with POSIX and as this behavior is more useful
> than what other shells do.
>
> > $ ./sh -o posix -c 'a=1; { a=2; } < /dev/null; echo "$a"'
> > 1
> >
> > Again 2 required b
2017-05-24 17:00:25 +0200, Joerg Schilling:
[...]
> > Let's be serious, if "posh" had such a bug it would have been
> > reported long ago and fixed. Presumably, you've compiled
> > it in a such way or on such a system that has never been tested
> > before and triggered a bug.
>
> A shell that does
Stephane CHAZELAS wrote:
> I reported 3 as that was the first 3 I tested:
>
> $ a=1 ./sh -o posix -c 'a=2; printenv a'
> 1
>
> POSIX requires 2 to be output there (assuming printenv a command
> to print the value of a given environment variable).
Do you have a pointer to the related text?
I did
2017-05-24 16:21:05 +0200, Joerg Schilling:
> Stephane Chazelas wrote:
>
> > 2017-05-24 14:48:12 +0100, Stephane Chazelas:
> > [...]
> > > > bash
> > > > bosh
> > >
> > > As discussed, as of the 2017-05-16 release, posh was not POSIX
> > > and still had many of non-conformances of the Bourne she
Stephane CHAZELAS wrote:
> 2017-05-24 16:15:03 +0200, Joerg Schilling:
> > A configure script (if done correctly) is a script with _very_
> > pessimistic assumptions on portability. Given that "posh" completely fails
> > here, makes it unusable for every day work.
>
> Without being more specif
Vincent Lefevre wrote:
> On 2017-05-24 16:15:03 +0200, Joerg Schilling wrote:
> > I have no idea what "posh" targets, but given that:
> >
> > posh
> > $ exit
> > posh: exit: bad number
>
> I can't reproduce this issue:
>
> cventin:~> posh
> $ exit
> cventin:~>
>
> on a Debian/unstable machine (
2017-05-24 16:15:03 +0200, Joerg Schilling:
> Stephane Chazelas wrote:
>
> > If your "configure" script works with "mksh" but not with
> > "posh", I suspect it's because that script is using non-POSIX
> > ksh extensions, as basically mksh is pdksh with a few fixes and
> > extensions added, while
On 2017-05-24 16:15:03 +0200, Joerg Schilling wrote:
> I have no idea what "posh" targets, but given that:
>
> posh
> $ exit
> posh: exit: bad number
I can't reproduce this issue:
cventin:~> posh
$ exit
cventin:~>
on a Debian/unstable machine (posh 0.12.6, 14 Feb 2016, so with
a version from m
Stephane Chazelas wrote:
> 2017-05-24 14:48:12 +0100, Stephane Chazelas:
> [...]
> > > bash
> > > bosh
> >
> > As discussed, as of the 2017-05-16 release, posh was not POSIX
> > and still had many of non-conformances of the Bourne shell.
> [...]
>
> Sorry, I meant "bosh", not "posh" above.
Well
Stephane Chazelas wrote:
> If your "configure" script works with "mksh" but not with
> "posh", I suspect it's because that script is using non-POSIX
> ksh extensions, as basically mksh is pdksh with a few fixes and
> extensions added, while posh is pdksh with a few fixes and most
> ksh extension
2017-05-24 14:48:12 +0100, Stephane Chazelas:
[...]
> > bash
> > bosh
>
> As discussed, as of the 2017-05-16 release, posh was not POSIX
> and still had many of non-conformances of the Bourne shell.
[...]
Sorry, I meant "bosh", not "posh" above.
The bash/posh/bosh trio sounds like it's been espe
2017-05-24 13:02:56 +, Austin Group Bug Tracker:
[...]
> (0003745) joerg (reporter) - 2017-05-24 13:02
> http://austingroupbugs.net/view.php?id=767#c3745
> --
> It seems that we should set up a list of shell implementations
Vincent Lefevre wrote:
> as shown by the following test:
>
>
> #!/bin/sh
>
> unset FOO
> export FOO
>
> echo "FOO='$FOO'"
>
> export -p > temp-file
> unset FOO
> FOO=blah
> . temp-file
>
> echo "FOO='$FOO'"
>
This
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=767
==
Reported By:dwheeler
Assigned To:ajosey
2017-05-24 15:06:59 +0200, Vincent Lefevre:
> It seems that the example for "export" is incorrect:
>
>Save and restore all exported variables:
>
>export −p > temp-file
>unset a lot of variables
>... processing
>. temp-file
>
[...]
One may
2017-05-24 12:59:59 +, Austin Group Bug Tracker:
[...]
> (0003744) kre (reporter) - 2017-05-24 12:59
> http://austingroupbugs.net/view.php?id=767#c3744
> --
> We can always avoid the unset var/func ambiguity by always
> usi
It seems that the example for "export" is incorrect:
Save and restore all exported variables:
export −p > temp-file
unset a lot of variables
... processing
. temp-file
as shown by the following test:
#!/
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=767
==
Reported By:dwheeler
Assigned To:ajosey
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=767
==
Reported By:dwheeler
Assigned To:ajosey
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=767
==
Reported By:dwheeler
Assigned To:ajosey
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=767
==
Reported By:dwheeler
Assigned To:ajosey
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=767
==
Reported By:dwheeler
Assigned To:ajosey
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=767
==
Reported By:dwheeler
Assigned To:ajosey
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=767
==
Reported By:dwheeler
Assigned To:ajosey
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=767
==
Reported By:dwheeler
Assigned To:ajosey
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=767
==
Reported By:dwheeler
Assigned To:ajosey
2017-05-23 23:38:40 +, Austin Group Bug Tracker:
[...]
> My guess (pure guess) would be that it was not specified to allow
> "command"
> but only "compound-command", as allowing "command" that way makes a
> redirect
> at the end of the line ambiguous - just what does that mean, ie: in
>
> f()
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=767
==
Reported By:dwheeler
Assigned To:ajosey
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=767
==
Reported By:dwheeler
Assigned To:ajosey
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1134
==
Reported By:nmav
Assigned To:
=
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=767
==
Reported By:dwheeler
Assigned To:ajosey
44 matches
Mail list logo
