Bashbug should warn reporters details will be public.
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux epicfail 2.6.30.7-libre-fshoppe1 #1 SMP Wed Sep 23 15:31:59 CEST 2009 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.2 Patch Level: 39 Release Status: release Description: ( Not sure if this is the correct way to report this issue ) When bashbug is run, the email sent lands in public locations. It would be great if it could warn about this. I'm not sure how intrusive this change should be, or if meantioning it for -h, --help and in the documentation would be enough. I'm reporting this after someone coming to complain in #gnu. thanks, kk Repeat-By: [Describe the sequence of events that causes the problem to occur.] Fix: [Description of how to fix the problem. If you don't know a fix for the problem, don't include this section.]
Re: Bash-4.1-rc1 available for FTP
On Dec 25, 2009, at 11:43 AM, Andreas Schwab wrote: What does that mean? TRACE: pid 17502: mark_dead_jobs_as_notified: ndeadproc (0) != js.c_reaped (14) It's a debugging/informational message. ndeadproc is a count of the number of dead child processes in the current jobs list. c_reaped is the total number of dead child processes the shell has reaped. If they are different, I either did not catch some reaped children, we have dead children that were not part of jobs, or we've walked the list before. That info doesn't get checked in "release" versions of the shell. Chet Sent from my iPhone
Re: Bash-4.1-rc1 available for FTP
Chet Ramey writes: > On Dec 25, 2009, at 11:43 AM, Andreas Schwab > wrote: > >> What does that mean? >> > > TRACE: pid 17502: mark_dead_jobs_as_notified: ndeadproc (0) != js.c_reaped > (14) > > It's a debugging/informational message. ndeadproc is a count of the > number of dead child processes in the current jobs list. c_reaped is the > total number of dead child processes the shell has reaped. If they are > different, I either did not catch some reaped children, we have dead > children that were not part of jobs, or we've walked the list before. I see that quite often in some more complicated shell scripts, with increasing values for js.c_reaped. It may have to do with the use of process substitution. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Bash-4.1-rc1 available for FTP
On Dec 26, 2009, at 2:26 PM, Andreas Schwab wrote: I see that quite often in some more complicated shell scripts, with increasing values for js.c_reaped. It may have to do with the use of process substitution. Yes, those do not end up in the jobs table. Chet Sent from my iPhone
command_not_found_handle not called if "command" includes a slash
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall
uname output: Linux hayes 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686
GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 4.0
Patch Level: 33
Release Status: release
Description:
I'm not sure this is a bug, but I notice that the
command_not_found_handle function is not called if the "command" has a
slash in it. I can't find anywhere in the bash source producing the
"No such file ..." error message, so I guess this is being caught
somewhere else before bash gets the command line to process.
The behavior is not new; a second example is included below from v3.2,
showing the same error message when the bad command looks like a path.
I'd like to dig into this, to see if there's any hope of hooking into
this case in order to provide a handler, but have no idea where to look.
Is there any hope for this?
Repeat-By:
$ export PS1='\$?=$?\n$ '
$?=0
$
$?=0
$ kj
-bash: kj: command not found
$?=127
$ ./kjdf
-bash: ./kjdf: No such file or directory
$?=127
$ command_not_found_handle() { cmd="$1"; exec echo "$cmd" "$@"; }
$?=0
$ kj a b c
kj kj a b c
$?=0
$ ./kj a b c
-bash: ./kj: No such file or directory
$?=127
$ bash --version
GNU bash, version 4.0.33(1)-release (i486-pc-linux-gnu)
Copyright (C) 2009 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.
$?=0
$
An example on v3.2:
$ export PS1='\$?=$?\n$ '
$?=0
$ bash --version
GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
$?=0
$ kj
bash: kj: command not found
$?=127
$ ./kj
bash: ./kj: No such file or directory
$?=127
Thanks!
