9 ms·

Unix Shell Programming: The Next 50 Years

159 points by mlerner 5y ago

mukundesh 5y ago
I would like a SAFE distributed shell - allow me to run commands seamlessly on remote machines as if they are on my own. Check out op https://docs.shoreline.io/op https://docs.shoreline.io/op op> hosts | filter(cpu_usage > 80) | `pkill high_cpu_proc`
sbpoli 5y ago
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. 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? 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.
PaulDavisThe1st 5y ago
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.
- adamnemecek 5y ago
  unix people like is a solipsistic world where windows doesn’t exist.
  - mmcgaha 5y ago
    Nope, unix people like the fact that thirty-year-old shell scripts still work just fine. In ten years, powershell will be be replaced and it will be the new vbscript. No thanks.
    - jeppesen-io 5y ago
      To have a real discussion on the future of shells while ignoring the PowerShell is not an honest discussion. I'm not sure why you'd want to run a 30 year old script when the computing environment has changed so much around those scripts. Regardless of what future you see for PowerShell as a product, the concepts and implementation, is a great place to see what works well and what didn't, particularly when it comes to non-text oriented pipeing
      - cybernautique 5y ago
        Stability is an important thing. The fact that 30 year old scripts still work, and still can be run, is a testament to the staying power of the underlying technology. That staying power generally means some reduction in cognitive load: I can use the same semantics, principles, and idioms on my phone, laptop, and computer. That's good. That's powerful. Contrast that with the JavaScript framework du jour: React today, React with new shiny hooks tomorrow; Svelte a week ago and a week from now; while the boss just told you in an email that the meeting an hour from now regards porting everything to Vue. That's the kind of cognitive load that we're thankfully spared by long-lasting technology. Now consider PowerShell. It is not an open standard. It is not an open technology. Its steward is Microsoft, of "Embrace, Extend, Extinguish" fame. It bucks against the long-established norm, so that all the established idioms are useless, while its semantics are just as tedious. Why, therefore, should I bother putting pilot time into this proprietary flying rug whose engine is more-likely-than-not a cracked bottle of Microsoft semen? As to whether PowerShell has anything to teach us about shell engineering: meh. It's not as good as Bash at doing Bash-like things and it's not as good as scripting languages at doing scripting things. EDIT: I figured I'd look to see whether PowerShell is open. Surprisingly, it is! With an MIT license to boot. However, as expected with any Microscum code, it includes telemetry out-of-the-box. As a matter of principle: I don't like it, I don't trust it, I don't want it. The semantics are ugly and it stinks of Microsoft.
  - cybernautique 5y ago
    I specifically and purposefully ignore anything Microsoft. I'm interested in open computing, which Windows and Microsoft exist to spite. I assume Microsoft does everything in bad faith, and that any technology they deploy is ultimately in service of their walled gardens. I refuse to participate; I won't let myself be walled-in, and I won't give them any credibility. Windows does exist, but it ought not to.
    - zerocount 5y ago
      And it keeps getting worse with each version.
    - TrumpRapedWomen 5y ago
      You really need to update your attitude, the new Microsoft has embraced open source in a very real and meaningful way. https://dotnet.microsoft.com/en-us/download https://dotnet.microsoft.com/en-us/download https://github.com/PowerShell/PowerShell https://github.com/PowerShell/PowerShell PowerShell is SO much better than any Linux/Unix shell.
  - agumonkey 5y ago
    I think it will change. I sense a reactive trend that will impact sys/shell interactions coming.
- d0mine 5y ago
  PowerShell might not satisfy: "Universal composition, Stream processing, Unix-native" points. Have you tried to pipe some bytes via PowerShell? Binary pipeline looks complicated https://stackoverflow.com/questions/33936074/decode-powershell-output-possibly-containing-non-ascii-unicode-characters-into-a https://stackoverflow.com/questions/33936074/decode-powershe...
  - jeppesen-io 5y ago
    I'd suspect the OP would not say PowerShell is perfect or should be the *nix future, but that it's worth evaluating the ideas it brings to the table 50 years is quite the time horizon after all
- jeppesen-io 5y ago
  As someone who moved to Linux full-time, professionally and personally, there are times I do miss PowerShell. Never used anything like it. To tab complete "apis" and complex data structures was very enjoyable For better or worse, it's what I and my team used to manage a decent size VMware cluster of a hundred hosts and 6k VMs ( I think, it was a very long time ago) Wouldn't go back, but there are aspects I miss
  - cobalt 5y ago
    powershell (core) is on linux btw
  - hnlmorg 5y ago
    Powershell is available on Linux. Albeit it doesn't always play too nicely with existing CLI tools. There are also other typed shells that appeal to yourself which aren't Powershell but do have behaviours similar to Powershell and which do play a lot more nicely with the wider Linux / UNIX ecosystem: - murex https://github.com/lmorg/murex https://github.com/lmorg/murex - Elvish https://github.com/elves/elvish https://github.com/elves/elvish - NGS https://github.com/ngs-lang/ngs https://github.com/ngs-lang/ngs I'm the maintainer of murex so happy to answer any questions on that shell here. I do know the the maintainers of Elvish and NGS pop on HN too.
- hulitu 5y ago
  It seems odd that everytime there is a discussions about shells on UNIX, an ad to powershell comes in. Powershell might have its virtues but: 1)One cannot rely on it for system administration when limited resources are available. 2) even on windows is slow to start. 3) documentation is ... where ?
  - jasode 5y ago
    >everytime there is a discussions about shells on UNIX, an ad to powershell comes in. The gp (Paul) is not "advertising Powershell" and he's not recommending people switch to it. Instead, he's saying that it's strange that an academic paper talking about future concepts doesn't even have a cursory survey of what other popular shells have done. Here's an example of that style of writing where other platform technologies are mentioned: Joshua Bloch is a ex-Sun employee and Java advocate proposing new syntax for Automatic Resource Management and in his note, he mentions what C# and C++ did: http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000011.html http://mail.openjdk.java.net/pipermail/coin-dev/2009-Februar... It shouldn't have to be said that citing C# & C++ does not mean it's an "ad for C#". When a new 2021 paper about future of shells has no mention of zsh, Powershell, etc by the authors, it's reasonable for readers to wonder if the team has overlooked what others have done. E.g. Powershell was designed by ex-UNIX admins.
nextaccountic 5y ago
So somehow this paper misses one of the greatest developments in this area, oil https://www.oilshell.org/ https://www.oilshell.org/ - which: 1. has a compatibility mode with sh and bash. it's the only new shell I know with a upgrade path from bash [0] 2. otherwise fixes tons of unix shell misfeatures and in particular fixes quoting hell [2] 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) [0] https://www.oilshell.org/why.html https://www.oilshell.org/why.html [1] https://www.oilshell.org/blog/2020/01/simplest-explanation.html https://www.oilshell.org/blog/2020/01/simplest-explanation.h... [2] https://www.oilshell.org/release/latest/doc/idioms.html https://www.oilshell.org/release/latest/doc/idioms.html [3] https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#why-is-it-written-in-python https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#w... [4] But actually I think there's still work to do to remove the CPython dependency at runtime, https://github.com/oilshell/oil/issues/636 https://github.com/oilshell/oil/issues/636
- hnlmorg 5y ago
  That paper misses a lot. Including: - murex https://github.com/lmorg/murex https://github.com/lmorg/murex - Elvish https://github.com/elves/elvish https://github.com/elves/elvish - NGS https://github.com/ngs-lang/ngs https://github.com/ngs-lang/ngs - Powershell - And any language REPLs turned into shells, such as Python, LISP, Lua and others. The author did say there is more to follow though so maybe the scope of this article was a little more closed by intention.
- clavicat 5y ago
  Great choice of name when there’s already an oil company called Shell.
  - pasabagi 5y ago
    Presumably that won't matter so much in 50 years, since either Shell will be bust, or civilization will have collapsed.
1vuio0pswjnm7 5y ago
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 less 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.
- chasil 5y ago
  In order to use less resources, features will have to be removed. The pdksh version of the Korn shell was available to the POSIX shell standardization committee. It was not chosen because it was too large, with too many features. Another round of less-capable tools does not seem productive.
- thanatos519 5y ago
  I dunno, I've never had any complaints about bash's performance ... but I do appreciate the idea of a simple performant shell, as long as it doesn't break anything. I was annoyed to find many #!/bin/sh scripts broken in Debian 11 until I update-alternatives'd it to bash. There goes my performance, but hey presto now things work!
- ilyash 5y ago
  > As a daily shell user, I want a shell that uses even less resources Why is this important consideration for you? What's the use case?
  - 1vuio0pswjnm7 5y ago
    Resource conservation. Computers I use are often older and/or have limited resources. I want to use available resources for other things. Example: http://cdn.netbsd.org/pub/NetBSD/NetBSD-current/src/distrib/utils/ssh/ssh.c http://cdn.netbsd.org/pub/NetBSD/NetBSD-current/src/distrib/...
throwawaybutwhy 5y ago
Thanks to the author for posting this. Thoughts, in no particular order: Repeatability: - We already have a dataflow graph, it's called makefiles - Going from shell commands to Ansible playbooks can be made easier - Declarative, idempotent commands - Integration with version control User friendliness: - GNU standards. If I cannot use --help and --version, I get angry - Backward compatibility. Ripgrep, I'm looking at you - 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 - Performance. Accidentally quadratic stuff is a Cthulhu-scaled abomination - Fancier prompts without needing to install extra software or add a bunch of PS1/PS2 scripts 'Novelties' (not so much, other OSes have had them before): - Coprocs - Easier parallelization - Improvement in job control - freezing and thawing jobs, moving jobs to other hosts etc. K8s/kubeflow and friends Security: - Better integration with secret managers - History cleanup when passwords are passed on the command line
- kaba0 5y ago
  > Backward compatibility. Ripgrep, I'm looking at you Is that really that important? I do have a few POSIX incantations ingrained into my muscle memory, but it’s not a good thing imo. Is that 4 God knows what flag and strange order really that important? Maybe add a separate backward compatible mode when issued through the old tool’s name, but I would like at least a partial revamp of the frankly, not too ergonomic POSIX tools. While Powershell can sometimes be more verbose, I would prefer a similar convention.
  - throwawaybutwhy 5y ago
    Definitely important. It is a damper on gung-ho, brazen disregard for existing code/user base. It prevents code base rot and saves money for corporations/governments. It forces developers to adhere to the principle of least surprise, and ensures smooth user experience. Mind you, Powershell beats POSIX on readability hands down, and autocompletion would make longer, more readable options much easier to write. Still, the easiest way to increase adoption is to meticulously copy conventions from predecessors. Compatibility mode would be enough for most purposes if it's maintained and not dropped three years later in the name of progress and limited maintainer attention span.
unbanned 5y ago
Powershell. At least you have actual objects returned and don't have to parse stdio
usr1106 5y ago
The paper is 7 months old and has been submitted a dozen times. Most discussion is here: https://news.ycombinator.com/item?id=27378444 https://news.ycombinator.com/item?id=27378444 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.
louiskottmann 5y ago
I am a bash expert. This paper reads like it was written by clueless academics with no real world experience. Multicore bash already exists and is seldom used, through the "parallel" cmd. Other points address no particular issue, and would actually make the language more painful to use. 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.
- thanatos519 5y ago
  I'm also a bash expert and I agree! I wrote 75 lines of bash to do failure-resistant streaming parallel computation on heterogeneous distributed systems. "parallel" was very close to doing what I want, but it wasn't particularly hard to do it myself without it. I fire it up, peg every core on as many spot instances as AWS will give me, then shut them all down. I regularly pass data structures through pipes, and "jq" does everything I have needed so far. The tools can always get a bit better, but I don't need my duct tape to be any smarter, KTHX.
  - arpa 5y ago
    what makes one a bash expert? genuinely curious if i could call myself one.
    - deleted 5y ago
      [deleted]
    - Bluecobra 5y ago
      What makes me an expert is the amount of computer books I have near my desk. Sort of like how the enchantment table works in Minecraft. I am also a bash expert because I own an O’Reilly book on the subject I bought at a Borders 20 years ago at retail price. :)
      - arpa 5y ago
        I am a bash expert as well then, and probably the only person insane enough to have a web framework, complete with http server written in bash.
throwaway984393 5y ago
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. 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 real dedicated program (like the `rename` command) so you don't have to write a crappy line of "scripting". 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.
Recursing 5y ago
I'm surprised to see no mention of nushell [0] I've tried it a while ago and seemed really promising [0] https://www.nushell.sh/ https://www.nushell.sh/
sally1620 5y ago
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. 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.

159 points by mlerner 5y ago

I would like a SAFE distributed shell - allow me to run commands seamlessly on remote machines as if they are on my own. Check out op https://docs.shoreline.io/op https://docs.shoreline.io/op op> hosts | filter(cpu_usage > 80) | `pkill high_cpu_proc`

sbpoli 5y ago

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. 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? 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.

PaulDavisThe1st 5y ago

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.

adamnemecek 5y ago
unix people like is a solipsistic world where windows doesn’t exist.
- mmcgaha 5y ago
  Nope, unix people like the fact that thirty-year-old shell scripts still work just fine. In ten years, powershell will be be replaced and it will be the new vbscript. No thanks.
  - jeppesen-io 5y ago
    To have a real discussion on the future of shells while ignoring the PowerShell is not an honest discussion. I'm not sure why you'd want to run a 30 year old script when the computing environment has changed so much around those scripts. Regardless of what future you see for PowerShell as a product, the concepts and implementation, is a great place to see what works well and what didn't, particularly when it comes to non-text oriented pipeing
    - cybernautique 5y ago
      Stability is an important thing. The fact that 30 year old scripts still work, and still can be run, is a testament to the staying power of the underlying technology. That staying power generally means some reduction in cognitive load: I can use the same semantics, principles, and idioms on my phone, laptop, and computer. That's good. That's powerful. Contrast that with the JavaScript framework du jour: React today, React with new shiny hooks tomorrow; Svelte a week ago and a week from now; while the boss just told you in an email that the meeting an hour from now regards porting everything to Vue. That's the kind of cognitive load that we're thankfully spared by long-lasting technology. Now consider PowerShell. It is not an open standard. It is not an open technology. Its steward is Microsoft, of "Embrace, Extend, Extinguish" fame. It bucks against the long-established norm, so that all the established idioms are useless, while its semantics are just as tedious. Why, therefore, should I bother putting pilot time into this proprietary flying rug whose engine is more-likely-than-not a cracked bottle of Microsoft semen? As to whether PowerShell has anything to teach us about shell engineering: meh. It's not as good as Bash at doing Bash-like things and it's not as good as scripting languages at doing scripting things. EDIT: I figured I'd look to see whether PowerShell is open. Surprisingly, it is! With an MIT license to boot. However, as expected with any Microscum code, it includes telemetry out-of-the-box. As a matter of principle: I don't like it, I don't trust it, I don't want it. The semantics are ugly and it stinks of Microsoft.
- cybernautique 5y ago
  I specifically and purposefully ignore anything Microsoft. I'm interested in open computing, which Windows and Microsoft exist to spite. I assume Microsoft does everything in bad faith, and that any technology they deploy is ultimately in service of their walled gardens. I refuse to participate; I won't let myself be walled-in, and I won't give them any credibility. Windows does exist, but it ought not to.
  - zerocount 5y ago
    And it keeps getting worse with each version.
  - TrumpRapedWomen 5y ago
    You really need to update your attitude, the new Microsoft has embraced open source in a very real and meaningful way. https://dotnet.microsoft.com/en-us/download https://dotnet.microsoft.com/en-us/download https://github.com/PowerShell/PowerShell https://github.com/PowerShell/PowerShell PowerShell is SO much better than any Linux/Unix shell.
- agumonkey 5y ago
  I think it will change. I sense a reactive trend that will impact sys/shell interactions coming.
d0mine 5y ago
PowerShell might not satisfy: "Universal composition, Stream processing, Unix-native" points. Have you tried to pipe some bytes via PowerShell? Binary pipeline looks complicated https://stackoverflow.com/questions/33936074/decode-powershell-output-possibly-containing-non-ascii-unicode-characters-into-a https://stackoverflow.com/questions/33936074/decode-powershe...
- jeppesen-io 5y ago
  I'd suspect the OP would not say PowerShell is perfect or should be the *nix future, but that it's worth evaluating the ideas it brings to the table 50 years is quite the time horizon after all
jeppesen-io 5y ago
As someone who moved to Linux full-time, professionally and personally, there are times I do miss PowerShell. Never used anything like it. To tab complete "apis" and complex data structures was very enjoyable For better or worse, it's what I and my team used to manage a decent size VMware cluster of a hundred hosts and 6k VMs ( I think, it was a very long time ago) Wouldn't go back, but there are aspects I miss
- cobalt 5y ago
  powershell (core) is on linux btw
- hnlmorg 5y ago
  Powershell is available on Linux. Albeit it doesn't always play too nicely with existing CLI tools. There are also other typed shells that appeal to yourself which aren't Powershell but do have behaviours similar to Powershell and which do play a lot more nicely with the wider Linux / UNIX ecosystem: - murex https://github.com/lmorg/murex https://github.com/lmorg/murex - Elvish https://github.com/elves/elvish https://github.com/elves/elvish - NGS https://github.com/ngs-lang/ngs https://github.com/ngs-lang/ngs I'm the maintainer of murex so happy to answer any questions on that shell here. I do know the the maintainers of Elvish and NGS pop on HN too.
hulitu 5y ago
It seems odd that everytime there is a discussions about shells on UNIX, an ad to powershell comes in. Powershell might have its virtues but: 1)One cannot rely on it for system administration when limited resources are available. 2) even on windows is slow to start. 3) documentation is ... where ?
- jasode 5y ago
  >everytime there is a discussions about shells on UNIX, an ad to powershell comes in. The gp (Paul) is not "advertising Powershell" and he's not recommending people switch to it. Instead, he's saying that it's strange that an academic paper talking about future concepts doesn't even have a cursory survey of what other popular shells have done. Here's an example of that style of writing where other platform technologies are mentioned: Joshua Bloch is a ex-Sun employee and Java advocate proposing new syntax for Automatic Resource Management and in his note, he mentions what C# and C++ did: http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000011.html http://mail.openjdk.java.net/pipermail/coin-dev/2009-Februar... It shouldn't have to be said that citing C# & C++ does not mean it's an "ad for C#". When a new 2021 paper about future of shells has no mention of zsh, Powershell, etc by the authors, it's reasonable for readers to wonder if the team has overlooked what others have done. E.g. Powershell was designed by ex-UNIX admins.

nextaccountic 5y ago

So somehow this paper misses one of the greatest developments in this area, oil https://www.oilshell.org/ https://www.oilshell.org/ - which: 1. has a compatibility mode with sh and bash. it's the only new shell I know with a upgrade path from bash [0] 2. otherwise fixes tons of unix shell misfeatures and in particular fixes quoting hell [2] 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) [0] https://www.oilshell.org/why.html https://www.oilshell.org/why.html [1] https://www.oilshell.org/blog/2020/01/simplest-explanation.html https://www.oilshell.org/blog/2020/01/simplest-explanation.h... [2] https://www.oilshell.org/release/latest/doc/idioms.html https://www.oilshell.org/release/latest/doc/idioms.html [3] https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#why-is-it-written-in-python https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#w... [4] But actually I think there's still work to do to remove the CPython dependency at runtime, https://github.com/oilshell/oil/issues/636 https://github.com/oilshell/oil/issues/636

hnlmorg 5y ago
That paper misses a lot. Including: - murex https://github.com/lmorg/murex https://github.com/lmorg/murex - Elvish https://github.com/elves/elvish https://github.com/elves/elvish - NGS https://github.com/ngs-lang/ngs https://github.com/ngs-lang/ngs - Powershell - And any language REPLs turned into shells, such as Python, LISP, Lua and others. The author did say there is more to follow though so maybe the scope of this article was a little more closed by intention.
clavicat 5y ago
Great choice of name when there’s already an oil company called Shell.
- pasabagi 5y ago
  Presumably that won't matter so much in 50 years, since either Shell will be bust, or civilization will have collapsed.

1vuio0pswjnm7 5y ago

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 less 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.

chasil 5y ago
In order to use less resources, features will have to be removed. The pdksh version of the Korn shell was available to the POSIX shell standardization committee. It was not chosen because it was too large, with too many features. Another round of less-capable tools does not seem productive.
thanatos519 5y ago
I dunno, I've never had any complaints about bash's performance ... but I do appreciate the idea of a simple performant shell, as long as it doesn't break anything. I was annoyed to find many #!/bin/sh scripts broken in Debian 11 until I update-alternatives'd it to bash. There goes my performance, but hey presto now things work!
ilyash 5y ago
> As a daily shell user, I want a shell that uses even less resources Why is this important consideration for you? What's the use case?
- 1vuio0pswjnm7 5y ago
  Resource conservation. Computers I use are often older and/or have limited resources. I want to use available resources for other things. Example: http://cdn.netbsd.org/pub/NetBSD/NetBSD-current/src/distrib/utils/ssh/ssh.c http://cdn.netbsd.org/pub/NetBSD/NetBSD-current/src/distrib/...

throwawaybutwhy 5y ago

Thanks to the author for posting this. Thoughts, in no particular order: Repeatability: - We already have a dataflow graph, it's called makefiles - Going from shell commands to Ansible playbooks can be made easier - Declarative, idempotent commands - Integration with version control User friendliness: - GNU standards. If I cannot use --help and --version, I get angry - Backward compatibility. Ripgrep, I'm looking at you - 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 - Performance. Accidentally quadratic stuff is a Cthulhu-scaled abomination - Fancier prompts without needing to install extra software or add a bunch of PS1/PS2 scripts 'Novelties' (not so much, other OSes have had them before): - Coprocs - Easier parallelization - Improvement in job control - freezing and thawing jobs, moving jobs to other hosts etc. K8s/kubeflow and friends Security: - Better integration with secret managers - History cleanup when passwords are passed on the command line

kaba0 5y ago
> Backward compatibility. Ripgrep, I'm looking at you Is that really that important? I do have a few POSIX incantations ingrained into my muscle memory, but it’s not a good thing imo. Is that 4 God knows what flag and strange order really that important? Maybe add a separate backward compatible mode when issued through the old tool’s name, but I would like at least a partial revamp of the frankly, not too ergonomic POSIX tools. While Powershell can sometimes be more verbose, I would prefer a similar convention.
- throwawaybutwhy 5y ago
  Definitely important. It is a damper on gung-ho, brazen disregard for existing code/user base. It prevents code base rot and saves money for corporations/governments. It forces developers to adhere to the principle of least surprise, and ensures smooth user experience. Mind you, Powershell beats POSIX on readability hands down, and autocompletion would make longer, more readable options much easier to write. Still, the easiest way to increase adoption is to meticulously copy conventions from predecessors. Compatibility mode would be enough for most purposes if it's maintained and not dropped three years later in the name of progress and limited maintainer attention span.

unbanned 5y ago

Powershell. At least you have actual objects returned and don't have to parse stdio

usr1106 5y ago

The paper is 7 months old and has been submitted a dozen times. Most discussion is here: https://news.ycombinator.com/item?id=27378444 https://news.ycombinator.com/item?id=27378444 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.

louiskottmann 5y ago

I am a bash expert. This paper reads like it was written by clueless academics with no real world experience. Multicore bash already exists and is seldom used, through the "parallel" cmd. Other points address no particular issue, and would actually make the language more painful to use. 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.

thanatos519 5y ago
I'm also a bash expert and I agree! I wrote 75 lines of bash to do failure-resistant streaming parallel computation on heterogeneous distributed systems. "parallel" was very close to doing what I want, but it wasn't particularly hard to do it myself without it. I fire it up, peg every core on as many spot instances as AWS will give me, then shut them all down. I regularly pass data structures through pipes, and "jq" does everything I have needed so far. The tools can always get a bit better, but I don't need my duct tape to be any smarter, KTHX.
- arpa 5y ago
  what makes one a bash expert? genuinely curious if i could call myself one.
  - deleted 5y ago
    [deleted]
  - Bluecobra 5y ago
    What makes me an expert is the amount of computer books I have near my desk. Sort of like how the enchantment table works in Minecraft. I am also a bash expert because I own an O’Reilly book on the subject I bought at a Borders 20 years ago at retail price. :)
    - arpa 5y ago
      I am a bash expert as well then, and probably the only person insane enough to have a web framework, complete with http server written in bash.

throwaway984393 5y ago

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. 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 real dedicated program (like the `rename` command) so you don't have to write a crappy line of "scripting". 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.

Recursing 5y ago

I'm surprised to see no mention of nushell [0] I've tried it a while ago and seemed really promising [0] https://www.nushell.sh/ https://www.nushell.sh/

sally1620 5y ago

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. 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.