2

I've been doing some shell scripting.

It always gives me a headache. Clearly this language has evolved organically, much as real life languages; new constructs have been dynamically added, constantly introducing new rules and complexities.

Here is an example:

I understand that people like to avoid polluting the variable namespace; hence the function and the local part, which in turn forces the use of double quotes, which in turn forces the need to double up some but not all backslashes (and to know which ones -- oy!). I find that unnecessarily complicated. Granted, there's a tiny risk of collision if someone overrides BLUE or whatever, but on the other hand, the double-quote solution also carries the risk that a terminal will have backslashes in its escape sequences. And since the contents of the escape sequences are being parsed in the double-quote solution, but not in the single-quote solution, such a terminal could mess things up. Example of the difference:

taken from http://mywiki.wooledge.org/BashFAQ/053

It is common to find this level of complexity in technical conversations about shell scripting.

Also there exist a multitude of different shells with subtle syntactic differences.

If a group of experts started from scratch, I bet they could come up with a universal shell scripting language that was much easier to learn, understand and program.

Just as a group of C experts planned C++, or C++ -> C#

There is an ANSI C standard, but is there something similar for shell scripting?

Might it be possible to construct an intermediate shell language, that can expand to various shells?

Is there any effort in this direction, or are we just stuck with things the way they are, like the QWERTY keyboard?

P i
  • 303
  • 3
    It's called POSIX: https://en.wikipedia.org/wiki/POSIX – glenn jackman Jan 28 '14 at 16:14
  • Whenever I'm writing shell scripts, I find myself rewriting them in another language like Perl or Python when they get longer than a few lines. The shell syntax is great for interactive use, but not so much for programming. – Martin von Wittich Jan 28 '14 at 16:33

1 Answers1

2

Efforts have been made along the lines you suggest:

  • fish - Friendly, Interactive Shell
  • scsh - an open-source Unix shell embedded within Scheme (the lisp-syntax functional programming language)
  • es - another functional programming language as a shell, with its Xs offshoot.

fish development appears to be ongoing. I haven't personally tried any of these except for es, and that was ages ago.

The problem with your proposed effort is the goal: "easier to learn, understand and program". No real agreement on "easy to learn" exists, and "easy to understand", and "easy to program" might lie in opposition to "easy to learn". Most physical-world tools aren't easy to learn, yet years of development have been invested in them, and they are very powerful.

You can see the same tension in many other areas: text editors are notorious for being either (a) easy to learn or (b) useful.

But the open source world gives us all the opportunity to use what we would. The dizzying array of Linux distros, and the even more dizzying array of X11 Window Managers shows that perhaps a one-size-fits-all model just can't possibly work, and doesn't need to.