Nsh: A fish/bash-like Posix shell in Rust

> If you like this syntax, that is fine, but I do not like it, and I also find it illogical, because McCarthy "and" and McCarthy "or" are really alternatives to the sequential execution denoted by ";"

‘alternative’ is doing some interesting work here, as evidenced by the example you use in the text that follows. If `&&` and `||` themselves sequencing delimiters that additionally imposed conditions upon the exit statuses of the commands in the sequence while also re-emitting those statuses, `&&` and `||` wouldn't behave the way they do in your example, affecting the behavior of the `&` operator. This means that your example shows that `||` and `&&` are also in a distinct syntactic category from that of `;`. Alternatively, we can nominally put them in the same category, as Bash does by calling `;`, `||`, and `&&` ‘control operators’ (along with pipes and other things), but then we find ourselves in a situation where _some_ control operators modify the scope of any `&` operators that succeed them but other control operators don't. So how conceptually useful is this category, now?

> Also, I have never reached deep enough in the fish documentation to discover how you can write the equivalent of: > > cmd1 && cmd2 || cmd3 && cmd4 & >

I am glad this expression is not idiomatic Fish. `&&` and `||`, as command operators here, serve to give chaining some commands together some resemblance to boolean expressions in other programming languages. But would-be formula in first-order logic which captures the logical component of this expression

  a ∧ b ∨ c ∧ d

is not a well-formed formula! So what it means is a matter of convention. The role of the final `&` here is the same: yet another construct whose meaning depends on the script language author's choice of operator precedence.

By contrast, in Fish, the behavior you should expect falls out of the ordinary syntax for the commands and the manual's description of the builtin `and` and `or` commands. In Fish, this is also quite easy to look up, e.g., with `help and`, which yields:

> and is used to execute a command if the previous command was successful (returned a status of 0).

> and statements may be used as part of the condition in an while or if block.

> and does not change the current exit status itself, but the command it runs most likely will. The exit status of the last foreground command to exit can always be accessed using the $status variable.

which is all you need to understand how `and` works. By contrast, in Bash (which I'll continue to use as my example for the more conventional syntax and semantics), to figure out your example expression, you have to read this from the Bash docs (after reading the section on pipelines, of course):

> Lists > A list is a sequence of one or more pipelines separated by one of the operators ;, &, &&, or ||, and optionally terminated by one of ;, &, or <newline>. > > Of these list operators, && and || have equal precedence, followed by ; and &, which have equal precedence. > > A sequence of one or more newlines may appear in a list instead of a semicolon to delimit commands. > > If a command is terminated by the control operator &, the shell executes the command in the background in a subshell. The shell does not wait for the command to finish, and the return status is 0. These are referred to as asynchronous commands. Commands separated by a ; are executed sequentially; the shell waits for each command to terminate in turn. The return status is the exit status of the last command executed. > > AND and OR lists are sequences of one or more pipelines separated by the && and || control operators, respectively. AND and OR lists are executed with left associativity. An AND list has the form > > command1 && command2

> command2 is executed if, and only if, command1 returns an exit status of zero (success). > > An OR list has the form > > command1 || command2 > > command2 is executed if, and only if, command1 returns a non-zero exit status. The return status of AND and OR lists is the exit status of the last command executed in the list.

Okay, okay. So anything conjoined by `&&` and `||` is like one big command, since && and || have higher precedence than anything else. That's why the final `&` in your example applies to the whole list of pipelines that come before it.

Only that's not true! A look inside the manpage for bash's builtins reveals blurbs like this in the entries for `set` and `trap`:

> part of any command executed in a && or || list except the command following the final && or || > part of a command executed in a && or || list except the command following the final && or ||

which is the exact opposite of the behavior `&&` and `||` exhibit in your example when followed by `&`. Fantastic. Very ‘logical’.

To return to this:

> Also, I have never reached deep enough in the fish documentation to discover how you can write the equivalent of: > > cmd1 && cmd2 || cmd3 && cmd4 & >

Fish has blocks, so you'd write:

  begin
    cmd1
    and cmd2
    or cmd3
    and cmd4
  end &

or use a function. But the above example doesn't actually work, because unfortunately Fish has a deeper defect than a syntactical discrepancy here, and job control is not implemented for Fish functions, see https://github.com/fish-shell/fish-shell/issues/238 and the Fish manual's section on job control https://fishshell.com/docs/current/language.html?job-control.... But again, this is not a syntax issue but a job control issue, a defect in the implementation rather than the design of the syntax.

Finally:

> For any shell wannabe, there is a very large part of the syntax used by ksh/zsh/bash that can be changed without problems, e.g. conditional structures, loops, variable and function definitions, various kinds of parameter expansions and expressions and so on. > > None of those is specific for a shell language and it is likely that better replacements can be found.

This is actually interesting and constructive, because it gives a clearer picture of the kind of ‘improved’ shell you might want. I hope that one comes to be, if it's not already being worked on.

But I just disagree that the traditional command list structure is necessary or good. It's full of arbitrary conventions and gotchas, and the additional flexibility it gives you is trivial. It's a bummer that Fish's job control lets us down here, but that has nothing to do with the syntax.

We wouldn’t have Rust either because why develop a new programming language when we already have programming languages?

I’m fact why even have Linux or macOS running atop x86 when we have perfectly good z80 micro computers running a BASIC interpreter…

I’m all for difference of opinions but that is clearly the dumbest one posted to HN in a long time.

`exec <shell>` would avoid nested shells and inherit the environment. Which might be preferable if you find your terminal emulator complaining about processes still running on close.

You can use fenv or bass for that. They run a snippet or script of bash in bash, then import all the environment changes for you

https://github.com/oh-my-fish/plugin-foreign-env

https://github.com/edc/bass

could you explain this? How could the script set env vars before you run it??