Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A big part of my daily job is developing software for use on machines with different versions of the same software, like bash, find, and grep. When encountering a feature which would be useful for example to simplify code, it is important to know whether this feature is available in the oldest installed tools. For critical stuff, it would also be useful to know whether this feature was new or has existed for years in the oldest installed tools.

What are quick ways to answer this authoritatively for Linux tools, especially the GNU Core Utils? Some possibilities in order of decreasing accuracy:

  • Binary binary search (sic) by running the different versions is of course the ultimate answer, but is by far the most time consuming. Older installations are often not available for security reasons.
  • Reading the code is almost as good, but it can be prohibitively time consuming if the feature is vaguely named, the name doesn't correspond directly to variable/function/object names, or it was implemented before it was enabled.
  • Change logs, when available, usually connect feature changes to software versions.
  • Commit logs can provide hints, but do not know which version they will be included in.
  • man pages rarely mention dates.
  • The same applies to Googling, and you'd also have a hard time excluding all the non-authoritative sources.
share|improve this question
Could you perhaps elaborate on the reason(s) behind this question? – Faheem Mitha Mar 23 '11 at 9:00
up vote 7 down vote accepted

Generally, there's a changelog. In fact, this (or other "prominent notices" of changes) is required by the GPL! (At least, effectively so for anything with multiple contributors — see GPLv2 section 2a.)

For the GNU coreutils package — and for pretty much everything else from the GNU project directly — this file is definitely the first place to look, and should answer your question 95% of the time.

share|improve this answer
Do you have a reference to the coreutils change log? The newest I could find was from 2007. – l0b0 Mar 23 '11 at 9:37
GNU Coreutils ChangeLog has not been updated since 2007. cvs.savannah.gnu.org/viewvc/coreutils/… You have to look at the git logs now. – Mikel Mar 23 '11 at 9:43
It may be auto-generated from the git logs. There's a ChangeLog.bz2 in /usr/share/doc/coreutils-8.10 on my Fedora system, and the top entry is from 2011-02-04. Possible also that this is a RH fork — I'll check into that later today. – mattdm Mar 23 '11 at 10:19
@mattdm: There's /usr/share/doc/coreutils/changelog.gz on Ubuntu - Thanks! Unfortunately it only goes back to 2008, which is too recent for some of the relevant tools. I guess it takes over where the last one ended, though. – l0b0 Mar 23 '11 at 10:24
Here is the proof: git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING Scroll to line 131. – Shinnok Mar 23 '11 at 12:00

Why not use the source control afferent to X to search for feature Y? The source repo is the best way to indentify when a particular feature was introduced.

For coreutils you can head to http://git.savannah.gnu.org/cgit/coreutils.git and search for keywords related to Y in log messages or particular lines of code you identified as belonging to Y. You can do that on the web interface directly, or even better, clone the source repo to your station and search using git-bisect, git-blame and git-log --grep.

Then Use git-describe to find out tag is the closest to a specific commmit. Tags are used for version numbers mostly, thus it will give you the version that introduced the commit.

You can adapt the above method, depending on X and it's source control.

share|improve this answer
How would you identify which commit / line went into which version of the software? Also, Savannah search is badly broken - No results for strings which are obviously in the same log messages. – l0b0 Mar 23 '11 at 9:26
Use git-describe to find out tag is the closest to a specific commmit. Tags are used for version numbers mostly. As for Savannah being broken, you can't do much about it. Git clone the repository to your box and work your way using the git commands i described in the post. – Shinnok Mar 23 '11 at 11:56

On Debian and Debian-derived platforms such as Ubuntu:

sudo apt-get changelog coreutils > changelog.txt 

provides the GNU Core Utilities' changelog all the way back to version 4.5.1-1.

Not sure if there are similarly convenient solutions on other platforms.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.