One temptation of shell scripting is reusing other people's code

June 18, 2023

At one point I read Martin Tournoij's The shell scripting trap, and it sparked some thoughts in me about why shell scripting is forever tempting people. One of the reasons I see is the enduring appeal of code reuse, because as programmers we're often all lazy (and system administrators can be extra lazy because we have other things to do; programming is often a sideline).

Here I don't mean reusing code from other shell scripts, because you can do that in any language. Where shell scripting is unique is that you immediately get to reuse a large mass of code in the form of all of the Unix utilities out there. Some of these utilities have relatively direct equivalents in languages like Python (especially if you're willing to be brute force), but not all of them and often not as easily, and you also don't get to integrate with other utilities in the fluid way you do with shell scripts.

(Of course this is also one of the traps of shell scripting, in that you have to rely on Unix utilities for many things; there's nothing in the shell to fall back on the way there is in Python or other languages.)

Since you do a lot of shell scripting by having Unix utilities work together with each other, there's a useful synergy in this code reuse (to phrase it one way). Up to a certain point, as you learn about more utilities (and learn more about complex utilities), you increase the number of useful connections and transformations you can put together.

I'm not sure if there's a good way to do this sort of 'code reuse' in another language. Years ago I wrote about some of the issues I saw in Making a good Unix glue language and Why there's a gulf between shells and programming languages, and I still think those are real issues. Unix shells have languages that are very well optimized for this 'code reuse' through running Unix utilities and connecting them together. You might be able to design a programming language that's as fluid for this while still being a good programming language, but I suspect it's not really feasible in something like Python.

(The one 'language' I suspect I should look at here is Microsoft's Powershell.)

Comments on this page:

By Ewen McNeill at 2023-06-19 05:49:58:

The Unix shell script environment is effectively a monad on stream read/write byte streams, with a collection of programs that all receive and output byte streams which can be combined together in any order. There are sub types of byte streams, eg line oriented byte streams with a cluster of programs, but in theory anything can be connected to anything.

One could fairly easily create another language with a monad on a common data type (including eg byte stream iterators), and a way of adding new functions ad hoc (eg similar to the shell search PATH), which could allow incremental composible development, perhaps like the JavaScript npm approach. And perhaps better data structure handling (eg built in arrays / dictionaries). But there needs to be a critical mass of functionality to make it useful, which is competing with ~40 years of Unix history, so it’s hard to see it getting past a prototype.

(I too have not used PowerShell much, but I believe it was explicitly designed around structured objects, rather than byte streams. So I think it has less of the connect anything to anything monad. But it is at least aimed at being system / application extensible and composible in a similar way to an OS shell.)


Written on 18 June 2023.
« Javascript modifying cut and paste can sometimes be a good thing in browsers
Link: The Difference Between Root Certificate Authorities, Intermediates, and Resellers »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jun 18 22:25:26 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.