BASH_ARG[CV] and functions
Hi all! Short question concerning BASH_ARG[CV] and function execution. According to the info manual and man pages, the arguments of functions should be pushed onto the named arrays. But this doesn't happen currently, only for the source built-in. I tracked the problem down to the lines around 3212 and 3264 in execute_function() in execute_cmd.c: /* Update BASH_ARGV and BASH_ARGC */ if (debugging_mode) push_args (words->next); [...] /* Restore BASH_ARGC and BASH_ARGV */ if (debugging_mode) pop_args (); The debugging_mode check should be removed, or the info manual and man pages need to be adjusted to represent the current behaviour. Cheers, Sven -- Sven Wegener Gentoo Developer http://www.gentoo.org/ pgphDUh9LYOnK.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: BASH_ARG[CV] and functions
On Mon, Nov 28, 2005 at 11:30:29AM -0500, Chet Ramey wrote: > Sven Wegener wrote: > > > The debugging_mode check should be removed, or the info manual and man > > pages need to be adjusted to represent the current behaviour. > > The documentation has already been corrected for the next release. Was just asking because the source built-in pushes its arguments onto the variables. Seems a little bit inconsistent. Sven -- Sven Wegener Gentoo Developer http://www.gentoo.org/ pgpBQvVFA12aV.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: backgrounded children forgotten
On Sat, Dec 10, 2005 at 11:36:36PM -0500, Aron Griffis wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: x86_64-pc-linux-gnu-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 -march=nocona -O3 -pipe > -fomit-frame-pointer > uname output: Linux vino 2.6.15-rc1 #1 SMP PREEMPT Thu Nov 17 10:10:29 EST > 2005 x86_64 Intel(R) Xeon(TM) CPU 3.20GHz GenuineIntel GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 3.0 > Patch Level: 16 > Release Status: release > > Description: > When 2 processes are backgrounded inside $(...), bash forgets the first > one was a child of the shell. > > Repeat-By: > Note this needs to be a script, not cmdline, otherwise $! doesn't work. > > $ cat demo > output=$( > true & > pid=$! > true & > sleep 1 > wait $pid > ) > > $ bash demo > demo: line 13: wait: pid 25183 is not a child of this shell Hi Aron! Hi list! To me it looks like, that you can only wait for child processes that are still running. The backgrounded true will exit nearly immediately and wait can't wait for it because it has already terminated. Looking at the source it proves me right for wait without any arguments. "But wait without any arguments means to wait for all of the shell's currently active background processes." And I guess that for wait the process still needs to be running. Replacing true in your example with e.g. sleep 10 makes wait work. Sven -- Sven Wegener Gentoo Developer http://www.gentoo.org/ pgpZVMaQDPvjd.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: eval in functions in pipelines doesn't set variables globally
On Mon, Feb 13, 2006 at 04:19:42PM +0100, [EMAIL PROTECTED] wrote: > Configuration Information [Automatically generated, do not change]: > Machine: sparc > OS: solaris2.8 > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc' > -DCONF_OSTYPE='solaris2.8' -DCONF_MACHTYPE='sparc-sun-solaris2.8' > -DCONF_VENDOR='sun' -DLOCALEDIR='/sw/opensrc/gnu/share/locale' > -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib > -I/sw/opensrc/gnu/include -I/sw/opensrc/include > -I/sw/opensrc/include/freetype2 -I/usr/local/ssl/include -O6 > uname output: SunOS suni2 5.8 Generic_117350-24 sun4u sparc > SUNW,Sun-Blade-2500 > Machine Type: sparc-sun-solaris2.8 > > Bash Version: 3.1 > Patch Level: 0 > Release Status: release > > Description: > Normally, the eval builtin used in functions to set variables > makes these variables available globally otutside the function. > However, when the function gets input from a pipline, the variables > are set only locally. This bug was already present in bash-3.0, maybe > also in earlier version. The correct behavior would be very usefull > to be able to write functions which receive stdin and put it's > contens - preprocessed by awk or similar - into an array. If you pipe something, the recipient of the piped data will be executed in a subshell and can't set variables of the calling shell. This is just how pipe'ing works. You can do an hackish workaround like: evalfunc_stdin B test < <( echo ) to execute the function in the current shell and receive input on stdin. Cheers, Sven -- Sven Wegener Gentoo Developer http://www.gentoo.org/ pgpy0I0Nqday9.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: PATH strange behaviour
On Fri, Aug 03, 2007 at 04:32:10PM +0200, J?r?my Herv? wrote: > - version : 3.1.17(2)-release (i486-slackware-linux-gnu) > - description : Strange behaviour ; second time I have it. I removed > an old apache package (1.3, /usr/sbin/httpd) and make;make-installed a > new one (/usr/bin/httpd). Here is the transcript of what appened then. > > [EMAIL PROTECTED]:/usr/bin# env | grep PATH > MANPATH=/usr/local/man:/usr/man:/usr/X11R6/man:/usr/lib/java/man:/usr/share/texmf/man > PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/opt/www/htdig/bin:/usr/lib/java/bin:/usr/lib/java/jre/bin:/usr/share/texmf/bin > PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig:/opt/kde/lib/pkgconfig > [EMAIL PROTECTED]:/usr/bin# ls -l httpd > -rwxr-xr-x 1 root root 643348 2007-08-03 15:49 httpd* > [EMAIL PROTECTED]:/usr/bin# ls -l /usr/sbin/httpd > /bin/ls: /usr/sbin/httpd: No such file or directory > [EMAIL PROTECTED]:/usr/bin# whereis httpd > httpd: /usr/bin/httpd /usr/include/httpd.h /usr/man/man8/httpd.8 > /usr/share/man/man8/httpd.8 > [EMAIL PROTECTED]:/usr/bin# httpd -v > -bash: /usr/sbin/httpd: No such file or directory > [EMAIL PROTECTED]:/usr/bin# ./httpd -v > Server version: Apache/2.2.4 (Unix) > Server built: Aug 3 2007 15:46:58 > [EMAIL PROTECTED]:/usr/bin# sh > [EMAIL PROTECTED]:/usr/bin# httpd -v > Server version: Apache/2.2.4 (Unix) > Server built: Aug 3 2007 15:46:58 > [EMAIL PROTECTED]:/usr/bin# ls -l /usr/sbin/httpd > ls: /usr/sbin/httpd: No such file or directory > [EMAIL PROTECTED]:/usr/bin# env | grep SHELL > SHELL=/bin/bash > [EMAIL PROTECTED]:/usr/bin# /bin/bash --version > GNU bash, version 3.1.17(2)-release (i486-slackware-linux-gnu) > Copyright (C) 2005 Free Software Foundation, Inc. > [EMAIL PROTECTED]:/usr/bin# Well, that's expected behaviour. bash remembers the full path name for commands executed. In this case it has remembered the location /usr/sbin/httpd for the httpd command. You're update has removed it, but bash doesn't know it's gone. The new shell you executed starts with an empty hash. You can use hash -r to force bash to forget it. Sven -- Sven Wegener Gentoo Developer http://www.gentoo.org/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
