
Elvish is a friendly interactive shell and an expressive programming language - fmakunbound
https://elv.sh
======
xiaq
Elvish author here, AMA :)

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

~~~
ilaksh
The API looks awesome. But when I tried it just now, I see no color in the
terminal, and it does not have anything like the completion I see in fish.

I don't know if you have tried it but fish basically predicts what you are
going to enter based on the directory you are in and what you have entered
before and gives a preview as you are typing, and then you can hit the right
arrow to complete it.

Since that is extremely convenient for me and your shell seems to not have
color (at least not in my Ubuntu terminal right now), I am going to stick with
fish.

------
hjek
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
> 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/termi...](https://github.com/zzamboni/elvish-
modules/blob/master/terminal-title.org)

------
svnpenn
FYI for Windows users, no Unicode

[https://github.com/elves/elvish/issues/1124](https://github.com/elves/elvish/issues/1124)

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

~~~
chubot
If you want familiar syntax, Oil is the most bash-compatible shell by a mile
(which means it's also POSIX compliant).

But you can opt in to a bunch of fixes for longstanding shell warts, shown
here:

[https://www.oilshell.org/release/0.8.0/doc/idioms.html](https://www.oilshell.org/release/0.8.0/doc/idioms.html)

So upgrading is / will be worth it.

\-----

There's an issue to run fzf, which was partially done last year:
[https://github.com/oilshell/oil/issues/322](https://github.com/oilshell/oil/issues/322)

I could use help looking into what remains there!

And there are more such issues here:
[https://github.com/oilshell/oil/labels/should-run-
this](https://github.com/oilshell/oil/labels/should-run-this)

Just running these scripts and localizing the error is a big help! And that
would get us closer to a new shell that can be realistically adopted.

Oil has run thousands of lines of unmodified bash scripts, and many thousands
more with minor patches, including some of the biggest shell scripts in the
world:

[https://www.oilshell.org/blog/2020/04/release-0.8.pre4.html](https://www.oilshell.org/blog/2020/04/release-0.8.pre4.html)

~~~
xiaq
> Oil is the most bash-compatible shell by a mile (which means it's also POSIX
> compliant).

Bash is not POSIX-compliant by default; it has a POSIX mode
([https://www.gnu.org/software/bash/manual/html_node/Bash-
POSI...](https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-
Mode.html)), which changes a lot of behaviors. It's mostly small things, but
it's a long list nonetheless.

I wonder what's Oil's approach here - does Oil has separate "bash mode" and
"POSIX mode"? Or are the divergences inconsequential enough for most scripts
that you don't bother distinguishing them?

FWIW, I avoid using the word "POSIX-compliant", because strict POSIX
compliance is usually not exactly what people want when they use this word.
Instead I'd just say "POSIX-ish" as a vague notation for the intersection set
between bash and the actual POSIX standard, and maybe more minimal POSIX-ish
shells like dash.

~~~
chubot
Yeah I agree it's not a great phrase, but people seem to have it in their
heads.

What I mean is that although Oil is very bash-compatible, and that's how I
usually describe it, it's not ONLY bash compatible.

Oil's spec tests run against multiple shells for this reason. I try not to
reproduce the bugs of bash unless they are necessary to actually run
something. (And this happens a lot -- there are accidental corners that nobody
uses.)

For example, the Linux distro milestone in 2018 showed Oil's portability:
Debian's debootstrap runs with dash, Alpine's abuild runs with busybox ash,
and Aboriginal runs with bash.

But Oil runs all 3 of those scripts by default, unmodified. For example, the
Alpine one used alias, which is off by default in bash, but on in POSIX mode.
Oil has aliases on for this reason (which makes it more POSIX compliant than
bash in that regard.)

\----

I also test with the Smoosh POSIX test suite, from the Smoosh formal semantics
(though that is not the only suite the paper uses to judge compliance.) On
that suite, Oil passes more POSIX tests than all shells except bash now. And
the differences are mostly unimplemented features, so I think it's inevitable
that it will pass more than bash.

So I still believe in the assertion here: Oil is actually a better POSIX. It
describes what shell scripts require in practice, better than POSIX does.

[http://www.oilshell.org/blog/2018/01/28.html#limit-to-
posix](http://www.oilshell.org/blog/2018/01/28.html#limit-to-posix)

\----

So Oil doesn't have a POSIX mode yet. It might in the future. So far it
doesn't seem necessary to run real shell scripts.

But yes I agree that "POSIX by the letter" isn't a super useful property. What
I mean is that Oil is designed to run a wide variety of shell scripts, and
also help people write portable code.

I think when people say "POSIX" they mean "I want my program to run under
multiple shells", and Oil definitely supports that.

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

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

------
mushufasa
is it posix script compliant?

~~~
fmakunbound
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
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
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
other than seeming inefficient, does doing that have any negative side effects
or cause problems somehow?

~~~
chubot
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#par...](http://www.oilshell.org/blog/tags.html?tag=parsing-
shell#parsing-shell)

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

------
thelazydogsback
Is there an Elmish front end?/

