[Bash-completion-devel] Bug#501479: bash-completion: Many incorrect assumptions based on uname
Josh Triplett
josh at freedesktop.org
Tue Oct 7 17:53:10 UTC 2008
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
More information about the Bash-completion-devel
mailing list