I would like to know which commands were re-written for Linux and which were retained from Unix?


It appears that you are confusing two very different parts of the OS. It's understandable, because they are often referred to interchangably, but it's technically incorrect, so your question is based on a faulty premise. In order to fully explore and hopefully answer the question that you likely want to ask, a short history lesson is needed.

First, there was UNIX. Basically, back in those days, UNIX meant the AT&T UNIX System, which came first. But AT&T UNIX became non-Free, so Richard Stallman started the GNU project to write a Unix system which was Free. Hence the name Gnu is Not Unix, abbreviated GNU. Plans for GNU were made public in 1983 and development began in 1984.

By the early 1990s, GNU had reimplemented most of the UNIX utilities from scratch. Wikipedia lists a few components of the overall system which were not rewritten (TeX, the X Window System, and the Mach microkernel are mentioned as examples of components that were not rewritten) but mostly, the userland tools were rewritten from scratch in order to meet the goal of avoiding reuse of any AT&T (or rather, non-Free) code, as well as expanding on their capabilities by adding command line options. As a result, the GNU utilities were regularly more powerful than the tools from which they drew their original inspiration.

At that point, GNU was still missing one vital component: an operating system kernel, which would allow everything to work together on an actual computer not running some other OS. In 1991, Linus Torvalds started working on a toy project which eventually became known as Linux. It was basically a school project to learn about the then-new 32-bit Intel 80386 CPU, and started out extremely simple, but eventually started to morph into an actually usable operating system kernel. But it didn't have any userland software; Linux on its own provides no shell, no system startup facilities beyond kernel initialization, no text editor, no graphical interface, nothing. The kernel is like a car engine; essential to make a useful car, but useless on its own (for a useful car, you need things like wheels, transmission, steering, somewhere for the driver to sit, a fuel tank or other store of energy, etc.). The Linux kernel was eventually distributed under the GNU General Public License, the same as the GNU software.

So people started to pair the two. You'd get a Unix-like userland, together with a kernel based around ideas from Unix (including a close resemblence to POSIX), complete with source code that you could hack away at however much you wanted, and it didn't cost anything. Especially before Linux distributions became common, it took a bit of tinkering to get things to work, but it was finished enough to be somewhat usable by those who were willing to spend some time on it.

These days, GNU provides a kernel of their own. You probably haven't heard of it, but it's called GNU Hurd. But Hurd wasn't around in the early 1990s, when Linux started gaining traction among hobbyists and tinkerers, so it was the combination of the Linux kernel and a mostly-GNU userland that got the most attention among developers.

Also, these days, many Unix systems install, or allow the administrator to install easily, parts of the GNU userland. You might see things like GNU bash, the GNU Compiler Collection, the GNU C library (vanilla or patched), and so on, on an otherwise non-GNU system.

To make matters even worse, some systems use the Linux kernel but no GNU userland at all. For a widely used example of this, consider Android OS, which is basically the Linux kernel coupled with a custom userland.

This is important because it significantly blurs the line between GNU, Linux and the various Unixes (there's only one UNIX, but there are many Unixes and yet more Unix-like OSes). When you're asking about Linux, you are really very often asking about the GNU/Linux system. But consider Debian GNU/kFreeBSD, which runs a GNU userland on top of the FreeBSD kernel, not using Linux at all. Or for example Solaris, on which you can easily install various GNU packages including e.g. coreutils. I think Mac OS X ships with parts of the GNU userland, too. Or consider the above-mentioned Android.

In the end, a usable GNU system might run non-GNU code, and a non-GNU system might run GNU code, but the GNU utilities don't contain non-GNU code.

  • 1
    Last time I used FreeBSD (years ago) it didn't use many GNU tools, but its own set - e.g. BSD make instead of GNU make. – reinierpost Aug 1 '13 at 15:59
  • 4
    @reinierpost OSX is very similar - a plain install contains mostly BSD versions of things, but GNU coreutils and the like are easily available through MacPorts and others. XCode utilizes LLVM, but also gcc. It's complicated :) – MattDMo Aug 1 '13 at 16:52
  • 1
    @reinierpost make isn't so bad to replace. The C compiler is a little more involved. At least FreeBSD 8.0 uses GCC as its default compiler; specifically version 4.2.1. The "licensing issues" referred to preventing integration of newer versions into the base system are probably about the switch from GPL2+ to GPL3+, but I haven't looked to be sure. – a CVn Aug 1 '13 at 18:11
  • 2
    @hunter2 It seems it wasn't needed, based on the vote counts thus far. ;) I didn't set out to write a full history either. Minix served an important role as a Linux development and bootstrap system before Linux became self-hosting, but has had little influence on e.g. the relationship between Linux, GNU and the original UNIX, which is more along the lines of what the question is about. – a CVn Aug 2 '13 at 10:52
  • 3
    @hunter2 If we were to go down that route, then it is absolutely true that UNIX certainly didn't come first either. But for the purposes of answering the question, this seemed a good enough approximation. The single sentence answer would have been something like "basically everything UNIX except TeX and X that you find on a Linux system was rewritten as part of GNU" but I think the additional context adds value, even if it made the answer significantly longer than absolutely necessary - and the answer still comes far short of covering every detail. – a CVn Aug 2 '13 at 11:25

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.