2

Can I somehow find out more about the history of the development process of the GNU coreutils commands? For example, have su and runuser (which provide kind of similar functions, yet were decided to be split up into two commands) always co-existed or did one precede the other? I don't really know where to start looking. info runuser on my Ubuntu 18.04 has

July 2014

at the bottom of the page. I guess that date has something to do with when the info page has been written or modified, as runuser itself will, of course, have to be much, much older. So no luck there or in the man page. The linked GNU website appears cluttered to me, but maybe I just fail to navigate it properly.

I only picked su and runuser as an example. I'm interested in all of the GNU coreutils development.

Where should I start looking? What's a good resource? Does documentation even exist that far back?

  • Are either of su and runuser actually part of GNU coreutils though? I don't think they are. – Kusalananda Nov 19 '19 at 18:35
  • Yeah, I might have picked kind of bad examples, I think. It seems like they've been moved out of coreutils. (Recently...? I don't know.) There is still a link to the GNU coreutils page in their manpages, though. – finefoot Nov 19 '19 at 18:36
  • Did you look at the NEWS file in the coreutils source distribution? – Kusalananda Nov 19 '19 at 18:38
3

To follow a larger development project, there are a certain number of things you can do:

  1. Sign up on the project's mailing list(s) and follow the current discussions. Sometimes there are both users' lists and developers' lists. You don't need to send messages to the list, you could just lurk and read what people are saying and observe how things are discussed and how decisions are taken. I tend to also sign up to commit message lists and bug mailing lists, if these are available for subscribing to 1. You will start to pick up names of frequent contributors after a while, which may be useful while reading commit messages later.
  2. Dig into the mailing list archives, if these are available. Sometimes these may even be searchable, so you could possibly use that to do your history research to some degree.
  3. Check out the source code from wherever this is located, and build it (you don't actually have to install it). Have a look at changelogs or "news" files if you're interested in history. Learn how to check out the project for particular revisions, dates or tags, if you want to do source-level inspections or comparisons. Read commit messages.

The GNU coreutils "homepage" is at https://www.gnu.org/software/coreutils/coreutils.html

The mailing lists available are listed on that page, and there are links to searchable mail archives.

The project has a Github repository at https://github.com/coreutils/coreutils and you could easily use that to fetch any release (note that the code depends on the gnulib submodule). You could also "watch" the Github repository to get email notifications when new commits are made (this corresponds to signing up to a commit mailing list). This would also, I believe, make you receive copies of issue reports done via Github (there's a separate bug-reporting mail adderss, so issues posted on Github are likely ignored).

Depending on what you want to do in terms of learning more about the history of the project, the NEWS file in the Github repository may be a good first stepping stone in any history-related research, for this particular project.

As for su and runuser...

su was removed from coreutils in 2012. This was found by searching through the output of git log:

commit 928dd73762e69cfeaab4a7ec9dd8f30f86a45ed4
Author: Jim Meyering <jim@meyering.net>
Date:   Fri May 25 18:10:25 2012 +0200

    su: remove program (util-linux is now the best source for it)
[...]

I find no mentioning of runuser in the Github commit logs for coreutils. I suspect that it references coreutils only due to being a "stripped down version of su", which used to be part of coreutils.


1This means that I get about 2000-4000 emails a week for the projects I'm interested in, most of which I don't read more than the title of, if even that, but sometimes there are interesting things even in commit messages.

| improve this answer | |
  • 1
    All good advice! The nice thing about coreutils is that the history has been imported into the current git repository, so it’s possible to trace changes all the way back to 1992. The bug mailing list archives go back to 2002. – Stephen Kitt Nov 19 '19 at 19:15
  • Oh, this is really nice, thanks! :) I completely missed the GitHub link on their page. I've been reading in there since you posted the NEWS link in your comment above. "This means that I get about 2000-4000 emails a week" I will have to rethink how I'm using emails right now, haha. Also looking into util-linux now, which seems to be the one with su and runuser – finefoot Nov 19 '19 at 19:43
  • @finefoot Some of those projects include the OpenBSD and NetBSD projects, the Go language, the ksh93, zsh, and bash shells and others, and they have active lists. I don't follow coreutils or util-linux at all so I don't know what kind of traffic those lists are seeing. A glance at the archives should tell you that. – Kusalananda Nov 19 '19 at 19:46
  • @finefoot: In the days of IMAP you can do all filtering on the server side and locally just sync folders you are interested in and want to backup. I'm also subscribed to a number of mailing lists because you need to be subscribed to post something on some of them but never download e-mails from them. Also notice that you can use NNTP interface such as gmane.org to read and post to many mailing lists. OTOH, if your e-mail goes public you're screwed anyway and should prepare for a lot of spam. – Arkadiusz Drabczyk Nov 19 '19 at 19:50
  • 2
    runuser was introduced in 2012, based on a su patch from Fedora. – Stephen Kitt Nov 19 '19 at 20:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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