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.
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:
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.
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.
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.
Thanks for the Oil shell suggestion. I will definitely check it out this evening.
I don't care for POSIX compatibility. I'm a long time Bash user, I've written programs I probably should not have in Bash, and I'm familiar with most of the pitfalls described in a recent HN post https://news.ycombinator.com/item?id=24401085 however, after reading through them I thought this is some serious bullshit one must contend with and went looking or alternate shells. Elvish being one of them.
If you've written programs you shouldn't have in bash, then you're very much the target user for Oil :) As stated on the home page, it's our upgrade path from bash to a better language and runtime.
So I would be interested if those programs run under Oil. Many do, and if they don't, the fix is usually small. Other programs I've run include Lisp and brainfuck interpreters in bash. And thousands of lines of bash completion scripts.
If the programs run, you can opt into strictness checks to improve them / find bugs. And if you want to drop bash compatibility, you can use the new Oil language. (still in progress, but you can try it right now)
The goal of Oil is very much to REMOVE all the pitfalls in that thread! It's done with option groups shopt -s oil:basic or shopt -s oil:all. Feel free to contact me on Github or Zulip about it. If you have bash programs, that makes it more interesting. I'm looking for feedback to help shape the Oil language :)
Based on my experience I think only 10% of bash users write a program that's longer than 5 lines, or use any bash features. Most people just use what their distro provides (which is what I did for years as well).
The buried lede here is that Oil uses some kind of tool to translate Python to C++ before running it. This sounds super interesting. Also am I misreading or is Oil written in Python 2.7?
There are 2 builds now: the one that runs under a slice of the Python 2 interpreter, and "oil-native", which is that code translated to C++.
Rather than saying Oil is written in Python 2, it's better to say that Oil is written in ASDL + a subset of statically typed Python + an abstract dialect of regexes (similar to Eggex).
In other words, it's a bunch of custom DSLs. And all of those DSLs translate to Python 2, as well as C++. So yes there is a lot of metaprogramming going on!
This makes the code shorter, more correct, and even pretty fast (slightly faster than bash, and it appears we will maintain that, although it may get slower in the short term)
Resources here, happy to answer any more questions:
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.
Eh, last time I messed with I lost interest after noting that from-json | to-json would silently convert all numbers into quoted strings and do terrible things when nil was involved. It made non-trivial JSON manipulation not worth it. They might have fixed it by now.
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.
fzf is indeed a very neat standalone tool, and for the use cases it has been optimized for, it is superior to Elvish's UI in many aspects. However, Elvish also has a very expressive programming language, and eventually it will offer more options in programmability.
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
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
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
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