bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: coreutils version number policy


From: Bob Proulx
Subject: Re: coreutils version number policy
Date: Sun, 17 Jul 2005 23:08:09 -0600
User-agent: Mutt/1.5.9i

Heiner Steven wrote:
> please excuse me if this is not the right mailing list to ask
> the question.

You have the right mailing list.  This is used for both discussion and
for bug reports.

> I have two different systems (Debina and SuSE), both with
> coreutils version 5.2.1 installed. The "uniq" commands on both
> system print the same version number (5.2.1), but support different
> command line options. In particular the first system's "uniq" supports
> the "-W" option, the second system's "uniq" does not.

Interesting...  I was unaware of that addition.

> Is this a (version numbering) bug, or intended behavior?

In a strict sense it is intended behavior because the packager did it
intentionally.

The "upstream" coreutils are the basic file, shell and text
manipulation utilities of the GNU operating system.  Additionally they
have been ported to many other systems.  They are licensed under the
GPL.  This allows anyone the freedom to make changes and
modifications.

What you are seeing with the -W option in Debian is a distribution
specific patch to the code to provide that option and associated
functionality.  It is not in the upstream GNU coreutils.

I looked in the Debian source (apt-get source coreutils) and I see
that it has been added by the Debian maintainer in a patch called
uniq-seperator-check-fields.  This may independently appear in other
distributions.  Also other distributions may include other
functionality not included in Debian.  This is often described as a
the "bazaar" development model because there is a lot of flexibility
and many possibilities.

I looked in the /usr/share/doc/coreutils/README.Debian file for Debian
specific information and I see the following:

  Be aware that the following modifications have not been accepted 
  upstream and should be avoided in portable applications:
  * uniq: --separator and --check-fields
  * cat: --reversible
  * tsort: cycle breaking
  * join: -n
  * paste: --first-eof

> I thought that the "coreutils" version number described a set of
> commands together with their features and bugs, new features
> causing a new version number.

And for the upstream project that is true.  Taken in isolation of any
changes to the upstream the version number is always modified when new
versions are released and so would uniquely describe a full set of
features.  But distros do often make modifications to upstream sources
for their own purposes.

> If a shell script depends on uniq's "-W" feature, how can it
> check for the right "coreutils" version, without actually
> calling "uniq --help" and parse its output?

I often find the need for just these types of tests.  I recently
needed to check that the rsync I was using had the recently added
--files-from option or I needed to fail with an appropriate error
message.  I came up with something similar to the following.

  if (rsync --files-from=/dev/null --version) >/dev/null; then : else
    echo "Error: missing rsync with --files-from option" 1>&2
    exit 1
  fi

Looking for a -W option would be similar.  Here is one way to do it.

  if (uniq --check-fields=1 /dev/null) >/dev/null; then
    uniq -W 1 $file
  else
    : handle the problem of not having -W available
  fi

Or perhaps if it is something that is only optional:

  if (uniq --check-fields=1 /dev/null) >/dev/null; then
    w_opts="--check-fields=1"
  fi
  uniq $w_opts ...

Hope that helps,
Bob




reply via email to

[Prev in Thread] Current Thread [Next in Thread]