Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-29 Thread Alan Coopersmith
On 05/29/17 01:56 PM, Joerg Schilling wrote: Alan Coopersmith wrote: We still ship a couple closed source shells in Solaris - the SVR4 Bourne Shell as /usr/sunos/bin/sh and a modified ksh88 as /usr/xpg4/bin/sh, but our primary day to day shells are the common open source ones - bash, ksh93, zs

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-29 Thread Joerg Schilling
Alan Coopersmith wrote: > We still ship a couple closed source shells in Solaris - the SVR4 Bourne Shell > as /usr/sunos/bin/sh and a modified ksh88 as /usr/xpg4/bin/sh, but our primary > day to day shells are the common open source ones - bash, ksh93, zsh, etc. Is there any bugfix in /usr/sunos

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-29 Thread Alan Coopersmith
On 05/29/17 04:37 AM, Robert Elz wrote: There is no requirement that you, or I, or anyone else in particular, be able to build and run any particular shell. While that's nice if possible, a shell is still a shell even if its source code is not openly available at all (like any that are in close

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-29 Thread Joerg Schilling
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 subshell, but y

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-29 Thread Robert Elz
Date:Mon, 29 May 2017 14:38:02 +0200 From:Joerg Schilling Message-ID: <592c162a.syoz+dozzpogtqep%joerg.schill...@fokus.fraunhofer.de> | The problem is that I have a FreeBSD system available for testing, | but not a NetBSD system... It is fairly easy to set up Net

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-29 Thread Joerg Schilling
Robert Elz wrote: > Date:Mon, 29 May 2017 11:47:04 +0200 > From:Joerg Schilling > Message-ID: > <592bee18.kvZiYpLd6LS/Evf/%joerg.schill...@fokus.fraunhofer.de> > > | If the related shells would be available as portable code, > | it would be easy to test them. >

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-29 Thread Robert Elz
Date:Mon, 29 May 2017 11:47:04 +0200 From:Joerg Schilling Message-ID: <592bee18.kvZiYpLd6LS/Evf/%joerg.schill...@fokus.fraunhofer.de> | If the related shells would be available as portable code, | it would be easy to test them. There is no requirement that you, o

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-29 Thread Joerg Schilling
Robert Elz wrote: > | It also would make sense to check with shells have maintainers > | that are on this list and willing to come to a common agreement. > > Neither were on your list, but the FreeBSD shell and NetBSD shell maintainers > are here too... If the related shells would be availab

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-29 Thread Joerg Schilling
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"

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Robert Elz
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

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Joerg Schilling
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"

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Robert Elz
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.

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Joerg Schilling
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

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Chet Ramey
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

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Stephane CHAZELAS
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; {

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Dan Kegel
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

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Joerg Schilling
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 >

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread 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; { a=2; } < /dev/null; echo "$a"' > > 1 > > > > Again 2 required b

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Stephane CHAZELAS
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

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Joerg Schilling
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

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Stephane CHAZELAS
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

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Joerg Schilling
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

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Joerg Schilling
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 (

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Stephane CHAZELAS
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

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Vincent Lefevre
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

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread 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 shell. > [...] > > Sorry, I meant "bosh", not "posh" above. Well

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread 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 posh is pdksh with a few fixes and most > ksh extension

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Stephane Chazelas
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

What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Stephane Chazelas
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