While removing weird stuff from daily bash annoyances is interesting, I'm not necessarily looking to replace that with brand new but also pretty random weird stuff. Adding new rules isn't the same as adding structure. The documentation is also frequently strange in a way that makes it hard to digest. From https://elv.sh/learn/first-commands.html#external-commands
> While Elvish provides a lot of useful functionalities as builtin commands, it can’t do everything. This is where external commands come in, which are separate programs installed on your machine. Many useful programs come in the form of external commands, and there is no limit on what they can do. Here are just a few examples: Git provides the git command to manage code repositories
At first I thought, wait, is this a shell or not, do I have to write code or something to get access to normal external commands? But no, this is more like going to a car dealership and having the salesman say "Hey thanks for coming by, a car is a mechanical device consisting of metal parts and rubber parts for the purpose of taking you where you need to go! Now that we're on the same page about that, money is a thing made of paper for the purposes of .."
Docs are hard, once or twice is fine, but lots of parts are like this and I gave up reading. Not sure if it's AI generated, but if the project is doing that then it should stop, and if it's not doing that it should consider starting to
I mean, you are literally reading the first chapter of the tutorial for beginners (“Beginner's Guide to Elvish is for you if you haven’t used shells a lot or want to brush up on the basics”).
I did browse around, that's the page I got the first part of my comment from. Modules are one example of something that sounds probably good (https://elv.sh/ref/language.html#modules ). Good stuff is really weakened though by the many random changes that seem to go from arbitrary to.. also arbitrary, while destroying any chance of readability, backwards compatibility, or interoperability. Why?
> Line continuation in Elvish uses ^ instead of \
> Bash: echo .[ch] vs Elvish: echo .?[set:ch]
One more example, guess what this does: `echo &sep=',' foo bar`. Is it bash, elvish? Some combination of the two with markdown? Legal in all three? Elvish certainly cleans up conditionals and stuff, but you probably shouldn't introduce new things with exactly the same name unless you've created a genuine superset/dialect where the older version still works without rewrite. Namespace it as elvish.echo or use your module system. Shadows aren't friendly, this is equivalent to the guy that monkey-patches sys.stderr=sys.stdout to work around their one-off problem
I've been using fish for many years now though I keep trying all these new shells.
Ultimately I've found that for my interactive shell I just want something widely supported and with easy syntax for `if` and `for` loops for short multi-line commands. For anything longer than that I just reach for real Python using either the `sh` or `plumbum` package.
I don't need the extra features very often, so I just run things in full Python where I'm already comfortable.
I've tried oils/ysh, elvish, xonsh, nushell, and while they are _fine_ I don't want to learn a different language that's not quite Python and not quite shell.
I'm also a fish fan and largely agree--but if you are forced to use Windows and you don't care for WSL, nushell is likely your best option. It's pretty good! Almost feels like Unix but you're in Windows. I don't think fish shell will be ported over to Windows anytime soon...
After getting frustrated with how unusual and convoluted BASH syntax tends to be, especially with involved scripts, I've tried almost all of the alternative shells: Elvish, Fish, Oil, Xonsh (Python!), Emacs's eshell, and even the Haskell-based shell repls like Turtle and Shelly. The only one I really stuck with was Nushell. It's friendly, pretty, intuitive, easy to read, heavy on pipes, and super powerful for data analysis. Plus it's modern replacement for a lot of tools, like `ls`, `jq`, `curl`, and so on. Writing a little command-line program is a joy in Nushell.
I went down this route based on HN recommendations, with some people calling it stable well documented.
There's TODOs all over the documentation! There's no background task tools for scripting, and in interactive use background tasks are barely supported - an issue about background tasks has people going roughly "nobody needs to do tasks in parallel, that was only important when people were working on mainframes". The shell hooks have (undocumented) weird restrictions. Lazy iteration of lists is only supported by using functions with callbacks. Stable = development appears stopped.
This is half baked and dead. For my new computer I really really wanted a lightweight new shell with orthogonal syntax thought out from the ground up and not glued together over 4 decades, and this seemed like the closest option! But this isn't it.
There’s also a lot of good design that’s gone into Elvish. And I don’t think it’s fair to call it “dead” when the maintainers for Elvish are active both on Github and here on HN too (probably other places too).
However if you’re looking for an alternative then there’s:
- Murex (disclaimer: I’m one of the maintainers) which does support background processes and has extensive documentation. https://murex.rocks
- Nushell: I’m not personally a fan of its design choices but it has a large following of people who do really enjoy it so it might also appeal to yourself too.
As for Elvish, I do encourage others to give it a go themselves. It’s really well thought out and what might be a deal breaker for some people isn’t for others.
Elvish had some very cool ideas, which is why I tried it out! Like the built in script checker! But it also has a lot of very basic issues that have been open for years, and TODOs in the documentation as I mentioned. People are going to read your message and put N hours into it and get burned, and I think this is a fair warning.
Nushell also had very minimal background task support, so I rejected that. They explicitly say use some other program for background tasks in their docs.
I actually looked at Murex after seeing it in previous threads, but I bounced for some reason... I just took another look though skipping the tutorial and I see you have `bg` and `fg` support! But does `bg` return the `fid`? Can you use those in scripts, or are they hobbled the same way bg/fg are in bash?
It's been a good 4-5 months since I went down this rabbit hole, but IIRC the basic things I wanted to do and got blocked in multiple shells were:
- System-wide interactive-use config file, I use Nixos and manage my system config using that
- Background task support - I need to start an ssh tcp proxy, pipe a command over it, then kill ssh once the command is done (all in a script).
- Post-command hook, to send a notification when a long command finishes
- Async iteration of command output, i.e. streaming events with swaymsg subscribe and running a command when certain events occur
- Value/call arity safety - i.e. a clear distinction between a single value and multiple values that doesn't rely on stringification hacks. I.e. in `command $x` `command` should always have one argument, regardless of the contents of `x`, and making that plural should be explicit.
And then other standard evaluation criteria, like I looked at xonsh but it seemed like a massive hack, despite handling a lot of the above.
could you go into more detail how (and maybe why) murex and elvish differ?
also, i'd like to know more about how the job control works. that's one of the pain points in elvish, but both are written in go, so maybe there are some ideas that elvish could copy.
If by any chance you're an Emacs user, check out Eshell. It blends Elisp macros with shell commands, and since it keeps the buffer model, you can use all the usual Emacs tools for searching, sorting, and more. It's a unique shell with some learning curve, but it's mature and powerful.
I think I didn't look at it initially because it was too close to bash, and then by the time I burned out on fully reimagined shells I fell back to zsh which was the shell I knew supported post-command hooks. Definitely not a final decision, but it might be a while before I try new shells again...
Just to add some further qualification, I was fully prepared to learn something from the ground up, throw away all my preconceptions, and give some weirdness a try - including no string interpolation. I wanted to 100% replace bash, both as a shell and for scripting everywhere. I was exactly Elvish's target user.
it's still under development, but it most certainly isn't dead. it's stable in that development is not disruptive. i use it as a daily driver.
you are right about lack of support for job control, it's annoying. but my understanding is that the problem seems to be a difficulty in implementing job control with go. when people say nobody needs parallel tasks that doesn't make sense because you can run jobs in the background. you just have to do it explicitly before starting, and you can't switch back and forth. yes, that's a problem, and for me it is one of the most annoying missing features. but it comes up seldom enough that it doesn't disrupt daily use for me. which is to show that the things i need for daily use are all there.
what can string interpolation do that i can't also do by sandwiching a variable between strings: 'string1'$var'string2'?
string interpolation is useful where concatenating strings requires an operator, but i don't see the benefit otherwise.
for more complex examples i can use printf, or someone could write a function that does string interpolation. since there is no need to fork, that should not be that expensive
I've been eyeing a "better shell" for a while, but I've just decided that a couple zsh plugins and I'm probably happiest. As the meme says "Change my mind".
I've been using fish for the last year or more, and I like some of the "batteries included", particularly the predicting of the command you want to run. But fish is too much like bash in syntax, meaning that I just think of it like bash until I have to type "(foo)" instead of "$(foo)", or "end" instead of "fi". The zsh plugins for doing command predicting and fancy prompt seems to get me all the fish benefits with none of the rough spots. And, frankly, the changes fish does doesn't seem to have any benefit (what is the benefit of "end" over "fi").
Even xonsh (I'm a huge Python fan) doesn't really have enough pull for me to stick in it. Oils, nu, elvish, they all have some benefits for scripting, but I can't see myself switching to them for interactive use.
It's kind of feeling like zsh is "good enough" with no real downsides. Maybe this is mostly that I've been using sh/ksh/bash/zsh for 40 years, some of these other shells might be easier to switch to if you lack the muscle memory?
> But fish is too much like bash in syntax, meaning that I just think of it like bash until I have to type "(foo)" instead of "$(foo)", or "end" instead of "fi"
Note that fish does also support bash's "$(foo)" syntax and has for a few years now.
supporting more and more bashisms is what makes fish less attractive for me. i used fish for years. $(foo) in bash forks a subshell. in fish it doesn't. i am not a fan of supporting different syntaxes to do the same thing. if they had implemented $() to fork a subshell, that might have made some sense, but otherwise it is just redundant. learning to use () instead of $() or `` really isn't hard. so why?
(Ftr, I've been using zsh for maybe 5-8 years, managed to avoid oh-my-zsh, and only use 'zsh-autosuggestions' and 'zsh-syntax-highlighting' plugins. I've customised a theme to suit me, but barely know anything about zsh to be honest...)
Well, pretty much what you said: syntax-highlighting, oh-my-zsh, git, command-not-found, autosuggestions, atuin, zoxide, and zsh-vi-mode. These days, I'm looking for as little stuff that I have to maintain myself as possible.
Ever since I 'discovered' Nushell I've noticed a lot of new shells appearing on HN.
The thing I like about Nushell is it does away with some of the things that I found hard with bash, and made data formats a first class citizen (something I enjoyed about powershell).
I think if you like Lisp elvish would be ideal but for me the lack (seeming, I've not done a deep dive on the docs) of built-in data parsing is a no.
Readit News
> While Elvish provides a lot of useful functionalities as builtin commands, it can’t do everything. This is where external commands come in, which are separate programs installed on your machine. Many useful programs come in the form of external commands, and there is no limit on what they can do. Here are just a few examples: Git provides the git command to manage code repositories
At first I thought, wait, is this a shell or not, do I have to write code or something to get access to normal external commands? But no, this is more like going to a car dealership and having the salesman say "Hey thanks for coming by, a car is a mechanical device consisting of metal parts and rubber parts for the purpose of taking you where you need to go! Now that we're on the same page about that, money is a thing made of paper for the purposes of .."
Docs are hard, once or twice is fine, but lots of parts are like this and I gave up reading. Not sure if it's AI generated, but if the project is doing that then it should stop, and if it's not doing that it should consider starting to
They have a separate set of docs for people who do have some experience with other shells (https://elv.sh/learn/); you may find the quick tour more suitable for your speed: https://elv.sh/learn/tour.html
> Line continuation in Elvish uses ^ instead of \
> Bash: echo .[ch] vs Elvish: echo .?[set:ch]
One more example, guess what this does: `echo &sep=',' foo bar`. Is it bash, elvish? Some combination of the two with markdown? Legal in all three? Elvish certainly cleans up conditionals and stuff, but you probably shouldn't introduce new things with exactly the same name unless you've created a genuine superset/dialect where the older version still works without rewrite. Namespace it as elvish.echo or use your module system. Shadows aren't friendly, this is equivalent to the guy that monkey-patches sys.stderr=sys.stdout to work around their one-off problem
Ultimately I've found that for my interactive shell I just want something widely supported and with easy syntax for `if` and `for` loops for short multi-line commands. For anything longer than that I just reach for real Python using either the `sh` or `plumbum` package.
I don't need the extra features very often, so I just run things in full Python where I'm already comfortable.
I've tried oils/ysh, elvish, xonsh, nushell, and while they are _fine_ I don't want to learn a different language that's not quite Python and not quite shell.
There's TODOs all over the documentation! There's no background task tools for scripting, and in interactive use background tasks are barely supported - an issue about background tasks has people going roughly "nobody needs to do tasks in parallel, that was only important when people were working on mainframes". The shell hooks have (undocumented) weird restrictions. Lazy iteration of lists is only supported by using functions with callbacks. Stable = development appears stopped.
This is half baked and dead. For my new computer I really really wanted a lightweight new shell with orthogonal syntax thought out from the ground up and not glued together over 4 decades, and this seemed like the closest option! But this isn't it.
However if you’re looking for an alternative then there’s:
- Murex (disclaimer: I’m one of the maintainers) which does support background processes and has extensive documentation. https://murex.rocks
- Nushell: I’m not personally a fan of its design choices but it has a large following of people who do really enjoy it so it might also appeal to yourself too.
As for Elvish, I do encourage others to give it a go themselves. It’s really well thought out and what might be a deal breaker for some people isn’t for others.
Nushell also had very minimal background task support, so I rejected that. They explicitly say use some other program for background tasks in their docs.
I actually looked at Murex after seeing it in previous threads, but I bounced for some reason... I just took another look though skipping the tutorial and I see you have `bg` and `fg` support! But does `bg` return the `fid`? Can you use those in scripts, or are they hobbled the same way bg/fg are in bash?
It's been a good 4-5 months since I went down this rabbit hole, but IIRC the basic things I wanted to do and got blocked in multiple shells were:
- System-wide interactive-use config file, I use Nixos and manage my system config using that
- Background task support - I need to start an ssh tcp proxy, pipe a command over it, then kill ssh once the command is done (all in a script).
- Post-command hook, to send a notification when a long command finishes
- Async iteration of command output, i.e. streaming events with swaymsg subscribe and running a command when certain events occur
- Value/call arity safety - i.e. a clear distinction between a single value and multiple values that doesn't rely on stringification hacks. I.e. in `command $x` `command` should always have one argument, regardless of the contents of `x`, and making that plural should be explicit.
And then other standard evaluation criteria, like I looked at xonsh but it seemed like a massive hack, despite handling a lot of the above.
also, i'd like to know more about how the job control works. that's one of the pain points in elvish, but both are written in go, so maybe there are some ideas that elvish could copy.
https://www.youtube.com/watch?v=9xLeqwl_7n0
Nine Reasons to Use OSH - https://oils.pub/osh.html - it runs existing shell scripts, ...
What is YSH? - https://oils.pub/ysh.html - It's the ultimate glue language, like shell + Python + JSON + YAML, seamlessly put together
Just to add some further qualification, I was fully prepared to learn something from the ground up, throw away all my preconceptions, and give some weirdness a try - including no string interpolation. I wanted to 100% replace bash, both as a shell and for scripting everywhere. I was exactly Elvish's target user.
you are right about lack of support for job control, it's annoying. but my understanding is that the problem seems to be a difficulty in implementing job control with go. when people say nobody needs parallel tasks that doesn't make sense because you can run jobs in the background. you just have to do it explicitly before starting, and you can't switch back and forth. yes, that's a problem, and for me it is one of the most annoying missing features. but it comes up seldom enough that it doesn't disrupt daily use for me. which is to show that the things i need for daily use are all there.
string interpolation is useful where concatenating strings requires an operator, but i don't see the benefit otherwise.
for more complex examples i can use printf, or someone could write a function that does string interpolation. since there is no need to fork, that should not be that expensive
Elvish, expressive programming language and a versatile interactive shell - https://news.ycombinator.com/item?id=40316010 - May 2024 (114 comments)
Elvish Scripting Case Studies - https://news.ycombinator.com/item?id=39549902 - Feb 2024 (1 comment)
Elvish is a friendly interactive shell and an expressive programming language - https://news.ycombinator.com/item?id=24422491 - Sept 2020 (49 comments)
Elvish: a shell with some unique semantics - https://news.ycombinator.com/item?id=17987258 - Sept 2018 (1 comment)
Elvish 0.11 released - https://news.ycombinator.com/item?id=16174559 - Jan 2018 (1 comment)
Elvish: friendly and expressive shell for Linux, macOS and BSDs - https://news.ycombinator.com/item?id=14698187 - July 2017 (86 comments)
Elvish – An experimental Unix shell in Go - https://news.ycombinator.com/item?id=8090534 - July 2014 (75 comments)
I've been using fish for the last year or more, and I like some of the "batteries included", particularly the predicting of the command you want to run. But fish is too much like bash in syntax, meaning that I just think of it like bash until I have to type "(foo)" instead of "$(foo)", or "end" instead of "fi". The zsh plugins for doing command predicting and fancy prompt seems to get me all the fish benefits with none of the rough spots. And, frankly, the changes fish does doesn't seem to have any benefit (what is the benefit of "end" over "fi").
Even xonsh (I'm a huge Python fan) doesn't really have enough pull for me to stick in it. Oils, nu, elvish, they all have some benefits for scripting, but I can't see myself switching to them for interactive use.
It's kind of feeling like zsh is "good enough" with no real downsides. Maybe this is mostly that I've been using sh/ksh/bash/zsh for 40 years, some of these other shells might be easier to switch to if you lack the muscle memory?
Note that fish does also support bash's "$(foo)" syntax and has for a few years now.
(Ftr, I've been using zsh for maybe 5-8 years, managed to avoid oh-my-zsh, and only use 'zsh-autosuggestions' and 'zsh-syntax-highlighting' plugins. I've customised a theme to suit me, but barely know anything about zsh to be honest...)
The thing I like about Nushell is it does away with some of the things that I found hard with bash, and made data formats a first class citizen (something I enjoyed about powershell).
I think if you like Lisp elvish would be ideal but for me the lack (seeming, I've not done a deep dive on the docs) of built-in data parsing is a no.
You want functions? For loops? Lists? They got them.
[1] https://github.com/rakitzis/rc