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
bash32-019 can't be applied
hi, http://frugalware.org/~vmiklos/logs/bash-3.2_025-1-i686.log after applying bash32-001..bash-018 patches, i can't apply bash32-019. is this expected? thanks, - VMiklos pgpL70fu2zUOk.pgp Description: PGP signature
Globbing omits file that should be included
Hi. I just ran into a globbing problem that doesn't at first sight seem to be caused by my environment. Details below. Terry --- Configuration Information [Automatically generated, do not change]: Machine: i386 OS: darwin8.5.1 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='darwin8.5.1' -DCONF_MACHTYPE='i386-apple-darwin8.5.1' -DCONF_VENDOR='apple' -DSHELL -DHAVE_CONFIG_H -DMACOSX -I. -I/sw/lib/include -I. -I./include -I./lib -I/sw/include -no-cpp-precomp uname output: Darwin terry-jones-computer.local 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 i386 i386 Machine Type: i386-apple-darwin8.5.1 Bash Version: 2.05b Patch Level: 0 Release Status: release Description: I have a mail directory with 6629 files in it. There is a file in the directory called OUT: ~/mail $ ls -la OUT -rw-rw-r--1 terryterry52088059 Aug 23 17:17 OUT There are also a bunch of other files, with names in the form OUT-MMDD-MMDD: ~/mail $ ls OUT* OUT-19890919-19900313 OUT-19941030-19950522 OUT-19981217-19990529 OUT-20030113-20030326 OUT-20060606-20061125 OUT-19900314-19901018 OUT-19950523-19951128 OUT-19990530-19990926 OUT-20030327-20030602 OUT.misc01 OUT-19901019-19910307 OUT-19951129-19960618 OUT-19990927-2305 OUT-20030603-20031001 OUT.misc02 OUT-19910308-19910827 OUT-19960619-19970203 OUT-2306-2630 OUT-20031002-20040509 OUT.misc03.asc OUT-19910828-19911129 OUT-19970204-19970531 OUT-2701-20001120 OUT-20040510-20041122 OUT.misc04 OUT-19911130-19920517 OUT-19970601-19970817 OUT-20001121-20010504 OUT-20041123-20050213 OUT.misc05 OUT-19920518-19921209 OUT-19970818-19980226 OUT-20010505-20011002 OUT-20050214-20050713 OUT-19921210-19930727 OUT-19980227-19980721 OUT-20011003-20020319 OUT-20050714-20051101 OUT-19930728-19940321 OUT-19980722-19981026 OUT-20020320-20020817 OUT-20051102-20060129 OUT-19940322-19941029 OUT-19981027-19981216 OUT-20020818-20030112 OUT-20060130-20060605 Notice how the OUT file is not included in the expansion of OUT* ??? I don't have any globbing vars set to do anything weird. As a test, when I make a new empty directory and touch the above file names (plus OUT), the OUT file _is_ matched by OUT*. I don't think any of the file names are affecting ls, as ls -- OUT* also misses the OUT file in the original dir, as does echo OUT* But, echo OUT* matches OUT in the test directory. So it looks like the failure to match OUT in my original directory has something to do with the directory itself.
Re: bash32-019 can't be applied
> hi, > > http://frugalware.org/~vmiklos/logs/bash-3.2_025-1-i686.log > > after applying bash32-001..bash-018 patches, i can't apply bash32-019. > is this expected? Nope. I just applied patches 1-25 to a freshly-unpacked copy of bash-3.2 without any failures. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/
short-circuit test ... -a ...
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux h-kub7 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.2 Patch Level: 13 Release Status: release Description: x=; test "$x" != "" -a "$x" -le 60 prints error: bash: test: : integer expression expected Shall not this *silently* short-circuit to false after subexpressio n '"$x" != ""' evaluated to false ? Repeat-By: always Fix: Short-circuit 'test ... -a ... 'when lhs evaluates to false.
Re: short-circuit test ... -a ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Yakov Lerner on 8/23/2007 11:24 AM: > > Description: > x=; test "$x" != "" -a "$x" -le 60 > prints error: > bash: test: : integer expression expected > Shall not this *silently* short-circuit to false after > subexpressio n '"$x" != ""' evaluated > to false ? According to POSIX, http://www.opengroup.org/onlinepubs/009695399/utilities/test.html, there is no requirement for -a to be short-circuiting, and the results of testing more than 4 arguments (you had 7) is unspecified. So there is no compelling reason to change the current behavior. If you want short-circuiting, do this instead: x=; test "$x" != "" && test "$x" -le 60 - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzftf84KuGfSFAYARArlOAJ9knaEbvPmpdfB9oR0JIav/IF/cUwCfUN9Y mRmMA4z/S9/MQ+vdxgPDYmo= =wKmK -END PGP SIGNATURE-
Numbering of items during completion
Hello list, I have several files with unicode characters in the file names. But I am using a German keymap, which only has a limited amount of characters mapped to it. The problem now is, if I want to change into a directory or open a file which has, say, a Korean character in it, I have no chance to open this file because I can't type in its character (I know, I could change the keyboard layout, but this is not convenient and sometimes, if I can't read the script, I have no way to input the files - Imagine a Chinese character, even though you can read chinese very well, it could happen that you cannot enter the character. Also, on the ordinary console, I have no way to change the keymap or use a more sophisticated input method). So I thought, what about numbering the files and directories? I think, the best possibility for this would be when the user types in the file name until he can't do it any further because he does not have the character on the keyboard. He would then press tab and a list of the directories would appear, just like it is now. The difference would be, that maybe every file or directory would have a number before it, which could then be accessed by maybe pressing an escape key and then by the number. e.g.: Several files, maybe file1 file2 datei1 datei2 directory1 directory2 If the user wants to get into directory2, he types “d”, presses Tab and then the following would appear 1| datei1 2| datei2 3| directory1/ 4| directory2/ he then types in an escape char and “4” which would result in changing the directory to directory2 Maybe there could be an option in a config file where the user would specify the characters he is able to input directly. So the mechanism to change by inputting numbers would only be displayed if there is a case where a file with a inaccessible character is shown. In all other cases, the user could change directories like he did all the time. This would really be good for using the command line. Right now, I sometimes have no other option but using a gui file manager where I can click onto the files. Thanks Gerrit Sangel
