7 ms·

Sometimes it seems like I'm the only person that doesn't feel like they need "a better shell". This topic comes up a lot on HN. Maybe if a better shell came al

Sometimes it seems like I'm the only person that doesn't feel like they need "a better shell". This topic comes up a lot on HN. Maybe if a better shell came along I'd be surprised, not knowing what I was missing. Perhaps I'm just in the dark or not imaginative enough to conceive of what one would look like. With that said, whenever the discussion comes up, it seems to revolve around user specific workflow cases and "do what I want you to do, not what I tell you to do" design patterns, that would (from my perspective at least) feel hard to get right for everyone. As a result, we have lots of different shells now that make different trade offs and take different design approaches. That's great, right? I don't know -- I'm rambling I suppose, I just don't ever really feel like Bash (or fish/zsh/whatever) is holding me back or making my work more difficult than it needs to be. We can argue about the esotericisms of shell scripting and how it's silly to emulate old terminal escape sequences in virtual terminals, but I feel like it misses the point. I don't know, I'm certainly willing to change my mind here, it's just that for all of the problems I have day to day in sysadmin/programming job functions, the shell is the least of my worries most of the time.

rgoulter 5y ago
Fish shell's joke tagline is "Finally, a command line shell for the 90s". I believe that the developer experience for all sorts of tooling has improved dramatically over the last 15 years or so, coinciding with GitHub's rise in popularity. e.g. the plugin ecosystem for Vim or Emacs have improved, let alone options like VSCode. Tools like Vagrant made it easier to work with VMs. Containerised workflows have similarly improved some cases. Languages like Go-lang or Rust seem pretty nice in some cases. etc. Shells are also the kind of thing that developers use. I don't believe bash is the best we can practically get. -- Though.. I have heard of other, fancier shells; (or cool ideas like https://ambrevar.xyz/lisp-repl-shell/ https://ambrevar.xyz/lisp-repl-shell/ or http://howardism.org/Technical/Emacs/literate-devops.html http://howardism.org/Technical/Emacs/literate-devops.html). These haven't caught on.
- bradknowles 5y ago
  I don’t even see the need for fish or zsh. Bash is fine for me, and I just don’t see the point. Sure, if you want to use something else, you should feel free to knock yourself out. I do kinda wish I could filter out all the articles about other shells, though. They seem like a bit of wasted space to me.
mixedCase 5y ago
I'm in the same boat. Even for nontrivial shell scripts just having shellcheck around, assuming bash availability everywhere and treating `set -euo pipefail` (optionally -x bit too for some scripts) as a required header means I'm very happy writing and reading shell scripts. The only thing I've seen after well over a decade of Linux usage on desktop and servers that I've thought "this shouldn't have been a shell script" was xdg-open. But even then when things when wrong I was glad it was a script I could easily tweak and debug, at least.
pxc 5y ago
Imo the OP isn't really talking about a better shell in the sense that most next-gen shells aim to be. Seems like what they're really asking for is newer standards for terminal emulation and terminal multiplexing that allow shells to handle all the configuration in one place and support better integration for web content and probably multimedia. I agree with the OP that that would be nice, but I agree with you that it seems less urgent than other aspects of my computing environment. This, though, I don't understand: > We can argue about the esotericisms of shell scripting [...] but I feel like it misses the point. Shells are, among other things, programming languages. How can attentiveness to the suitability of that language possibly miss the point?
- spsesk117 5y ago
  Thanks for the reply. I think you make a fair point regarding shells as programming languages. I guess what I meant regarding missing the point is that, from my perspective, the shell was and is a basic way to interface with your computer system. Basic is a keyword here -- there are other ways to do it (native programs, syscalls, etc), but as a basic interface into operating and running programs on a computer, I think most shells do a pretty good job. As I said in my original comment, maybe they could be doing a better job and I'm just not seeing it, but this is in essence my thought. If Bash is too messy, there are a wealth of other highly portable and maintainable languages to do cross platform scripting on. Python comes to mind, as does Rust, and even older things such as Perl. I'm rambling a bit, I'm not sure my thoughts on the matter are that coherent. I guess in summation I'd just say, I think it's fine if shells are shells, and if they can't be stretched to accommodate hyper specific workflows and patterns, maybe consider writing it another language? Do shells languages have to be as capable as general purpose programming languages, and if so, why?
  - pxc 5y ago
    > I'm rambling a bit, I'm not sure my thoughts on the matter are that coherent. [...] Do shells languages have to be as capable as general purpose programming languages, and if so, why? I think your thoughts here are definitely coherent, and in fact you're getting to the heart of the issue. This exact question is pretty central in motivating many next-generation shells. I'll refer to the documentation of a few of them below. Feel free to follow the associated link to tug on any of the threads and see if the overall argument holds in your opinion. > Python and Ruby aren't good shell replacements in general. Shell is a domain-specific language for dealing with concurrent processes and the file system. Python and Ruby have too much abstraction over these concepts, sometimes in the name of portability (e.g. to Windows). They hide what's really going on. — Oil Shell: Why create a new shell?: Shouldn't scripts over 100 lines be rewritten in Ruby or Python? ( https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#shouldnt-scripts-over-100-lines-be-rewritten-in-python-or-ruby https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#s... ) > Traditional shells use strings for all kinds of data. They can be stored in variables, used as function arguments, written to output and read from input. Strings are very simple to use, but they fall short if your data has an inherent structure. A common solution is using pseudo-structures of “each line representing a record, and each (whitespace-separated) field represents a property”, which is fine as long as your data do not contain whitespaces. If they do, you will quickly run into problems with escaping and quotation and find yourself doing black magics with strings. […] Elvish offers first-class support for data structures such as lists and maps. — Elvish: Some Unique Semantics: Structureful IO: Motivation ( https://elv.sh/learn/unique-semantics.html#motivation https://elv.sh/learn/unique-semantics.html#motivation ) > bash does not meet any modern expectations for syntax, error handling nor has ability to work with structured data (beyond arrays and associative arrays which can not be nested). Let it go. You are not usually coding in assembly, FORTRAN, C, or C++, do you? They just don’t match the typical Ops tasks. Don’t make your life harder than it should be. Let it go. (Let’s not make it a blanket statement. Use your own judgement when to make an exception). > > Python along with many other languages are general purpose programming languages which were not intended to solve specifically Ops problems. The consequence is longer and less readable scripts when dealing with files or running external programs, which are both pretty common for Ops. For example, try to check every status code of every program you run, see how your code looks like. Sure you can import 3rd party library for that. Is that as convenient as having automatic checking by default + list of known programs which don’t return zero + convenient syntax for specifying/overriding expected exit code? I guess not. — Next Generation Shell: bash or Python? The Square Pegs and a Round Hole Situation: Both are Inadequate for Ops ( https://ilya-sher.org/2020/10/31/bash-or-python-the-square-pegs-and-a-round-hole-situation/ https://ilya-sher.org/2020/10/31/bash-or-python-the-square-p... ) For me, the great thing about a shell language is that it's a programming language I get to _live_ in. Scripts can just grow organically from commands I chain together at my shell prompt, including simple loops and blocks and stuff. The better I get at the programming language, the better I get at navigating my computer and performing routine tasks. The better I get at navigating my computer and performing routine tasks, the better I get at the programming language. This is a really wonderful kind of thing imo, but its usefulness is undermined when one dimension of the shell (interactivity or programming capability) holds back the combination of the two. The idea with these new shells is to try to find a way to enhance the programming capabilities of shells without making them any less convenient for navigating the filesystem and performing simple tasks with external programs. There definitely are shells that (imo) have tried to improve programmability (usually be embedding in a full-fledged programming language) in a way that undermines the simplicity and freeform character of shell languages, for example Rush (embedded in Ruby), Ammonite (embedded in Scala) and Xonsh (embedded in Python). But other next-generation shells, mostly following the examples of PowerShell and Fish (and lots of programming languages), (imo) do a remarkable job of improving programmability without making simple, everyday shell navigation workflows feel any weirder or more laborious. In particular, Elvish, Nushell, and Oil Shell strike me as very thoughtful efforts whose very small teams of contributors have been hacking away at them for quite a long time. One important thing to keep in mind for this particular breed of next-gen shells is that their novelty is mostly in the synthesis of a collection of minor and conservative innovations— things that we've seen in some shells (like PowerShell) and some programming languages (especially Lisps) for a long time. Each of these shells is a substantial leap forward beyond shells like Bash only because the language designs of shells like Bash have been largely frozen for decades. For a concrete example of this perspective: > Nu takes cues from a lot of familiar territory: traditional shells like bash, advanced shells like PowerShell, functional programming, systems programming, and more. But rather than trying to be the jack of all trades, Nu focuses its energy on doing a few things well: > > * Create a flexible cross-platform shell with a modern feel > * Allow you to mix and match commandline applications with a shell that understands the structure of your data > * Have the level of UX polish that modern CLI apps provide — The Nushell Book: Introduction ( https://www.nushell.sh/book/#introduction https://www.nushell.sh/book/#introduction ) That phrase at the end of the second bullet point is key: ‘a shell that understands the structure of your data’. We can see a clear call for shells like that in the growing crop of fancy new CLI tools designed for chopping up, querying, and modifying ‘structured’ (not merely textual or stringly-typed) data. Tools like that frequently show up here on HN: jq for JSON, yq for YAML, xsv for CSV, etc. Developers and sysadmins want to be able to pull in structured data from whatever source and query it and manipulate it right there inside their shells. But each format gets its own utilities for that kind of querying and manipulation, and they don't necessarily know how to talk to each other. The pipelines we use to plug various tools like this into each other, meanwhile, only know about raw text/byte streams. The natural thing to want, when you're faced with this, is to be able to just ingest data of all of these forms into variables in your shell which retain that structure, and query them in a uniform way (that your shell may even be able to assist you with as you type, with some static checking!). The Elvish shell has a nice example of using this to query the latest Elvish issues from GitHub on their website: curl -s https://api.github.com/repos/elves/elvish/issues | from-json | all (one) | each [issue]{ echo $issue[number]: $issue[title] } | head -n 11 which prints, on my system right now: 1396: Exception control: “try” should rethrow flow control exceptions 1391: Document forking behaviour 1385: Feature request: command to find location of rc.elv file 1381: `use edit` creates a crash situation for elvish 1380: Issues running `wal -i` 1377: exit builtin does not trigger program's defer statements 1376: buildin cmd source ! 1374: Feed stdin to all code blocks in run-parallel 1373: Recent performance/speed benchmarks? 1372: Octal Format Specifier 1371: "autoview", tables, new data formats... Imo that's pretty neat and concise! Now that JSON is increasingly a de facto standard interchange format, not just for web apps but often (optionally) for CLI programs, I think having idioms like this in your shell makes a ton of sense. And we don't have to give up the convenience of a simple, fast, filesystem-oriented, interactive shell experience to get it!
BeetleB 5y ago
Have you tried magit? Not a serious user myself, but for many, many folks it is way better than using git on the command line (or via any GUI). When he says he'd like that type of interface for all command line utilities (like tar), I can appreciate what he's referring to. Much more discoverable than reading man pages.
- spsesk117 5y ago
  Thanks for the reply. I do use magit, daily, and I really enjoy it. I think what I don't understand about the OP's point is that, why is that the shells problem? Tar is a utility that works great, and is typically pretty easy to use on the CLI. If however, I don't particularly like it, or would rather use a GUI that's totally understandable. The OP could even implement one in elisp for emacs. I guess my thought is that, why is the burden on the author of this magical new shell to write a piece of software that can GUIfy tar, than the user of tar who doesn't like it's ergonomics? Maybe that's not what the author is saying, but to me it just seems like something not really related to the shell, or a discussion on shells. If you like using GUIs, find a GUI for tar, or write one. I don't say that to be flippant, but more to reiterate my misunderstanding of how this relates to a discussion on shells.
  - BeetleB 5y ago
    > I think what I don't understand about the OP's point is that, why is that the shells problem? I think to understand his point, substitute "universal text interface" with "shell". What he really is describing is something very Emacs-like, but with a better config than you normally find in Emacs. He'd like most command line utilities to automatically have a magit-like interface through some universal spec/language (i.e. so that each utility doesn't have to create the interface independently). Tar is one of those utilities that many people, including me, can never remember the options. I can relate to him on that one. If I had a magit like interface for tar, I'd be really happy.
    - User23 5y ago
      Spacemacs[1] is a particularly nifty solution to the emacs defaults being... special. There are other bespoke config systems out there, but it really impresses me. The maintainers take performance and, more importantly to me, interface consistency and discoverability seriously. It supports both Vi style bindings as well as the traditional Emacs ones. Combined with a distribution like Emacs Plus[2] with the --with-native-comp it's a very nice way to interact with the system. [1] https://www.spacemacs.org/ https://www.spacemacs.org/ [2] https://github.com/d12frosted/homebrew-emacs-plus https://github.com/d12frosted/homebrew-emacs-plus
mamcx 5y ago
Well, nearly nobody have experience with a REAL good shell. Is like using C all your life and don't have experience what a truly good language is. I work in FoxPro DOS back in the days. That is another dimension. Was close to jupyter + IDE + Database Builder + Form Builder + Code Editor + ... and the language to make stuff is NOT a joke. That is not the only vision that happen in the past but is forgotten (or rebuilded with a massive micro-service/over-engineer/multi-machine version). /r So, to me, using the shell is purely because not exist most stubborn people that the one that lives in the unix/c world, that have forced for decades the use of the most arcane and inferior toolchain possible, and always shutdown any attempts of improvements under the excuse "but it works for me". Is like regulatory capture to 1000x. /r
- deleted 5y ago
  [deleted]
1vuio0pswjnm7 5y ago
"Sometimes I feel like I'm the only person that doesn't feel like they need "a better shell"." You are not the only person. There are HN readers who are not programming language wonks, who actually enjoy using the shell. Whenever someone today, usually one of said programming language wonks, tries to "improve" on existing shells it never manages to improve over the relative speed/size/simplicity I am getting with ash already. It never feels like its being written by someone who likes the shell; it feels like some programming language wonk who dislikes the shell (thus wants to "improve" it). Give me a shell thats even simpler, smaller and faster than ash. That would be an improvement. Early era and deliberately "reduced" shells I have tried in place of ash do not have command history. I have tried to learn to work more "deterministically", without need for history but have never succeeded. I think it can be done. (So does the maintainer of the Heirloom Project.)^1 In practice I often edit command lines in vi, using the fc built-in. Why cant I do all editing in vi or ed. I suspect its the addictiveness of the "REPL" workflow. For whatever reason, I am more motivated to try shells with reduced functionality than I am ones with increased functionality. For any repeated task, taking a long view, non-interactive use is always faster than interactive use, so although a nifty feature like tcsh-style auto-completion might speed up interactive use, a script that automates navigation is going to save time in the long-term. 1. "interactive use. The Bourne shell provides job control if it is invoked as jsh and runs on a terminal. Of course, it lacks fancy features such as a command history, command line completion, etc. But working with these features tends to distract the user's attention. After a familiarization phase, use of the Bourne shell can lead to a more even-tempered, concentrated working style. Give it a try. Seriously." https://heirloom.sourceforge.net/sh.htm https://heirloom.sourceforge.net/sh.htm
otabdeveloper4 5y ago
Just fix bash so it saves every line of your history ever, no exceptions and no deletions. (Except for the 'leading space' trick when security considerations are in play.) It's insane that this isn't the default behavior and can't even be configured in 2021!
curryst 5y ago
I think there's stuff that could definitely be an improvement. One that I take issue with is the "everything is a string" mentality of bash. It makes working with structured data harder than necessary, and a ton of stuff I do with my shell involves structured data like JSON. A sane array and hashmap implementation would be nice. Another thing, which I picked up from elvish, is the concept of separating the textual output of a function from the value it returns. Bash lacks that distinction; the textual output is the value, which makes it annoying to do things like log from a function but also return a value. I really like Elvish. It's similar enough to bash that I don't feel like the floor has been pulled out from under me, but it makes it dead simple to do something like pull data from a REST API without me having to pull out Python. The other big pattern I've seen is object-oriented shells like Powershell and Nushell. They seem neat, but too complicated for me to manage in my head while trying to get stuff done. They're a little further towards "programming lanugage" on the range of shell to programming language.
bgro 5y ago
Same. Every time I hear someone complain about, for example, bash it's always because they put no effort into learning how to use it / what it can do / best practices. They just get mad that their typo on a filename isn't auto corrected, and completely ignore the fact that you can tab to auto complete and avoid that problem in the first place. Everyone wants to rush to fix these perceived problems without realizing how some sort of fully automated AI guessing ability about which file to rm -rf is not a good idea, and is not what anybody actually wants.

rgoulter 5y ago

Fish shell's joke tagline is "Finally, a command line shell for the 90s". I believe that the developer experience for all sorts of tooling has improved dramatically over the last 15 years or so, coinciding with GitHub's rise in popularity. e.g. the plugin ecosystem for Vim or Emacs have improved, let alone options like VSCode. Tools like Vagrant made it easier to work with VMs. Containerised workflows have similarly improved some cases. Languages like Go-lang or Rust seem pretty nice in some cases. etc. Shells are also the kind of thing that developers use. I don't believe bash is the best we can practically get. -- Though.. I have heard of other, fancier shells; (or cool ideas like https://ambrevar.xyz/lisp-repl-shell/ https://ambrevar.xyz/lisp-repl-shell/ or http://howardism.org/Technical/Emacs/literate-devops.html http://howardism.org/Technical/Emacs/literate-devops.html). These haven't caught on.

bradknowles 5y ago
I don’t even see the need for fish or zsh. Bash is fine for me, and I just don’t see the point. Sure, if you want to use something else, you should feel free to knock yourself out. I do kinda wish I could filter out all the articles about other shells, though. They seem like a bit of wasted space to me.

mixedCase 5y ago

I'm in the same boat. Even for nontrivial shell scripts just having shellcheck around, assuming bash availability everywhere and treating `set -euo pipefail` (optionally -x bit too for some scripts) as a required header means I'm very happy writing and reading shell scripts. The only thing I've seen after well over a decade of Linux usage on desktop and servers that I've thought "this shouldn't have been a shell script" was xdg-open. But even then when things when wrong I was glad it was a script I could easily tweak and debug, at least.

pxc 5y ago

Imo the OP isn't really talking about a better shell in the sense that most next-gen shells aim to be. Seems like what they're really asking for is newer standards for terminal emulation and terminal multiplexing that allow shells to handle all the configuration in one place and support better integration for web content and probably multimedia. I agree with the OP that that would be nice, but I agree with you that it seems less urgent than other aspects of my computing environment. This, though, I don't understand: > We can argue about the esotericisms of shell scripting [...] but I feel like it misses the point. Shells are, among other things, programming languages. How can attentiveness to the suitability of that language possibly miss the point?

spsesk117 5y ago
Thanks for the reply. I think you make a fair point regarding shells as programming languages. I guess what I meant regarding missing the point is that, from my perspective, the shell was and is a basic way to interface with your computer system. Basic is a keyword here -- there are other ways to do it (native programs, syscalls, etc), but as a basic interface into operating and running programs on a computer, I think most shells do a pretty good job. As I said in my original comment, maybe they could be doing a better job and I'm just not seeing it, but this is in essence my thought. If Bash is too messy, there are a wealth of other highly portable and maintainable languages to do cross platform scripting on. Python comes to mind, as does Rust, and even older things such as Perl. I'm rambling a bit, I'm not sure my thoughts on the matter are that coherent. I guess in summation I'd just say, I think it's fine if shells are shells, and if they can't be stretched to accommodate hyper specific workflows and patterns, maybe consider writing it another language? Do shells languages have to be as capable as general purpose programming languages, and if so, why?
- pxc 5y ago
  > I'm rambling a bit, I'm not sure my thoughts on the matter are that coherent. [...] Do shells languages have to be as capable as general purpose programming languages, and if so, why? I think your thoughts here are definitely coherent, and in fact you're getting to the heart of the issue. This exact question is pretty central in motivating many next-generation shells. I'll refer to the documentation of a few of them below. Feel free to follow the associated link to tug on any of the threads and see if the overall argument holds in your opinion. > Python and Ruby aren't good shell replacements in general. Shell is a domain-specific language for dealing with concurrent processes and the file system. Python and Ruby have too much abstraction over these concepts, sometimes in the name of portability (e.g. to Windows). They hide what's really going on. — Oil Shell: Why create a new shell?: Shouldn't scripts over 100 lines be rewritten in Ruby or Python? ( https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#shouldnt-scripts-over-100-lines-be-rewritten-in-python-or-ruby https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#s... ) > Traditional shells use strings for all kinds of data. They can be stored in variables, used as function arguments, written to output and read from input. Strings are very simple to use, but they fall short if your data has an inherent structure. A common solution is using pseudo-structures of “each line representing a record, and each (whitespace-separated) field represents a property”, which is fine as long as your data do not contain whitespaces. If they do, you will quickly run into problems with escaping and quotation and find yourself doing black magics with strings. […] Elvish offers first-class support for data structures such as lists and maps. — Elvish: Some Unique Semantics: Structureful IO: Motivation ( https://elv.sh/learn/unique-semantics.html#motivation https://elv.sh/learn/unique-semantics.html#motivation ) > bash does not meet any modern expectations for syntax, error handling nor has ability to work with structured data (beyond arrays and associative arrays which can not be nested). Let it go. You are not usually coding in assembly, FORTRAN, C, or C++, do you? They just don’t match the typical Ops tasks. Don’t make your life harder than it should be. Let it go. (Let’s not make it a blanket statement. Use your own judgement when to make an exception). > > Python along with many other languages are general purpose programming languages which were not intended to solve specifically Ops problems. The consequence is longer and less readable scripts when dealing with files or running external programs, which are both pretty common for Ops. For example, try to check every status code of every program you run, see how your code looks like. Sure you can import 3rd party library for that. Is that as convenient as having automatic checking by default + list of known programs which don’t return zero + convenient syntax for specifying/overriding expected exit code? I guess not. — Next Generation Shell: bash or Python? The Square Pegs and a Round Hole Situation: Both are Inadequate for Ops ( https://ilya-sher.org/2020/10/31/bash-or-python-the-square-pegs-and-a-round-hole-situation/ https://ilya-sher.org/2020/10/31/bash-or-python-the-square-p... ) For me, the great thing about a shell language is that it's a programming language I get to _live_ in. Scripts can just grow organically from commands I chain together at my shell prompt, including simple loops and blocks and stuff. The better I get at the programming language, the better I get at navigating my computer and performing routine tasks. The better I get at navigating my computer and performing routine tasks, the better I get at the programming language. This is a really wonderful kind of thing imo, but its usefulness is undermined when one dimension of the shell (interactivity or programming capability) holds back the combination of the two. The idea with these new shells is to try to find a way to enhance the programming capabilities of shells without making them any less convenient for navigating the filesystem and performing simple tasks with external programs. There definitely are shells that (imo) have tried to improve programmability (usually be embedding in a full-fledged programming language) in a way that undermines the simplicity and freeform character of shell languages, for example Rush (embedded in Ruby), Ammonite (embedded in Scala) and Xonsh (embedded in Python). But other next-generation shells, mostly following the examples of PowerShell and Fish (and lots of programming languages), (imo) do a remarkable job of improving programmability without making simple, everyday shell navigation workflows feel any weirder or more laborious. In particular, Elvish, Nushell, and Oil Shell strike me as very thoughtful efforts whose very small teams of contributors have been hacking away at them for quite a long time. One important thing to keep in mind for this particular breed of next-gen shells is that their novelty is mostly in the synthesis of a collection of minor and conservative innovations— things that we've seen in some shells (like PowerShell) and some programming languages (especially Lisps) for a long time. Each of these shells is a substantial leap forward beyond shells like Bash only because the language designs of shells like Bash have been largely frozen for decades. For a concrete example of this perspective: > Nu takes cues from a lot of familiar territory: traditional shells like bash, advanced shells like PowerShell, functional programming, systems programming, and more. But rather than trying to be the jack of all trades, Nu focuses its energy on doing a few things well: > > * Create a flexible cross-platform shell with a modern feel > * Allow you to mix and match commandline applications with a shell that understands the structure of your data > * Have the level of UX polish that modern CLI apps provide — The Nushell Book: Introduction ( https://www.nushell.sh/book/#introduction https://www.nushell.sh/book/#introduction ) That phrase at the end of the second bullet point is key: ‘a shell that understands the structure of your data’. We can see a clear call for shells like that in the growing crop of fancy new CLI tools designed for chopping up, querying, and modifying ‘structured’ (not merely textual or stringly-typed) data. Tools like that frequently show up here on HN: jq for JSON, yq for YAML, xsv for CSV, etc. Developers and sysadmins want to be able to pull in structured data from whatever source and query it and manipulate it right there inside their shells. But each format gets its own utilities for that kind of querying and manipulation, and they don't necessarily know how to talk to each other. The pipelines we use to plug various tools like this into each other, meanwhile, only know about raw text/byte streams. The natural thing to want, when you're faced with this, is to be able to just ingest data of all of these forms into variables in your shell which retain that structure, and query them in a uniform way (that your shell may even be able to assist you with as you type, with some static checking!). The Elvish shell has a nice example of using this to query the latest Elvish issues from GitHub on their website: curl -s https://api.github.com/repos/elves/elvish/issues | from-json | all (one) | each [issue]{ echo $issue[number]: $issue[title] } | head -n 11 which prints, on my system right now: 1396: Exception control: “try” should rethrow flow control exceptions 1391: Document forking behaviour 1385: Feature request: command to find location of rc.elv file 1381: `use edit` creates a crash situation for elvish 1380: Issues running `wal -i` 1377: exit builtin does not trigger program's defer statements 1376: buildin cmd source ! 1374: Feed stdin to all code blocks in run-parallel 1373: Recent performance/speed benchmarks? 1372: Octal Format Specifier 1371: "autoview", tables, new data formats... Imo that's pretty neat and concise! Now that JSON is increasingly a de facto standard interchange format, not just for web apps but often (optionally) for CLI programs, I think having idioms like this in your shell makes a ton of sense. And we don't have to give up the convenience of a simple, fast, filesystem-oriented, interactive shell experience to get it!

BeetleB 5y ago

Have you tried magit? Not a serious user myself, but for many, many folks it is way better than using git on the command line (or via any GUI). When he says he'd like that type of interface for all command line utilities (like tar), I can appreciate what he's referring to. Much more discoverable than reading man pages.

spsesk117 5y ago
Thanks for the reply. I do use magit, daily, and I really enjoy it. I think what I don't understand about the OP's point is that, why is that the shells problem? Tar is a utility that works great, and is typically pretty easy to use on the CLI. If however, I don't particularly like it, or would rather use a GUI that's totally understandable. The OP could even implement one in elisp for emacs. I guess my thought is that, why is the burden on the author of this magical new shell to write a piece of software that can GUIfy tar, than the user of tar who doesn't like it's ergonomics? Maybe that's not what the author is saying, but to me it just seems like something not really related to the shell, or a discussion on shells. If you like using GUIs, find a GUI for tar, or write one. I don't say that to be flippant, but more to reiterate my misunderstanding of how this relates to a discussion on shells.
- BeetleB 5y ago
  > I think what I don't understand about the OP's point is that, why is that the shells problem? I think to understand his point, substitute "universal text interface" with "shell". What he really is describing is something very Emacs-like, but with a better config than you normally find in Emacs. He'd like most command line utilities to automatically have a magit-like interface through some universal spec/language (i.e. so that each utility doesn't have to create the interface independently). Tar is one of those utilities that many people, including me, can never remember the options. I can relate to him on that one. If I had a magit like interface for tar, I'd be really happy.
  - User23 5y ago
    Spacemacs[1] is a particularly nifty solution to the emacs defaults being... special. There are other bespoke config systems out there, but it really impresses me. The maintainers take performance and, more importantly to me, interface consistency and discoverability seriously. It supports both Vi style bindings as well as the traditional Emacs ones. Combined with a distribution like Emacs Plus[2] with the --with-native-comp it's a very nice way to interact with the system. [1] https://www.spacemacs.org/ https://www.spacemacs.org/ [2] https://github.com/d12frosted/homebrew-emacs-plus https://github.com/d12frosted/homebrew-emacs-plus

mamcx 5y ago

Well, nearly nobody have experience with a REAL good shell. Is like using C all your life and don't have experience what a truly good language is. I work in FoxPro DOS back in the days. That is another dimension. Was close to jupyter + IDE + Database Builder + Form Builder + Code Editor + ... and the language to make stuff is NOT a joke. That is not the only vision that happen in the past but is forgotten (or rebuilded with a massive micro-service/over-engineer/multi-machine version). /r So, to me, using the shell is purely because not exist most stubborn people that the one that lives in the unix/c world, that have forced for decades the use of the most arcane and inferior toolchain possible, and always shutdown any attempts of improvements under the excuse "but it works for me". Is like regulatory capture to 1000x. /r

deleted 5y ago
[deleted]

1vuio0pswjnm7 5y ago

"Sometimes I feel like I'm the only person that doesn't feel like they need "a better shell"." You are not the only person. There are HN readers who are not programming language wonks, who actually enjoy using the shell. Whenever someone today, usually one of said programming language wonks, tries to "improve" on existing shells it never manages to improve over the relative speed/size/simplicity I am getting with ash already. It never feels like its being written by someone who likes the shell; it feels like some programming language wonk who dislikes the shell (thus wants to "improve" it). Give me a shell thats even simpler, smaller and faster than ash. That would be an improvement. Early era and deliberately "reduced" shells I have tried in place of ash do not have command history. I have tried to learn to work more "deterministically", without need for history but have never succeeded. I think it can be done. (So does the maintainer of the Heirloom Project.)^1 In practice I often edit command lines in vi, using the fc built-in. Why cant I do all editing in vi or ed. I suspect its the addictiveness of the "REPL" workflow. For whatever reason, I am more motivated to try shells with reduced functionality than I am ones with increased functionality. For any repeated task, taking a long view, non-interactive use is always faster than interactive use, so although a nifty feature like tcsh-style auto-completion might speed up interactive use, a script that automates navigation is going to save time in the long-term. 1. "interactive use. The Bourne shell provides job control if it is invoked as jsh and runs on a terminal. Of course, it lacks fancy features such as a command history, command line completion, etc. But working with these features tends to distract the user's attention. After a familiarization phase, use of the Bourne shell can lead to a more even-tempered, concentrated working style. Give it a try. Seriously." https://heirloom.sourceforge.net/sh.htm https://heirloom.sourceforge.net/sh.htm

otabdeveloper4 5y ago

Just fix bash so it saves every line of your history ever, no exceptions and no deletions. (Except for the 'leading space' trick when security considerations are in play.) It's insane that this isn't the default behavior and can't even be configured in 2021!

curryst 5y ago

I think there's stuff that could definitely be an improvement. One that I take issue with is the "everything is a string" mentality of bash. It makes working with structured data harder than necessary, and a ton of stuff I do with my shell involves structured data like JSON. A sane array and hashmap implementation would be nice. Another thing, which I picked up from elvish, is the concept of separating the textual output of a function from the value it returns. Bash lacks that distinction; the textual output is the value, which makes it annoying to do things like log from a function but also return a value. I really like Elvish. It's similar enough to bash that I don't feel like the floor has been pulled out from under me, but it makes it dead simple to do something like pull data from a REST API without me having to pull out Python. The other big pattern I've seen is object-oriented shells like Powershell and Nushell. They seem neat, but too complicated for me to manage in my head while trying to get stuff done. They're a little further towards "programming lanugage" on the range of shell to programming language.

bgro 5y ago

Same. Every time I hear someone complain about, for example, bash it's always because they put no effort into learning how to use it / what it can do / best practices. They just get mad that their typo on a filename isn't auto corrected, and completely ignore the fact that you can tab to auto complete and avoid that problem in the first place. Everyone wants to rush to fix these perceived problems without realizing how some sort of fully automated AI guessing ability about which file to rm -rf is not a good idea, and is not what anybody actually wants.