Re: Possible bug in bash

2023-01-17 Thread Dale R. Worley
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

Re: Possible bug in bash

2023-01-16 Thread Chet Ramey
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

Re: Possible bug in bash

2022-05-17 Thread Chet Ramey
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 |

Re: Possible bug in bash

2022-05-14 Thread Robert Elz
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

Re: Possible bug in bash

2022-05-13 Thread Robert Elz
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

Re: Possible bug in bash

2022-05-13 Thread Greg Wooledge
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

Re: Possible bug in bash

2022-05-13 Thread Dale R. Worley
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 "

Re: Possible bug in bash

2022-05-13 Thread flyingrhino
> > 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

Re: Possible bug in bash

2022-05-13 Thread David
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 >

Re: Possible bug in bash

2022-05-13 Thread flyingrhino
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: >

Re: Possible bug in bash

2022-05-13 Thread flyingrhino
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

Re: Possible bug in bash

2022-05-12 Thread Robert Elz
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

Re: Possible bug in bash

2022-05-12 Thread Lawrence Velázquez
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

Re: possible bug in Bash 5.0

2019-12-25 Thread Eli Schwartz
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

Re: Possible bug in bash... or maybe UFU?

2019-06-04 Thread Chet Ramey
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

Re: Possible bug in Bash Reference Manual - lists of commands

2019-05-22 Thread Greg Wooledge
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

Re: Possible Bug in BASH

2010-02-25 Thread Chet Ramey
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

Re: Possible Bug in BASH

2010-02-25 Thread Andreas Schwab
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

Re: Possible Bug in BASH

2010-02-25 Thread Matthew Strax-Haber
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

Re: Possible Bug in BASH

2009-06-20 Thread Bob Proulx
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

Re: Possible bug in bash error reporting

2005-07-31 Thread Chet Ramey
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