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". Th…
Elvish – Scripting language and interactive shell
21–30 of 62 posts
Re: Elvish – Scripting language and interactive shell
#22Earlier quoted context omitted.
> Built in Rust > Built in golang Does that matter? If you intend to be a contributor, of course the chosen language matters, but only a very small proportion of users will be contributors.
I don't think it matters whether it's Rust or Go especially, for an end user tool. But it definitely matters if it's Rust/Go compared to something else like C or Python. The language choice has certain implications and I would say Rust & Go have fairly similar implications: it's going to be pretty fast and robust, and it'll have a static binary that makes it easy to install. Implications for other languages: C: proba…
I have not really had problems with installing C (on the rare occasions I have compiled anything of any complexity) nor Python applications. Xonsh is supposed to be pretty good and written in Python, and most existing shells (bash, zsh, csh etc.) are written in C.
Amusing aside, I use fish and until I decided to fact check before adding it to the list of shells written in C, I did not realise it was written in Rust.
Re: Elvish – Scripting language and interactive shell
#23I 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". Th…
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.
Re: Elvish – Scripting language and interactive shell
#24The 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.
Re: Elvish – Scripting language and interactive shell
#25I 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". Th…
Oil shell (now oils) was too close to bash for your goal?
Re: Elvish – Scripting language and interactive shell
#26Earlier quoted context omitted.
I don't think it matters whether it's Rust or Go especially, for an end user tool. But it definitely matters if it's Rust/Go compared to something else like C or Python. The language choice has certain implications and I would say Rust & Go have fairly similar implications: it's going to be pretty fast and robust, and it'll have a static binary that makes it easy to install. Implications for other languages: C: proba…
Not even that matters to me: I will install from repos. It might make packagers' lives a bit more difficult in some cases but they are probably very familiar with that. I have not really had problems with installing C (on the rare occasions I have compiled anything of any complexity) nor Python applications. Xonsh is supposed to be pretty good and written in Python, and most existing shells (bash, zsh, csh etc.) are…
Re: Elvish – Scripting language and interactive shell
#27I 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". Th…
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 - Nushel…
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.
Re: Elvish – Scripting language and interactive shell
#28Ever 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.
Re: Elvish – Scripting language and interactive shell
#29I 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". Th…
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 - Nushel…
Re: Elvish – Scripting language and interactive shell
#30I 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". Th…
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.