Thanks for Elvish. On a daily driver basis I still use fish. I find the fish autocomplete a bit more compelling. I’m more productive with fish on the prompt (though I do think the elvish scripting language is nicer).
In elvish I need to request an autocomplete— in fish I get a suggestion in a light font which is usually a good one.
Another nice thing in fish is that valid file names get automatically underlined. It’s another subtle but useful feature.
So I think you know what is coming. A feature request :-):
Please make Elvish prompt autocomplete/suggestions more like fish. I wouldn’t be surprised if this has not been requested already !
I can't promise anything, but I'm undertaking a major refactoring of Elvish's TUI and that should make it much easier to implement this feature in the near future.
Hi, thanks for your time! I'm really keen on finding alternatives for bash scripting, and from looking at the examples, it seems to go a long way in that direction.
I'm not keen on trading bashisms for elvishisms though :-)
A somewhat random example from looking at the docs, where you have this example:
Quoting '-' instead of using (bash-style) "${platform:os}-${platform:arch}" seems really counterintuitive to me. After all, '-' is simply itself (a plain dash), it's the variable name that is special here and deserves quoting. Any thoughts on this?
It's more verbose than quoting the dash so I opted to the latter.
You seem to use "elvishism" in a negative way, and this particular example is one of the more quirky ones, but the whole reason you would use Elvish is that it's different from other shells! :)
My apologies if the comment came across as negative. I just meant to say that I didn't want to exchange one set of shell quirks for another. But using {$x}-style grouping is a fine solution too. And in any case I'm sure that bash has a lot more quirks than Elvish :-)
So I'll definitely do more testing with Elvish and see what the overall experience is like. Coming from Solaris, we still have a ton of ksh scripts in our shop (with people working on them who have very different backgrounds and scripting skill levels). Something with less pitfalls than bash would be great... Thanks for putting in your time and effort!
Oh, I definitely didn't read your entire comment as negative, just the way you used "elvishism". Elvish definitely has its quirks! But I hope you'll find it a compelling package overall :)
It would be nice to be able to make an executable version of an Elvish script that could be installed and run without having to install Elvish separately. So this executable would have to contain the Elvish interpreter.
Two quick questions: Is there a way to implement !!? Via functions maybe? "Last Command" looks to be hotkey based, and I can't think of how that would work.
Related: is there a comprehensive list of hotkeys floating around? I didn't see it in the docs. Things like Alt-Enter and Alt-, are mentioned in the Quick Start, but I couldn't find them elsewhere.
The directory history idea seems incredibly useful, but I’ve never see of it before. Did you come up with it yourself?
It has the characteristics of a really great idea: seems obvious in retrospect, doesn’t look too difficult to implement, but somehow everybody seems to have… just missed it?
What's the primary reason you set out to build this? I like the look and feel of the language but I'm on the fence whether the drawbacks of using something different than bash are outweighed by the benefits of elvish.
I believe shells have the potential to be much more than what they are today, and traditional shells are held back by their rather weak languages.
Re the cost of switching: on the one hand, I'd say that "switching" is really the wrong mentality, because you can always still use bash! You can "switch" to Elvish as your interactive shell and still use bash for scripting. Or you can "switch" to Elvish for some new scripts and still use bash as your interactive shell (and your existing scripts). If you want to give Elvish a try, you can just do it without giving up everything you do with bash today, and reap the incremental benefits of using a better shell.
On the other hand, the mental barrier of adopting "a new thing" is definitely real, even after you overcome the more irrational fears. We only want so much software in our lives anyway. To that I'd say Elvish needs to be more compelling than what it is today. Elvish today, with its nice interactive features and a real programming language, is perhaps 2x to 4x better than traditional shells on its own (if we ignore the whole ecosystem issue), but it needs to be more than that to stand out to people as something radically better. I'm still trying to figure out how to do that, but two ideas I'm exploring are:
- Make it super easy to build TUIs in Elvish - we've had a "renaissance" of TUI tools in recently years, but if you want to build a TUI from scratch it's still surprisingly complicated. Much simpler than building GUIs, but still much more complex than just building a CLI. I feel Elvish as a shell language is a really good place to have a nice TUI framework in.
- Make it super easy to manage a simple homelab or build farm in Elvish - this is traditionally a strength of shells and people still cobble together shell scripts for this purpose, but traditional shell languages are clumsy and you can't easily expose a nice UI from shell scripts. It would be very nice if you can compose some Elvish scripts together and have a nice TUI or a web UI for management at a very low extra cost.
I personally don’t find the TUI idea compelling. I’d rather use a general purpose language like Rust or Python. Many powerful and mature frameworks are already available to build TUIs there. You want to optimise the average one-off hacked-up script writing experience. Most scripts are written in a hurry to accomplish some boring task or automation.
I would spend time building a top notch LSP for Elvish. Shell scripting languages tend to be highly untyped and flexible so building a good LSP will be tough here. But if you were able to build one that works really well you would have another really compelling reason to use Elvish.
P.S. I am aware that Elvish has a built in LSP. It’s somewhat basic though IIRC.
> I personally don’t find the TUI idea compelling. I’d rather use a general purpose language like Rust or Python. Many powerful and mature frameworks are already available to build TUIs there. You want to optimise the average one-off hacked-up script writing experience. Most scripts are written in a hurry to accomplish some boring task or automation.
That's interesting, because I have the same starting point as you (optimise hacked-up script experience) but a lot of the time as my script grows I really wish there's a nice little TUI for it. For example, rather than finding my invocation of the script from my command history and edit the CLI arguments, can I just have a little "pop-up menu" for my workflows, where I can probably add some string argument? Or allow me to see the outputs of the script in a slightly more fancy way than a stream of text - like a Miller column view, which Elvish already has implemented in its file manager? Ideally, these should be "ready-made" UI components that you can take advantage of from your hacked-up script with just one or two lines of code.
I'm also coming from the viewpoint of implementation - I've built Elvish's TUI using some very generic building blocks but they are only used for very specialized builtin features of Elvish, so I'm really keen on exposing the capability for shell scripts to use.
I guess we're thinking of different things when we say "TUI" - perhaps you are thinking of full blown TUI applications, like an editor? I'd agree that a more [1] general-purpose language is more suitable and Elvish is not in the business of being a good language to implement the next TUI editor :) Maybe I should coin a new term for what I have in mind, which should be something you can hack up as easily as a CLI. "TUIlet" maybe?
> I would spend time building a top notch LSP for Elvish. Shell scripting languages tend to be highly untyped and flexible so building a good LSP will be tough here. But if you were able to build one that works really well you would have another really compelling reason to use Elvish.
Definitely! It's not what I'm working on in the immediate future, but good editor integration is a must to make the experience of writing scripts much better than more traditional shells.
1. Emphasis on "more", because Elvish is a general-purpose language itself, just not the most general-purpose :)
Bash reigns supreme indeed. If you’re writing software for yourself or a small team the benefits of Elvish are higher productivity. Try it out — I was really satisfied at the power and cleanliness of the scripting language.
Bash will be dethroned some day. As general purpose languages like Rust, Julia, Python etc have risen, Fortran, pascal etc have declined. And so that will eventually happen with bash. Not “if” but “when” !
PowerShell is quite heavyweight. Aside from the feel of the language and the requirement of .Net runtime, it also makes PowerShell very slow to start up, which is a dealbreaker for interactive usage for me.
Also when I started Elvish 10 years ago (!) PowerShell wasn't ported to non-Windows operating systems yet, so it wasn't even viable for most people.
You are right, even now on my Linux laptop poweshell process takes 100-200ms to start while bash takes 5ms.
But these problems you mentioned are a specifics of a particular implementation, not the approach (objects instead of text processing) itself.
Well, Elvish doesn't have objects, but it's also not based only on text processing - it has lists and maps that can be arbitrarily nested. On this front it is somewhat aligned with PowerShell but without all the OO paradigm.
Unix shells are already a bit LISP-y on a superficial level, because commands are syntactically like impure functions in prefix notation. Subshells act a lot like parens in a LISP, and the pipeline itself has analogs in FP like Clojure's thread macro. And of course, the command line itself is a REPL.
Elvish visibly leans into this to try to have a consistent syntax. Sometimes the similarities go deeper, too; IIRC, its number types are inspired by Scheme, for example.
> Elvish visibly leans into this to try to have a consistent syntax. Sometimes the similarities go deeper, too; IIRC, its number types are inspired by Scheme, for example.
Yes! Similarity to Lisp is very much a deliberate design choice and I feel happy every time a Lisper picks that up :)
I believe Elvish has also contributed a novel solution to the Lisp-1/Lisp-2 divide by making the space of command names equivalent to the subspace of variable names with a suffix - the command "foo" is equivalent to the variable "$foo~" and vice versa. (There's a bit more twist than that - the command "foo" can also resolve to the external command named "foo", but then that's represented by the "$e:foo~" variable.)
Powershell is closer to FP than OOP. What people mean is that it supports structured data.
Powershell is not true FP, but, if you stretch terminology:
- the unit of feature delivery is the function
- you can pass functions as values (but it's not idiomatic or elegant)
- objects tend to look more like anonymous records than OOP classes with methods
- pattern matching is supported (sort of)
Thanks, I like that it seems similar enough to posix shell to draw me in before surprising me :). I like how the option vs arguments distinction is done and generally a lot of posix shell issues are improved. A few feature requests/impressions:
1) Maybe link at the top of the ref page to the learn page? I started looking at ref but some stuff I needed to know was much better explained under learn and it took me a while to notice that it was there also (I'm guessing the existance of ref would be more obvious from the learn page).
2) Local documentation is vital for a shell, if there is a way to generate a man page from the available documentation that would be quite helpful (at least instaling the website would be good, but that looks like a package issue that should be easy to do).
3) If I want the equivalent of fd -X but being able to use aliases (functions in elvish) there is from-terminated and (all) but despite the long command line lengths these days it can overflow. A builtin simplified version of xargs that works with elvish lists and aggregates arguments while breaking into acceptable length command lines would be great.
4) There seems to be no way to execute code from a different file in the current context? For bash to get aliases in fd -X you can use a complicated fd ... -X bash -ic '<alias> "$@"' 'fd bash', however it seems that elvish both doesn't have -i and has no way to even source the rc file from elvish -c? Or to split rc files into multiple files without using modules?
5) &> and to a lesser extent |& are handy in bash to simplify combining stderr and stdout. Hopefully elvish doesn't have the 2>&1 placement issues that posix shells do but even if not I'd consider a shorthand worthwhile.
6) Some type of cooperative locking would be helpful along the lines of Debian's lockfile-progs but built in to make it easy to avoid scripts that break if you accidently run it twice at the same time (ideally compatible with lockfile-progs unless there is a good reason not to be).
7) Beyond that, some type of built in concurrency managed database based on elivish data types might be worth considering to simplify sharing state between independent execution of related utilities (or multiple execution of a single utility).
8) I like your idea of exposing more TUI abilities. In addition to what you said, being able to create a status line or two while preserving the scrolling history of other commands would be helpful (and this would be potentially interesting in an interactive shell also). I like your rprompt.
Overall, I like the look of elvish and for some reason it seems more approachable to me (not a big fan of lisp) than the PowerShell style shells.
