Shell != REPL

A shell is not the same as a REPL (Read Evaluate Print Loop). They look similar, but they have deep differences.

Shells are designed for one-line commands, and they’re a little awkward when used as programming languages.

Scripting languages are designed for files of commands, and they’re a little awkward to use from a REPL.

IPython is an interesting hybrid. You could think of it as a Python REPL with shell-like features added. Eshell is another interesting compromise, a shell implemented in Emacs Lisp that also works as a Lisp REPL. These hybrids are evidence that as much as people like their programming languages, they appreciate additions to a pure language REPL.

* * *

For daily tips on Python and scientific computing, follow @SciPyTip on Twitter.

Scipytip twitter icon

For daily tips on using Unix, follow @UnixToolTip on Twitter.

UnixToolTip twitter icon

8 thoughts on “Shell != REPL

  1. In my opinion, PowerShell is a better shell than scripting language. And I believe that’s what its designers were after. They could have made it a little better as a scripting language, but at the expense of making is a little worse as a shell.

  2. Canageek beat me to it: bash (ksh, zsh, csh) are programming languages.

    Just really super-interactive ones, is all. So interactive most of us forget that we’re doodling around inside a primitive REPL.

  3. Sure, you can use bash as a programming language, but it is a programming language designed first and foremost for single-line commands. If bash were intended to be used solely in scripts, and not at the command line, it would have been designed somewhat differently.

    Shell languages like bash and PowerShell excel at the command line. That’s what they were designed for. You can use them to write large programs, but it’s easier to write large programs in languages that were designed for writing large programs.

  4. John: “You *can* use [bash][/bash] to write large programs, but it’s easier to write large programs in languages that were designed for writing large programs”.

    I’m a fan, John, but I think you’re confusing some programming dimensions here. As an example, C was never designed for writing large programs; it was designed to match high-level procedural programming to native machine architecture. It was surely anticipated that you’d write large programs (the operating system) in it, but it wasn’t designed for it. I’d say Lisp was not designed for large programs either.

    And I’d disagree that the Bourne shell, and variants were not designed for programming. I believe that they were specifically designed to be used *both* for the command line and for programming. In point of fact, if you’re are trying to perform small to moderately scaled job management, you should do it in a UNIX shell language program (file), that is what it is designed for. And that kind of job control is arduous at best to do in Java, etc. Other things, like UNIX operational control and installation, should be done as Shell programs. Trying to do these in Java or C is not a great idea, not even Perl helps.

    The Bourne shell, Bash, and K-shell man pages are large and complex not because they have endured feature-bloat (though they have of course), but because they are complete programming languages that manage UNIX operations exceedingly well. And not only can they be excellent at programmatic solutions, but also at the command line.

    I agree that many REPL implementations aren’t good command-line substitutes, but I think that the UNIX shell languages are the one existence proof that you can have a good REPL and a good programming language.

  5. but it is a programming language designed first and foremost for single-line commands.

    My apologies if you understood me to believe shell was intended to be only a scripting language.

    I was not around when sh was released [1] but wiki appears to claim [2] sh was intended to be a scripting language first, with the interactive function second.

    Which – since I saw the light in 1999 – is how I’ve been using it. Even when I didn’t know I was programming … I was.

    Perhaps I am suffering from the ‘if you have a hammer, everything is a nail’ problem. I look at bash as glue to get things done that systems don’t easily otherwise allow (PERL being super glue).

    (examples redacted for brevity)

    [1] My first brush with unix was 1992 – a Major at the G2 shop offered to bring me on as his system administrator. Those big ol’ Sun computers looked weird and strange – I chose to stick with VINES. It was The Future. I’d like to go back and slap myself.


Leave a Reply

Your email address will not be published. Required fields are marked *