Live data from Hacker News

Elvish – Scripting language and interactive shell

github.com

21–30 of 62 posts

Re: Elvish – Scripting language and interactive shell

#21
post #17

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…

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.

https://www.youtube.com/watch?v=9xLeqwl_7n0

Re: Elvish – Scripting language and interactive shell

#22
post #11

Earlier 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…

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

#23
post #17

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…

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.

Re: Elvish – Scripting language and interactive shell

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

Re: Elvish – Scripting language and interactive shell

#25
post #20
post #17

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…

Oil shell (now oils) was too close to bash for your goal?

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

Re: Elvish – Scripting language and interactive shell

#26
post #22

Earlier 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…

Fish switched from C++ to Rust really recently.

https://fishshell.com/blog/rustport/

Re: Elvish – Scripting language and interactive shell

#27
post #23
post #17

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…

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…

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.

Re: Elvish – Scripting language and interactive shell

#28

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.

Elvish was a bit slow to me, nush is nice but I found out I can do most of the tasks using yq and jc more intuitively.

Re: Elvish – Scripting language and interactive shell

#29
post #23
post #17

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…

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…

There is ysh

Re: Elvish – Scripting language and interactive shell

#30
post #17

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…

Arrg, s/lazy/async/.

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.

Post reply on HN