Re: Bash source repository
Bob Proulx wrote: > Jan Schampera wrote: >> The official patches should be there as individual commits. Though, I >> admit it's not a small amount of work to do all that for the past >> releases. Such a GIT or SVN repository technically is easy to do, but >> who feeds it :( > > Moving forward from now it should be reasonably easy to keep it up to > date with official patches. But recreating the history of all of the > past releases and all official patches for all past releases would be > significant effort. Just trying to locate all of them would be quite > the task. > > If someone actually had all of the releases and all of the patches > together (the hard part) then I would be willing to put them together > (the easy part) for the version control history. But as you say, then > someone still needs to feed it when new official patches are released. All the release tarfiles and official patches dating back to at least bash-1.14 are on ftp.gnu.org in pub/gnu/bash (though the form of the patches has changed). This is at least a 15-year chronology. 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: Bash 4 and ECHOCTL
On Thu, Nov 19, 2009 at 06:32:49PM +0100, Joachim Schmitz wrote: > In siglist.c the compiler complained bitterly about having to convert the > reseult of _() into a char * (sometimes comming from int, somtimes coming > from const char *) My nasty workaround: The correct fix for that one is to #include "bashintl.h" in siglist.c. This bug has been observed on HP-UX also (different symptom), and Chet's fixed it for bash 4.1.
Re: sudo: command: not found
On Sun, Nov 22, 2009 at 06:14:56PM +0800, wrote: > run the command "drcomd" ,successful! > > but run command "sudo drcomd" ,return "sudo : drcomd: command not found" Not really a bash bug. > under both (fedora)the PATH is > /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin > it's really confusing!!! What it sounds like to me, is that the "drcomd" command is in your PATH when you login, but is not in the PATH that sudo uses, which I presume is different. First, you should find out where the command actually is, by doing: type -p drcomd Then you might find it instructive to see what PATH sudo uses, by doing: sudo bash -c 'echo $PATH' If I'm correct, you'll discover that the directory which contains drcomd is not in the sudo PATH. Configuring sudo to use a different PATH is a bit outside the scope of a bash bug mailing list. Depending on what OS and/or distribution you're on, and what version of sudo you're using, there might be a line in /etc/sudoers which is setting sudo's PATH, or there might have been a compile-time override (Debian calls this "the SECURE_PATH build option"). Take a look at sudoers(5) and look for the "secure_path" option. I think that's what you want to set. If you can't figure out how to configure sudo according to your needs, then you could always use this: sudo "$(type -p drcomd)" It's inconvenient, but it'll probably work.
Re: DEBUG trap breaks pipelines
> > Well, then there's no way to tell how large the intersection of these > two sets is, is there? We'll know once I upgrade to the latest bash. Ideally, we should no longer need our own private hacks to get bash cross compiling for our arch. If we do, we'll know which patches still needs to go upstream. I'll raise a bug internally and see when I can get to it.
caller builtin returns wrong lineno when sourced
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: i686-pc-linux-gnu-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -
DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -
DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -
DHAVE_CONFIG_H -I. -I. -I./include -I./lib -
DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
-DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin' -
DSYS_BASHRC='/etc/bash/bashrc' -DSYS_BASH_LOGOUT='/etc/bash/bash_logout' -
DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -march=pentium4 -g -O2 -pipe
uname output: Linux localhost 2.6.31.6-grsec #1 Fri Nov 13 21:21:04 CET 2009
i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 4.0
Patch Level: 33
Release Status: release
Description:
The bash builtin function "caller" outputs wrong line numbers if the
script was sourced within the current shell. This may have to do with
subshells, but the output is correct if a newly spawned shell
runs the script. The contents of "bash-caller-bug.sh" documented
below.
$ bash bash-caller-bug.sh
calling 'func2' in a subshell from line 33
this is 'func1' at line 25 -- so where we end?
Bash backtrace:
25 func1 ./bash-caller-bug.sh
29 func2 ./bash-caller-bug.sh
33 main ./bash-caller-bug.sh
$ source bash-caller-bug.sh
calling 'func2' in a subshell from line 33
this is 'func1' at line 1 -- so where we end?
Bash backtrace:
1 func1 ./bash-caller-bug.sh
-27 func2 ./bash-caller-bug.sh
33 source ./bash-caller-bug.sh
Repeat-By:
#!/bin/bash -e
# besides kill, there is no reliable way to terminate a script
# from a subshell [= anything running between (), i.e. $()].
die() {
local -i n=0
echo -n "$1" >&2
[[ "$2" != "0" ]] \
&& echo "( function returned error "$2" )" >&2 \
|| echo >&2;
echo "Bash backtrace:" >&2
while ( [[ true ]] ); do
local frame=$(caller $n)
local msg="\t$frame"
[[ $frame ]] && echo -e "$msg" >&2 || break;
n=$((++n))
done
# kill $$;
exit 1; # don't exec subsequent statements from subshell
}
func1() {
die "this is '${FUNCNAME}' at line ${LINENO} -- so where we
end?" 0
}
func2() {
echo "$(func1)";
}
echo "calling 'func2' in a subshell from line ${LINENO} $(func2)";
# END OF FILE
RE: Bash 4 and ECHOCTL
Greg Wooledge wrote: > On Thu, Nov 19, 2009 at 06:32:49PM +0100, Joachim Schmitz wrote: >> In siglist.c the compiler complained bitterly about having to >> convert the reseult of _() into a char * (sometimes comming from >> int, somtimes coming from const char *) My nasty workaround: > > The correct fix for that one is to #include "bashintl.h" in siglist.c. > This bug has been observed on HP-UX also (different symptom), and > Chet's fixed it for bash 4.1. That indeed fixes it, I don't quite get why I didn't spot this myself, I did find the spot where _() is #defined'd, but apparently didn't conecte the dots. When will bash-4.1 be available? And what about the other issues I mentioned? Bye, Jojo
Re: Bash 4 and ECHOCTL
Joachim Schmitz wrote: > When will bash-4.1 be available? In the fullness of time. It's close. > And what about the other issues I mentioned? As I already said in the reply I sent you, they are all fixed in bash-4.1. -- ``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: caller builtin returns wrong lineno when sourced
Just for completeness: Same with 3.2.39, 4.1 alpha and beta. Jan
