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/15/12 1:32 PM, Aharon Robbins wrote:
> Is there something that can be done for 4.2.24 (/bin/bash on Ubuntu 12.04)?
Regrettably, nothing other than upgrading to at least bash-4.2 patch 29,
or requesting that Ubuntu (really Debian) do so.
Chet
--
``The lyf so short, the craft so long to ler
On 10/15/12 11:26 AM, William F Hammond wrote:
>> If you indeed are using bash-4.2.37, you can enable variable expansion
>> by running `shopt -s direxpand'. This will produce the behavior you
>> want.
>>
>> I'm wondering if you've got programmable completion enabled, or whether
>> you're running
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
In article ,
Chet Ramey wrote:
>On 10/14/12 8:52 AM, William F Hammond wrote:
>>
>> Configuration Information [Automatically generated, do not change]:
>> Machine: i686
>> OS: linux-gnu
>> Compiler: gcc
>> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
>-DCONF_OSTYPE='linux-gnu' -D
Chet --
Many thanks for your reply.
You write:
> On 10/14/12 8:52 AM, William F Hammond wrote:
>>
>> Configuration Information [Automatically generated, do not change]:
>> Machine: i686
>> OS: linux-gnu
>> Compiler: gcc
>> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
>> -DCONF_
On 10/15/12 10:47 AM, Dan Douglas wrote:
> Also I may as well overload this mail by reporting that nearly every issue
> I've ever sent to this list over the last year or so (that turned out being
> "legitimate") appears to have been addressed in devel (at least, according to
> a few minutes of
This makes a lot of sense. Thanks for the nice explanation and link!
On Sunday, October 14, 2012 01:10:17 PM Chet Ramey wrote:
> It's a little easier to see how ! ! is a no-op that way.
The "negated false pipeline" isn't something I'd given much thought to. It
turns out "! !" is an even faster n
On 10/15/12 8:33 AM, Greg Wooledge wrote:
> (*) "Required" insofar as he wants bash to remain POSIX compliant.
Posix conformance has been a bash design criterion from its earliest days.
There has to be a good reason to not conform, since not conforming implies
a deliberate difference between bash
On Mon, Oct 15, 2012 at 10:04:39AM +0800, Tinni wrote:
> Thank you so much for your reply and explanation.
>
> >>So, you're trying to retrieve 3 separate (string?) values from a remote
> system.
>
> Yes.
>
> >> Why not simply prompt the user for the
> information on the local system and skip t
On Sunday, October 14, 2012 05:21:05 PM Linda Walsh wrote:
> Seriously -- why not just fix it?
>
> If you think it is broken -- Fix it.
This should fix most scripts.
case $- in
*e*) exec /bin/sh -c 'cat; rm -f "$1"; exit 1' -- "$BASH_SOURCE" <<-"EOF"
>&2
Error: Braindamage detected. Pro
On Sun, Oct 14, 2012 at 05:21:05PM -0700, Linda Walsh wrote:
> Steven W. Orr wrote:
> >Seriously, can we just put a trap on all messages to this list that have
> >the string 'set -e' in it? Just point the sender to a message that tells
> >them to not use it.
>
>
> Seriously -- why not just
24 matches
Mail list logo
