-
-
Notifications
You must be signed in to change notification settings - Fork 165
YSH FAQ
This is an initial cut of FAQ based on questions from lobste.rs.
You may want to read A Tour of YSH before this FAQ.
One way to look at it is in this table: Oils is Exterior-First > Survey of alternative shells
That is, the design of YSH is what we call "exterior", like POSIX shell and OSH. It's based on operating system processes and pipes.
In contrast, PowerShell, nushell, and Elvish are "interior": they have language- or VM-specific notions of processes and pipes. They can use the OS primitives, but they are not the "primary" mechanisms.
This affects how easy it is to write certain programs.
It's a tradeoff, but for the scripts I write, "exterior" is generally more powerful because it's closer to the OS. For Windows, the "interior" design might be more convenient, since Windows exposes functionality as shared libraries, which the PowerShell VM can access.
But PowerShell is still not "universal glue".
I view "interior" designs as "one level up". For example, you may use a shell script to glue together a PowerShell script and a nushell script!
It's more consistent to parse and explain if we say that expressions are introduced to the right of var, const, and setvar. Recall that Oil has both expression mode and command mode.
The syntax is intended to be "huffman coded": mutation with setvar is less common than const, IMO.
Note that a bare x = 42 does work for config files in Oil, but that requires shopt --set parse_equals (because x = 42 in shell runs a command named x with arguments = and 42!).
But we want a syntax for mutation that does not change between oil:basic and oil:all. That is, we want two languages (OSH and Oil), not three!
In shell/OSH it's x=mystr (no spaces); in Oil it's setvar x = 'mystr' (quotes required).
It's an abstraction that can be thought of as either a "procedure" or "process". Like an external binary, it can serve both purposes.
July 2021: The func construct will likely be built on top of proc, but it isn't done yet.
The former is syntactic sugar for the latter. You could d['key'] everywhere, and the program would still work.
If you have a key like d['with spaces'], you have to use the bracketed form. Something like d->with spaces is a syntax error because of the space.
The ! inverts an exit code; while the not operator inverts a Python- / JS- like boolean.
The ! is only accepted in command mode; and not is only accepted in expression mode.