$PWD completion wrong
Configuration Information [Automatically generated, do not change]: Machine: amd64-linux OS: suse114 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='amd64-linux' -DCONF_OSTYPE='suse114' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/scr/os2-suse114/koenig/bash-4.2.8-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.37.6-0.7-default #1 SMP 2011-07-21 02:17:24 +0200 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.2 Patch Level: 8 Release Status: release Description: echo $PWD/ expands to echo \$PWD/ which is *wrong* (and does not work neither for futher file name completion nor for calling whatever with the real directory path as argument). same happens with 4.2.10 (opensuse 12.1 beta-test), but works fine with bash-3.* and bash-4.1 for my opensuse bug report see https://bugzilla.novell.com/show_bug.cgi?id=725657 Repeat-By: typeecho $PWD/ -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196
empty lines at the end of quoted command subsitutions missing
Configuration Information [Automatically generated, do not change]: Machine: amd64-linux OS: sles10, suse 11.1, suse 11.3 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/flebbe/bash-3.2.25-3/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.27.45-0.1-default #1 SMP 2010-02-22 16:49:47 +0100 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: empty line(s) at the end of quoted command subsitutions are missing: example: # echo "$( echo ; echo a ; echo "b" ; echo "" ; echo "" ; echo ) " ; echo done a b done # while there should be two empty lines between "b" and "done" like this : # echo "$( echo ; echo a ; echo "b" ; echo "" ; echo "" ; echo ) " ; echo done a b done # bash 4.1.7(1)-release from opensuse 11.3 gives the same output, but Im still mostly bash3-based, so a fix for this in bash3 is welcome too;) Repeat-By: echo "$( echo ; echo a ; echo "b" ; echo "" ; echo "" ; echo ) " ; echo done -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196
Re: $PWD completion wrong
Hi Chet, On Oct 21, Chet Ramey wrote: > Yes. Look at the bug-bash list archives for extensive discussion on > this topic. There will be several changes and fixes in the next bash > release to address this and other completion issues. thanks for your quick reply! I found/read Subject: bash tab variable expansion question? - msg#00273 is there any other thread ? more important: is there any patch available to get back to the good old behaviour ? opensuse is very close to release 12.1 (they're more or less on RC1) and I (not related to *suse*) would be *very* happy if they'd ship a litte-bit-less-broken bash if possible;-) btw: where can I find decent bash development sources ? http://www.gnu.org/s/bash/ points to http://savannah.gnu.org/projects/bash/ but there, the CVS is emmpty and http://savannah.gnu.org/git/?group=bash git://git.savannah.gnu.org/bash.git stops at 2009-09-12, nothing newer:-( thanks for any pointer to a revert patch... 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\ \ OOOOO|// Harald Koenig \/\/\/\/\/\/\/\/\/ science+computing ag// / \\ \ koe...@science-computing.de^ ^ -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196
Re: $PWD completion wrong
On Oct 21, Chet Ramey wrote: > On 10/21/11 2:42 PM, Harald Koenig wrote: > > If you read further in that thread, you'll find a message I sent out on > 9/2 containing a patch that adds a `direxpand' option. The new option aaah! the web mailing list browswer didn't step from february to march with "thread next" :-((( thanks!! > is intended to restore the bash-4.1 behavior of performing word expansion > on variables in directory names when completing. It works pretty well; > there are a couple of rough edges that will be worked out. > > Look for <4e612f5b.5040...@case.edu>. yes, that's what I was looking for! a very quick first test with 4.2.8 and "shopt -s direxpand" looks like that's what I'll use for now! I'll forward your hints to that mail/patch to suse and see what they'll do;-) thanks a lot for your quick help and solution!! 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// / \\ \ koe...@science-computing.de^ ^ -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196
close(63) after ENOEXEC
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -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 -g -O2 uname output: Linux foo 3.2.0-64-generic #97-Ubuntu SMP Wed Jun 4 22:04:21 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.3 Patch Level: 18 Release Status: release Description: bash closes fd #63 for process subsitution when executing script without shebang line. I don't see why this might be a feature -- so I assume it's a bug;) this happens with bash-4.2.25(1) from Ubuntu 12.04 LTS, and the freshly built 4.3.18(1) (just to be sure it's not fixed in the mean time...) Rationale: I want to run some scripts identically on both Linux and Android with bash. but on android bash is installed in /system/bin/bash (vs. /bin/bash on Linux) and I do not want to add some symlinks for "/system -> ." or similar, so I can't use shebang to explicitly start bash... so far this seems to be the only bash feature which breaks when using "#" instead of "#!/bin/bash" Repeat-By: cat > works.sh <<'EOF' #!/bin/bash ls -l /dev/fd/ cat $1 EOF cat > breaks.sh <<'EOF' # ls -l /dev/fd/ cat $1 EOF chmod +x works.sh breaks.sh ./works.sh <( echo test works ) ./breaks.sh <( echo test breaks ) thanks for a fix (and not explaining why it might be a (anti-)feature;-), 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 // / \\ \ koe...@tat.physik.uni-tuebingen.de ^ ^
$* and $@ broken on some (64 bit?) platforms in bash 3.1
Configuration Information [Automatically generated, do not change]: Machine: powerpc OS: darwin8.0 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='powerpc' -DCONF_OSTYPE='darwin8.0' -DCONF_MACHTYPE='powerpc-apple-darwin8.3.0' -DCONF_VENDOR='apple' -DLOCALEDIR='/scr/vemac1/koenig/bash-3.1/PREINSTALL//usr/local//share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DMACOSX -I. -I. -I./include -I./lib -I./lib/intl -I/scr/vemac1/koenig/bash-3.1/ARENA/32/lib/intl -O2 -D_LARGE_FILES -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 uname output: Darwin vemac1 8.3.0 Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC Power Macintosh powerpc Machine Type: powerpc-apple-darwin8.3.0 Bash Version: 3.1 Patch Level: 14 Release Status: release Description: $* and $@ show $1 (or $2, only on DEC Alpha) instead of " " (space) as separator of arguments. I've tried both bash 3.1 patch level 5 and 14 on Mac OS X, no difference. bash 3.00.16(2)-release does not show this bug! Repeat-By: ./mactest.sh x y z xxyxz xxyxz xxyxz arg1 = x arg2 = y with the following script: 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< #!/usr/local/bin/bash echo $* echo $@ echo "$@" echo "arg1 = $1" echo "arg2 = $2" 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< further testing on other platforms show the patterns below, so it looks like being a problem on some 64 bit platforms, but not on x86_64 (running SUSE 9.0). we're using gcc-3.3.3 or gcc-3.3.4 for building on those platforms. separator is $1: BASH_VERSINFO=([0]="3" [1]="1" [2]="5" [3]="3" [4]="release" [5]="hppa2.0w-hp-hpux11.11") xxyxz BASH_VERSINFO=([0]="3" [1]="1" [2]="14" [3]="4" [4]="release" [5]="powerpc-apple-darwin8.0") xxyxz BASH_VERSINFO=([0]="3" [1]="1" [2]="5" [3]="4" [4]="release" [5]="powerpc-ibm-aix4.3.3.0") xxyxz BASH_VERSINFO=([0]="3" [1]="1" [2]="5" [3]="3" [4]="release" [5]="ia64-hp-hpux11.22") xxyxz separator is $2: BASH_VERSINFO=([0]="3" [1]="1" [2]="5" [3]="3" [4]="release" [5]="alphaev56-dec-osf4.0e") xyyyz ok: BASH_VERSINFO=([0]="3" [1]="1" [2]="5" [3]="3" [4]="release" [5]="hppa2.0w-hp-hpux11.00") x y z BASH_VERSINFO=([0]="3" [1]="1" [2]="5" [3]="2" [4]="release" [5]="hppa2.0-hp-hpux10.20") x y z BASH_VERSINFO=([0]="3" [1]="1" [2]="5" [3]="2" [4]="release" [5]="i686-pc-linux-gnu") x y z BASH_VERSINFO=([0]="3" [1]="1" [2]="5" [3]="2" [4]="release" [5]="sparc-sun-solaris2.5.1") x y z BASH_VERSINFO=([0]="3" [1]="1" [2]="5" [3]="2" [4]="release" [5]="x86_64-unknown-linux-gnu") x y z BASH_VERSINFO=([0]="3" [1]="1" [2]="5" [3]="3" [4]="release" [5]="sparc-sun-solaris2.8") x y z BASH_VERSINFO=([0]="3" [1]="1" [2]="5" [3]="2" [4]="release" [5]="powerpc-ibm-aix5.1.0.0") x y z BASH_VERSINFO=([0]="3" [1]="1" [2]="5" [3]="3" [4]="release" [5]="mips-sgi-irix6.5") x y z 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]^ ^ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: $* and $@ broken on some (64 bit?) platforms in bash 3.1
Hi again,
I've done some more testing -- but still I don't get the whole figure.
here are some more mosaic pieces for the jigsaw puzzle, maybe you know
what's going wrong here ?!
I've done some more compile tests mostly on HP-UX 11.11 (and 11.22).
my default build (which is broken) was with gcc used MULTIBYTE support.
trying to compile with system "cc" breaks because of broken wchar.h,
I need the following small patch
---
--- orig/bash-3.1/config-bot.h 2004-03-19 23:56:23.0 +0100
+++ bash-3.1/config-bot.h 2006-03-27 15:18:33.0 +0200
@@ -139,6 +139,17 @@
# endif
#endif
+/* HAK: wchar.h is broken on HP-UX */
+#if defined (HAVE_WCHAR_H) && defined(__hpux__)
+#include
+size_t mbrlen(const char *s, size_t n, mbstate_t *ps);
+size_t wcsrtombs(char *dst, const wchar_t **src, size_t len, mbstate_t *ps);
+size_t wcrtomb(char *s, wchar_t wc, mbstate_t *ps);
+size_t mbrtowc(wchar_t *pwc, const char *s, size_t n, mbstate_t *ps);
+size_t mbsrtowcs(wchar_t *dst, const char **src, size_t len, mbstate_t *ps);
+#endif
+
+
/* If we don't want multibyte chars even on a system that supports them, let
the configuring user turn multibyte support off. */
#if defined (NO_MULTIBYTE_SUPPORT)
---
but again this binary still is broken.
next I compiled with
#undef HANDLE_MULTIBYTE
at the end of config-bot.h. using system cc, the binary still shows the same
problems, but the "gcc" binary seems to be ok!!
using "#undef HANDLE_MULTIBYTE" on Mac OS X removes those problems too.
I've looked into the errors in output of "tests/run-test" using,
it's not the test itself which fails but argument passing
to the shell function:
./bash -c ' t() { test "$@"; echo -n "$@ $? "; } ; t -a noex ; test -a
noex2 ; echo $? '
correct output (cc no-MB):
-a noex 1 1
bad output:
-aÏÏnoex 0 1
^^
there are two 0xCF charaters after "-a" instead of the space.
or on Mac OS X with non-working HANDLE_MULTIBYTE :
-a-anoex 0 1
I don't really like the idea to disable HANDLE_MULTIBYTE on platforms
like HP-UX 11.11/22 or even Mac OS X -- there must be another solution ?!?!?
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]^ ^
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
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
Re: completion always appends /
On Aug 15, [EMAIL PROTECTED] wrote:
> 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!!!
update: thanks to the discussion with a colleague and many more tests
we found a method to trigger that / bug. means to press the TAB key:
setup:
mkdir emptydir
cd emptydir
mkdir dir
touch file
good: (note the space afte 1st backquote!!)
echo ` ./di`
gives
echo ` ./dir/`
echo fi
gives
echo file
BUT:
echo `./di`
now
echo fi
gives
echo file/
until you exit bash or you patch the contents of rl_completion_append_character
back to value ' ' (32).
thinking a bit more about this example makes me guess that
the special code to change rl_completion_append_character to '/'
is mostly useless but pretty harmfull ?!
for now I use the following hack patch which avoids triggering the
always-/-bug with the only drawback that there will no / after `./dir
with no space after `
---
--- bashline.c~ 2006-07-29 22:39:30.0 +0200
+++ bashline.c 2007-08-15 11:05:19.0 +0200
@@ -1598,9 +1598,11 @@
/* If there's a single match and it's a directory, set the append char
to the expected `/'. Otherwise, don't append anything. */
+#if 0
if (matches && matches[0] && matches[1] == 0 && test_for_directory
(matches[0]))
rl_completion_append_character = '/';
else
+#endif
rl_completion_suppress_append = 1;
}
---
Fix:
some more thinking the issue leads me to a better solution (forget about
the patch above, now it's only worth for documentation of cognition;)
what if I just reset the append_character just after being used once...
there are two possible places or such a reset, at your choice:
---
--- lib/readline/complete.c~2006-07-28 17:35:49.0 +0200
+++ lib/readline/complete.c 2007-08-15 11:14:20.0 +0200
@@ -1528,6 +1528,8 @@
else if (rl_completion_suppress_append == 0 &&
rl_completion_append_character)
temp_string[temp_string_index++] = rl_completion_append_character;
+ rl_completion_append_character = ' ';
+
temp_string[temp_string_index++] = '\0';
if (rl_filename_completion_desired)
---
or
---
--- lib/readline/complete.c~2006-07-28 17:35:49.0 +0200
+++ lib/readline/complete.c 2007-08-15 11:14:20.0 +0200
@@ -1569,6 +1569,8 @@
rl_insert_text (temp_string);
}
+ rl_completion_append_character = ' ';
+
return (temp_string_index);
}
-------
with this reset (no other patch), bash completion works fine for me
(no unwanted slashes anymore;-)
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
Re: completion always appends /
Hello GNU Bash developers!
a week ago I've send you a bug report and as follow-up the fix patch below,
but so far I did not get any reply, not even an ACK or ticket number
that anyone received my mails.
I would like to roll out that bug fix and did hope that I'll get
a) any reaction and comment on my report and esp. on the patch
b) this will be a an official patch before I roll out my new binaries.
otherwise I'll have to revert my patch later and apply your
(possibly different and better) fix later, resulting in another rollout
which I'd like to avoid...
anyone reading bash-bug mails these day ?
any comments or suggestions/optimizations for this patch ?
thanks for any hint!
On Aug 15, Harald Koenig wrote:
> ---
> --- lib/readline/complete.c~ 2006-07-28 17:35:49.0 +0200
> +++ lib/readline/complete.c 2007-08-15 11:14:20.0 +0200
> @@ -1528,6 +1528,8 @@
>else if (rl_completion_suppress_append == 0 &&
> rl_completion_append_character)
> temp_string[temp_string_index++] = rl_completion_append_character;
>
> + rl_completion_append_character = ' ';
> +
>temp_string[temp_string_index++] = '\0';
>
>if (rl_filename_completion_desired)
> ---
>
> or
>
> ---
> --- lib/readline/complete.c~ 2006-07-28 17:35:49.0 +0200
> +++ lib/readline/complete.c 2007-08-15 11:14:20.0 +0200
> @@ -1569,6 +1569,8 @@
> rl_insert_text (temp_string);
> }
>
> + rl_completion_append_character = ' ';
> +
>return (temp_string_index);
> }
>
> ---
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
Re: completion always appends /
Hi Chet, thanks for your quick answer! On Aug 22, Chet Ramey wrote: > > a) any reaction and comment on my report and esp. on the patch > > The code fix is in the wrong place; it needs to go into > set_completion_defaults(). thanks for this pointer! > > b) this will be a an official patch before I roll out my new binaries. > > There may not be an official patch for this; it's a relatively minor issue. YMMV. for me and some of my colleagues it's not that minor at all. my typical "work week" is to login on monday moring and logout every friday evening. during this time I "collect" multiple xterms with bash each having a directory stack of ~10-30+ and quite often 10++ backgound jobs (so I'm pretty shell based;) loosing the whole context of such a shell is pretty annoying, and with that / appended to every completion it's no fun anymore to work with such a shell... so for some of us this is real issue and one major reason to roll out a new bash version on 200+ machines (10+ different plattforms)... anyway, thanks for your help finding the correct place for this fix, 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
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
