Unix shell programming: the next 50 years

Glad I learnt the shell before some hyped "modern" scripting language. Shell scripts just keep working year after year, they do not go "out of style" and they are generally fast. I cannot predict the future, the direction of populist computer programming is hilariously nonsensical, so much hype and failed attempts at improvement. However, like the authors of this ACM article, I know for sure the shell will outlive me. I love the UNIX shell. Not for what it is, but what it isn't.

Past submissions:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27378444" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27378444</a> (77 days ago)<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27036572" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27036572</a> (3 months ago)<p>More non-HN comments here: <a href="http:&#x2F;&#x2F;www.oilshell.org&#x2F;blog&#x2F;2021&#x2F;06&#x2F;hotos-shell-panel.html#theres-a-lot-of-interest-in-unix-shell" rel="nofollow">http:&#x2F;&#x2F;www.oilshell.org&#x2F;blog&#x2F;2021&#x2F;06&#x2F;hotos-shell-panel.html#...</a> (as well as my notes on the HotOS conference event)

The biggest problem with Python is there&#x27;s always some divide between it&#x27;s environment and shell. I don&#x27;t think Perl had this problem as accessing the shell was built into the language.<p>There needs to be a modern language that looks friendly, is compatible with shell, and is apart of the shells environment.<p>I am one of many people who don&#x27;t really care for shell, it&#x27;s old, limited, and just plain ugly. Unfortunately it&#x27;s still the best way to interact with Unix, so it should be built upon to keep compatibility.<p>Wouldn&#x27;t it be nice to write shell scripts with objects and data structures?

To me it seems like the REPL is the eventual solution. A shell is pretty much one already, you install programs in the same way one loads libraries in a repl. It lacks a language to glue them together since bash is not up to the task. The reason people want structured data and not just text is to be able to glue programs in the same way you can with functions.<p>The glue should be structured data, none of that object bs. It should also have the option for plain text because sometimes that is all you need and you want simple tasks to remain simple. I&#x27;m guessing you&#x27;ll use some sort of binary spec in order to help in the conversion of data structures between languages.<p>Once you have the communication between programs handled all you need is a decent language to handle the logic. The language doesn&#x27;t really matter though since the core that allows all of this is not tied to any one language. I&#x27;m sure plenty of people would write their own wrapper for their favorite language.

Coming from HPC and HEP. No the UNIX shell it&#x27;s not foreign to academia. It&#x27;s the bread and butter of research at scale and has been since the mainframe...<p>With that in mind I&#x27;ll confess to not having read the rest of the article because really, that&#x27;s so far from a correct point as to render discussion mute.

I have an idea for a shell I&#x27;ve been very slowly building out where the user can embed other languages in {#! ... } blocks of an otherwise POSIX compliant shell. I haven&#x27;t solved the hard problems yet and I regularly wonder why I&#x27;m bothering myself with this, but it still feels cool sometimes. Even if I can&#x27;t really use it for every day things yet without tab-complete, proper redirection and a million other missing features.<p>Yes, I think the shell is an amazingly empowering tool, and yes it&#x27;s also in need of some love. It&#x27;s hard pulling apart what pieces of the specs still make sense, and what parts don&#x27;t. But I&#x27;ve tried to learn and love fish shell (for example) and I think it&#x27;s just proof for me that a new shell language is just going to cause more integrations and translations I need to perform on the fly. I already convert from 12 hour to 24 hours in real time, I don&#x27;t really need to be translating bash-&gt;fish every time I want to do a conditional.<p>Embedding languages inside each other is a topic of theoretical consideration now for me, and I&#x27;ll admit I haven&#x27;t found a compelling source for previous research on this yet, but I feel like I might need it one day.<p>Anyway, I&#x27;ll just be happy if one day I can try and forget about all the weird flags shell options that can be set at any time and impact the evaluation strategies of future expressions directly.<p>But alas, the shell would never stay still.

This proposes a JIT compiler which can e.g. increase parallelism inside a chain of pipelined commands:<p><pre><code> We propose a dynamically triggered optimization regime for the shell that we call Jash, short for ‘Just a shell’. Jash inspects each shell command as it comes in to identify candidates for rewriting.</code></pre>

Important subject, but that’s a pretty terrible article. I do understand the need to have publications by one’s name (I’ve been there too) but still, it’s a bit embarrassing to see this, which is just a blog post really, dressed up as an “academic article”.

In 100 years, we&#x27;ll have strong AI writing our bash scripts.<p>Technology adoption is driven by extrinsic need, not intrinsic merit - so backcompatibility is hard to beat. This is especially true of infrastructure, from train tracks to bash scripts.

If you like Clojure there&#x27;s babashka.

I think people use Bash&#x2F;Sh, because there&#x27;s no other default choices, much like javascript in the browser.<p>If they switched the bash terminal to a python repl, or just reliably offered stable python, that was available on every single distro, and just worked...I bet people would be fine with it.<p>Same with replacing JS in the browser with python or another dynamic language.<p>Tech people are practical and will just learn whatever they need to get things done quickly without introducing additional complexity.<p>But then there&#x27;s the idea that todays elegant language become tomorrow&#x27;s kludgy language.<p>So in the long run theres no winning. :)