Is shell script as "close to silicon" as C?

Question

A couple of years ago, when I switched careers to programming, I remember learning the now-familiar hierarchy of low level to high level programming languages: machine code -> assembly language -> C -> Java, Python, C#, etc.

However, I've always had difficulty fitting shell script into that hierarchy. From one point of view, typing shell script commands into the terminal is the most direct means the programmer has of passing instructions to a Linux machine. However, I half suspect that all one is doing there is passing instructions to the operating system, which acts as a kind of interventionist middleman between the programmer and the actual hardware.

I remember being taught - this must have been in 2017 - that shell script is a subset of C. Looking back now that I know a little bit more about programming, that statement strikes me as, at best, a gross over-simplification of the historical co-development of shell script and C, and possibly just plain wrong. Anyway, I'd be grateful if anyone could set me straight on the relationship between the two languages - either from a historical or technical perspective, or both.

Answer 1

Here's another way to look at the issue:

Can you execute C from assembler? ... yes but it's usually the other way around
so C is higher level than assembler!

Can you execute Python from C? I really don't know, but (I guess) it's usually the other way around!
so Python is higher level than C.

Can you execute (for suitable definition of execute) a regex from BASIC... yes (maybe [I have no idea]), so BASIC is higher level than regexes.

...

Answer 2

When you type commands into a terminal, you are really a long way from directly interacting with the operating system. (Which, in itself, mediates between you and the hardware by providing a number of useful services.)

To start with, you're looking at images painted on your screen by a "window manager". The window manager is just another program, not part of the operating system at all (at least in the case of Linux and other Unix-like systems.)

As the name implies, the window manager is primarily responsible for the arrangement of windows on the screen; the contents of the windows are produced by the various programs you are running, which instruct the window manager what to draw in the rectangles reserved for them.

One of the programs which you can run through the window manager is a so-called "terminal", more accurately described as a "terminal emulator". The name comes from the days when you interacted with your computer through a separate device with its own screen, which accepted simple commands from the computer sent over a serial cable (or through a telephone using a modem).

Linux, like many other Unix-like systems, does include a "console", which is a direct interface with the keyboard and screen. The Linux console does not have windows: it's a single array of characters which takes up the whole screen. Using the console bypasses the window manager and terminal emulator, but you're still far from interacting directly with the operating system.

What you are actually interacting with in both cases is a "shell", which is a simple program operating without special privileges. The shell doesn't even have a graphical interface; it just sends characters (and dome simple formatting commands) as though it were communicating with a real terminal. In Linux, that's mediated by an operating-system interface called a "pseudo-terminal" ("pty" for short).

The shell reads the commands you type, which are mostly requests to run other programs. Most shell commands do no more than find a program and run it with the arguments you provide. The shell does provide some facilities, like variable substitution, conditionals, and loops, which make it possible to write programs (or "scripts"). But these scripts are reinterpreted by the shell every time they are run.

At the bottom of this chain are the command-line utilities like ls (which is an actual program you will find on your filesystem, probably at /bin/ls). These programs do interact with the operating system. They are typically written in C (or some similar compiled language) and call specific library functions to request operating-system services.

That's a very brief and condensed view of what's going on when you type a terminal command. You can probably find more details by searching for the terms introduced above, although a more structured learning approach would be to pick up an introductory textbook.

Answer 3

that shell script is a subset of C

Definitely not true at all. sh may be influenced by C and have some C-like features, but it is a completely different language.

The most distinctive difference is that sh is not compiled. It's run row by row, or more command by command, while C needs to be compiled as a whole before it's run. (That's not technically true; it exists C interpreters, but that's very rarely used, and strictly speaking, the do not conform to the C standard either)

Also, compiled vs interpreted does not say much about if it's high level or not. Assembly is closer to be interpreted line by line rather than compiled if you compare to C and Java.

Another difference is that sh is a very high level language. When C was new, it was considered a high level language, but that was in comparison with assembly. Today it's considered a low level language.

I've always had difficulty fitting shell script into that hierarchy.

It's easy with the hierarchy "hardware -> machine code -> assembly -> everything else" but splitting up "everything else" is not trivial and can be done in a lot of different ways. Exactly how that should be done tend to be very opinionated. Personally, I would do something like this:

Fortran -> C -> Java -> Python -> Sh

Answer 4

Strictly speaking the "shell" is just an interactive REPL. Any programming language that offers a REPL can be satisfingly be used as a shell (I know people who are using ipython as their main shell).

As far as "levelness" goes, it can be anything between JIT compiled to native execution (e.g. https://luajit.org/), down to tokenized interpretation as standard Ruby does.

Your typical *nix shell (ash, dash, bash, zsh) is a token interpreter that works itself through the script token-by-token and for each token changes its internal state accordingly. Think of a token interpreter as a VM that doesn't operate on binary opcodes, but on human readable strings.

Also a shell is not merely passing commands to the operating system. There's a lot more going on in there.

Answer 5

Basically, a shell script is something like Python. Both of them have their own interpreters (/bin/sh and /usr/bin/python), so shell scripting take last place in "language evolution". Moreover, you can consider shell as something like user interface, because at first shell created to launch programs. For example, when you execute cp file1 file2 you launch GNU coreutils tool named cp. Like one man said, shell is a glue of Unix.

So no, shell is not "close to silicon" at all.