6 ms·

Elvish is a friendly interactive shell and an expressive programming language

149 points by fmakunbound 6y ago

mushufasa 6y ago
is it posix script compliant?
- fmakunbound 6y ago
  No, it is not. That might be desirable though depending on your perspective or use-case https://elv.sh/ref/language.html https://elv.sh/ref/language.html
  - chrisweekly 6y ago
    FWIW, XONSH (https://xon.sh https://xon.sh - pronounced "konsh") is a POSIX-compliant shell that lets you write everything in Python. (I don't use it, but my cousin is one of its authors.)
    - chubot 6y ago
      My memory of how it works is that it's only POSIX complaint because it does os.system() to a POSIX compliant shell. It parses some Python syntax on the command line and then uses Python's eval() to handle it. And then for shell parts it calls os.system(). My memory is fuzzy though so I'd be happy for a correction ...
      - em-bee 6y ago
        other than seeming inefficient, does doing that have any negative side effects or cause problems somehow?
        chubot 6y ago
        Well, I'm biased because I'm working on Oil, and I'm sure the xonsh developers are aiming at something very different. However on top of actually being slow (not just seeming slow) [1], I see it as a huge problem because it makes for an ill-defined language. The behavior of your shell now depends on whatever /bin/sh and Python interpreter is on your machine. When you change Python versions, are your xonsh commands going to break? What about when you change shell versions? What happens when you copy some xonsh from one machine to another, with possibly different versions? Do they still work? Some people might say that it's for interactive use, not for programs. But to me the point of shell is that you can seamlessly cut and paste your interactive sessions and now you have full automation. It's an amazing way to quickly build programs. In other words, shell is the language with the best REPL. And it has the biggest standard library [2] ----- Oil takes a very principled approach to parsing, e.g. http://www.oilshell.org/blog/tags.html?tag=parsing-shell#parsing-shell http://www.oilshell.org/blog/tags.html?tag=parsing-shell#par... while the xonsh approach is just about the most unprincipled approach there is. Again, I think they were aiming at something very different, but to me it falls short of what I want in a shell (and what other people have told me they want.) ----- [1] I have some experience with running the bash completion scripts that xosnh scrapes: http://www.oilshell.org/blog/2018/10/10.html http://www.oilshell.org/blog/2018/10/10.html . It is indeed slow. [2] https://news.ycombinator.com/item?id=24083764 https://news.ycombinator.com/item?id=24083764
        em-bee 6y ago
        Some people might say that it's for interactive use, not for programs. But to me the point of shell is that you can seamlessly cut and paste your interactive sessions and now you have full automation. It's an amazing way to quickly build programs. one could argue that a shell based on python should be especially suitable for turning your commandline into scripts. i have never tried xonsh but i have used the python repl to interactively build a python script xonsh approach is just about the most unprincipled approach there is could you possibly elaborate on that please?
        chubot 6y ago
        It's not Python though.. it's a tightly coupled mix of Python, shell and other stuff. You would have to extract the Python to actually run it with a Python interpreter, in which case you don't need xonsh at all. What I mean by unprincipled is that it doesn't parse or define its language. It passes the problem off to other programs (sh and Python).
- xiaq 6y ago
  No. If you are looking for a POSIX-ish shell with modern features, Oil (http://www.oilshell.org/ http://www.oilshell.org/) is your best option.
SiebenHeaven 6y ago
Or you could get fzf innyour current shell for most of the features (the command history search, file preview/open, etc). Familiar syntax is a big plus though, a point on which most shells leave a lot of desired.
- simias 6y ago
  FZF is amazing and I highly recommend it as well, but this project seems to go beyond what FZF provides. This bit in particular: curl https://api.github.com/repos/elves/elvish/issues | from-json | all (one) | each [issue]{ echo $issue[number]: $issue[title] } | head -n 11 That being said I'm still not willing to switch to a non-standard shell syntax, too difficult to use third party servers after that. Also un*x shells are inherently limited by the underlying concept of pipes exchanging only byte streams with no metadata or higher level constructs. You can hack your way around that (as this project seems to be doing) but it's always going to be kludgy. In particular you can't expect any third-party command to play by your rules.
  - guitarbill 6y ago
    presumably you can get jq to do something similar, well enough for 95% of the time, which is the issue. like you, i'm not saying new shells don't have a place, but adoption is really the problem. you can get around this if the features are compelling enough. personally, i like fish. certainly, it was a rough adoption curve, but worth it IMO so i can stop setting up and tweaking zsh, plus the built-in auto-complete is fzf-ish enough for me. and i'm told people use powershell even on non-Windows systems. it's just a very tough sell.
  - xiaq 6y ago
    > too difficult to use third party servers after that Just "scp" the binary to the server and you're good to go :)
    - fmakunbound 6y ago
      Yeah this one of the selling points, IMO. It's a gigantic Go static executable and easily available for a wide variety of architectures.
hjek 6y ago
Amazing! Built-in file manager and folder history are wonderful, but it doesn't set the pane title in tmux correctly out-of-the-box.
- xiaq 6y ago
  > it doesn't set the pane title in tmux correctly out-of-the-box Yeah, it's an unfortunate side effect of Elvish not having job control at the moment; tmux (and terminal emulators) use the information about the foreground process group to automatically set the title, but since Elvish doesn't have job control and stays in the foreground, that doesn't work. However, there is a module that does this: https://github.com/zzamboni/elvish-modules/blob/master/terminal-title.org https://github.com/zzamboni/elvish-modules/blob/master/termi...
xiaq 6y ago
Elvish author here, AMA :)
- ilaksh 6y ago
  Hello. Looks amazing. How does the command completion compare to fish? That's the feature I like about fish because it seems very predictive. But just the other day I needed to parse JSON from curl or whatever and ended up writing a Node.js script which would have been unnecessary with Elvish.
  - xiaq 6y ago
    Elvish has a really simple API for writing completers (https://elv.sh/ref/edit.html#completion-api https://elv.sh/ref/edit.html#completion-api). The simplicity of the API stems from some fundamental language features like first-class functions, value pipes and composite data types. In more traditional shells without these language features (including fish), the completer API is usually made up of obscure naming conventions, specialized command for outputting candidates and controlling the format, etc. I think Elvish's simple completer API (which is very similar to completion protocols used by editors, FWIW) is proof that serious programming capabilities is actually quite essential for a shell. You wouldn't write editor plugins using bash, but people have to write completers and other shell plugins in bash all the time. However, what would affect your day to day experience the most is probably the coverage of existing completers. There are some community efforts you can find in https://github.com/elves/awesome-elvish#completion-scripts https://github.com/elves/awesome-elvish#completion-scripts, but it's quite clear that Elvish is lagging behind. This is mostly because I'm still trying to figure out a lot of things in the language itself, and I don't want people to invest a lot of completers before they get broken by language changes. Once the language becomes more stable (which will perhaps take another year or so) I'll invest much more in this area.
    - warent 6y ago
      This is really exciting. I've been using zsh for years but would probably change to this shell with better completions and theming.
thelazydogsback 6y ago
Is there an Elmish front end?/
svnpenn 6y ago
FYI for Windows users, no Unicode https://github.com/elves/elvish/issues/1124 https://github.com/elves/elvish/issues/1124
Awtem 6y ago
This looks really cool and useful. Does anybody know how this compares to NuShell?
toomim 6y ago
This looks really cool. I'd be curious to see a video demo of the file manager, directory, and command history UIs.

149 points by fmakunbound 6y ago

mushufasa 6y ago

is it posix script compliant?

fmakunbound 6y ago
No, it is not. That might be desirable though depending on your perspective or use-case https://elv.sh/ref/language.html https://elv.sh/ref/language.html
- chrisweekly 6y ago
  FWIW, XONSH (https://xon.sh https://xon.sh - pronounced "konsh") is a POSIX-compliant shell that lets you write everything in Python. (I don't use it, but my cousin is one of its authors.)
  - chubot 6y ago
    My memory of how it works is that it's only POSIX complaint because it does os.system() to a POSIX compliant shell. It parses some Python syntax on the command line and then uses Python's eval() to handle it. And then for shell parts it calls os.system(). My memory is fuzzy though so I'd be happy for a correction ...
    - em-bee 6y ago
      other than seeming inefficient, does doing that have any negative side effects or cause problems somehow?
      - chubot 6y ago
        Well, I'm biased because I'm working on Oil, and I'm sure the xonsh developers are aiming at something very different. However on top of actually being slow (not just seeming slow) [1], I see it as a huge problem because it makes for an ill-defined language. The behavior of your shell now depends on whatever /bin/sh and Python interpreter is on your machine. When you change Python versions, are your xonsh commands going to break? What about when you change shell versions? What happens when you copy some xonsh from one machine to another, with possibly different versions? Do they still work? Some people might say that it's for interactive use, not for programs. But to me the point of shell is that you can seamlessly cut and paste your interactive sessions and now you have full automation. It's an amazing way to quickly build programs. In other words, shell is the language with the best REPL. And it has the biggest standard library [2] ----- Oil takes a very principled approach to parsing, e.g. http://www.oilshell.org/blog/tags.html?tag=parsing-shell#parsing-shell http://www.oilshell.org/blog/tags.html?tag=parsing-shell#par... while the xonsh approach is just about the most unprincipled approach there is. Again, I think they were aiming at something very different, but to me it falls short of what I want in a shell (and what other people have told me they want.) ----- [1] I have some experience with running the bash completion scripts that xosnh scrapes: http://www.oilshell.org/blog/2018/10/10.html http://www.oilshell.org/blog/2018/10/10.html . It is indeed slow. [2] https://news.ycombinator.com/item?id=24083764 https://news.ycombinator.com/item?id=24083764
        em-bee 6y ago
        Some people might say that it's for interactive use, not for programs. But to me the point of shell is that you can seamlessly cut and paste your interactive sessions and now you have full automation. It's an amazing way to quickly build programs. one could argue that a shell based on python should be especially suitable for turning your commandline into scripts. i have never tried xonsh but i have used the python repl to interactively build a python script xonsh approach is just about the most unprincipled approach there is could you possibly elaborate on that please?
        chubot 6y ago
        It's not Python though.. it's a tightly coupled mix of Python, shell and other stuff. You would have to extract the Python to actually run it with a Python interpreter, in which case you don't need xonsh at all. What I mean by unprincipled is that it doesn't parse or define its language. It passes the problem off to other programs (sh and Python).
xiaq 6y ago
No. If you are looking for a POSIX-ish shell with modern features, Oil (http://www.oilshell.org/ http://www.oilshell.org/) is your best option.

SiebenHeaven 6y ago

Or you could get fzf innyour current shell for most of the features (the command history search, file preview/open, etc). Familiar syntax is a big plus though, a point on which most shells leave a lot of desired.

simias 6y ago
FZF is amazing and I highly recommend it as well, but this project seems to go beyond what FZF provides. This bit in particular: curl https://api.github.com/repos/elves/elvish/issues | from-json | all (one) | each [issue]{ echo $issue[number]: $issue[title] } | head -n 11 That being said I'm still not willing to switch to a non-standard shell syntax, too difficult to use third party servers after that. Also un*x shells are inherently limited by the underlying concept of pipes exchanging only byte streams with no metadata or higher level constructs. You can hack your way around that (as this project seems to be doing) but it's always going to be kludgy. In particular you can't expect any third-party command to play by your rules.
- guitarbill 6y ago
  presumably you can get jq to do something similar, well enough for 95% of the time, which is the issue. like you, i'm not saying new shells don't have a place, but adoption is really the problem. you can get around this if the features are compelling enough. personally, i like fish. certainly, it was a rough adoption curve, but worth it IMO so i can stop setting up and tweaking zsh, plus the built-in auto-complete is fzf-ish enough for me. and i'm told people use powershell even on non-Windows systems. it's just a very tough sell.
- xiaq 6y ago
  > too difficult to use third party servers after that Just "scp" the binary to the server and you're good to go :)
  - fmakunbound 6y ago
    Yeah this one of the selling points, IMO. It's a gigantic Go static executable and easily available for a wide variety of architectures.

hjek 6y ago

Amazing! Built-in file manager and folder history are wonderful, but it doesn't set the pane title in tmux correctly out-of-the-box.

xiaq 6y ago
> it doesn't set the pane title in tmux correctly out-of-the-box Yeah, it's an unfortunate side effect of Elvish not having job control at the moment; tmux (and terminal emulators) use the information about the foreground process group to automatically set the title, but since Elvish doesn't have job control and stays in the foreground, that doesn't work. However, there is a module that does this: https://github.com/zzamboni/elvish-modules/blob/master/terminal-title.org https://github.com/zzamboni/elvish-modules/blob/master/termi...

xiaq 6y ago

Elvish author here, AMA :)

ilaksh 6y ago
Hello. Looks amazing. How does the command completion compare to fish? That's the feature I like about fish because it seems very predictive. But just the other day I needed to parse JSON from curl or whatever and ended up writing a Node.js script which would have been unnecessary with Elvish.
- xiaq 6y ago
  Elvish has a really simple API for writing completers (https://elv.sh/ref/edit.html#completion-api https://elv.sh/ref/edit.html#completion-api). The simplicity of the API stems from some fundamental language features like first-class functions, value pipes and composite data types. In more traditional shells without these language features (including fish), the completer API is usually made up of obscure naming conventions, specialized command for outputting candidates and controlling the format, etc. I think Elvish's simple completer API (which is very similar to completion protocols used by editors, FWIW) is proof that serious programming capabilities is actually quite essential for a shell. You wouldn't write editor plugins using bash, but people have to write completers and other shell plugins in bash all the time. However, what would affect your day to day experience the most is probably the coverage of existing completers. There are some community efforts you can find in https://github.com/elves/awesome-elvish#completion-scripts https://github.com/elves/awesome-elvish#completion-scripts, but it's quite clear that Elvish is lagging behind. This is mostly because I'm still trying to figure out a lot of things in the language itself, and I don't want people to invest a lot of completers before they get broken by language changes. Once the language becomes more stable (which will perhaps take another year or so) I'll invest much more in this area.
  - warent 6y ago
    This is really exciting. I've been using zsh for years but would probably change to this shell with better completions and theming.

thelazydogsback 6y ago

Is there an Elmish front end?/

svnpenn 6y ago

FYI for Windows users, no Unicode https://github.com/elves/elvish/issues/1124 https://github.com/elves/elvish/issues/1124

Awtem 6y ago

This looks really cool and useful. Does anybody know how this compares to NuShell?

toomim 6y ago

This looks really cool. I'd be curious to see a video demo of the file manager, directory, and command history UIs.