On Fri, Sep 24, 2010 at 03:22, Marc Herbert wrote:
>> On Thu, Sep 23, 2010 at 04:38:42PM -0500, Michael Witten wrote:
>>> This is also possible:
>>>
>>> [ -f "$file" ] && do_something
>
> Note that this style is not compatible with set -e
I was going to note that same caveat in my original emai
On Fri, Sep 24, 2010 at 04:43:38PM +0100, Marc Herbert wrote:
> Bourne shell is the only programming language I know that ignores
> errors by default. "set -e" does not completely repair this design
> flaw but it goes a long and appreciated way.
C does too. This is probably not a coincidence.
Le 24/09/2010 15:38, Greg Wooledge a écrit :
> If this is turning into a general discussion of errexit (set -e) then
> please also see
>
> http://mywiki.wooledge.org/BashFAQ/105 and
> http://fvue.nl/wiki/Bash:_Error_handling
These pages are great and should be read. But from experience, I
total
If this is turning into a general discussion of errexit (set -e) then
please also see
http://mywiki.wooledge.org/BashFAQ/105 and
http://fvue.nl/wiki/Bash:_Error_handling
Le 24/09/2010 14:52, Sascha Ziemann a écrit :
> The expression:
>
> declare a='x'$(false)
>
> means: concatenate the string 'x', which evaluates to itself, and the
> output of a sub shell, which performs the false command, and assign
> the concatenated value to the variable a.
>
> This means th
>> Description:
>> The errexit option does not work, if an error occures in a declare
>> statement.
>
> There is no error, because `declare' is defined to return success if the
> variable assignment is performed without an error.
As far as I know about interpreters the arguments of an assig
On 9/23/10 5:09 AM, Sascha Ziemann 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' -DCONF_MACHTYPE='i686-pc-linux-gnu'
> -DCONF_VEN
On 9/24/10 8:19 AM, Greg Wooledge wrote:
> On Thu, Sep 23, 2010 at 10:12:28PM +0900, sky wrote:
>> #
>> # prepare 1000 strings of 6 digits
>> #
>> TEST_LIST=`seq 100100 100 20`
>> echo $TEST_LIST | wc
>
> Actually, this is one gigantic string, not 1000 strings.
>
>> #
>> # delete "15"
>>
On Thu, Sep 23, 2010 at 10:12:28PM +0900, sky wrote:
> #
> # prepare 1000 strings of 6 digits
> #
> TEST_LIST=`seq 100100 100 20`
> echo $TEST_LIST | wc
Actually, this is one gigantic string, not 1000 strings.
> #
> # delete "15"
> #
> T0=$SECONDS
> A=${TEST_LIST//15}
> T1=$SECONDS
>
On Fri, Sep 24, 2010 at 11:28:50AM +0200, Sven Mascheck wrote:
> > test x && test y || test z
> which, on the other hand, people sometimes use as replacement for
>if test x; then test y; else test z; fi
> although it behaves differently. In the former, test z is also
Oh dear, it was disc
On Fri, Sep 24, 2010 at 09:22:50AM +0100, Marc Herbert wrote:
> [...]
> For longer conditions brackets are easier to "parse"; the reader has no
> doubt where it ends.
>
> By the way I wonder if this makes any difference to the actual parser.
>
> On the other hand some people explain that long co
> On Thu, Sep 23, 2010 at 04:38:42PM -0500, Michael Witten wrote:
>> This is also possible:
>>
>> [ -f "$file" ] && do_something
Note that this style is not compatible with set -e
Le 24/09/2010 00:35, Ken Irving a écrit :
> While we're talking about style... I prefer using 'test' rather than
12 matches
Mail list logo
