[Bash-completion-devel] Bug#497597: bash-completion: gdb argument completions returns error

[Kevin Mitchell]

Ok, well it probably should have occured to me to actually include my
$PATH variable:

$ echo $PATH
:/home/kevmitch/bin:/usr/local/bin:/usr/bin:/bin:/usr/games

Note the preceding ":" which should include the current directory in
accordance with bash(1):

       PATH   The  search  path for commands.  It is a colon-separated
list of directories in which the
              shell looks for commands (see COMMAND EXECUTION below).
A zero-length  (null)  directory
              name  in  the  value  of PATH indicates the current
directory.  A null directory name may
              appear as two adjacent colons, or as an initial or
trailing colon. . .

If I turn that into
$PATH=.$PATH
$IFS=":"
$path_array=( $(echo "$PATH") )
$IFS=$'\n'
$find "${path_array[@]}" . -mindepth 1 -maxdepth 1 -not -type d
-executable -printf "%f\\n" > /dev/null
$
then we're good to go. I still can't say I completely understand this,
I guess because I don't really understand what's happening in 'find
"${path_array[@]}"'. I guess I would have expected this bug to show up
as find not searching the current directory. Is there a
straightforward way to search and replace an empty field with "." for
find's benefit other than a for/sed?

Kevin

On Sat, Sep 6, 2008 at 2:27 PM, David Paleino <d.paleino at gmail.com> wrote:
> On Sat, 6 Sep 2008 14:02:40 -0700, Kevin Mitchell wrote:
>
>> It seems to do the same thing. I tried picking things apart a little
>> more this time by just entering parts of the gdb entry in the shell.
>> Now I'm really confused:
>>
>> $ IFS=":"
>> $ path_array=( $(echo "$PATH") )
>> $ IFS=$'\n'
>> $ find "${path_array[@]}" . -mindepth 1 -maxdepth 1 -not -type d
>> -executable -printf "%f\\n" > /dev/null
>> find: cannot search `': No such file or directory
>
> I can't reproduce all this, sorry.
>
> $ IFS=":"
> $ path_array=( $(echo "$PATH") )
> $ IFS=$'\n'
> $ find "${path_array[@]}" . -mindepth 1 -maxdepth 1 -not -type d -executable \
>> -printf "%f\\n" > /dev/null
> $
>
> Could this be a find(1) bug? But, well, it should happen here as well.
> Do you have any "strange" configuration? LVM, ...?
>
>> $ echo find "${path_array[@]}" . -mindepth 1 -maxdepth 1 -not -type d
>> -executable -printf "%f\\n"
>
> find /home/neo/bin /usr/local/bin /usr/bin /bin /usr/games /home/neo/bin /sbin /usr/sbin /usr/local/sbin /home/neo/bin /sbin /usr/sbin /usr/local/sbin .
> -mindepth 1 -maxdepth 1 -not -type d -executable -printf %f\n
>
>> $ find  /home/kevmitch/bin /usr/local/bin /usr/bin /bin /usr/games .
>> -mindepth 1 -maxdepth 1 -not -type d -executable -printf %f\n >
>> /dev/null
>  $
>
> Ok, the same result I had above.
>
>> $ wtf?
>> bash: wtf?: command not found
>
> Oh, well :)
>
>> $ ls -l /bin/sh
>> lrwxrwxrwx 1 root root 4 2008-08-21 14:44 /bin/sh -> bash
>
> $ ls -l /bin/sh
> lrwxrwxrwx 1 root root 4 16 mag 14:53 /bin/sh -> bash
>
>> $ apt-cache policy findutils
>> findutils:
>>   Installed: 4.4.0-2
>>   Candidate: 4.4.0-2
>>   Version table:
>>  *** 4.4.0-2 0
>>         500 http://debian.yorku.ca testing/main Packages
>>         600 http://debian.yorku.ca unstable/main Packages
>>         100 /var/lib/dpkg/status
>>      4.2.28-1etch1 0
>>         400 http://debian.yorku.ca stable/main Packages
>
> $ LANG=C apt-cache policy findutils
> findutils:
>  Installed: 4.4.0-2
>  Candidate: 4.4.0-2
>  Version table:
>  *** 4.4.0-2 0
>        500 http://ftp.de.debian.org unstable/main Packages
>        100 /var/lib/dpkg/status
> $
>
>
> I can't really see anything different, apart from the very first part I quoted.
>
> Are you sure you aren't typing any strange-non-printable character? :)
>
> David
>
> --
>  . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
>  : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
>  `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
>   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
>