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

[Josh Triplett]

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