5 ms·

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 ba

by rendaw 1y ago

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.

nerdponx 1y ago
The big one for me is no string interpolation, as a deliberate design choice.
- em-bee 1y ago
  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
  - layer8 1y ago
    I mostly agree, but in Bash for example "string1${var}string2" guarantees to be a single argument, which 'string1'$var'string2' doesn‘t (when $var contains whitespace). So it entails certain other language design choices.
    - em-bee 1y ago
      in bash yes, so that makes sense. thanks for pointing that out. in elvish $var is guaranteed to remain one string, and so 'string1'$var'string2' is always going to remain one argument too.
onli 1y ago
Oil shell (now oils) was too close to bash for your goal?
- rendaw 1y ago
  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...
- chubot 1y ago
  FWIW Oils has two modes, and I wrote new landing pages for them recently: Nine Reasons to Use OSH - https://oils.pub/osh.html https://oils.pub/osh.html - it runs existing shell scripts, ... What is YSH? - https://oils.pub/ysh.html https://oils.pub/ysh.html - It's the ultimate glue language, like shell + Python + JSON + YAML, seamlessly put together
rahen 1y ago
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 https://www.youtube.com/watch?v=9xLeqwl_7n0
hnlmorg 1y ago
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 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.
- rendaw 1y ago
  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.
rendaw 1y ago
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.
em-bee 1y ago
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.

by rendaw 1y ago

nerdponx 1y ago

The big one for me is no string interpolation, as a deliberate design choice.

em-bee 1y ago
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
- layer8 1y ago
  I mostly agree, but in Bash for example "string1${var}string2" guarantees to be a single argument, which 'string1'$var'string2' doesn‘t (when $var contains whitespace). So it entails certain other language design choices.
  - em-bee 1y ago
    in bash yes, so that makes sense. thanks for pointing that out. in elvish $var is guaranteed to remain one string, and so 'string1'$var'string2' is always going to remain one argument too.

onli 1y ago

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

rendaw 1y ago
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...
chubot 1y ago
FWIW Oils has two modes, and I wrote new landing pages for them recently: Nine Reasons to Use OSH - https://oils.pub/osh.html https://oils.pub/osh.html - it runs existing shell scripts, ... What is YSH? - https://oils.pub/ysh.html https://oils.pub/ysh.html - It's the ultimate glue language, like shell + Python + JSON + YAML, seamlessly put together

rahen 1y ago

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 https://www.youtube.com/watch?v=9xLeqwl_7n0

hnlmorg 1y ago

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

rendaw 1y ago
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.

rendaw 1y ago

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.

em-bee 1y ago

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.