bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Command substitution and errexit


From: Nikolai Kondrashov
Subject: Re: Command substitution and errexit
Date: Tue, 16 Oct 2012 00:12:43 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.7) Gecko/20120922 Icedove/10.0.7

Hi Greg,

On 10/15/2012 11:13 PM, Greg Wooledge wrote:
On Mon, Oct 15, 2012 at 04:00:01PM -0400, DJ Mills wrote:
I'm also not entirely sure what you mean by "errexit will always be
stored as off."

My interpretation is that he wants to write a "portable function" for
someone else to use, and that he wants to use errexit while inside it,
and therefore he believes he needs to retrieve the current value of
errexit so that the can restore that value right before exiting.

Actually, I'm writing it for myself and I want to *disable* errexit
temporarily for other's code and also to contain errexit effect to ( )
subshells for a crude try/catch implementation. I don't so much "believe" I
need to retrieve the current value, as more it is a part of the design.

So, he's trying to capture stuff=$(set +o) to retrieve the settings,
but since errexit gets disabled in (some? I don't know/care) subshells,
it's not acting as he expects.

imadev:~$ bash -c 'set -e; set +o | grep errexit'
set -o errexit
imadev:~$ bash -c 'set -e; x=$(set +o); echo "$x" | grep errexit'
set +o errexit

I reiterate my position that set -e (errexit) should be avoided.  It
brings nothing but suffering.

Thanks Greg, I think you may be right, but I'll try to evaluate the benefits
against the amount of suffering it brings, before abandoning errexit usage.

It could be that I simply haven't used as much Bash features as you and Daniel
did and that's why I haven't suffered that much :)

Thanks for the wiki, BTW :)

Sincerely,
Nick



reply via email to

[Prev in Thread] Current Thread [Next in Thread]