Package: bash-completion Version: 20080705 Severity: normal 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.
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. * Completion for the "man", "apropos", and "whatis" commands depends on a uname of GNU, Linux, Darwin, FreeBSD, SunOS, Cygwin, or OpenBSD. This misses at least NetBSD, if not others. This completion seems applicable to any system which has the appropriate commands. Furthermore, the completion function itself makes assumptions about how to determine manpaths based on a subset of those unames. * Completion for killall, pkill, and pgrep depends on a uname of Linux or FreeBSD. I suspect this relates to the identically named but drastically different SysV killall command, found as "killall5" on Debian systems. * Completion for the commands pidof, ifup, ifdown, and ifstatus depends on a uname of Linux; however, these commands exist on other systems as well. Checking for the presence of the command seems sufficient. * Completion for the commands iwconfig, iwlist, iwspy, iwpriv, ipsec, and route depends on a uname of Linux. While these commands indeed do run only on Linux, it seems better to simply check for the commands in question rather than the kernel in use. That way, if the commands ever run on non-Linux systems, bash-completion will not need updating. For instance, other systems have a "route" command which behaves similarly, though I do not know if the existing completions will work unmodified on it. * Completion for the various GCC compilers occurs on any system, but only with a uname of GNU, Linux, or Cygwin will bash-completion add those same completions to the "cc" command. bash-completion probably assumes that other systems will not have gcc installed as "cc". * The completion for "info" declares a local variable "UNAME" but never uses it. - Josh Triplett -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.27-rc7-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages bash-completion depends on: ii bash 3.2-4 The GNU Bourne Again SHell bash-completion recommends no packages. bash-completion suggests no packages. -- no debconf information _______________________________________________ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel