The history of the ps command
Introduction
Introduction
The ps command will turn 50 years old this January (that is, January 2023).
Vital to the work of sysadmins, IT analysts, and operational engineers, the ps command line tool comes with a complex past.
Reflecting on its origins can help us appreciate the conflicts that produced it’s present character. Uncovering the stories of its history can keep us from getting complacent with our own ps usage patterns.
ps at 50
The ps utility is not a shell builtin (as are such commands as echo and alias).
ps is also not a part of the GNU coreutils, (containing familiar packages such as cat and ls).
In fact, ps is not a GNU userspace package at all. Nor is it part of the Linux kernel, nor the standard package of Linux utilities called util-linux.
The version included in almost all Linux distributions is part of an independently maintained package called procps (more formally, procps-ng, with ng an abbreviation for “next generation”). In total, the procps project contains seventeen process-related utilities under its umbrella:
free
kill
pgrep
pkill
pmap
ps — Report information of processes
pwdx
skill
slabtop
snice
sysctl
tload
top
uptime
vmstat
w
watch
Behind the scenes, these utilities share a common library called libprocps, which provides an API for reading from the /proc filesystem.
The procps project says it is “now the only maintained version of procps”. However, it is not the only maintained version of ps.
Even as procps has become nigh-ubiquitous as the default ps for thousands of Linux distros, it isn’t portable to other POSIX-compliant operating systems.
BSD-flavored operating systems maintain their own implementations of ps. MacOS has never had a /proc filesystem. OpenBSD eliminated its /proc in 2015, and FreeBSD keeps its /proc filesystem disabled by default. Naturally, the BSDs employ other methods to read which processes are currently running, and thus require different implementations of ps.
Curious invocations
To see the status of running processes on Linux, on BSD, or on many other operating systems, the ps command is crucial. This command is rarely useful without supplying some command line flags. Running ps without any arguments normally outputs only the name of your shell, and, depending on implementation, the running ps command itself. To look for some particular running process, piping ps aux or ps -ef through a grep search is a common pattern. Typically, all a system’s processes, regardless of owner or how they were initiated, will print to STDOUT when either of ps ax, ps -e, or ps -A are entered. Whether or not hyphens are required is system-dependent.
The Linux ps manual explains the “sometimes-hyphen” from the standpoint of various historical invocation styles.
This version of ps accepts several kinds of options:1UNIX options, which may be grouped and must be preceded by a dash.2BSD options, which may be grouped and must not be used with a dash.3GNU long options, which are preceded by two dashes.If this short explanation leaves you with additional questions, like “why are there command-line arguments that don’t need hyphens” or “how did we get so many different ways of supplying options”, then you’ve recognized some of the apparent mysteries around the ps command. To explore them, we can dig deeper.
Manuals today
Several ps implementations record crumbs of history within their man pages.
The MacOS man page for ps claims, rather oddly:
HISTORY
The ps command appeared in Version 4 AT&T UNIX.While this is technically true, it’s unclear why the previous version of AT&T UNIX, the 3rd edition, isn’t mentioned.
The OpenBSD man page for ps accurately states:
HISTORY
A ps command first appeared in Version 3 AT&T UNIX.Naïve computer historians might be tempted to believe this indicates the popular UNIX System III, released in 1982. It does not. Instead it refers to Research Unix, 3rd Edition, whose manual was written in early 1973.
The man pages for the DragonflyBSD, NetBSD, and FreeBSD implementations provide some additional clarity, all of them identically averring:
HISTORY
The ps command appeared in Version 3 AT&T UNIX in section 8 of the manualOn Linux, the man page shares even more historical context, but constrains the story to Linux’s ps, of the procps legacy.
Author
ps was originally written by Branko Lankester <lankeste@fwi.uva.nl>. Michael K. Johnson
<johnsonm@redhat.com> re-wrote it significantly to use the proc filesystem, changing a few things in the
process. Michael Shields <mjshield@nyx.cs.du.edu> added the pid-list feature. Charles Blake
<cblake@bbn.com> added multi-level sorting, the dirent-style library, the device name-to-number mmaped
database, the approximate binary search directly on System.map, and many code and documentation
cleanups. David Mossberger-Tang wrote the generic BFD support for psupdate. Albert Cahalan
<albert@users.sf.net> rewrote ps for full Unix98 and BSD support, along with some ugly hacks for obsolete
and foreign syntax.
Unix Background
The program known as ps -- process status was born at Bell Laboratories as an administrative application for UNIX.
Before UNIX was formally released to the public, it went through several rounds of internal revisions as a research operating system. The first edition of UNIX had 60 commands in total, but no ps.
Dennis Ritchie gave a hint as to why the first and second Unix editions had little need for ps in his essay “The Evolution of the Unix Time-sharing System” where he explained:
“Processes (independently executing entities) existed very early in PDP-7 Unix. There were in fact precisely two of them, one for each of the two terminals attached to the machine. There was no fork, wait, or exec.”
The first ps
1973
In 1973, ps was born. The first implementation of ps was written in assembly code specific for the PDP-7 microcomputer, the only architecture Unix supported at that time.
The 3rd edition of the Unix Programmer’s Manual contained the first ever documentation for ps, on a page dated “1/20/73”.
Unlike all subsequent editions of the Unix Programmer’s Manual, ps was not grouped in section 1, with other user commands. It was listed in section 8, for SYSTEM MAINTENANCE, along with 16 other maintenance commands. Section numbers in this manual used Roman numerals, as in:
PS (VIII)
To this day, numbered documentation categories still appear in man page titles on Unix and Linux.
About Section VIII specifically, the 3rd edition manual’s introduction warned:
Section VIII discusses commands which are not intended for use by the ordinary user, in some cases because they disclose information in which he is presumably not interested, and in others because they perform privileged functions.
The synopsis for this first ever ps man page located the program file in /usr/adm/ps . Third edition research Unix was the first to spread out the executables into directories beyond /bin. The administrative tools of Section VIII resided in the adm subdirectory.
The description in this manual noted how “The information is columnar”. Every ps implementation since then has persisted this visual design.
In the original ps, there were only three possible command line flags: x, l, and t. These flags differ so much from the modern command-line flags that it’s illuminating to examine each one.
x — Running processes without any associated “control typewriter” would be printed with the character x . Without this flag, only processes initiated by a person who had logged-in and entered the command via their teletypewriter, the computer input/output mechanism, got printed.
l — A PID was not displayed by default. The original ps displayed “The process’s unique ID” only when this flag was provided.
t — The number of hours, modulo 100, and minutes of system, disk, and user-process time accumulated by the process and all its terminated descendants.
Without flags, ps presented four columns, the last one being “An educated guess” as to the command that created the process.
Third edition Unix read from disk to get the current processes, not from memory. Although future Unix ps implementations would read out the process information from the special memory file /dev/mem (and later /dev/kmem) running processes were originally read out from /dev/rf0. So what was /dev/rf0? Elsewhere in the Unix Programmer’s Manual:
This file refers to the concatenation of both RS-11 disks. It may be either read or written, although writing is inherently very dangerous, since a file system resides there.
Hence, running process information was written to disk.
Early changes
The 4th edition of UNIX PROGRAMMER’S MANUAL, dated nine months after the 3rd edition, noted in its introduction:
“The most important changes result from a complete rewrite of the UNIX system in the C language.”
And so, less than a year after its creation, ps had been rewritten from scratch.
In the 4th edition Unix manual, ps had been moved to section 1, making it PS(I). The hyphen was also eliminated from its command line argument list, making this the first ps with what are now called “BSD-style options.”
SYNOPSIS
ps [ alx ]The DESCRIPTION was reworded from “ps prints certain facts about active processes” to “ps prints certain indicia about active processes”, a phrase that stayed in the UNIX manuals for the next seven years. The new diction ameliorated a contradiction in the 3rd edition manual, which warned that “Because ps examines a dynamically changing data structure, it can produce incorrect results”.
If results can be incorrect, they clearly would not be facts.
The 4th edition ps limited the default output to only those processes owned by the current user, necessitating the new -a option for including processes owned by other users.
Already in this first rewrite, one former feature got the axe: the -t option, for seeing process running time.
The 4th edition ps contained a pessimistic note in the BUGS section:
The ability to see, even if dimly, the name by which the process was invoked would be welcome.
The header of the 4th edition ps manual page displayed the date 10/15/73. On this same date, a Monday, the Fourth ACM Symposium on Operating Systems Principles was taking place. Dennis Ritchie and Ken Thompson presented the UNIX operating system to the public for the first time at this conference. Their design overview, entitled “The UNIX Time-Sharing system” mentioned several Unix programs, but not ps.
This date conflict implies that the original C-language ps was not written by Dennis Ritchie or Ken Thompson, who would have been preoccupied in Yorktown Heights, New York on the day its documentation was being formatted.
More options
1974
The earliest version of ps for which the source code has been preserved was that of UNIX 5th edition. It possessed an all-new -k command line option to specify a memory file to search instead of core memory, increasing the number of command line options to four.
SYNOPSIS
ps [ aklx ] [ namelist ]1975
Ken Thompson brought a copy of UNIX 6th edition to the University of California, Berkeley and installed it on the new PDP-11/70 belonging jointly to the Mathematics and Computer Science departments. In those days, UNIX included all source code, so Berkeley graduate students Bill Joy and Chuck Haley were able to study the kernel internals and optimize some code independently. They would eventually bundle these source code modifications with some user programs of their own into the first “Berkeley Software Distribution” (BSD) in 1977.
The so-called BSD-style options for ps originated from that copy of 6th edition research UNIX that Ken Thompson installed at the university while he was a visiting professor there. The Berkeley Software Distribution would eventually completely overwrite all AT&T Unix code over a period of many years and subsequent releases.
1980
AT&T released UNIX System III as Unix gained mainstream traction. (Aside: There was never any System I, no System II, nor a System IV). In System III, the man page for ps contained more options than fit on a one-line summary. The new ps synopsis simply ran:
ps [ options ]
Removing the word “indicia” from the description, and replacing it with the phrase “Ps prints certain information about active processes” (emphasis mine) certainly simplified the man page’s reading comprehension level.
Options were hyphenated in System III ps, which had not been the case since the very first ps back in the 3rd edition of research Unix.
System III marked the origin of what would later be called System V style options. It was also the first UNIX where the manual for ps (printed in physical copy then) spilled onto a second page.
Literature about ps
1981
The first published book for the general reader — not a technical paper, university lecture notes, or a manual — appears to have been Using The UNIX System by Richard Gauthier.
In his book, Gauthier offered this seasoned suggestion:
1983
Another early UNIX book called Introducing the UNIX system (by Henry McGilton and Rachel Morgan) addressed a bad habit the authors noticed some UNIX users indulging:
1984
The first edition of The Unix Programming Environment by Brian Kernighan and Rob Pike, the first book about Unix written by a Unix co-creator, had little to say about ps itself; however, their discussion of the “process-id” contained this now-antiquated advice:
If you are desperate,
kill 0will kill all your processes except your login shell.
1985
AT&T published Version 1 of the System V Interface definition (SVID), a proposed pan-industry standard specifying behavior for Unix-variations across platforms. The SVID was based on AT&T’s own commercially successful Unix System V, released two years earlier. For generality’s sake, all implementation-specific absolute filepaths were removed.
1986
Maurice Bach, in his book The Design Of The Unix Operating System, noted a challenge underlying the ps software design:
The command ps reports interesting information on process activity in a running system. In traditional implementations, ps reads the information in the process table directly from kernel memory. Such a method is unstable in a development environment where the size of process table entries changes and ps cannot easily find the correct fields in the process table.
1992
The 1st edition of W. Richard Steven’s book Advanced programming in the UNIX environment noted this complaint with diverging ps implementations:
Unfortunately, the output of the ps(1) command differs in almost every version of Unix.
Variations proliferate
1986
A usenet post on net.unix shared the source code for an alternative to ps called sps. It promised terminal output sorted by the username of the process owner.
sps (written principally by J. E. Kulp and J. Robert Ward) is a definite
improvement over the obscurity of ps. It shows the structure of process
relations as well as the nature of their connections, and refers to process
owners by name instead of uid. It was distributed over net.sources some
months ago, and currently runs at our site under 4.3BSD.
1986
AIX 1.1 was released for real-time computers. The accompanying manual provided a 4-page entry on ps, and, like other AIX commands, it displayed a railroad-track diagram illustrating the invocation syntax:
The FILES section of the AIX ps man page mentions the following filenames embedded in the source code:
/unix - System kernel image
/dev/mem - Memory
/etc/passwd - Supplies UID information.
/etc/ps_data - Internal data structure
/dev - Searched to find work station (tty) names1990
In a code commit dated three months before the release of 4.3BSD-Reno, the BSD implementation of ps adopted support for hyphenated options for the first time. A comment embedded in that change confessed mixed feelings:
/*
* ICK (all for getopt), would rather hide the ugliness
* here than taint the main code.
*
* ps foo -> ps -foo
* ps 34 -> ps -p34
*
* The old convention that 't' with no trailing tty arg means the users
* tty, is only supported if argv[1] doesn't begin with a '-'. This same
* feature is available with the option 'T', which takes no argument.
*/1992
Solaris 2.0 (previously known as SunOS) shipped for the first time with two separate versions of ps: one at /usr/bin/ps and the other at /usr/ucb/ps, the latter supporting so-called BSD-style options and the former with single-hyphen (or System-V style) options.
1992
The Plan 9 experimental operating system introduced “new, simpler implementations” of ps and other commands intended to be “similar to that of UNIX”.
The plan9 man page described ps and psu together on one page, the latter taking as an argument the user whose processes were to be described.
A major innovation in the plan9 ps implementation is that it was the first system to gather the process information needed for ps output from the /proc pseudo-filesystem, a practice that would later come to define the eventual Linux ps against nearly all others.
1993
By 1993, ps was standardized as part of the POSIX.2 standard for shells and utilities (also known as IEEE Std 1003.2–1992), and later ratified as ISO/IEC 9945–2:1993.
This POSIX.2 specification outlined the motivating problem it sought to mitigate by standardizing the requirements any ps program should provide:
There is very little commonality between BSD and System V implementations of
ps. Many options conflict or have subtly different usages.
The POSIX.2 entry on ps goes through many of those collisions, proposing common flags to be upper-cased or re-lettered altogether to remedy these conflicting usage patterns.
1997
Redhat introduced oldps as an alternative ps implementation bundled in the same procps package as ps. The oldps man page justified its existence with a caveat:
The command-line options for this version of ps are derived from the
BSD version of ps, not the System V version.
The command-line arguments should not be preceeded by a `-' character
[...]
For now, ps will give you a warning if you use a `-' for a short
option, but it will still work. If you have shell scripts which use
BSD-style arguments to ps, take heed of the warning and fix them, or
else your scripts will fail to function correctly at some point in the
future. If you want to turn off the warnings, set the I_WANT_A_BRO-
KEN_PS environment variable.This “point in the future” would materialize in 2002, when oldps was removed from procps in the 3.0.0 release.
Linux and other operating systems
1992
Linus Torvalds included this note in the sixth ever release of the Linux kernel, version 0.97:
- The buffer-cache and memory management code has been edited quite a
bit. ps/free etc programs that reads kernel memory directly no
longer work, and even a recompilation won’t be enough. They actually
need editing before they work.Roger Binns, author of the first Linux top application, explained some of the challenges on early Linux with seeing the active processes:
One thing the fledgling Linux didn’t have is getting a list of running processes. (It also didn’t have sound, mice, networking, gui, or a whole bunch of other normal stuff yet so that wasn’t a big omission.) You had to press the Scroll Lock key and it would spew some stuff on the console showing the running processes. That wasn’t a huge burden since it only supported 63 processes total.
Branko Lankester of the University of Amsterdam, who also contributed to the Hack-Tic Techno-Anarchy zine, wrote the first ps program for Linux.
He included patches to the Linux kernel required for his ps to work.
Later that year, in December, Michael K. Johnson, then at St. Olaf College, released procps, an implementation of ps that read from the /proc filesystem instead of from /dev/kmem.
He would later sum up his creation (a collaboration with kmem-ps author Branko Lankester) this way:
The original proc filesystem did not have enough functionality for a full replacement version of ps. I modified it to have all the necessary data for ps and uptime, and then wrote procps as a suite of programs that used the new functionality.
Michael K. Johnson called his project procps because it used the /proc filesystem, differentiating it from the other Linux ps which instead read process information from the kernel virtual memory device file/dev/kmem.
As far as I know, my original procps was the original implementation of ps that defaulted to sorted output. All versions of ps that directly read /dev/kmem, as far as I know, listed the data in the order it happened to find it in the kernel memory it was digging through, and I was tired of juggling sort arguments when invoking ps.
I believe my original procps was also among the first, if not the first, to just recognize both BSD or SysV command line arguments and do what you meant, rather than requiring you to remember which syntax you needed to use on this particular system.
1993
Rick Sladkey announced a “new kmem-ps suite for Linux 0.99.14” on usenet. The number of options one could supply in this version well-exceeded twenty. A stackexchange researcher with the handle JdeBP would later observe:
As you can see, there was one personality, a single meaning for the letters, and no leading minus sign characters.
1994
Argonne National labs released a suite of Unix Tools for parallel processors, including a ps implementation built for parallel processors, which they named pps:
The parallel ps has the same format as ps with the exeception [sic] of the specification of the processors to run on. The output is similar except that each output has the processor number prepended.
1995
The BusyBox set of programs saw its initial release. The project aimed “to be the smallest and simplest correct implementation of the standard Linux command line tools.”
The BusyBox ps to this day only has two flags, -o “Select columns for display”, and -T for “Show threads”.
1996
Textbook writer Andrew Tannenbaum released the first open source version of his Minix operating system: Minix 2.0.0. Since earlier Minix versions were only available with a purchase of a software license, Minix 2 is the earliest Minix for which the manual documentation is public. Minix’s man page for ps(1) noted that:
The files /dev/{mem,kmem} are used to read the system tables and command line arguments from.Despite actually supporting a few more options, the Minix ps manual only showed three in its options and examples sections: -a, -l, and -x. Perhaps coincidentally, it thus mirrored the very first PS(I) of the 4th edition research Unix.
1997
In May, Bell Labs released version 1.0 of the Inferno operating system, which included a ps implementation written in the Limbo programming language. Its man page , titled “ps — process (thread) status”, explained that this ps read process information from a /prog pseudo-device. Since Inferno-OS was built as a distributed operating system, it was possible to mount the /prog device from a remote machine.
2005
Wikibooks user Kernigh contextualized the differences between Linux ps and that of other operating systems in a wikibook called Guide to Unix:
Linux has some special filesystems which are not used for normal files.
/proc holds information about running processes. Other Unix-like systems sometimes provide /proc, but it is not as important as with Linux.
Development formalizes
1999
The Critical Vulnerability and Exploitation (CVE) database launched in September. It saw fit to award ps the 164th ever CVE:
A race condition in the Solaris ps command allows an attacker to overwrite critical files.
In total, ps found a mention in six CVEs that first year, four of them specific to the Solaris ps.
CVE-1999–1587
CVE-1999–1270
CVE-1999–1191
CVE-1999–0388
CVE-1999–0301
CVE-1999–0164
2000
Craig Small wrote a HACKING file where he conveyed the difficulty of enforcing command line options from various historic ps implementations all in one program.
Unless the personality forces BSD parsing, parser.c tries to parse the
command line as a mixed BSD+SysV+Gnu mess. On failure, BSD parsing is
attempted. If BSD parsing fails _after_ SysV parsing has been attempted,
the error message comes from the original SysV parse.2002
Albert Cahalan announced Procps version 3.0.1 on the Linux kernel mailing list. No announcement was made for the also-very-recent version 3.0.0, but its changelog was included in the same announcement. Some “new maintainers” were alluded to. The post began with an unflattering indictment of the old procps 2.x.x maintainer, RedHat’s Michael K. Johnson:
Contrary to popular belief, procps is maintained.
The procps-ng wiki allows us to imagine this announcement as a heroic moment for Cahalan:
In 2002, Albert moved procps to http://procps.sourceforge.net. This was done to ensure that years of testing and bug fixes would not be lost. The major version number was changed to 3, partly to avoid confusing users
The major version bump from 2 to 3 came with a new home for procps on the web. Albert Cahalan’s announcement to the Linux community represented his transition from a “low profile” bug-fixer to the owner of the new repository. The responsibility for merging in the myriad patches that had accumulated against the “buggy old code in Red Hat’s CVS” rested on Cahalan’s shoulders, and on those of Craig Small and Jim Warner, co-maintainers whom he praised in the post’s first sentence.
2002
The GNU Hurd project added procfs into its hurdextras project. This optional emulation of the Linux /proc pseudo-filesystem paved the way for procps to be compiled and used on GNU Hurd.
2002
The first BeOS implementation of ps was committed. Originally it accepted no command-line flags at all, and produced 7-column output with these headers:
#define PS_HEADER “ thread name state prio user kernel semaphore”2004
Tony Lawrence published a two-part blog post containing an interview with Albert Cahalan, the then-maintainer of ps. One subject was the various “personalities” of ps. At the time, these personalities were enumerated on the Linux man page as follows:
none
aix
bsd
compaq
debian
digital
gnu
hp
hpux
irix
linux
old
posix
sco
sgi
sun
sunos
sysv
unix
unix95
unix98Each of these personalities mapped a historic ps implementation to a set of command-line options. This allowed users with legacy shell scripts or old habits to set an environment variable and keep receiving the same ps output they were used to.
Lawrence’s apparent motivation for writing this piece was the flag I_WANT_A_BROKEN_PS. This environment variable affected how ps parsed its command line options, though in a perverse way. Its wry name coerced any user who needed its functionality to confess his fatuous intentions into his own private terminal. Albert Cahalan defended the variable and its name (though he insisted it was Michael K. Johnson who had written the code for it):
If you set that option, you make ps violate the POSIX and
UNIX standards. The common "ps -ef" command will not work.
(this is an ISO, IEEE, Open Group, and ANSI standard)According to the standards, "ps -aux" is parsed the same
way as "ps -a -u x", with "x" being a username!…
The whole POINT of the changes is to meet the POSIX
standard! The POSIX standard will parse "ps -aux" for sure,
but not in a way that BSD fans could tolerate. I'd expected
former SCO users to use "ps -ef" and recognize what "ps -aux"
does on a Real UNIX system. Simply pretend that Linux is SysV.
Stick to the UNIX syntax and you'll never see a warning.My ultimate hope is to unify things, to the extent that an
admin can sit down at any UNIX-like system and expect that
both "ps -ef" and "ps aux" will work. I seem to have the
FreeBSD developers 60% convinced. Sun merely needs to cause
/bin/ps to run /usr/ucb/ps when an unparsable option is
found or when the first arg lacks a "-". AIX and Tru64 already
support both syntaxes. In fact, Tru64 (then called OSF/1) is
where I got the idea from in the first place.I've been thinking of submitting the BSDisms to be included
in the UNIX standard. I almost did last time, but real-life
events got too intense for me to write up the spec in time.
I'd leave out the ability to mix BSD syntax with UNIX syntax,
so that Sun would have an easy time complying.2010
The maintainers of Debian, Fedora and openSUSE forked procps again, calling the new fork procps-ng. This allowed Cahalan to step back from the public responsibility of owning the project. By the following year, all development would be done on http://gitorious.org/procps. From the project’s wiki:
The import occurred in late 2010 and was then followed by a flurry of patching imports that was held back previously. Eventually the level of backlogged patches reduced and procps is now actively maintained.
When Gitlab purchased Gitorious in 2015, the procps project’s Gitorious infrastructure became Gitlab infrastructure, and ps has had a Gitlab codebase since then.
2011
Sami Kerola committed a new usage function. As he contested at the time, “the 85 lines long help simply looks and feels wrong.” The older, purged, usage function had pleaded in a leading code comment:
/*
* The help message must not become longer, because it must fit
* on an 80x24 screen _with_ the error message and command prompt.
*/Kerola’s newly designed ps --help output organized the the usage hints into seven sections, allowing users to drill down into whichever command line option they especially needed to see an example for.
2022
In October, procps 4.0 was released, representing the first major version bump (from 3 to 4) in twenty years.
Influences and legacy
1984
The first release of top, a program named for its ability to view the “top cpu-using processes” was announced by author William LeFebvre. He summarized its functionality by calling it “a full-screen ps output that gets updated at regular intervals”.
2004
An anonymous user created the first Wikipedia page on ps. This brief overview meagerly offered:
In most Unix-like operating systems, the ps command line program gives a snapshot of the currently running processes, including ps itself.
ps has many options, though it is commonly run with the options aux, where “a” lists all processes on a terminal, including those of other users, “x” lists all processes without controlling terminals and “u” adds the controlling user for each process
2004
Java Platform, Standard Edition v5 (JDK 1.5) introduced The Java Virtual Machine Process Status Tool, called jps.
It can report the status of java process from local host as well as from remote hosts.
2006
In November, Microsoft released Powershell 1.0 for Windows XP SP2 and Windows Vista RC1. Microsoft Windows now finally included ps, an alias to the powershell cmdlet Get-Process. This represented quite the milestone, as these two letters, once capable of getting process statuses on Unix-derived operating systems, could now be run on a Microsoft Windows command prompt and produce reasonably comparable output.
On Microsoft’s devblog announcing the release, the PowerShell team wrote:
Many thanks go to our friends at MySpace.com for coming all the way to Barcelona to show how they’re using Windows PowerShell in production today for the mission critical task of maintaining and managing the second busiest website in the world.
2009
The python library psutil tagged its first release, version 0.1.0. It summarized itself at the time as “a module providing convenience functions for managing processes in a portable way by using Python.”
2014
A “process lookup utility” written in javascript saw release v0.0.1, in a node package named ps-node.
2019
A “replacement for ps written in Rust” cut their first release as procs v0.1.0.
2020
The earliest release, v1.0.0, of go-ps, a ps implemented in the Go programming language, for Linux, Mac OS X, Solaris, and Windows.
2021
Linux Weekly News announced the intention to remove support for the /dev/kmem special file . This article sparked several reflections from Linux developers who remembered this file as the interface that originally made ps possible at all. “Chances are that /dev/kmem will not be missed,” Jonathan Corbet wrote in the lede, “but in passing it takes away a venerable part of the Unix kernel interface.”
Conclusion
Ken Thompson and Dennis Ritchie introduced UNIX to the world as “a general-purpose, multi-user, interactive operating system”. Since that time, the program ps has benefitted from myriad individuals’ contributions. Fully enumerating all the ports, imitations, flame wars, standardizations, and contentious dramas that ps has inspired over the past half-century could comprise a voluminous tome.
A fifty-year anniversary is reason to celebrate. Recognizing the discontinuities and parallel histories of ps, or of any tool that we love, ought to be a source of creative inspiration. Asking questions about why our tools are the way they are can draw out ideas from the past that inform both our experiences using the command-line and the future course of free software development.