Skip to main content

How to make Linux feel like Unix

Take a trip back in time to 1972, and see what it's like for a modern Linux user to work exclusively in the Unix terminal.
Photo of a Teletype DMD 5620

Image Marcin Wichary, CC BY 2.0, via Wikimedia Commons

You might not give much thought these days to Unix or what it means. In 2022, most "Unix" systems are actually running some version of Linux, which includes modern tools and commands that were unthinkable when Unix hit the scene in the early 1970s. But here we are, some 50 years later, and Unix still lives on.

[ Learn how to manage your Linux environment for success. ]

I wanted to look back on Unix's history and experience first-hand what it was like to use the original Unix. Unix 2nd Edition debuted in June 1972, and I chose that version as my target. That's transporting back in time 50 years.

Setting the stage

A big part of running Linux as the original Unix was the interface. I run my desktop Linux with GNOME, where I use graphical user interface (GUI)-based applications like LibreOffice, Firefox, Inkscape, and Rhythmbox. But Unix 50 years ago didn't have a graphical interface. Everything was on the command line.

In the late 1960s, the computing "interface" was usually a teletype terminal, a kind of electronic typewriter that printed input and output on a long roll of paper. By the 1970s, electronic display terminals became more common. While simple, these "video display units" approached what we recognize today as a terminal emulator window.

That's how the team at Bell Labs used Unix in 1972, and that's how I decided to use Linux 50 years later, in 2022. While I still booted my Linux system into GNOME, I did all of my work using GNOME Terminal.

You can use GNOME Terminal like a 1970s video terminal.
(Jim Hall, CC BY-SA 4.0)

[ Download now: A sysadmin's guide to Bash scripting. ]

Setting my goals

For several weeks, I configured my Linux system to simulate an early Unix terminal from 1972. I restricted myself to only the commands that were available at the time, according to a copy of the Unix Programmer's Manual, Second Edition (June 12, 1972). For example, I interacted with Linux only via the command line, and edited files using ed, as our primitive ancestors once did.

I assigned myself a few tasks for this "throwback" experiment:

  1. Write a non-trivial C program with the ed editor.
  2. Write a FORTRAN 66 program.
  3. Prepare a document using nroff.

What it's like

With those limitations, I threw myself into Unix from 50 years ago. At first, the difference was jarring. While I didn't mind using the command line, I wasn't able to use many of the modern commands I've grown accustomed to. Even the multipurpose awk command was missing; awk was created in 1977 and first appeared in Unix 7th Edition in 1979.

Despite the gap of so many years, we would still favorably compare the original Unix to today's Linux. Certainly, the command line would feel familiar. The original Unix tools introduced in Unix 1st Edition (1971) included commands we use every day on Linux systems, such as cat to display files, cp to copy files, df and du to report disk usage, ls to list files, rm and rmdir to remove files and directories, and a long list of other now-familiar commands. Unix 2nd Edition also introduced the man command to read system documentation, which was processed with nroff.

Yes, I was able to complete the three tasks I set for myself: I wrote several C programs, and I wrote a special file-loading function for another project I'm working on entirely in ed. I used GNU gfortran to write a FORTRAN 66 program that performed numerical analysis simulation of trajectory data, similar to other data-analysis programs I wrote as an undergraduate physics student in the early 1990s. Fortunately, gfortran is backward-compatible with previous iterations of the FORTRAN language and can compile a FORTRAN 66 program without problems.

I relearned nroff and created my own set of macros to help write a few documents. I used GNU groff to emulate the old nroff and wrote my own macros. I wrote the first draft of this article this way.

After a few hours of working entirely at the terminal, I settled into a rhythm. After another day, I became quite productive. Once I slipped into the mindset of working entirely in character mode, leveraging the command line, and processing plain-text files, things felt fairly smooth. I became more comfortable using ed to work on files, and soon the editor's commands became almost second nature.

Working completely inside a terminal, I found myself getting into a "zone." At the end of each day during the experiment, it felt a little weird to check my email in a graphical client or to visit websites in a web browser. The terminal is a different experience, yet very effective.

What I learned

This was a fun experiment to demonstrate what Unix was like 50 years ago. It reminded me about the power of using the command line and the flexibility to do things my way. I first used Unix systems in 1992 as an undergraduate student, and this experience reminded me why I fell in love with the command line. If you don't mind typing your commands and learning a little command syntax, you can do almost anything.

But times have changed, and our work has changed with it. These days, I can't manage my daily work from the terminal. I rely on new tools such as visual word processors, graphics programs, and web browsers. So while I enjoyed this look back at Unix from 50 years ago, I was also glad to return to my GNOME desktop when it was over.

Topics:   Linux   Programming   Command line utilities  
Author’s photo

Jim Hall

Jim Hall is an open source software advocate and developer, best known for usability testing in GNOME and as the founder + project coordinator of FreeDOS. More about me

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.