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 &&
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
u.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
> bash (version 5.1
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.
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
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
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,
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
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
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
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
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''.
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
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
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
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).
>
>
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
, April 11, 2013 2:03 PM
To: Lenga, Yair [ICG-MKTS]
Cc: 'chet.ra...@case.edu'; 'Dan Douglas'; 'bug-bash@gnu.org'
Subject: Re: Possible bug with BASH V4: The $!
On 4/11/13 12:15 PM, Lenga, Yair wrote:
Dan, Chet: Many thanks for the info about BASHPID.
I've checked BASHPID on RH6, and it looks
Hi,
I'm using a bash scripts that is running one of the functions in the scripts as
a background.
function my_func {
MAINPID=$$ # Does not work, report PID of main process.
MYPID=$! # Work with bash 3.0, return unbound value for bash 4.0
echo Deamon run as PID=$MYPID
On Thu, Apr 11, 2013 at 01:05:43PM +, Lenga, Yair wrote:
Is it possible to add back the functionality to allow the child process to
somehow retrieve it's OWN PID.
You are looking for the BASHPID variable, which expands to the process
ID of the current bash process (even in a subshell).
On Thursday, April 11, 2013 01:05:43 PM Lenga, Yair wrote:
With BASH 3.0, the backgrounded task could access the PID of the parent using
$$, and the PID Of itself as $!.
With BASH 4.0, the script fail, the $! is not available to the child
process.
Is it possible to add back the
On 4/11/13 9:24 AM, Dan Douglas wrote:
On Thursday, April 11, 2013 01:05:43 PM Lenga, Yair wrote:
With BASH 3.0, the backgrounded task could access the PID of the parent using
$$, and the PID Of itself as $!.
With BASH 4.0, the script fail, the $! is not available to the child
process.
Is
Ramey [mailto:chet.ra...@case.edu]
Sent: Thursday, April 11, 2013 10:14 AM
To: Lenga, Yair [ICG-MKTS]
Cc: Dan Douglas; bug-bash@gnu.org; chet.ra...@case.edu
Subject: Re: Possible bug with BASH V4: The $!
On 4/11/13 9:24 AM, Dan Douglas wrote:
On Thursday, April 11, 2013 01:05:43 PM Lenga, Yair
On Thu, Apr 11, 2013 at 04:15:45PM +, Lenga, Yair wrote:
+ The man page list BASH_VERSION, etc., but no indication of BASHPID. It's
probably a good idea to put a note next to '$!' about BASHPID.
It is certainly in the man page:
BASHPID
Expands to the process ID of the
On Thursday, April 11, 2013 04:15:45 PM Lenga, Yair wrote:
( echo $!)
( echo $!)
According to POSIX, both calls should print (nothing). As the background
command does not come from the current shell.
With BASH4, The first call will print (nothing), second call will print
the PID of
On 4/11/13 12:15 PM, Lenga, Yair wrote:
Dan, Chet: Many thanks for the info about BASHPID.
I've checked BASHPID on RH6, and it looks OK. Few comments related to making
the change visible, and POSIX compliance.
+ The 'set' command, does not print the BASHPID, this make it very hard to
Matthew Strax-Haber strax-habe...@neu.edu 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
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 this behavior before. This
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
34 matches
Mail list logo
