So somehow this paper misses one of the greatest developments in this area, oil <a href="https://www.oilshell.org/" rel="nofollow">https://www.oilshell.org/</a> - which:<p>1. has a compatibility mode with sh and bash. it's the only new shell I know with a upgrade path from bash [0]<p>2. otherwise fixes tons of unix shell misfeatures and in particular fixes quoting hell [2]<p>PS: one fun quirk of the oil implementation is that it's written in Python.. but actually in a DSL that generates statically typed C++ code, ditching the Python runtime altogether [3] [4] - when you do compile Oil, you just get a C++ tarball (somewhat like fftw, a FFT package written in OCaml but which generates C code; fftw developers write OCaml, but fftw users compile C)<p>[0] <a href="https://www.oilshell.org/why.html" rel="nofollow">https://www.oilshell.org/why.html</a><p>[1] <a href="https://www.oilshell.org/blog/2020/01/simplest-explanation.html" rel="nofollow">https://www.oilshell.org/blog/2020/01/simplest-explanation.h...</a><p>[2] <a href="https://www.oilshell.org/release/latest/doc/idioms.html" rel="nofollow">https://www.oilshell.org/release/latest/doc/idioms.html</a><p>[3] <a href="https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#why-is-it-written-in-python" rel="nofollow">https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#w...</a><p>[4] But actually I think there's still work to do to remove the CPython dependency at runtime, <a href="https://github.com/oilshell/oil/issues/636" rel="nofollow">https://github.com/oilshell/oil/issues/636</a>
It seems odd that any paper on this topic (I read both TFA and the paper it references) would not mention PowerShell once, nor the broader issue of how the Unix shell uses text streams as the only intermediary format between pipeline components.
The paper is 7 months old and has been submitted a dozen times. Most discussion is here:<p><a href="https://news.ycombinator.com/item?id=27378444" rel="nofollow">https://news.ycombinator.com/item?id=27378444</a><p>The title is promising, but when I read the paper half a year ago I found it disappointing, no practical value. Academic considerations to get a conference paper.
The shell is first and foremost a user interface. Its entire purpose is just to help users use the computer. A huge amount of its functionality is in dealing with making it convenient for people to do work - from looking at command history, to skipping back and forth along a text line, to dynamically changing a prompt, to auto-completion. Think of it as an IDE.<p>Shell 'scripting' is only supposed to be a way to automate that IDE. It's not supposed to be a programming language. Literally the purpose is that you're sitting there at your terminal and you think "boy, I would really love to rename 100 files in a certain way". At first you write a quick one-line series of commands with a loop. But the intention is to eventually write a <i>real</i> dedicated program (like the `rename` command) so you don't have to write a crappy line of "scripting".<p>Shell scripting should remain limited in functionality, and be tailored to helping someone use the IDE. If you want a systems programming language, then develop one. Go crazy and develop new ideas and push the boundaries of computer science. But please don't ruin the shell experience by trying to solve some unrelated problems with it and end up ruining the simple end user experience.
I am a bash expert.<p>This paper reads like it was written by clueless academics with no real world experience.<p>Multicore bash already exists and is seldom used, through the "parallel" cmd.<p>Other points address no particular issue, and would actually make the language more painful to use.<p>Bash has its limits, which pushes you to use a full fledged language if you attempt to walk past them. It's a good system.
As a daily shell user, I want a shell that uses even less resources, and perhaps even does less. Otherwise I am going to use the default scripting shell. Today, that's an Almquist derivative as it has been for 20+ (at least, for NetBSD, Linux adoption was more recent). Never do I see proposals for a "next generation shell" which uses <i>less</i> resources than Almquist and can do all the same things. Anyways, Almquist shell isn't going away anytime soon, not for at least another 50 years. IMHO.
Unix shell isn't usable by normal public. It's just a stash of random symbols everywhere with unintuitive semantics. You'd loose your brain if you begin writing one. There are so many quirky considerations you've to take in mind to handle for all cases just gets even more complex then remembering C++ rules.<p>The substitution and shell-quoting are the things that piss me off. Why in 2021 would ever want all that legacy cruft? I better write a Python script that is far more readable and intuitive than figuring out all the symbol combinations in shell programming. We deserve better, don't we?<p>Shell programming is like necromancing, one simple mistake leads to big disasters. Also, these shells never point out the actual mistake, like are very unhelpful.
I hope not. I was hoping that Unix and its shell would die out at some point. But it is a hydra that will live on and haunt our dreams.<p>FWIW, I have switched to Powershell & Python for most of my work. I only use Python when I have to share scripts with colleages, though. Powershell still beats Python for scripting.
I would like a SAFE distributed shell - allow me to run commands seamlessly on remote machines as if they are on my own.<p>Check out op <a href="https://docs.shoreline.io/op" rel="nofollow">https://docs.shoreline.io/op</a>
op> hosts | filter(cpu_usage > 80) | `pkill high_cpu_proc`
I'm surprised to see no mention of nushell [0] I've tried it a while ago and seemed really promising<p>[0] <a href="https://www.nushell.sh/" rel="nofollow">https://www.nushell.sh/</a>
Thanks to the author for posting this. Thoughts, in no particular order:<p>Repeatability:<p>- We already have a dataflow graph, it's called makefiles<p>- Going from shell commands to Ansible playbooks can be made easier<p>- Declarative, idempotent commands<p>- Integration with version control<p>User friendliness:<p>- GNU standards. If I cannot use --help and --version, I get angry<p>- Backward compatibility. Ripgrep, I'm looking at you<p>- Autocompletion is still in its infancy. Co-operative autocompletion is easy, and can be done by utility authors. What are the options (no pun intended) when the author would not update an autocompletion script? fzf and its kin greatly enhance user experience<p>- Performance. Accidentally quadratic stuff is a Cthulhu-scaled abomination<p>- Fancier prompts without needing to install extra software or add a bunch of PS1/PS2 scripts<p>'Novelties' (not so much, other OSes have had them before):<p>- Coprocs<p>- Easier parallelization<p>- Improvement in job control - freezing and thawing jobs, moving jobs to other hosts etc. K8s/kubeflow and friends<p>Security:<p>- Better integration with secret managers<p>- History cleanup when passwords are passed on the command line