On 10/16/2012 03:16 PM, Greg Wooledge wrote:
On Mon, Oct 15, 2012 at 08:08:10PM -0400, DJ Mills wrote:
done< <(set -o)
Huh... that's interesting. I wouldn't have expected it, but it turns
out you don't "lose" the value of errexit in a process substitution the
way you do in a command substitu
On Mon, Oct 15, 2012 at 08:08:10PM -0400, DJ Mills wrote:
> done < <(set -o)
Huh... that's interesting. I wouldn't have expected it, but it turns
out you don't "lose" the value of errexit in a process substitution the
way you do in a command substitution.
imadev:~$ bash -c 'set -e; x=$(set +o);
Hi Chet,
On 10/16/2012 02:13 AM, Chet Ramey wrote:
On 10/15/12 11:23 AM, Nikolai Kondrashov wrote:
I've noticed that errexit is disabled inside command substitution.
Is this intentional?
Yes. It's been that way since bash-1.14. The reasons why are lost in
time -- it was 17 years ago, after
On 10/16/2012 03:08 AM, DJ Mills wrote:
Do not use for to iterate over the output of an unquoted command
substitution.
Well, I wanted to keep it simple in this case.
Instead, use a while read loop.
See http://mywiki.wooledge.org/DontReadLinesWithFor and
http://mywiki.wooledge.org/BashFAQ/001
On 10/16/2012 03:21 AM, DJ Mills wrote:
On Mon, Oct 15, 2012 at 8:08 PM, DJ Mills wrote:
while read -r attr state; do
if [[ $shellopts = *:"$attr":* ]]; then
set -o "$attr"
else
set +o "$attr"
fi
done< <(set -o)
Erm, correction, that won't work for the first and last value
On Mon, Oct 15, 2012 at 8:08 PM, DJ Mills wrote:
> while read -r attr state; do
> if [[ $shellopts = *:"$attr":* ]]; then
> set -o "$attr"
> else
> set +o "$attr"
> fi
> done < <(set -o)
Erm, correction, that won't work for the first and last values in shellopts.
You could add colon
On Mon, Oct 15, 2012 at 5:18 PM, Nikolai Kondrashov
wrote:
> On 10/16/2012 12:08 AM, Greg Wooledge wrote:
>>
>> Sidestepping the direct question for a moment, you could use a temporary
>> file instead of a command substitution to store the output. Then there
>> would be no subshell involved.
>
>
On 10/15/12 11:23 AM, Nikolai Kondrashov wrote:
> Hi everyone,
>
> I've noticed that errexit is disabled inside command substitution.
> Is this intentional?
Yes. It's been that way since bash-1.14. The reasons why are lost in
time -- it was 17 years ago, after all -- but probably go something l
On 10/16/2012 12:08 AM, Greg Wooledge wrote:
Sidestepping the direct question for a moment, you could use a temporary
file instead of a command substitution to store the output. Then there
would be no subshell involved.
Thanks, Greg. I don't like creating temporary files unnecessarily, so I we
Hi Andreas,
On 10/16/2012 12:20 AM, Andreas Schwab wrote:
Nikolai Kondrashov writes:
Actually, I'm writing it for myself and I want to *disable* errexit
temporarily for other's code
o=$-; set +e; ...; case $o in *e*) set -e;; esac
Thanks, I considered the usage of $- (only found it today).
Nikolai Kondrashov writes:
> Actually, I'm writing it for myself and I want to *disable* errexit
> temporarily for other's code
o=$-; set +e; ...; case $o in *e*) set -e;; esac
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 827
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 th
On Tue, Oct 16, 2012 at 12:01:56AM +0300, Nikolai Kondrashov wrote:
> I'm trying to implement a pair of functions that would save/restore option
> state onto/from a stack, so I could modify options temporarily for some
> parts
> of code. I've worked around this problem already and it is not the su
On 10/15/2012 11:00 PM, DJ Mills wrote:
I'm also not entirely sure what you mean by "errexit will always be
stored as off."
I mean that if I try to capture option state with, for example: opts=`set +o`,
the errexit status will be lost.
It's on there... Do you not understand that command subst
Hi Daniel,
On 10/15/2012 10:44 PM, DJ Mills wrote:
On Mon, Oct 15, 2012 at 11:23 AM, Nikolai Kondrashov
wrote:
I've noticed that errexit is disabled inside command substitution.
Is this intentional?
It makes it hard to save and restore errexit state. I.e. you can't simply
say
opts=`set +o`,
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 therefo
On Mon, Oct 15, 2012 at 11:23 AM, Nikolai Kondrashov
wrote:
> Hi everyone,
>
> I've noticed that errexit is disabled inside command substitution.
> Is this intentional?
>
> It makes it hard to save and restore errexit state. I.e. you can't simply
> say
> opts=`set +o`, because errexit will always
On Mon, Oct 15, 2012 at 11:23 AM, Nikolai Kondrashov
wrote:
> Hi everyone,
>
> I've noticed that errexit is disabled inside command substitution.
> Is this intentional?
>
> It makes it hard to save and restore errexit state. I.e. you can't simply
> say
> opts=`set +o`, because errexit will always
Hi everyone,
I've noticed that errexit is disabled inside command substitution.
Is this intentional?
It makes it hard to save and restore errexit state. I.e. you can't simply say
opts=`set +o`, because errexit will always be stored as off. What's
interesting, $SHELLOPTS shows it still on inside
19 matches
Mail list logo
