Greg Wooledge writes:
> On Fri, May 13, 2022 at 10:36:56PM -0400, Dale R. Worley wrote:
>> Reading your message, I believe that the rule can be stated as follows,
>> and I'd thank you to check it: && and || have the same precedence, and
>> they both "associate left". So for example
>> x && y
On 1/17/23 2:21 AM, anonymous4feedb...@outlook.com wrote:
I am sorry I made a mistake in the first email. Bash printed foo= bar=v and
all other shells printed foo=v bar=. It turns out I am using --posix to
enable alias in bash, and that’s what makes the difference.
Thanks for the update; I fix
ug-bash@gnu.org>
抄送: chet.ra...@case.edu<mailto:chet.ra...@case.edu>
主题: Re: Possible bug in bash
On 1/15/23 7:42 AM, anonymous4feedb...@outlook.com wrote:
> For the follow script
> alias al=' '
> alias foo=bar
> al for foo in v
> do echo foo=$foo bar=$bar
> done
&g
On 1/15/23 7:42 AM, anonymous4feedb...@outlook.com wrote:
For the follow script
alias al=' '
alias foo=bar
al for foo in v
do echo foo=$foo bar=$bar
done
bash (version 5.1.16) prints foo=v bar=, while all other shells I tested (dash,
ksh, zsh, and yash) all prints foo= bar=v.
That's strange. I
For the follow script
alias al=' '
alias foo=bar
al for foo in v
do echo foo=$foo bar=$bar
done
bash (version 5.1.16) prints foo=v bar=, while all other shells I tested (dash,
ksh, zsh, and yash) all prints foo= bar=v.
Apparently bash substitutes foo for bar in line 3 because the previous alias al
On 5/13/22 10:36 PM, Dale R. Worley wrote:
Robert Elz writes:
Note particularly that there is no operator precedence between
&& and || - they are the same (unlike in C for example)
Reading your message, I believe that the rule can be stated as follows,
and I'd thank you to check it: && and |
Date:Fri, 13 May 2022 23:27:50 -0400
From:Greg Wooledge
Message-ID:
| Not really.
What's the difference?
| Let's say you have a bunch of commands strung together like this:
|
| a && b || c && d || e && f || g
|
| We start with the shell's command parser
Date:Fri, 13 May 2022 22:36:56 -0400
From:"Dale R. Worley"
Message-ID: <87ilq8hmbb@hobgoblin.ariadne.com>
| Reading your message, I believe that the rule can be stated as follows,
| and I'd thank you to check it:
OK
| && and || have the same precedence, an
On Fri, May 13, 2022 at 10:36:56PM -0400, Dale R. Worley wrote:
> Reading your message, I believe that the rule can be stated as follows,
> and I'd thank you to check it: && and || have the same precedence, and
> they both "associate left". So for example
> x && yy || zz
> is equivalent (as a
Robert Elz writes:
> Note particularly that there is no operator precedence between
> && and || - they are the same (unlike in C for example)
Reading your message, I believe that the rule can be stated as follows,
and I'd thank you to check it: && and || have the same precedence, and
they both "
>
> Have a thorough look around at:
> http://mywiki.wooledge.org/BashPitfalls
> http://mywiki.wooledge.org/BashFAQ
> http://mywiki.wooledge.org/BashGuide
>
> and you will find a lot of useful knowledge that is
> explained with considerable effort by many people.
Pity I didn't find this page when
On Fri, 13 May 2022 at 18:18, flyingrhino wrote:
> Before opening the bug I looked online for if-then-else vs [[ and no
> proper information was available, definitely not to the extent you explain
> here.
Have a look here:
http://mywiki.wooledge.org/BashPitfalls#cmd1_.26.26_cmd2_.7C.7C_cmd3
>
Thanks Lawrence for the response.
Between you and Robert I now have a clear understanding on this and I'll go
back and fix the bug in my code which used this construct.
Ken.
On Fri, 13 May 2022 00:51:49 -0400
Lawrence Velázquez wrote:
> On Thu, May 12, 2022, at 11:34 PM, flyingrhino wrote:
>
Hi,
Thank you very much for the detailed description of this scenario.
Before opening the bug I looked online for if-then-else vs [[ and no proper
information was available, definitely not to the extent you explain here.
This is very useful and rare knowledge and the effort you took to explain t
Not a bug.
Do not use && || as if they were a replacement for if then else fi
they aren't. In some simple cases it all works out OK, but not in
general, as you discovered. If you mean if x; then y; else z; fi
then write that, not x && y || z
The way and-or lists work, is that the first command
On Thu, May 12, 2022, at 11:34 PM, flyingrhino wrote:
> Should the "else" condition after the: || run if the last command in
> the: && section exits non zero?
Yes. This behavior is not a bug; ''A && B || C'' is simply not
equivalent to ''if A then B; else C; fi''.
https://mywiki.wooledge.or
Hi,
Should the "else" condition after the: || run if the last command in
the: && section exits non zero?
I tested it this way:
Script:
#!/bin/bash
[[ "a" == "a" ]] && \
{
echo "equal"
ls x
} || {
echo "* SHOULD NOT DISPLAY 4"
}
Result:
./moo.sh
equal
ls:
On 12/25/19 5:41 PM, Xin Wu wrote:
> Hi,
>
> I found the single-bracket [ ... ] and double-bracket [[ ... ]] behave
> differently for string comparison in the follow simple Bash-script.
>
> # comma (,) is before two (2) in ASCII
> a=,rst
> b=2rst
> if [ "$a" \> "$b" ]; then
> echo "single-brack
Hi,
I found the single-bracket [ ... ] and double-bracket [[ ... ]] behave differently for string
comparison in the follow simple Bash-script.
# comma (,) is before two (2) in ASCII
a=,rst
b=2rst
if [ "$a" \> "$b" ]; then
echo "single-bracket"
fi
if [[ "$a" > "$b" ]]; then
echo "double-bra
On 6/4/19 3:09 AM, George R Goffe wrote:
> Hi,
> I'm trying to build the latest bash from ftp.gnu.org and am having some
> problems. Are these a bug or am I doing something wrong?
This is what happens when the bash configure can't find a working termcap
or curses library. What does the Makefile h
On Wed, May 22, 2019 at 02:38:29PM +0800, Ralph Jensen wrote:
> The Bash Reference Manual, Edition 5 and earlier versions define lists of
> commands as follows:
>
> "A list is a sequence of one or more pipelines separated by one of the
> operators ..." (Bash Reference Manual 3.2.3).
>
> Shouldn't
The Bash Reference Manual, Edition 5 and earlier versions define lists
of commands as follows:
"A list is a sequence of one or more pipelines separated by one of the
operators ..." (Bash Reference Manual 3.2.3).
Shouldn't that say commands rather than pipelines?
Ralph Jensen
On 2/25/10 2:05 AM, Matthew Strax-Haber wrote:
>>> Below is a simple demonstration of the unexpected behavior:
>>>
>>> SHELL 1:
>>> mattsh$ alias c=clear
>>> mattsh$ c () { echo foo; }
>>> mattsh$ clear
>>> foo
>>
>> Here c is the first word. So it is replaced by the alias. (I didn't
>> know thi
Matthew Strax-Haber writes:
> Perhaps it is not a bug, but if it is not then the documentation is
> inconsistent with the behavior.
There is no inconsistency. In the first example you define a function
with the name `clear', in the second example you define a function with
the name `c'. Surel
On Jun 20, 2009, at 3:47 PM, Bob Proulx wrote:
> Matthew Strax-Haber wrote:
>> I think I may have found a bug in BASH 3.2.17(1)-release on a mac.
>
> I am not sure it is a bug but it does seem ood.
Perhaps it is not a bug, but if it is not then the documentation is
inconsistent with the behavio
Matthew Strax-Haber wrote:
> I think I may have found a bug in BASH 3.2.17(1)-release on a mac.
I am not sure it is a bug but it does seem ood.
> Below is a simple demonstration of the unexpected behavior:
>
> SHELL 1:
> mattsh$ alias c=clear
> mattsh$ c () { echo foo; }
> mattsh$ clear
> foo
He
I think I may have found a bug in BASH 3.2.17(1)-release on a mac.
Below is a simple demonstration of the unexpected behavior:
SHELL 1:
mattsh$ alias c=clear
mattsh$ c () { echo foo; }
mattsh$ clear
foo
SHELL 2:
mattsh$ alias c=clear
mattsh$ function c () { echo foo; }
mattsh$ clear
[blanks scre
Jan Schampera wrote:
>
> Configuration Information [Automatically generated, do not change]:
> Machine: i586
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-mandrake-linux-gnu'
> -DCONF_VENDOR='man
Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-mandrake-linux-gnu'
-DCONF_VENDOR='mandrake' -DLOCALEDIR='/usr/share/local
29 matches
Mail list logo
