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
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 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 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
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 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
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_
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
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
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
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
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 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
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
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
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 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).
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
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/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: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 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 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
24 matches
Mail list logo
