On 3/7/17 7:23 AM, Stephane Chazelas wrote:
> See also:
>
> $ POSIXLY_CORRECT=1 bash -c 'set +o posix; set +o' | grep posix
> set +o posix
> $ POSIXLY_CORRECT=1 bash +o posix -c 'set +o' | grep posix
> set -o posix
>
> (not a regression, already in 4.3)
>
> I'd expect explicit command line opti
2017-03-03 08:27:03 -0500, Chet Ramey:
> On 3/1/17 4:58 PM, Stephane Chazelas wrote:
>
> > BTW, there seems to have been a regression in the handling of the -O
> > option to the bash interpreter:
>
> Thanks, I'll take a look. It looks to be specific to the various
> compat* options.
[...]
See a
2017-03-01 09:49:52 -0500, Chet Ramey:
[...]
> > Would you recommend people start adding:
> >
> > shopt -s compat44 2> /dev/null || true
> >
> > at the start of their script that they develop for bash-4.4 now
> > so that it still works even when bash-6.0 makes a non-backward
> > compatible change
On 3/1/17 12:06 PM, Greg Wooledge wrote:
> The purpose of the compat options is that you, as the script writer,
> right now, can write and test and deploy your script on a specific
> version of bash. Once you know that your script works on this version
> of bash (say, 4.4) you can set the compat
On 3/1/17 11:48 AM, L A Walsh wrote:
> But the way it is now -- if someone is using a compat option
> for an earlier version, and now needs another compat option
> for some other incompat, then they have a problem. I'm
> fairly sure that wasn't by design, as the compat options seem
> to have been
On Wed, Mar 01, 2017 at 08:48:20AM -0800, L A Walsh wrote:
> Chet Ramey wrote:
> >Compatibiity options are all mutually exclusive, last one wins.
> ---
> But the way it is now -- if someone is using a compat option
> for an earlier version, and now needs another compat option
> for some other incom
Chet Ramey wrote:
On 3/1/17 7:43 AM, Stephane Chazelas wrote:
It's not clear what combining several
compat options could do. For instance with shopt -s compat31
compat43 would not be compatible with bash-4.3 in that the [[ =~
]] operator would work the bash-3.1 way. That could cause
confusion
On 3/1/17 7:43 AM, Stephane Chazelas wrote:
> 2017-02-28 16:18:05 -0500, Chet Ramey:
> [...]
>>> Just my personal opinion, but I think I'd rather the spec had
>>> been updated to accomodate the bash (and many other shells)
>>> behaviour rather than bash breaking its backward compatibility
>>> to co
2017-02-28 16:18:05 -0500, Chet Ramey:
[...]
> > Just my personal opinion, but I think I'd rather the spec had
> > been updated to accomodate the bash (and many other shells)
> > behaviour rather than bash breaking its backward compatibility
> > to comply to a requirement that is not particularly u
On 2/28/17 3:10 PM, Stephane Chazelas wrote:
> There was a related discussion on the Austin group mailing list
> back in May last year:
>
> http://permalink.gmane.org/gmane.comp.standards.posix.austin.general/12614
>
> Just my personal opinion, but I think I'd rather the spec had
> been updated
2017-02-28 19:43:11 +0100, tarot:
> Gr! it is not a bug!!!
>
>
> xx. Fixed a bug that could allow `break' or `continue' executed from shell
> functions to affect loops running outside of the function.
>
> My BIG script doesn't work with bash-4.4
>
There was a related discussion on
11 matches
Mail list logo
