[Bash-completion-devel] Bug#501479: Bug#501479: bash-completion: Many incorrect assumptions based on uname

[David Paleino]

retitle 501479 don't assume sed being GNU sed on Linux systems

clone 501479 -1
retitle -1 check for the use of `uname` within man, apropos, whatis completions
priority -1 minor

clone 501479 -2
retitle -2 check for conflicts with killall5 (killall on SysV) for killall, pkill and pgrep completions

clone 501479 -3
retitle -3 don't use uname for pidof completion, just check for its presence
block -3 by -2
priority -3 minor

clone 501479 -4
retitle -4 don't use uname for if{up,down,status}, just check for their presence
priority -4 minor

clone 501479 -5
retitle -5 don't use uname for iw{config,list,spy,priv}, just check for their presence
priority -5 minor

clone 501479 -6
retitle -6 don't use uname for ipsec, just check for its presence
priority -6 minor

clone 501479 -7
retitle -7 don't use uname for route, just check for its presence
priority -7 minor

clone 501479 -8
retitle -8 complete for 'cc' also on !GNU, !Linux and !Cygwin
priority -8 minor

clone 501479 -9
retitle -9 unused local variable UNAME in _info()
priority -9 minor

thanks

On Tue, 07 Oct 2008 10:53:10 -0700, Josh Triplett wrote:

> Package: bash-completion
> Version: 20080705
> Severity: normal

Hello Josh,
it would've been better if you filed a separate bug for each of the issues you
found. I'm doing this right now, so please reply to each bug separately.

> bash-completion extensively uses the value of uname -s to decide which
> completions to provide, making assumptions that will fail for several
> of Debian's non-Linux ports, or for more unusual systems running on
> Linux.  In general, any reference to the uname in bash-completion
> represents a bug, given that the kernel in use may not correlate with
> expectations of userspace behavior.

Ok, thanks for the information.
We (me and Luk) adopted bash-completion from upstream, which completely
abandoned it, and now we are upstream ourselves.
I'm not personally involved, nor experienced at all, with non-Linux ports of
the GNU system. I don't know about Luk, but he's probably far too busy with the
Lenny release that he won't work on bash-completion anyways.

So, I kindly ask your help for some of the issues you found. And, possibly, I
kindly ask you to file *every* issue you find for non-Linux ports of the GNU
system (as a Linux-only user, I am not aware of possible implications, apart
from well-known ones).

> Some of bash-completion's assumptions (not a complete list):
> 
> * bash-completion assumes that a uname of Linux implies that the "sed"
>   command refers to GNU sed, while on other systems it aliases sed to
>   "gsed" if present.  While not possible on Debian, someone could
>   easily make a Linux system with GNU sed installed as "gsed" and some
>   other standards-compliant sed installed as "sed".  Why bother having
>   the check for Linux at all?  Just always use "gsed" if present.
>   Incidentally, bash-completion also leaves the alias sed=gsed in
>   place if added, which seems like a surprising side-effect to occur
>   due to sourcing bash-completion.

Ok, will work on this.

> [..]

Please see corresponding bugs for each of the reported issues.

Kindly,
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/bash-completion-devel/attachments/20081010/b41956c0/attachment-0002.pgp