bash-3.2 breaks mc (echo -e '\137')
Configuration Information [Automatically generated, do not change]: Machine: amd64-linux OS: suse90 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='amd64-linux' -DCONF_OSTYPE='suse90' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/scr/os2-suse90/koenig/bash-3.2.1-1/PREINSTALL//usr/local//share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -D_LARGE_FILES -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 uname output: Linux atuin 2.6.16.21-0.25-smp #1 SMP Tue Sep 19 07:26:15 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 3.2 Patch Level: 1 Release Status: release Description: bash versions before 3.2 all allowed echo -e '\137' to display an underscore, but now in 3.2 _only_ echo -e '\0137' seems to be valid. this breaks apps and scripts which (still) use the old (non-posix) always-three-digit-oactal-number scheme. one such application is mc (upto 4.6.1). the following fails _only_ with bash-3.2 so far: mkdir a_b cd a_b mc mc can't "cd" to $CWD because of the underscore in "a_b" which roughly gets translated into something like echo -e a\\137b | bash-running-on-pty which now fails. please tell me that this is just a bug in decent bash which will be fixed, and not yet another braindaed posix compatibility which breaks scripts which have been working really for decades! I know that using /bin/sh will work around this new habit, but IMHO that's not an option in quite some use cases (e.g. login shells;-)) Harald -- "I hope to die ___ _ before I *have* to use Microsoft Word.", 0--,|/OOO\ Donald E. Knuth, 02-Oct-2001 in Tuebingen.<_/ / /OOO\ \ \/OOO\ \ O|// Harald Koenig \/\/\/\/\/\/\/\/\/ science+computing ag// / \\ \ [EMAIL PROTECTED]^ ^ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
completion always appends /
Configuration Information [Automatically generated, do not change]: Machine: amd64-linux OS: suse90 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='amd64-linux' -DCONF_OSTYPE='suse90' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -D_LARGE_FILES -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 uname output: Linux atuin 2.6.16.27-0.9-smp #1 SMP Tue Feb 13 09:35:18 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 3.2 Patch Level: 17 Release Status: release Description: sometimes an instance of bash starts to append a / to every command or file name completion instead of a space character. I don't know what triggers this problem since it happens only every few weeks -- but it shows up for quite a long time now. comparing output of env/set/bin/complete never showed any significant difference between bad/good shells. yesterday the /-problem showed up again and I started to debug what's going on: sometimes 'rl_completion_append_character' will be set to '/' and it never will be reset back to ' ' : atuin bash-3.2 > grep -r rl_completion_append_character . ==> ./lib/readline/complete.c:int rl_completion_append_character = ' '; ./lib/readline/complete.c: else if (rl_completion_suppress_append == 0 && rl_completion_append_character) ./lib/readline/complete.c:temp_string[temp_string_index++] = rl_completion_append_character; ./lib/readline/readline.h:extern int rl_completion_append_character; ./lib/readline/readline.h: rl_completion_append_character will not be appended. */ ==> ./bashline.c: rl_completion_append_character = '/'; so far I don't understand how to trigger the change of rl_completion_append_character in bashline.c (I really would like to know which operation triggers that bug!!) and I'm not familar with the internal structures of bash to make a good guess where/when this variable should be reset to ' ' for the next completion operation (or, if it ever should be changed to / at all ?!) Repeat-By: set rl_completion_append_character to '/' -- no idea how to trigger that directly I _really_ would love to get rid of that annoying bug!!! thanks for any help or fix!! Harald -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196
command completion doesn't work with wildcards
Configuration Information [Automatically generated, do not change]: Machine: amd64-linux OS: suse10les Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='amd64-linux' -DCONF_OSTYPE='suse10les' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/scr/os2-sles10/koenig/bash-3.2.25-1/PREINSTALL//usr/local//share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -D_LARGE_FILES -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 uname output: Linux atuin 2.6.16.27-0.9-smp #1 SMP Tue Feb 13 09:35:18 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 3.2 Patch Level: 25 Release Status: release Description: command completion (1st parameter) doesn't expand exact matches, nor does it display matching patterns/files when using wildcards. doing completion on file paramters (2nd argument etc.) does expand the same patterns and does show possible matches. I'm not sure if this might be wanted behaviour (why? docs?), to me this looks like a bug -- or a nasty feature ;-) at least for my work style it would be nice if this would work too. I just checked older bash versions for this behaviour back to bash 1.14.7(1) on a RedHat-6.2 system -- they all don't show matches for the command completion, and bash 1.14.7 not even expanded the (uniqe) echo argument /bin/l*d* (and I was really sure that this worked in some older bash versions :-( so this doesn't look like a new bug, but a (wanted? why?) feature? Repeat-By: mkdir dir touch dir/foo-bar-baz chmod +x dir/foo-bar-baz does not expand nor show match(es): dir/foo*baz echo dir/foo*baz expands to echo dir/foo-bar-baz does not expand: cd dir ./foo* does not show any match: /bin/l*d* shows matches: echo /bin/l*d* thanks in advance (either for explaining why, or even better for changing;), Harald Koenig -- "I hope to die ___ _ before I *have* to use Microsoft Word.", 0--,|/OOO\ Donald E. Knuth, 02-Oct-2001 in Tuebingen.<_/ / /OOO\ \ \/OOO\ \ O|// Harald Koenig \/\/\/\/\/\/\/\/\/ science+computing ag// / \\ \ [EMAIL PROTECTED]^ ^ -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196
