bash(1) says /etc/bash.bash.logout, should be bash_logout

[dkg]

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-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -Wdate-time 
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall
uname output: Linux alice 4.7.0-rc7-amd64 #1 SMP Debian 4.7~rc7-1~exp1 
(2016-07-14) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.3
Patch Level: 46
Release Status: release

Description:

I think the documentation is wrong about the systemwide filename that
bash reads when a login shell exits.  the manpage says
"/etc/bash.bash.logout", but the binary appears to be built with
"/etc/bash.bash_logout" (note the change from "." to "_").

0 dkg@alice:~$ man bash 2>/dev/null | grep -A2 /etc/bash.bash.logout
   /etc/bash.bash.logout
  The  systemwide  login shell cleanup file, executed when a login
  shell exits
0 dkg@alice:~$ strings $(which bash) | grep /etc/bash.bash.logout
/etc/bash.bash_logout
0 dkg@alice:~$ 

This should probably be fixed by fixing whatever generates the bash
manpage.

Regards,

--dkg

Re: bash test: lastpipe.tests failed

[Chet Ramey]

On 8/12/16 4:06 AM, dengke...@windriver.com wrote:
> But when I run the test line by line, it's OK.
> 
> I used the version of bash is 4.3.30 on master branch, run the test on
> the qemux86-64.

The current version of bash on the master branch is 4.3.46.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: bash(1) says /etc/bash.bash.logout, should be bash_logout

[Greg Wooledge]

On Fri, Aug 12, 2016 at 09:59:00AM -0400, d...@fifthhorseman.net wrote:
> I think the documentation is wrong about the systemwide filename that
> bash reads when a login shell exits.  the manpage says
> "/etc/bash.bash.logout", but the binary appears to be built with
> "/etc/bash.bash_logout" (note the change from "." to "_").

This is a vendor (distribution) feature.  Submit a bug report to your
operating system.

Upstream bash does not read either of those files, and does not mention
either of them in its man page.

Re: Unable to dereference function-local nameref to global variable of same name

[Chet Ramey]

On 8/10/16 12:06 PM, Andreas Kusalananda Kähäri wrote:

> Bash Version: 4.3
> Patch Level: 46
> Release Status: release
> 
> Description:
> When declaring a variable in a function as a nameref, it can not
> be dereferenced if the variable it's a nameref to happen to have
> the same name as the nameref itself.  This imposes unnecessary
> restrictions on the caller.

There was extensive discussion about namerefs on bug-bash earlier this
year.  I have a reasonable suggestion about how to change this behavior,
and I will be looking at it after bash-4.4 is released.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: bash test: lastpipe.tests failed

[Chet Ramey]

On 8/12/16 4:14 AM, dengke...@windriver.com wrote:
> I used the strace tool to follow it. I touch a file named lastpipe just
> contain:
> 
> shopt -s lastpipe
> exit 142 | false
> 
> run command:)$ ./bash --version

OK.

$ ./bash --version
GNU bash, version 4.3.46(3)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ cat x1
shopt -s lastpipe
exit 142 | false

echo ${PIPESTATUS[@]}
$ ./bash ./x1
142 1
$ uname -a
Linux chet-mail 2.6.32-642.1.1.el6.x86_64 #1 SMP Fri May 6 14:54:05 EDT
2016 x86_64 x86_64 x86_64 GNU/Linux



-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Intriguing error with arithmetic evaluation

[NO REPLY]

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-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -D_FORTIFY_SOURCE=2 -g 
-O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -Wall
uname output: Linux hdara1-wsl 3.13.0-85-generic #129-Ubuntu SMP Thu Mar 17 
20:50:15 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.3
Patch Level: 11
Release Status: release

Description:
I have a few increment expressions used as ((level++)) and only one of 
those is giving an error. When used with set -e, bash aborts
execution. Using ERR trap, I was able to identify the expression.


Repeat-By:

I have this simple logic in which I am running a sequence of commands 
conditionally, based on what a user provided level is.
The intention is to only run those groups of commands appropriate for 
the level specified. To demonstrate the idea, here is
a simple script:

>>> CUT HERE <<<
#!/usr/bin/env bash
set -eEu -o pipefail
   
trap 'echo "*** ERROR: Detected error on command: $BASH_COMMAND at 
line: $LINENO"' ERR
   
DEBUG_LEVEL=$1
   
function debug_mode() {
declare -i level=0
(( level >= DEBUG_LEVEL )) || {
echo "Running: level $((level+1)) commands"
((level++))
}
(( level >= DEBUG_LEVEL )) || {
echo "Running: level $((level+1)) commands"
((level++))
}
}
   
debug_mode
>>> CUT HERE <<<

When this script works (as is the case on "GNU bash, version 
3.2.57(1)-release (x86_64-apple-darwin15)"), you would see the below 
interaction:

$ debug.sh 0
$ debug.sh 1
Running level 1 commands
$ debug.sh 2
Running level 1 commands
Running level 2 commands

However, when run on this version of bash (or even on GNU bash, version 
4.1.2(1)-release (x86_64-redhat-linux-gnu)), the first "((level++))" results in 
an error:

$ debug.sh 0
$ debug.sh 1
Running: level 1 commands
*** ERROR: Detected error on command: ((level++)) at line: 8

If I replace the first "((level++))" with ": $((level++))" or 
"level+=1", then it goes through fine, and the second "((level++))" doesn't 
generate any error.

Re: bash(1) says /etc/bash.bash.logout, should be bash_logout

[Chet Ramey]

On 8/12/16 9:59 AM, d...@fifthhorseman.net wrote:

> Bash Version: 4.3
> Patch Level: 46
> Release Status: release
> 
> Description:
> 
> I think the documentation is wrong about the systemwide filename that
> bash reads when a login shell exits.  the manpage says
> "/etc/bash.bash.logout", but the binary appears to be built with
> "/etc/bash.bash_logout" (note the change from "." to "_").

That's a change your vendor made.  The default logout file is
~/.bash_logout, and that's what appears in the man page as I distribute it.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Unable to dereference function-local nameref to global variable of same name

[Andreas Kusalananda Kähäri]

On Fri, Aug 12, 2016 at 09:34:40AM -0400, Chet Ramey wrote:
> On 8/10/16 12:06 PM, Andreas Kusalananda Kähäri wrote:
> 
> > Bash Version: 4.3
> > Patch Level: 46
> > Release Status: release
> > 
> > Description:
> > When declaring a variable in a function as a nameref, it can not
> > be dereferenced if the variable it's a nameref to happen to have
> > the same name as the nameref itself.  This imposes unnecessary
> > restrictions on the caller.
> 
> There was extensive discussion about namerefs on bug-bash earlier this
> year.  I have a reasonable suggestion about how to change this behavior,
> and I will be looking at it after bash-4.4 is released.

Thanks Chet.

I'm mostly a ksh user, and the background to my report above is
that I was trying to make a tiny library of shell functions for
manipulating PATH-like shell variables available to bash users while
still maintaining functionality in both shells.  All functions were
using a local nameref called "var" and the issue came up when one
function tried to use one of the others.

My workaround is currently to slightly obfuscate the name of the local
nameref previously called "var" in each function so that their names
won't clash within the library and so that it's less likely that they
clash with global variables in the shell.

I'm looking forward to a future bash release!

Regards,


signature.asc
Description: PGP signature

Re: Intriguing error with arithmetic evaluation

[Greg Wooledge]

On Fri, Aug 12, 2016 at 02:22:26PM +0530, NO REPLY wrote:
>   I have a few increment expressions used as ((level++)) and only one of 
> those is giving an error. When used with set -e, bash aborts
>   execution. Using ERR trap, I was able to identify the expression.

http://mywiki.wooledge.org/BashFAQ/105

Not much point in you filing a bug report if you use an invalid email
address, though, is there.  How are we supposed to communicated with you?

Re: Unable to dereference function-local nameref to global variable of same name

[Chet Ramey]

On 8/12/16 11:30 AM, Andreas Kusalananda Kähäri wrote:

> My workaround is currently to slightly obfuscate the name of the local
> nameref previously called "var" in each function so that their names
> won't clash within the library and so that it's less likely that they
> clash with global variables in the shell.

Yes, a naming convention that provides `enough' uniqueness is a good
workaround.

Chet


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/



signature.asc
Description: OpenPGP digital signature

Re: Intriguing error with arithmetic evaluation

[Chet Ramey]

On 8/12/16 4:52 AM, NO REPLY wrote:

> Bash Version: 4.3
> Patch Level: 11
> Release Status: release
> 
> Description:
>   I have a few increment expressions used as ((level++)) and only one of 
> those is giving an error. When used with set -e, bash aborts
>   execution. Using ERR trap, I was able to identify the expression.
> 
> 
> Repeat-By:
> 
>   I have this simple logic in which I am running a sequence of commands 
> conditionally, based on what a user provided level is.
>   The intention is to only run those groups of commands appropriate for 
> the level specified. To demonstrate the idea, here is
>   a simple script:
> 
>   >>> CUT HERE <<<
> #!/usr/bin/env bash
> set -eEu -o pipefail
>
> trap 'echo "*** ERROR: Detected error on command: $BASH_COMMAND at 
> line: $LINENO"' ERR
>
> DEBUG_LEVEL=$1
>
> function debug_mode() {
> declare -i level=0
> (( level >= DEBUG_LEVEL )) || {
> echo "Running: level $((level+1)) commands"
> ((level++))
> }
> (( level >= DEBUG_LEVEL )) || {
> echo "Running: level $((level+1)) commands"
> ((level++))
> }
> }
>
> debug_mode
>   >>> CUT HERE <<<
> 
>   When this script works (as is the case on "GNU bash, version 
> 3.2.57(1)-release (x86_64-apple-darwin15)"), you would see the below 
> interaction:
> 
>   $ debug.sh 0
>   $ debug.sh 1
>   Running level 1 commands
>   $ debug.sh 2
>   Running level 1 commands
>   Running level 2 commands
> 
>   However, when run on this version of bash (or even on GNU bash, version 
> 4.1.2(1)-release (x86_64-redhat-linux-gnu)), the first "((level++))" results 
> in an error:
> 
>   $ debug.sh 0
>   $ debug.sh 1
>   Running: level 1 commands
>   *** ERROR: Detected error on command: ((level++)) at line: 8
> 
>   If I replace the first "((level++))" with ": $((level++))" or 
> "level+=1", then it goes through fine, and the second "((level++))" doesn't 
> generate any error.

The relevant change was probably the change in the set of commands to which
`set -e' applies.  The (( command (among others) was added to that list
in bash-4.1.  The change was the result of Posix changing the semantics
of the errexit option and expanding its scope from simple commands to
all commands.

The (( command returns 1 if the expression evaluates to 0.  When `level' is
0, level++ returns a 0 value, and (( returns a status of 1.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: bash test: lastpipe.tests failed

[dengke...@windriver.com]

But when I run the test line by line, it's OK.

I used the version of bash is 4.3.30 on master branch, run the test on
the qemux86-64.

On 2016年08月10日 19:16, Chet Ramey wrote:

On 8/10/16 3:32 AM, dengke...@windriver.com wrote:

Hi all

When I run the bash test lastpipe.tests, there were some errors occurred.

The code in lastpipe.tests:

 shopt -s lastpipe
 ...
 exit 142 | false
 echo $? -- ${PIPESTATUS[@]}

The error output:

 lastpipe.tests: line 41:   708 Exit 142exit 142
 703 Hangup  | false
 129 -- 142 129

I can't reproduce this.  It looks system-specific; there shouldn't be
anything sending a SIGHUP to a simple command there.

Re: bash test: lastpipe.tests failed

[dengke...@windriver.com]

I used the strace tool to follow it. I touch a file named lastpipe just 
contain:


shopt -s lastpipe
exit 142 | false

run command:

$ strace /bin/bash lastpipe

the output:

read(3, "shopt -s lastpipe\nexit 142 | fal"..., 80) = 35
lseek(3, 0, SEEK_SET)   = 0
getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}) = 0
fcntl(255, F_GETFD) = -1 EBADF (Bad file 
descriptor)

dup2(3, 255)= 255
close(3)= 0
fcntl(255, F_SETFD, FD_CLOEXEC) = 0
fcntl(255, F_GETFL) = 0x8000 (flags 
O_RDONLY|O_LARGEFILE)

fstat(255, {st_mode=S_IFREG|0644, st_size=35, ...}) = 0
lseek(255, 0, SEEK_CUR) = 0
read(255, "shopt -s lastpipe\nexit 142 | fal"..., 35) = 35
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
pipe([3, 4])= 0
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [CHLD], 8) = 0
clone(child_stack=0, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7fc40e9fb9d0) = 774

rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
close(4)= 0
close(4)= -1 EBADF (Bad file 
descriptor)

getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}) = 0
fcntl(255, F_GETFD) = 0x1 (flags FD_CLOEXEC)
fcntl(254, F_GETFD) = -1 EBADF (Bad file 
descriptor)

dup2(0, 254)= 254
close(0)= 0
dup2(3, 0)  = 0
close(3)= 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
dup2(254, 0)= 0
close(254)  = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=774, 
si_uid=0, si_status=142, si_utime=0, si_stime=0} ---
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 142}], WNOHANG, NULL) 
= 774
wait4(-1, 0x7ffc0efc1658, WNOHANG, NULL) = -1 ECHILD (No child 
processes)

rt_sigreturn({mask=[]}) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGINT, {0x440490, [], SA_RESTORER, 0x7fc40e04b100}, 
{SIG_DFL, [], SA_RESTORER, 0x7fc40e04b100}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7fc40e04b100}, 
{0x440490, [], SA_RESTORER, 0x7fc40e04b100}, 8) = 0

rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
fstat(2, {st_mode=S_IFCHR|0600, st_rdev=makedev(4, 64), ...}) = 0
ioctl(2, TCGETS, {B115200 opost isig icanon echo ...}) = 0
write(2, "lastpipe: line 3:   774 Exit 142"..., 57lastpipe: line 3:   
774 Exit 142exit 142

) = 57
write(2, "   773 Hangup   "..., 43   773 
Hangup  | false

) = 43
read(255, "", 35)   = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
exit_group(129) = ?
+++ exited with 129 +++


On 2016年08月10日 19:16, Chet Ramey wrote:

On 8/10/16 3:32 AM, dengke...@windriver.com wrote:

Hi all

When I run the bash test lastpipe.tests, there were some errors occurred.

The code in lastpipe.tests:

 shopt -s lastpipe
 ...
 exit 142 | false
 echo $? -- ${PIPESTATUS[@]}

The error output:

 lastpipe.tests: line 41:   708 Exit 142exit 142
 703 Hangup  | false
 129 -- 142 129

I can't reproduce this.  It looks system-specific; there shouldn't be
anything sending a SIGHUP to a simple command there.