BASH bug or expected behaviour?
In GNU Bash-2.05b (Fedora Core 1), I observe the following behaviour:
If bash script A is invoked (via "source") with command line parameters,
and bash script A invokes (via "source") bash script B with NO
parameters specified, then the parameters specified for A are passed to
B (rather than what I would have thought would be the expected
behaviour, that script B is called with NO parameters).
Is this intended behaviour, or a bug? I've worked around it by
specifying in script A just one null ("") parameter to script B.
-- Dean
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Bash completion buggy if -o nospace, -o filenames and -W used together.
Hello,
I've found a bug in bash autocompletion...
Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux
Compiler: gcc -I/usr/src/packages/BUILD/bash-3.0
-L/usr/src/packages/BUILD/bash-3.0/../readline-5.0
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
-DCONF_OSTYPE='linux' -DCONF_MACHTYPE='i586-suse-linux'
-DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -march=i586
-mcpu=i686 -fmessage-length=0 -Wall -g -D_GNU_SOURCE -Wall -pipe -g
-fbranch-probabilities
uname output: Linux cboltz 2.6.11.4-21.7-default #1 Thu Jun 2 14:23:14
UTC 2005 i686 i686 i386 GNU/Linux
Machine Type: i586-suse-linux
Bash Version: 3.0
Patch Level: 16
Release Status: release
Description:
Bash completion is buggy if -o nospace, -o filenames and -W are
used together. See the commented example below.
If you let one of the options away, the problem doesn't occour.
Also -o dirnames instead of -o filenames works well.
Repeat-By:
("" means pressing the "tab" key)
# complete -d -o nospace -o filenames -W '--foo=' foo
# foo
dir1/ dir2/ --foo=
# foo --f # results in "--foo\="
# foo --foo\= # <-- why does this backslash appear?
--foo=# It prevents dirname autocompletion :-(
# foo --foo=# <-- manually removed the backslash,
dir1/ dir2/ --foo= # now it works :-)
It would be nice if you could fix that problem ;-)
Regards,
Christian Boltz
--
2.-5.9.2005: Weinfest in Insheim
Bei der Landjugend: Liquid, AH-Band und Deafen Goblins
Mehr Infos: www.Landjugend-Insheim.de
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: BASH bug or expected behaviour?
Dean K. Gibson wrote:
> If bash script A is invoked (via "source") with command line parameters,
> and bash script A invokes (via "source") bash script B with NO
> parameters specified, then the parameters specified for A are passed to
> B (rather than what I would have thought would be the expected
> behaviour, that script B is called with NO parameters).
>
> Is this intended behaviour, or a bug? I've worked around it by
> specifying in script A just one null ("") parameter to script B.
Yes that is expected behavior. If you source a script without
parameters then it is as if that script were included in the parent.
It is as if the script is run in exactly the same environment. On the
other hand if you pass parameters then the script is called with the
$* positional parameter set to those arguments.
This matches the existing legacy practice of /bin/sh on systems for
many years. If you want to clear the parameter list then using set --
is the typical way to do this.
set --
Bob
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: BASH bug or expected behaviour?
Dean K. Gibson wrote: > In GNU Bash-2.05b (Fedora Core 1), I observe the following behaviour: > > If bash script A is invoked (via "source") with command line parameters, > and bash script A invokes (via "source") bash script B with NO > parameters specified, then the parameters specified for A are passed to > B (rather than what I would have thought would be the expected > behaviour, that script B is called with NO parameters). It's expected behavior. `.' works just as if all of the commands in the file were directly executed by the calling shell, which means that everything is inherited, including the positional parameters. It's a bash extension that allows additional arguments to `.' to be temporarily treated as positional parameters. The behavior with no additional arguments is backwards compatible. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live...Laugh...Love Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
