N&Bx: dissecting (ba)sh

Welcome to Nuts&Bolts with Linux, or ‘N&Bx’.

I’ll keep sharing some of the things that have recently found. It’s amazing how rich a GNU/Linux system actually is. I’ve jokingly said many times that you can either play games, or just explore more and more of a Linux. Either way you won’t run out of things to do.

What is a shell?

The shell is really what it says; kind of cover, an enclosing; “world of its own”. The shell’s purpose is to interpret commands and act as a middleman between users and the core of the operating system. Without a shell we’d be really hardcore enthusiasts, like those of the 1950s who knew how to program a computer by switching levers and knobs on and off.

There are mainly 3 kinds of shell usage

The most usual that we think of with a shell is interactive use: you type commands, and the shell is your tool to speaking with underlying OS. A shell can contain a lot of amenities and amendments that we take for granted, and some that are probably still undiscovered by many users.

Second kind of usage is executing a single command with a shell. You’ve probably seen those

sh -c "echo '1' >> file"

kind of commands that take advantage of the shell’s rich internal commands, pipes, and combine these sometimes with program execution.

Third use case is where a script uses a shell as an executing environment. This is the batch mode; for example in Linux, the commands that regularly run via scheduling, take a shell underlying, which sets a execution environment, and then the payload command runs on top of that. The payload itself can be a shell script, internal shell command or an external binary (program).

Bash had been my default shell in Linux for years. I had not even thought the decision originally as to ‘why’, but I guess bash seemed somewhat more sophisticated than the standard ‘sh’ shell.

Next in N&Bx we’ll check out how does bash set up the “environment” and its own options. Until then, adios!