Live data from Hacker News

Elvish – Scripting language and interactive shell

github.com

41–50 of 62 posts

Re: Elvish – Scripting language and interactive shell

#41
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?

FWIW Oils has two modes, and I wrote new landing pages for them recently:

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

Re: Elvish – Scripting language and interactive shell

#42
post #39

Earlier quoted context omitted.

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

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

Re: Elvish – Scripting language and interactive shell

#43

Earlier quoted context omitted.

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

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 is designed for use on Windows as well, where \ is the directory separator and wouldn’t be uncommon to occur at the end of a command line, so that can’t be used for line continuation. Windows (and DOS?) batch files use ^ for line continuation, so that’s probably where it was adopted from.

Re: Elvish – Scripting language and interactive shell

#44
post #35

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…

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

Re: Elvish – Scripting language and interactive shell

#45
post #42
post #39

Earlier quoted context omitted.

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

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.

Re: Elvish – Scripting language and interactive shell

#46
Related. Others?

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)

Re: Elvish – Scripting language and interactive shell

#48
post #34
post #27

Earlier quoted context omitted.

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

> does `bg` return the `fid` There's two kinds of process IDs in Murex: FID (function IDs) and PID (process IDs) Forking is expensive in POSIX and has a number of drawbacks such as the inability to share scoped variables without resorting to environmental variables. So a FID is basically a PID but managed inside the scope of Murex's runtime. You can manage FIDs in much the same way as you can manage PIDs, albeit usin…

Thanks for the answer! I think we may be talking past eachother a bit, but it's good to get confirmation on a lot of those!

AFAICT named pipes have nothing to do with ssh tcp proxies, or at least that bit is tangential to the key point - the key point I was making is that ssh is running in the background while I'm running another command (with no relation between them, as far as the shell is concerned).

You didn't answer my question about if `bg` returns a `fid` or not, and the documentation doesn't answer this either, nor did you say if those could be used in scripts... but it sounds like you're saying I have to parse `jobs` to get the `fid` of the command I just launched?

> Async iteration

This isn't about objects but about how operators evaluate. Maybe "streams" or "async streams" would be a better description? Actually, maybe this is where the named pipes you mentioned would be useful?

    while true; do echo hi; sleep 1; done | while read line; do echo $line 2; done
in bash, prints "hi 2" once a second. That is, the body of the while loop is executed asynchronously with the pre-pipe command.

AFAICT elvish doesn't have a `read` command, and `for` waits for the argument to complete before executing the body at all. This is a pretty common pattern, so I was surprised when there's no mention of it in the elvish docs. I don't like `read` in bash since it's yet another completely different syntax, but maybe Murex has something similar?

TBH I just looked at the Murex docs again and I'm lost. Where's the reference? There's the "user guide" which contains the "user guide" (again) and also the "beginners guide" which to me are synonyms, "cheat sheet" and "read more" which both appear to be a bunch of snippets (again synonyms?), "operators and tokens" which are a reference of just a subset of the language, etc etc. I couldn't find anything on loops, which I'd expect to be a section somewhere. Clicking on "read / write a named pipe" in "builtin commands" somehow teleports me to an identically named page in a completely different "operators and tokens" section.

In the end the read/write pipes page only shows examples of reading/writing pipes to other pipes, not using them in a for loop or anything. One example appears to use some unique syntax in `a` to send array elements to the pipe, but I couldn't find anything about that in the `a` section when I finally found the `a` section.

Also are named pipes always global? Why can't they be local variables like other structures?

It's great you have so much documentation, but I think it actually turned me away - it seems bloated with every bit of information split into multiple pieces and scattered around. Simplifying, consolidating, and reorganizing it from the top might help.

> Arity safety

Thanks! Yeah, I wasn't talking about arrays here, but if e.g. `x` in my example contains space-separated "these three words", will `command` receive 3 arguments or 1. In bash, `command` would get 3 arguments, if you don't invoke the variable quote hack. I just tried this out though, and it gets 1 argument, so great!

Re: Elvish – Scripting language and interactive shell

#50
post #44
post #35

Earlier quoted context omitted.

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

>really isn't hard. so why?

Fair question. For me, it's extra friction whenever I copy a shell snippet that includes these non-fishisms, or when I'm running things between my workstation and the nearly 200 machines I manage, and I don't want to force my coworkers to have fish as the default root shell, or have to remember to "sudo --shell" or set up aliases. Well, plus, I'm still not entirely sold on fish, so I haven't wanted to set it up on my whole fleet.

I just recently switched my cordless tool ecosystem at home for DIY work. There's something about having tools that I'll reach for because they're a joy to work with, rather than avoiding picking them up because of rough edges.

Post reply on HN