Re: typeset -p on an empty integer variable is an error. (plus -v test w/ array elements)
On Sun, Jan 13, 2013 at 03:31:24AM +0100, John Kearney wrote:
> set -o errexit
> test_func() {
> [ ! -d test ] && echo test2
> }
>
> echo test3
> test_func
> echo test4
>
> now so long as test doesn't exist in the cwd it should errexit.
> at least it did for me just now.
Cannot reproduce.
imadev:~$ cat bar
#!/bin/bash
set -e
f() { test ! -d nosuchdir && echo no dir; }
f
echo survived
imadev:~$ ./bar
no dir
survived
"$(echo "x'" '{1,2}')" performs brace expansion, even though it should not
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=x86-64
-mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4
-D_FORTIFY_SOURCE=2
-DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin'
-DSTANDARD_UTILS_PATH='/usr/bin:/bin:/usr/sbin:/sbin'
-DSYS_BASHRC='/etc/bash.bashrc' -DSYS_BASH_LOGOUT='/etc/bash.bash_logout'
uname output: Linux laptop 3.6.11-1-ARCH #1 SMP PREEMPT Tue Dec 18 08:57:15 CET
2012 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.2
Patch Level: 42
Release Status: release
Description:
If a double-quoted command substitution command contains a
double-quoted string containing a single-quote, followed by a
single-quoted string containing a brace-expansion expression,
then the command to be substituted is not executed correctly.
See examples below.
Also tested with the following versions and produces the same behaviour:
GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu)
Repeat-By:
$ echo "$(echo "x" '{1,2}')" # Produces expected result
x {1,2}
$ echo "$(echo "x'" '{1,2}')" # Bug case: Add single-quote to first
string, causing brace-expansion!
x' 1 x' 2
$ echo $(echo "x'" '{1,2}') # Produces expected result, but unquoted!
x' {1,2}
Re: "$(echo "x'" '{1,2}')" performs brace expansion, even though it should not
On 1/14/13 8:57 AM, Marco Elver wrote: > Machine Type: x86_64-unknown-linux-gnu > > Bash Version: 4.2 > Patch Level: 42 > Release Status: release > > Description: > If a double-quoted command substitution command contains a > double-quoted string containing a single-quote, followed by a > single-quoted string containing a brace-expansion expression, > then the command to be substituted is not executed correctly. Thanks for the report. This has been fixed in the bash development versions for some time. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: typeset -p on an empty integer variable is an error. (plus -v test w/ array elements)
Am 14.01.2013 14:33, schrieb Greg Wooledge:
> On Sun, Jan 13, 2013 at 03:31:24AM +0100, John Kearney wrote:
>> set -o errexit
>> test_func() {
>> [ ! -d test ] && echo test2
>> }
>>
>> echo test3
>> test_func
>> echo test4
>>
>> now so long as test doesn't exist in the cwd it should errexit.
>> at least it did for me just now.
> Cannot reproduce.
>
> imadev:~$ cat bar
> #!/bin/bash
>
> set -e
> f() { test ! -d nosuchdir && echo no dir; }
> f
> echo survived
> imadev:~$ ./bar
> no dir
> survived
the "no dir" above means that the test didn't fail. The exit only
happens if the test fails. Sorry I keep seeming to make typos. I really
need more sleep.
this should exit.
#!/bin/bash
set -e
f() { test -d nosuchdir && echo no dir; }
echo testings
f
echo survived
All I was pointing out that its safer to use syntax
[] ||
or
[] && ||
you always need a || on a one liner to make sure the return value of the
line is a 0.
this isn't necessary in the script body I think but in a function it is,
unless its the last command then it will be auto returned..
but lets say you want to do 2 things in a function you have to do
something like.
f(){
mkdir "${1%/*}" ||return $? # so the line doesn't return an error.
touch "${1}"
}
any way it is nearly always something that should be being done anyway.
It only the conditional one liners that tend to frustrate people a lot
from what I've seen.
Re: typeset -p on an empty integer variable is an error. (plus -v test w/ array elements)
On Mon, Jan 14, 2013 at 08:08:53PM +0100, John Kearney wrote:
> this should exit.
> #!/bin/bash
>
> set -e
> f() { test -d nosuchdir && echo no dir; }
> echo testings
> f
> echo survived
OK, cool. That gives me more ammunition to use in the war against set -e.
==
imadev:~$ cat foo
#!/bin/bash
set -e
test -d nosuchdir && echo no dir
echo survived
imadev:~$ ./foo
survived
==
imadev:~$ cat bar
#!/bin/bash
set -e
f() { test -d nosuchdir && echo no dir; }
f
echo survived
imadev:~$ ./bar
imadev:~$
==
imadev:~$ cat baz
#!/bin/bash
set -e
f() { if test -d nosuchdir; then echo no dir; fi; }
f
echo survived
imadev:~$ ./baz
survived
==
> All I was pointing out that its safer to use syntax
>
> [] ||
>
> or
>
> [] && ||
I don't even know what "safer" means any more. As you can see in my
code examples above, if you were expecting the "survived" line to appear,
then you get burned if you wrap the test in a function, but only if the
test uses the "shorthand" && instead of the "vanilla" if.
But I'm not sure what people expect it to do. It's hard enough just
documenting what it ACTUALLY does.
> you always need a || on a one liner to make sure the return value of the
> line is a 0.
Or stop using set -e. No, really. Just... fucking... stop. :-(
> but lets say you want to do 2 things in a function you have to do
> something like.
> f(){
> mkdir "${1%/*}" ||return $? # so the line doesn't return an error.
> touch "${1}"
> }
... wait, so you're saying that even if you use set -e, you STILL have to
include manual error checking? The whole point of set -e was to allow
lazy people to omit it, wasn't it?
So, set -e lets you skip error checking, but you have to add error checking
to work around the quirks of set -e.
That's hilarious.
Re: typeset -p on an empty integer variable is an error. (plus -v test w/ array elements)
Am 14.01.2013 20:25, schrieb Greg Wooledge:
> On Mon, Jan 14, 2013 at 08:08:53PM +0100, John Kearney wrote:
>> this should exit.
>> #!/bin/bash
>>
>> set -e
>> f() { test -d nosuchdir && echo no dir; }
>> echo testings
>> f
>> echo survived
> OK, cool. That gives me more ammunition to use in the war against set -e.
>
> ==
> imadev:~$ cat foo
> #!/bin/bash
>
> set -e
> test -d nosuchdir && echo no dir
> echo survived
> imadev:~$ ./foo
> survived
> ==
> imadev:~$ cat bar
> #!/bin/bash
>
> set -e
> f() { test -d nosuchdir && echo no dir; }
> f
> echo survived
> imadev:~$ ./bar
> imadev:~$
> ==
> imadev:~$ cat baz
> #!/bin/bash
>
> set -e
> f() { if test -d nosuchdir; then echo no dir; fi; }
> f
> echo survived
> imadev:~$ ./baz
> survived
> ==
>
>> All I was pointing out that its safer to use syntax
>>
>> [] ||
>>
>> or
>>
>> [] && ||
> I don't even know what "safer" means any more. As you can see in my
> code examples above, if you were expecting the "survived" line to appear,
> then you get burned if you wrap the test in a function, but only if the
> test uses the "shorthand" && instead of the "vanilla" if.
>
> But I'm not sure what people expect it to do. It's hard enough just
> documenting what it ACTUALLY does.
>
>> you always need a || on a one liner to make sure the return value of the
>> line is a 0.
> Or stop using set -e. No, really. Just... fucking... stop. :-(
>
>> but lets say you want to do 2 things in a function you have to do
>> something like.
>> f(){
>> mkdir "${1%/*}" ||return $? # so the line doesn't return an error.
>> touch "${1}"
>> }
> ... wait, so you're saying that even if you use set -e, you STILL have to
> include manual error checking? The whole point of set -e was to allow
> lazy people to omit it, wasn't it?
>
> So, set -e lets you skip error checking, but you have to add error checking
> to work around the quirks of set -e.
>
> That's hilarious.
>
I have no idea why errexit exists I doubt it was for lazy people
thought. its more work to use it.
I use trap ERR not errexit, which allows me to protocol unhandled errors.
I actually find trap ERR/errexit pretty straight forward now. I don't
really get why people are so against it. Except that they seem to have
the wrong expectations for it.
btw
|| return $?
isn't actually error checking its error propagation.
f(){
# not last command in function
mkdir "${1%/*}" # exit on error.
mkdir "${1%/*}" ||return $? # return an error.
mkdir "${1%/*}" ||true # ignore error.
# last command in function
touch "${1}"# return exit code
}
what is confusing though is
f(){
touch "${1}"# exit on error
return $?
}
this wll not work as expected with errexit.
because the touch isn't the last command in the function, however just
removing the return should fix it.
also need to be careful of stuff like
x=$(false)
need something more like
x=$(false||true)
or
if x=$(false) ; then
basically any situation in which a line returns a non 0 value is
probably going to cause the exit especially in functions.
I just do it automatically now.
I guess most people aren't used to considering the line return values.
Re: "$(echo "x'" '{1, 2}')" performs brace expansion, even though it should not
On Monday, January 14, 2013 01:57:14 PM Marco Elver wrote:
> echo "$(echo "x'" '{1,2}')"
This was fixed in git a while back, but not backported to 4.2. I believe this:
8/21
command.h
- W_NOBRACE: new word flag that means to inhibit brace expansion
subst.c
- brace_expand_word_list: suppress brace expansion for words with
W_NOBRACE flag
--
Dan Douglas
Re: typeset -p on an empty integer variable is an error. (plus -v test w/ array elements)
On 1/14/13 2:57 PM, John Kearney wrote: > I have no idea why errexit exists I doubt it was for lazy people > thought. its more work to use it. I had someone tell me one with a straight (electronic) face that -e exists `to allow "make" to work as expected' since historical make invokes sh -ce to run recipes. Now, he maintains his own independently-written version of `make', so his opinion might be somewhat skewed. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: "$(echo "x'" '{1, 2}')" performs brace expansion, even though it should not
On 1/14/13 11:00 AM, Dan Douglas wrote:
> On Monday, January 14, 2013 01:57:14 PM Marco Elver wrote:
>> echo "$(echo "x'" '{1,2}')"
>
> This was fixed in git a while back, but not backported to 4.2. I believe this:
>
> 8/21
>
> command.h
> - W_NOBRACE: new word flag that means to inhibit brace expansion
>
> subst.c
> - brace_expand_word_list: suppress brace expansion for words with
> W_NOBRACE flag
No, this:
4/2
---
braces.c
- brace_gobbler: fix to understand double-quoted command substitution,
since the shell understands unquoted comsubs. Fixes bug reported
by Michael Whitten
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: typeset -p on an empty integer variable is an error. (plus -v test w/ array elements)
On Mon, Jan 14, 2013 at 08:57:41PM +0100, John Kearney wrote: > ... > btw > || return $? > > isn't actually error checking its error propagation. Also btw, I think you can omit the $? in this case; from bash(1): return [n] ... If n is omitted, the return status is that of the last command executed in the function body. ... and similarly for exit: exit [n] ... If n is omitted, the exit status is that of the last command executed. ... Ken
Re: typeset -p on an empty integer variable is an error. (plus -v test w/ array elements)
Am 14.01.2013 22:09, schrieb Ken Irving: > On Mon, Jan 14, 2013 at 08:57:41PM +0100, John Kearney wrote: >> ... >> btw >> || return $? >> >> isn't actually error checking its error propagation. > Also btw, I think you can omit the $? in this case; from bash(1): > > return [n] > ... > If n is omitted, the return status is that of the last command > executed in the function body. ... > > and similarly for exit: > > exit [n] > ... If n is omitted, > the exit status is that of the last command executed. ... > > Ken > Thanks yhea your right, but I think its clearer to include it especially for people with less experience. I try to be as explicit as possible. Perl cured me of my taste for compactness in code . ;)
question of command cd's option [-e]
Configuration Information :
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OS
TYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' -DCONF_VENDOR
='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAV
E_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protec
tor --param=ssp-buffer-size=4 -m64 -mtune=generic
uname output: Linux Fedora16-MSM 3.6.10-2.fc16.x86_64 #1 SMP Tue Dec 11
18:55:03 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 4.2
Patch Level: 28
Release Status: release
Description:
I want to use the option [-e] of command cd. But I found I can't use. The
problem as follows:
$ cd -P -e Donwloads
bash: cd: -e: invalid option
cd: usage: cd [-L|[-P [-e]]] [dir]
$ cd -Pe Downloads
bash: cd: -e: invalid option
cd: usage: cd [-L|[-P [-e]]] [dir]
$ cd -Pe
bash: cd: -e: invalid option
cd: usage: cd [-L|[-P [-e]]] [dir]
and I read the source code of bash, it seems the function internal_getopt
doesn't deal with option 'e'.
It's a bug or I didn't use it correctly? details as follows:
reset_internal_getopt ();
while ((opt = internal_getopt (list, "LP")) != -1)
{
switch (opt)
{
case 'P':
verbatim_pwd = pflag = 1;
break;
case 'L':
verbatim_pwd = 0;
break;
default:
builtin_usage ();
return (EXECUTION_FAILURE);
}
}
list = loptend;
about one feature in V4.2 against V4.1
Hello: i am from China and i am working on investigating the difference between bash V4.2 and V4.1 according to official log there is a new feature description "Posix mode shells no longer exit if a variable assignment error occurs with an assignment preceding a command that is not a special builtin" i wrote a script saved as "test.sh" readonly a=3 a=2 echo "this is incorrect." and i wanted to demonstrate the different behavior on bash V4.1 and V4.2 but i tried all below,there was no difference 1) set -o posix then ran the script 2) bash --posix test.sh 3) sh test.sh i appreciate if you can tell me what's the problem and how to demonstrate the new feature against V4.1 sorry for my disturbance Dou
