Re: incorrect brace expansion when using default values
[EMAIL PROTECTED] (Paul Jarc) writes:
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
>> this little bit of code doesnt work right:
>> foo() { echo "${1:-a{b,c}}" ; }
>
> Brace expansion happens before parameter expansion (man bash,
> EXPANSION).
Brace expansion doesn't come into play here, because the braces are
quoted.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: incorrect brace expansion when using default values
On Wednesday 06 September 2006 05:04, Andreas Schwab wrote:
> [EMAIL PROTECTED] (Paul Jarc) writes:
> > Mike Frysinger <[EMAIL PROTECTED]> wrote:
> >> this little bit of code doesnt work right:
> >> foo() { echo "${1:-a{b,c}}" ; }
> >
> > Brace expansion happens before parameter expansion (man bash,
> > EXPANSION).
>
> Brace expansion doesn't come into play here, because the braces are
> quoted.
without quotes has the same behavior
foo() { echo ${1:-a{b,c}} ; }
-mike
pgp33m2mxSCoE.pgp
Description: PGP signature
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
completion inconsistencies involving symlinks
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc'
-DLOCALEDIR='/var/local/akkartik/akk.tmp/bash/bash-3.1/install/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2
uname output: Linux .cs.utexas.edu 2.6.17.4 #1 SMP Wed Jul 12 14:41:00
CDT 2006 i686 GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 3.1
Patch Level: 17
Release Status: release
Description:
If any part of cwd is a symlink, file completion when you try to navigate
above that part follows the logical path. This is in conflict with all
coreutils commands that use the physical path.
---
In an ideal world I think bash's completion makes more sense than coreutils
semantics. But after looking into coreutils sources and ext2 documentation
(http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.11.tar.bz:Documentation/filesystems/ext2.txt)
I conclude that the 'logical path' is maintained only by the shell, not in
the filesystem. If I'm right, then the whole notion of logical path is a
leaky abstraction honored only by 'cd -L' (are there any others?). I would
really like to be told I'm wrong.
Repeat-By:
$ mkdir base_dir
$ cd base_dir
$ mkdir -p x/y
$ ln -s x/y f
$ cd f
$ ls ..
y
# Testing out tab-completion
$ ls ../
f x
# stat("../x") returns ENOENT.
$ cat > x.c
#include
#include
#include
struct stat buf ;
int main () { printf ("%d %d\n", stat("../x", &buf), errno); }
$ gcc x.c
$ a.out
-1 2
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
comint: long lines truncated
`comint.el' versions since revision 1.14 of 2006/05/25 02:49:47 -0 unconditionally add `TERM=dumb' to environment of all processes they start. Programs using readline, including bash 3.1 with their bundled readline libraries, with this setting incorrectly truncate long input lines. This may be reproduced with inserting long enough command in comint mode buffer and calling `comint-send-input'. For `echo' with single argument, string of 256 `.'s as arg bash process outputs part of them, and for the rest of them outputs bash: : command not found This does not even depend on what libraries were linked to readline. They may be from `libncurses5-5.3-1.20040125.4mdk' or `libtermcap2-2.0.8-35mdk' packages, it is always the same. With `TERM=emacs' (set manually) these programs would behave in comint buffers normally, process commands of arbitrary length. This is how `comint.el' would set it before revision 1.13. It avoided hitting this bug. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
completion hosed by :
Version: 3.1. If user enters unescaped `:' in command line so that the word already input constitutes prefix of some existing file names, and invokes `complete' (), what happens can not even be interpreted as provision for colon separated file name lists like `PATH' value. If `0:0', `0i', `0.tar' files exists in current directory, `0:' is completed with `0\:0' to obtain `0:0\:0'. If 1st `:' is a file name separator, the file name prefix to complete is empty, all files in current directory must be considered for completion. If `:' is part of file name, it should be completed with `0', and optionally escaped to distinguish from file name separator. To obtain `0:0' or `0\:0'. It is certainly better than previous versions did, to consider existing file names with `:'. If file names are included in colon separated list, they do not contain colons themselves. Also, file names obtained from them by appending colon and more text normally do not exist. So the cases of colon separated lists and file names containing colons may be easily distinguished. If entered word constitutes prefix of some existing file names, it is file name prefix, even if it contains colons, should be completed as such, and colons may optionally be escaped. If no such file names exist, but string starting from last colon in the word consititutes existing file name prefix, the word is colon separated list, and last item of the list should be completed. Certainly modifying prefix already entered, to escape colons, increasing its size, may be tedious to implement. The very interpretation of `:' in file name completion in any special way is not documented in `bashref.texi' at all. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
possibly a bash build problem?
Howdy, This result (see below) seems to be redily re-creatable. Could you take a peek at this and tell me if it is a bug or if I'm doing something wrong please? Regards and thanks for your time, George... rm -f bash gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde -L./lib/malloc -L./lib/sh -static -static -rdynamic -pg -g -O2 -o bash shell.o eval.o y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o execute_cmd.o variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o version.o alias.o array.o arrayfunc.o braces.o bracecomp.o bashhist.o bashline.o list.o stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o -lbuiltins -lsh -lreadline -lhistory -lcurses -lglob -ltilde -lmalloc lib/intl/libintl.a /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libc.a(dcigettext.o)(.text+0x684): In function `_nl_find_msg': : multiple definition of `_nl_find_msg' lib/intl/libintl.a(dcigettext.o)(.text+0x568):/tools/bash/bash-3.1/lib/intl/dcigettext.c:740: first defined here /usr/bin/ld: Warning: size of symbol `_nl_find_msg' changed from 851 to 1361 in /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libc.a(dcigettext.o) collect2: ld returned 1 exit status make: *** [bash] Error 1 = _/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/_/ _/_/_/_/ _/_/_/_/ - _/ _/ _/_/ _/_/ _/ _/ _/ _/_/ _/_/_/_/ _/_/ _/_/_/ _/ _/_/ _/_/_/_/ - _/_/ _/ _/_/ _/ _/ _/_/ _/ _/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/ _/_/_/_/ _/_/_/_/ - "It's not what you know that hurts you, It's what you know that ain't so." Will Rogers __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
make bash use authentication type?
In a recet discussion about ssh, the ida was put forth to get opnssh to export a variable that defines the authentication method used. The idea being to limit access to su use to only those authenticating through a public / privat key pairing. is there any way currently to configure bash to use this and limit access to su if the authentication is not through th ky pair, without hurting the transparency of normal ssh access? Jaqui __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Problems with bash+cygwin and longjmp
Hi! We have a very strange and non-repeatable bug in bash came with the last version of cygwin. It appears during execution of a set of long-play scripts. These scripts do a lot of work and their normal execution time is 20-40 hours. Sometimes after 20 or more hours of work bash exits as it was killed with signal 9. I.e. it exits in the middle of the scripts without saying any word to stdout or stderr. At other times it exits with printing stack frame or some other info and the error description. Error description is similar to "C:\cygwin\bin\bash.exe (4588): *** WFSO timed out after longjmp", i.e. this message is different from time to time but when it's printed it always has some mentioning of longjmp. I can conclude from this that there's some wrong using of longjmp in the bash source code... This bug is not stable, so there's a lot of times when scripts finished it's work successfully. But as this failure appears and as there were periods when it happened often, we want to correct this behaviour very much. BTW: the same scripts work in Linux bash and they had never failed there in such way. Can you tell us something about this strange behaviour and give some advice about healing it? ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
completion inconsistencies if cwd contains symlinks
[manually resending after bashbug seems to have failed to send.]
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc'
-DLOCALEDIR='/var/local/akkartik/bash-3.1/install/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2
uname output: Linux lutie.cs.utexas.edu 2.6.17.4 #1 SMP Wed Jul 12 14:41:00 CDT
2006 i686 GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 3.1
Patch Level: 17
Release Status: release
Description:
If any part of cwd is a symlink, file completion when you try to navigate
above that part follows the logical path. This is in conflict with all
coreutils commands that use the physical path.
---
In an ideal world I think bash's completion makes more sense than coreutils
semantics. But after looking into coreutils sources and ext2 documentation
(http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.11.tar.bz:Documentation/filesystems/ext2.txt
or http://www.mjmwired.net/kernel/Documentation/filesystems/ext2.txt)
I conclude that the 'logical path' is maintained only by the shell, not in
the filesystem. If I'm right, then the whole notion of logical path is a
leaky abstraction honored only by 'cd -L' [anybody else?]. I would
really like to be told I'm wrong.
Repeat-By:
$ mkdir base_dir
$ cd base_dir
$ mkdir -p x/y
$ ln -s x/y f
$ cd f
$ ls ..
y
# Testing out tab-completion
$ ls ../
f x
# stat("../f") returns ENOENT.
$ cat > x.c
#include
#include
#include
struct stat buf ;
int main () {
printf ("%d %d\n", stat("../f", &buf), errno);
}
$ gcc x.c
$ a.out
-1 2
Kartik
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
possible history bug?
discovered something interesting while using the bash shell. It seems to work with tcsh so perhaps its not a bash bug at all.. anyway.. the "history" service will not pick up commands which have a few spaces placed in front of them. eg: torproxy:~ # history | tail -5 63 cd 64 ls 65 history 66 echo $SHELL 67 history | tail -5 torproxy:~ # history | tail -6 62 ls 63 cd 64 ls 65 history 66 echo $SHELL 67 history | tail -5 torproxy:~ # SLES 10 on i386. bash --version GNU bash, version 3.1.17(1)-release (i586-suse-linux) -- Greg Whynott|IDTe Toronto|Systems and Networks 489 Queen Street E, Toronto, Ontario, M5A 1V1 ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
The removal fails if the first number é precede d from one zero not meaningful one.
Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux nerone 2.4.20-42.7.legacysmp #1 SMP Sun Feb 20 11:10:30 EST 2005 i686 unknown Machine Type: i686-pc-linux-gnu Bash Version: 2.05a Patch Level: 0 Release Status: release Description: Hello! I am Temperini Rolando, an Italian programmers and this the first time that I write to you. In bash the removal fails if the first number é preceded from one zero not meaningful one. Repeat-By: Case 1) pippo=$[013-1] echo $pippo Results is : 10 Case 2) pippo=$[09-1] Results is : bash: 09: value too great for base (error token is "09") Fix: I have not any idea. My best regards, Temperini Rolando. p2.vert.ukl.yahoo.com uncompressed/chunked Fri Sep 1 10:22:11 GMT 2006 ___ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
completion inconsistencies if cwd contains symlinks
[Resending for third time.]
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc'
-DLOCALEDIR='/var/local/akkartik/bash-3.1/install/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2
uname output: Linux lutie.cs.utexas.edu 2.6.17.4 #1 SMP Wed Jul 12 14:41:00 CDT
2006 i686 GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 3.1
Patch Level: 17
Release Status: release
Description:
If any part of cwd is a symlink, file completion when you try to navigate
above that part follows the logical path. This is in conflict with all
coreutils commands that use the physical path.
---
In an ideal world I think bash's completion makes more sense than coreutils
semantics. But after looking into coreutils sources and ext2 documentation
(http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.11.tar.bz:Documentation/filesystems/ext2.txt
or http://www.mjmwired.net/kernel/Documentation/filesystems/ext2.txt)
I conclude that the 'logical path' is maintained only by the shell, not in
the filesystem. If I'm right, then the whole notion of logical path is a
leaky abstraction honored only by 'cd -L' [anybody else?]. I would
really like to be told I'm wrong.
Repeat-By:
$ mkdir base_dir
$ cd base_dir
$ mkdir -p x/y
$ ln -s x/y f
$ cd f
$ ls ..
y
# Testing out tab-completion
$ ls ../
f x
# stat("../f") returns ENOENT.
$ cat > x.c
#include
#include
#include
struct stat buf ;
int main () {
printf ("%d %d\n", stat("../f", &buf), errno);
}
$ gcc x.c
$ a.out
-1 2
Kartik
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: incorrect brace expansion when using default values
On 2006-09-06, Andreas Schwab wrote:
> [EMAIL PROTECTED] (Paul Jarc) writes:
>
>> Mike Frysinger <[EMAIL PROTECTED]> wrote:
>>> this little bit of code doesnt work right:
>>> foo() { echo "${1:-a{b,c}}" ; }
The first '}' is interpreted as the end of the parameter expansion.
>>
>> Brace expansion happens before parameter expansion (man bash,
>> EXPANSION).
>
> Brace expansion doesn't come into play here, because the braces are
> quoted.
Quote them, and they do expand:
$ foo() { echo "${1:-"a{b,c}"}" ; }
$ foo
ab ac
However, there is a problem:
$ foo 1
1 1
Where is the second '1' coming from?
--
Chris F.A. Johnson
===
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
hardwired DEBUGGER_START_FILE points to wrong location
Currently if the environmental variable is not set then
DEBUGGER_START_FILE defaults to this;
configure.in: DEBUGGER_START_FILE=
${ac_default_prefix}/lib/bashdb/bashdb-main.inc
However looking at the bashdb package Makefiles I note that
bashdb-main.inc will be found in $(datadir)/bashdb/, thus I think
DEBUGGER_START_FILE should default to that instead of
${ac_default_prefix}/lib/
Simply changing this to;
configure.in: DEBUGGER_START_FILE=${datadir}/bashdb/bashdb-main.inc
does not quite work as pathname.h ends up looking like this;
#define DEBUGGER_START_FILE "${prefix}/share/bashdb/bashdb-main.inc"
but I'm sure someone that understands autoconf/automake better can
correct this.
Thanks,
Nick
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
bash 3.1.17: ~/.inputrc key bindings not being read
Configuration Information [Automatically generated, do not change]: Machine: powerpc OS: darwin8.7.0 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='powerpc' - DCONF_OSTYPE='darwin8.7.0' -DCONF_MACHTYPE='powerpc-apple- darwin8.7.0' -DCONF_VENDOR='apple' -DLOCALEDIR='/usr/local/share/ locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DMACOSX -I. -I. - I./include -I./lib -I./lib/intl -I/usr/local/src/bash-3.1-17/lib/ intl -g -O2 uname output: Darwin JP-PB.local 8.7.0 Darwin Kernel Version 8.7.0: Fri May 26 15:20:53 PDT 2006; root:xnu-792.6.76.obj~1/RELEASE_PPC Power Macintosh powerpc Machine Type: powerpc-apple-darwin8.7.0 Bash Version: 3.1 Patch Level: 17 Release Status: release Description: ~/.inputrc has the following key bindings which work correctly in bash 2.05b: # Mac forward delete "\e[3~": delete-char # Toggle insert/overwrite mode $if mode=emacs "\M-i": overwrite-mode $endif # Kill the entire line "\M-k": kill-whole-line When using bash 3.1.17 they do not work and the results of bind - p are: "\M-[3~": delete-char "?": kill-whole-line "?": overwrite-mode As can be seen the modifier keys are being read incorrectly. Repeat-By: Creating the above key bindings in ~/.inputrc. C-x C-r Press the respective key combinations--they don't work Run bind -p Note that the keys are not picked up Regards John Purnell ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
1 error detected in the compilation of "y.tab.c"
Dear Gentle people. After ./configure, then issued make, I got the following compile error: *** * * * GNU bash, version 3.1.0(3)-release (ia64-hp-hpux11.23) * * *** rm -f y.tab.o cc -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"ia64"' -DCONF_OSTYPE='"hpux11.23"' -DCONF_MACHTYPE='"ia64-hp-hpux11.23"' -DCONF_VENDOR='"hp"' -DLOCALEDIR='"/usr/local/share/locale"' -DPACKAGE='"bash"' -DSHELL -DHAVE_CONFIG_H -DHPUX -I. -I. -I./include -I./lib -I./lib/intl -I/tmp/bash-3.1/lib/intl -g -c y.tab.c "/usr/src/local/chet/src/bash/src/parse.y", line 4891: error #2020: identifier "mbrlen" is undefined mbclen = mbrlen (shell_input_line + previ, i - previ + 1, &mbs); ^ 1 error detected in the compilation of "y.tab.c". *** Error exit code 2 Stop. Thanks for your support. -norio -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Norio Ishizaki Inspire International Inc. Email: [EMAIL PROTECTED] URL:http://www.inspire-intl.com Main : +81-3-5333-7480 Fax : +81-3-5333-7494 -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: completion inconsistencies involving symlinks
"Kartik K. Agaram" <[EMAIL PROTECTED]> wrote: > I conclude that the 'logical path' is maintained only by the shell, not in > the filesystem. If I'm right, then the whole notion of logical path is a > leaky abstraction honored only by 'cd -L' (are there any others?). I would > really like to be told I'm wrong. Sorry, you're not wrong. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: incorrect brace expansion when using default values
On 9/6/06, Chris F.A. Johnson <[EMAIL PROTECTED]> wrote:
On 2006-09-06, Andreas Schwab wrote:
> [EMAIL PROTECTED] (Paul Jarc) writes:
>
>> Mike Frysinger <[EMAIL PROTECTED]> wrote:
>>> this little bit of code doesnt work right:
>>> foo() { echo "${1:-a{b,c}}" ; }
The first '}' is interpreted as the end of the parameter expansion.
>>
>> Brace expansion happens before parameter expansion (man bash,
>> EXPANSION).
>
> Brace expansion doesn't come into play here, because the braces are
> quoted.
Quote them, and they do expand:
$ foo() { echo "${1:-"a{b,c}"}" ; }
$ foo
ab ac
However, there is a problem:
$ foo 1
1 1
Where is the second '1' coming from?
It seems
foo() { echo "${1:-"a{b,c}"}" ; } expands to
foo() { echo ${1:-ab} ${1:-ac} ; }
--
Chris F.A. Johnson
===
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
