Home > Articles > Operating Systems, Server > Linux/UNIX/Open Source

  • Print
  • + Share This
Like this article? We recommend

7. Putting wildcard expansion in the shell isn’t a bug, it’s a feature.

Very early UNIX systems could only run one process at a time. Whenever a context switch occurred, it flushed the changed RAM to out-of-core storage and loaded the new process from swap. The implementation of fork() as a mechanism for creating new processes seemed logical—you already had a copy of the parent process in-core, so you acquired the copy for free.

The system itself ran on a PDP-7. This machine lacked many features that modern computer users take for granted, such as a memory management unit. There were no shared libraries—UNIX didn’t get these until it was 15 years old. Putting wildcard expansion in the shell was not a conscious decision; there was simply nowhere else to put it.

In a modern operating system, this functionality would obviously go in a shared library, but by the time such advances came to UNIX, 15 years of tradition was telling developers that wildcard expansion belonged in the shell. Anyone wanting to write a new shell had written his own (often slightly different) code for this, or tweaked an existing shell.

The original UNIX system was used mainly for text processing. In this context, small programs were an adequate substitute for shared libraries (and easier to implement). Gradually this little hack became a tradition, and the original reasons for it were overlooked.

If UNIX had started off with shared libraries from the start, things might have been quite different.

  • + Share This
  • 🔖 Save To Your Account