when was shellshock introduced

[Stephane Chazelas]

2014-09-12 15:56:44 -0400, Chet Ramey:
[...]
> Importing exported function definitions was introduced in bash-1.13.
[...]

(bug-bash CCed).

Hi Chet,

I know that in the early day of the discovery, you came to the
conclusion that "shellshock" was introduced in 1.13, mostly my
fault for saying earlier that it was not in 1.05 or in the
ChangeLog while it plainly was.

When asked, you and I ended up spreading the word that it was
introduced in 1.13 and there's now a lot of confusion in the
news and FOSS and security communities around the actual date
the bug was introduced (I've seen 1.03, 1.05, 1.13, 1.14, from the
beginning... Mentioned).

It was then discovered that the feature and vulnerability were
indeed in 1.05 and the ChangeLog in there makes it clear when it
was introduced:

http://www.oldlinux.org/Linux.old/bin/old/bash-1.05/ChangeLog

Fri Sep  1 18:52:08 1989  Brian Fox  (bfox at aurel)

   * readline.c: rl_insert ().  Optimized for large amounts
 of typeahead.  Insert all insertable characters at once.

   * I update this too irregularly.
 Released 1.03.
[...]
Sat Aug  5 08:32:05 1989  Brian Fox  (bfox at aurel)

   * variables.c: make_var_array (), initialize_shell_variables ()
 Added exporting of functions.

(I don't have access to the 1.03 source, but I've no reason to
beleive it was any different than 1,05).


Some discussions in gnu.bash.bug and comp.unix.questions (that
one by you) around that time also mention the new feature.
https://groups.google.com/d/msg/gnu.bash.bug/72jXoIWYsfE/jJqC-fjSh0wJ
https://groups.google.com/d/msg/comp.unix.questions/LwsdchovzFY/qokUr2mfCboJ

More at:
http://thread.gmane.org/gmane.comp.security.oss.general/14177/focus=14181
http://www.dwheeler.com/essays/shellshock.html#timeline
http://thread.gmane.org/gmane.comp.security.oss.general/14177/focus=14190
http://unix.stackexchange.com/questions/157381/when-was-the-shellshock-cve-2014-6271-7169-bug-introduced-and-what-is-the-pat/157495#157495
https://twitter.com/SChazelas/status/518316463225315328

The WikiPedia entry
http://en.wikipedia.org/wiki/Shellshock_%28software_bug%29
got corrected at some point but then reverted for lack of
"authoritative" information (not
http://en.wikipedia.org/wiki/Bash_%28Unix_shell%29 though).

For the sake of correctness, would you mind confirming here that
the bug and feature were indeed introduced in August 1989 and
first released in 1.03 in September that same year, so WikiPedia
can have an "authoritative" source of information?

Thanks,
Stephane

Re: Random loss of bash history

[Linda Walsh]

Your ironic stance won't help your case.
Especially when what you describe is not true, 0 in 4.2 means 0.


FWIW, in the 4.3 README, under differences from 4.2:

n.  Setting HISTSIZE to a value less than zero causes the history list to be
unlimited (setting it 0 zero disables the history list).

o.  Setting HISTFILESIZE to a value less than zero causes the history file size
to be unlimited (setting it to 0 causes the history file to be truncated
to zero size).

---
and that's why user's should be wary of reading release notes! ;-)

Re: Random loss of bash history

[Linda Walsh]

I stand corrected... this isn't new.  Still
when such numbers often mean unlimited and negative
ones are invalid, I see little or no utility in
truncating someone's histfile to 0.  If someone wanted
to delete it, they would.   Defaulting to truncation behavior
on changing those controls to '0', serves little purpose
other than to potentially wipe someone's history and keep
it disabled -- when if that's really what they wanted, the'd
just turn the option off.

So, it's not a brilliant NEW feature.  It's a brilliant
design.  Period.

Happier?

(Sitting corrected...;-) )


Pierre Gaston wrote:



On Fri, Oct 10, 2014 at 11:40 AM, Linda Walsh > wrote:


You DID read the release notes and changes from 4.2->4.3.

Someone had the bright idea that .. in 4.2, '0' meant no limit in
history (in bash and readline)... but in 4.3, '0' means 0 and throw
away history while negative values mean keep it all.

Perhaps you were hit by this brilliant new feature -- no doubt
a new POSIX blessing.


Your ironic stance won't help your case.
Especially when what you describe is not true, 0 in 4.2 means 0.

$ HISTSIZE=10
$ echo $BASH_VERSION
4.2.53(1)-release
$ history
  999  PS1=\$\
 1000  HIST_SIZE=10
 1001  echo $BASH_VERSION
 1002  history
$ HISTSIZE=0
$ history
$

Re: Cannot build bash-4.2 with Patch 53

[Chet Ramey]

On 10/10/14, 2:02 PM, TODD TRIMMER wrote:
> You're right. The y.tab.[ch] files never got rebuilt. They still had the
> same timestamps from the base archive of 4.2. Renaming them forced a
> rebuild, which had significant diffs. Is there a flag that can be sent to
> configure or make to force a rebuild? BTW, bison was already installed.

The idea is that make does the work for you.  parse.y has a newer timestamp
than y.tab.c; y.tab.c depends on parse.y; make rebuilds y.tab.c by running
bison on parse.y.  It worked correctly on the machines I tested on.

Chet


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Cannot build bash-4.2 with Patch 53

[TODD TRIMMER]

You're right. The y.tab.[ch] files never got rebuilt. They still had the
same timestamps from the base archive of 4.2. Renaming them forced a
rebuild, which had significant diffs. Is there a flag that can be sent to
configure or make to force a rebuild? BTW, bison was already installed.

On Thu, Oct 9, 2014 at 11:47 PM, Steve Simmons  wrote:

>
> On Oct 9, 2014, at 9:34 PM, TODD TRIMMER  wrote:
>
> > If I compile from bash-4.2 from source, cumulatively applying patches
> through 52, things work fine. If I start from scratch and apply through 53,
> it errors out:
> >
> > gcc -L.. . .
> > ./builtins/libbuiltins.a(evalstring.o): In function `parse_and_execute':
> > /home/ttrimmer/depot/ext/bash/patch/src/builtins/evalstring.c:274:
> undefined reference to `parser_remaining_input'
> > collect2: ld returned 1 exit status
> > make: *** [bash] Error 1
> >
> >
> > I can see parser_remaining_input patched in parse.y and
> builtins/evalstring.c. However, it will not compile.
>
> Sounds like y.tab.[ch] never got (re)built from parse.y. Try renaming them
> to -old and give the 'make' command again. If you don't have yacc or bison,
> that'll fail. Get and install bison and try again.

Re: [RFC] Logically composable variant of errexit

[Ángel González]

On Andreas Grünbacher wrote:
> With errexit, you get vastly different results from functions depending
> on how the functions are called, for example,
> 
>foo() {
>   echo "foo: top"
>   false
>   echo "foo: bottom"
>}
> 
>set -o errexit
> 
># bottom of foo reached:
> if foo; then
>   echo "success"  # reached
>fi
> 
># bottom of foo not reached:
>foo
> 
> With errfail, "foo:bottom" and "success" would not be reached.

I disagree. IMHO the function should have the errfail value of its
parent scope at the time of its definition.

Otherwise, a function expecting to ignore errors would mysteriously fail
in a script that set -o errexit, unaware that one of the commands it
calls is [shadowed by] a function.

Thus, you would have to put the set at the top for the behavior you expected.


> Command substitutions would continue to behave as basic commands
> do with respect to control flow: inside functions, a failure would cause
> the function to return; outside of functions, the script would exit.

+1

Re: Testing for Shellshock ... combinatorics and latest(Shellshock) Bash Vulnerability...(attn: Chet Ramey)

[Stephane Chazelas]

2014-10-10 09:04:10 -0600, Eric Blake:
> On 10/10/2014 08:55 AM, Stephane Chazelas wrote:
> 
> > But I can't see why the content of a variable should be
> > interpreted as anything else than an arithmetic expression just
> > because it's in an array subscript.
> 
> For the record, there are vulnerable shell scripts in the wild that fail
> to sanitize their inputs before passing it through arithmetic expansion,
> all because MULTIPLE shells (bash, ksh, mksh, zsh) all have the same
> semantic decision of performing command substitution as part of
> arithmetic expansion.  For example:
> 
> $ /usr/sbin/fsadm -n resize /dev/sdb '0+x[`id >/dev/tty`]T'
> 
> demonstrates that fsadm is vulnerable for trying to do $(($1)) without
> sanitizing $1 first.
[...]

In this case though, it would still be vulnerable with a
strictly POSIX shell as with

/usr/sbin/fsadm -n resize /dev/sdb 'PATH=1'

The evaluation of $(($1)) when $1 is 'PATH=1' is required to
assign 1 to PATH.

What is unspecified by POSIX is:

var=PATH=1; : $((var))

so changing the shell so it no longer does assignments and other
expansions upon indirect/nested/recursive arithmetic evaluation
would not break POSIX compliance (so could be done by
ksh/bash/zsh when invoked as sh), but you'd still have a problem
if you did:

var=PATH=1; : $(($var))

But at least in that case, it's more obvious that you need to
sanitize the input.

-- 
Stephane

Re: Testing for Shellshock ... combinatorics and latest(Shellshock) Bash Vulnerability...(attn: Chet Ramey)

[Eric Blake]

On 10/10/2014 08:55 AM, Stephane Chazelas wrote:

> But I can't see why the content of a variable should be
> interpreted as anything else than an arithmetic expression just
> because it's in an array subscript.

For the record, there are vulnerable shell scripts in the wild that fail
to sanitize their inputs before passing it through arithmetic expansion,
all because MULTIPLE shells (bash, ksh, mksh, zsh) all have the same
semantic decision of performing command substitution as part of
arithmetic expansion.  For example:

$ /usr/sbin/fsadm -n resize /dev/sdb '0+x[`id >/dev/tty`]T'

demonstrates that fsadm is vulnerable for trying to do $(($1)) without
sanitizing $1 first.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Testing for Shellshock ... combinatorics and latest(Shellshock) Bash Vulnerability...(attn: Chet Ramey)

[Stephane Chazelas]

2014-10-10 10:17:40 -0400, Chet Ramey:
[...]
> > bash -c '(( XDG_VTNR < 7 ))
> > 
> > That allows arbitrary code execution (and can't easily be
> > fixed without breaking backward compatibility).
> > 
> > Try with "export XDG_VTNR='a[$(echo>&2 vulnerable)]'".
> 
> Sure, and that's documented, intended, and not unique.
[...]

Is it really intended and documented that cmdsubst be performed
there?

AFAICT, it's not useful and not consistent.

a='$(echo 1+1)' bash -c 'echo $((a))'

Doesn't work. So why would these work

a='b[$(echo 1+1)]' bash -c 'echo $((a))
Or
a='$(echo 1+1)' bash -c 'echo $((b[a]))'

then? Where is it documented that variable, arithmetic, command, tilde and
process substitution are performed in array subscripts in indirectly
evaluated arithmetic expressions?

I can accept:

echo $((a[$(echo 1+1)]))
or:
a[$(echo 1+1)]=2

being accepted intentionaly.

But I can't see why the content of a variable should be
interpreted as anything else than an arithmetic expression just
because it's in an array subscript.

-- 
Stephane

Re: CVE-2014-7187

[Eric Blake]

On 10/10/2014 08:00 AM, Nabiałek, Wojciech wrote:

> 
> This code is not mine, refer to: 
> http://stevejenkins.com/blog/2014/09/how-to-manually-update-bash-to-patch-shellshock-bug-on-older-fedora-based-systems/
>  Exploit 5. 

That blog is wrong.  Here's how you test if your shell is vulnerable:

probe='() { echo vulnerable; }' bash -c probe

If that outputs:

bash: probe: command not found

your shell is secure (and bash 4.3.30 has this behavior).  If it outputs:

vulnerable

then your shell still needs a patch.  Remember, bash 4.3.27 was THE
patch that matters.  There were six patches in a row, five of them (25,
26, 28, 29, and 30) addressed 6 different parser bugs (all 6 of which
were assigned a CVE number), but none of those five solve the
vulnerability.  ONLY patch 27 (the one with no corresponding CVE)
actually solves the vulnerability.  The vulnerability was that attackers
could abuse the contents of environment variables to cause the parser to
be executed when it should not be.

Some of the sites purporting to have tests for the various
vulnerabilities are confusing the two issues - there's a difference
between a parser bug (and we've patched 6 of them so far) and an
exploitable vulnerability (a single patch solved that, AND prevents even
yet-to-be-discovered parser bugs from also being vulnerabilities).  In
particular, the code you quoted did not have ANY mention of an
environment variable; therefore, it CANNOT be testing the vulnerability,
only whether a parser bug is present.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: CVE-2014-7187

[Chet Ramey]

On 10/10/14, 10:00 AM, Nabiałek, Wojciech wrote:

> [root@e-mail wojtek]# (for x in {1..200} ; do echo "for x$x in ; do :"; done; 
> for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 
> vulnerable, word_lineno"
> bash: line 2: `x{1..200}': not a valid identifier
> CVE-2014-7187 vulnerable, word_lineno

Yeah, that's a flawed test.  I'm sure the author never thought that the
test would be run by a shell that didn't implement brace expansion, but
you managed to do it.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Testing for Shellshock ... combinatorics and latest(Shellshock) Bash Vulnerability...(attn: Chet Ramey)

[Chet Ramey]

On 10/10/14, 5:40 AM, Stephane Chazelas wrote:
> 2014-10-09 21:35:09 -0400, Chet Ramey:
>> On 10/9/14, 6:06 PM, Pádraig Brady wrote:
>>> On 10/09/2014 08:46 PM, Rick Karcich (rkarcich) wrote:
 Hello Chet,

 Re: testing for Shellshock...  would like your feedback... specifically, 
 regarding the possibility of human-directed combinatorial testing to find 
 this Bash vulnerability...
>>>
>>> Sounds like how Michal Zalewski found the related CVE-2014-6278
>>> http://lcamtuf.blogspot.ie/2014/10/bash-bug-how-we-finally-cracked.html
>>
>> That's a promising approach.  I asked Michal to continue running the fuzzer
>> against the patched, but he did not respond to that yet.
> [...]
> 
> What's the point? That would be wasted effort IMO.

It depends on your goals.

> Who cares if bash does something unexpected on incorrect input as
> long as it's not exploitable?

I do, if it can cause a crash.

> The problem here was bash interpreting untrusted input. That has
> been fixed by stopping the parser from being exposed to
> untrusted input. Now bugs in the parser are only relevant if
> they affect functionality, that is, bash behaving the wrong way
> on valid input (code) and fuzzers are not likely to help much
> there. From that point of view, all the CVEs related to
> shellshock are non-bugs or very insignificant ones once the
> parser is no longer exposed.

I agree that the important thing is that the parser isn't exposed in
the way it was, and that the reports post-patch 27 are simple shell
bugs.  However, I'm interested in shell bugs.

> 
> From a security point of view, there are things in bash and
> other shells that are far more inportant to look at than what it
> does on incorrect code: when it deals with other forms of
> untrusted input.
> 
> One thing  for instance and that also affects some other shells
> are like:
> 
> bash -c '(( XDG_VTNR < 7 ))
> 
> That allows arbitrary code execution (and can't easily be
> fixed without breaking backward compatibility).
> 
> Try with "export XDG_VTNR='a[$(echo>&2 vulnerable)]'".

Sure, and that's documented, intended, and not unique.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: CVE-2014-7187

[Greg Wooledge]

On Fri, Oct 10, 2014 at 02:00:41PM +, Nabia??ek, Wojciech wrote:
> Difference is in version number, mine is 4.3.30(3), your 4.3.30(2)

The number in parentheses is simply how many times Bash has been compiled
in the current source tree.  If you apply a new patch and run "make"
again, the number goes up.  It's not actually a different version.

> [root@e-mail wojtek]# (for x in {1..200} ; do echo "for x$x in ; do :"; done; 
> for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 
> vulnerable, word_lineno"
> bash: line 2: `x{1..200}': not a valid identifier
> CVE-2014-7187 vulnerable, word_lineno

Your interactive shell is not Bash (or it's a very OLD Bash), so the
{1..200} was not expanded.  That's why this test failed.

Run it again from within Bash.

And for god's sake, don't do vulnerability testing as root.

RE: CVE-2014-7187

[Nabiałek , Wojciech]

Thanks for quick reply

Difference is in version number, mine is 4.3.30(3), your 4.3.30(2)

[root@e-mail wojtek]# bash --version
GNU bash, version 4.3.30(3)-release (i686-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[root@e-mail wojtek]# (for x in {1..200} ; do echo "for x$x in ; do :"; done; 
for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 
vulnerable, word_lineno"
bash: line 2: `x{1..200}': not a valid identifier
CVE-2014-7187 vulnerable, word_lineno

This code is not mine, refer to: 
http://stevejenkins.com/blog/2014/09/how-to-manually-update-bash-to-patch-shellshock-bug-on-older-fedora-based-systems/
 Exploit 5. 
The standard version of shellshock was ignored by me as hard to use for real 
remote attack. It was very short time to see I was wrong, so this time I want 
to be sure :)

Regards, Wojtek

-Original Message-
From: Chet Ramey [mailto:chet.ra...@case.edu] 
Sent: Friday, October 10, 2014 3:37 PM
To: Nabiałek, Wojciech; bug-bash@gnu.org
Cc: chet.ra...@case.edu
Subject: Re: CVE-2014-7187

On 10/10/14, 4:03 AM, Nabiałek, Wojciech wrote:
> Hi,
> 
> Bash 4.3 after patch 30 is still vulnerable for shellshock CVE-2014-7187.

No, it's not.

> (for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; 
> do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"

I'm curious about what you think this demonstrates, but in the meantime:

$ ./bash --version
GNU bash, version 4.3.30(2)-release (x86_64-unknown-linux-gnu) Copyright (C) 
2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ (for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; 
do echo done ; done) | ./bash $ echo $?
0

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: CVE-2014-7187

[Chet Ramey]

On 10/10/14, 4:03 AM, Nabiałek, Wojciech wrote:
> Hi,
> 
> Bash 4.3 after patch 30 is still vulnerable for shellshock CVE-2014-7187.

No, it's not.

> (for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; 
> do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"

I'm curious about what you think this demonstrates, but in the meantime:

$ ./bash --version
GNU bash, version 4.3.30(2)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ (for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200}
; do echo done ; done) | ./bash
$ echo $?
0

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Random loss of bash history

[Pierre Gaston]

On Fri, Oct 10, 2014 at 11:40 AM, Linda Walsh  wrote:

> You DID read the release notes and changes from 4.2->4.3.
>
> Someone had the bright idea that .. in 4.2, '0' meant no limit in
> history (in bash and readline)... but in 4.3, '0' means 0 and throw
> away history while negative values mean keep it all.
>
> Perhaps you were hit by this brilliant new feature -- no doubt
> a new POSIX blessing.
>

Your ironic stance won't help your case.
Especially when what you describe is not true, 0 in 4.2 means 0.

$ HISTSIZE=10
$ echo $BASH_VERSION
4.2.53(1)-release
$ history
  999  PS1=\$\
 1000  HIST_SIZE=10
 1001  echo $BASH_VERSION
 1002  history
$ HISTSIZE=0
$ history
$

CVE-2014-7187

[Nabiałek , Wojciech]

Hi,

Bash 4.3 after patch 30 is still vulnerable for shellshock CVE-2014-7187.

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do 
echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"

Probably you know that, but better to have more than less information.

Thanks, Wojtek

Re: Testing for Shellshock ... combinatorics and latest(Shellshock) Bash Vulnerability...(attn: Chet Ramey)

[Stephane Chazelas]

2014-10-09 21:35:09 -0400, Chet Ramey:
> On 10/9/14, 6:06 PM, Pádraig Brady wrote:
> > On 10/09/2014 08:46 PM, Rick Karcich (rkarcich) wrote:
> >> Hello Chet,
> >>
> >> Re: testing for Shellshock...  would like your feedback... specifically, 
> >> regarding the possibility of human-directed combinatorial testing to find 
> >> this Bash vulnerability...
> >
> > Sounds like how Michal Zalewski found the related CVE-2014-6278
> > http://lcamtuf.blogspot.ie/2014/10/bash-bug-how-we-finally-cracked.html
>
> That's a promising approach.  I asked Michal to continue running the fuzzer
> against the patched, but he did not respond to that yet.
[...]

What's the point? That would be wasted effort IMO.

Who cares if bash does something unexpected on incorrect input as
long as it's not exploitable?

The problem here was bash interpreting untrusted input. That has
been fixed by stopping the parser from being exposed to
untrusted input. Now bugs in the parser are only relevant if
they affect functionality, that is, bash behaving the wrong way
on valid input (code) and fuzzers are not likely to help much
there. From that point of view, all the CVEs related to
shellshock are non-bugs or very insignificant ones once the
parser is no longer exposed.

>From a security point of view, there are things in bash and
other shells that are far more inportant to look at than what it
does on incorrect code: when it deals with other forms of
untrusted input.

One thing  for instance and that also affects some other shells
are like:

bash -c '(( XDG_VTNR < 7 ))

That allows arbitrary code execution (and can't easily be
fixed without breaking backward compatibility).

Try with "export XDG_VTNR='a[$(echo>&2 vulnerable)]'".

How do you fuzz-test for that? You can't really until you've
identified the problem already (that the arithmetic parsing has
side effects (here expands cmdsubst inside arrays, but
XFG_VTNR='PATH=1' could be as much of a problem).

Without breaking backward compatibility, the best way to address
it is document it: always sanitize external input before using
them in arithmetic context.

-- 
Stephane

Re: [RFC] Logically composable variant of errexit

[Andreas Grünbacher]

2014-10-10 8:38 GMT+02:00 Dan Douglas :
> I would still propose that a simple and powerful way to extend Bash with
> exception handling would be to extend the ERR trap by passing it some metadata
> about the type and location of the exception incurred so that it can be 
> handled
> by user code. This proposal allows us to largely avoid having to answer the
> question of "when and where does it make sense for this to get triggered?" for
> the user.
>
> It might require a new type of trap that just fires on anything that returns
> false or fails so that the user handler can choose what to do about it in
> various contexts.

Well, currently, the ERR trap only triggers when errexit would
trigger, so another
type of trap would certainly be needed. I don't think it's reasonable
to expect from
users to use trigger tricks to get basic error handling working in a sane way,
though; this should be built in and trivial to activate.

Thanks,
Andreas

Re: [RFC] Logically composable variant of errexit

[Andreas Grünbacher]

2014-10-10 3:29 GMT+02:00 Chet Ramey :
> What does logically composable mean in this context?

I would like the hypothetical errfail option to:

 * Behave like errexit at the top level (outside of functions).

 * Be inherited by functions,  subshells, and command substitution.

 * Inside functions, it should trigger like errexit would outside of
   functions, no matter how the function is called.
   It should return instead of exiting, though.

With errexit, you get vastly different results from functions depending
on how the functions are called, for example,

   foo() {
  echo "foo: top"
  false
  echo "foo: bottom"
   }

   set -o errexit

   # bottom of foo reached:
if foo; then
  echo "success"  # reached
   fi

   # bottom of foo not reached:
   foo

With errfail, "foo:bottom" and "success" would not be reached.

Command substitutions would continue to behave as basic commands
do with respect to control flow: inside functions, a failure would cause
the function to return; outside of functions, the script would exit.

Thanks,
Andreas

Re: umask --help

[Notes Jonny]

On 10 Oct 2014 01:25, "Chet Ramey"  wrote:
>
> On 10/9/14, 3:05 PM, Notes Jonny wrote:
>
> >> If and when it happens, it will
> >> show up in the devel git branch on savannah.
> >>
> >> Chet
>
> > Thank you for your reply.
> >
> > I understand that requests can't be implemented immediately.
> >
> > Is there anything I could do to get this implemented? Eg. I would offer
to
> > pay £100 for an engineer to complete the updates.
>
> Did you check the devel git branch on savannah? :-)
>
> The changes went in in early September.

Fantastic. Thanks :-) Jonny

Re: Random loss of bash history

[Linda Walsh]

You DID read the release notes and changes from 4.2->4.3.

Someone had the bright idea that .. in 4.2, '0' meant no limit in
history (in bash and readline)... but in 4.3, '0' means 0 and throw
away history while negative values mean keep it all.

Perhaps you were hit by this brilliant new feature -- no doubt
a new POSIX blessing.


Darshit Shah wrote:
I'm running Bash 4.3.30(1)-release on Arch Linux. Recently after I 
rebooted by system I realized that all my Bash History had been erased. 
The ~/.bash_history file existed, but it was completely empty.


The situation occurred just now once again. I boot up my system and 
realize that I have no bash history at all. The issue does not occur at 
every boot, it's random and I am unable to correlate the two instances 
in which this has happened to me.


I haven't any idea as to how I should debug this problem to provide more 
information. Could you please start out by helping me there?