Re: [Help-bash] confused by command substitution...

[Andy Chu]

On Mon, Feb 11, 2019 at 6:03 AM Greg Wooledge <address@hidden> wrote:
> They're all 100% wrong.  If one of them happens not to throw a syntax
> error, that's just bash's way of lulling newbies into complacency so
> that their scripts blow up LATER instead of IMMEDIATELY.  Obviously a
> script that APPEARS to work has a better chance of going into production
> in a broken state.  This maximizes the chances of chaos and destruction.
> Bash craves these things.  The suffering of fools is its lifeblood.

I think you're exaggerating, but only by a little :)

I named the latest release announcement for my Oil shell project in
honor of this sentiment:

OSH 0.6.pre15 Does Not Crave Chaos and Destruction:
http://www.oilshell.org/blog/2019/02/18.html

I also added a new `set -o strict-argv` option that disallows this
behavior, since I agree that it's almost always an indication of an
error in the shell script.  The user didn't intend an empty argv
array, and only hit it by accident.

$ osh -c 'set -o strict-argv; $unquoted_empty_var'
Line 1 of '<command string>'
  set -o strict-argv; $unquoted_empty_var
                      ^~~~~~~~~~~~~~~~~~~
fatal: Command evaluated to an empty argv array

I've gotten feedback that error messages are important.  This part of
Oil was somewhat inspired by the move from GCC to Clang at work
several years ago -- users really liked Clang's error messages.
(GCC's messages have improved since.)

-----

I suspect most people are unfamiliar with the project, so here's a summary:

- "Why Create a New Unix Shell?" http://www.oilshell.org/blog/2018/01/28.html

- It can run thousands of lines of distro build scripts unmodified.
  - "Success with Aboriginal, Alpine, and Debian Linux"
http://www.oilshell.org/blog/2018/01/15.html

- It can run much of the bash-completion project, with patches that I
describe in the release notes above.
  - "Success With the Interactive Shell"
http://www.oilshell.org/blog/2019/02/05.html
  - bash-completion scripts use some of the worst corners of the
language.  It's really another dialect of bash. It also tries to parse
bash in bash, which is a bad idea.

- The source code is 8x smaller than bash's when you count significant
lines of code (11K vs. 88K).

- However, that's not a fair comparison since it's still *way too
slow*.  I concentrated on defining a strict and sane version of the
language compactly in a high level language (Python).
  - "Parsing Shell Like a Programming Language"
http://www.oilshell.org/blog/2019/02/07.html.

I hope to speed up the whole thing this year using metaprogramming
techniques, some of which are described on the blog.

If you really feel that strongly about the error messages in bash, I
would encourage you to try it on your shells scripts and report bugs!
This will help me define a stricter language that can still run real
bash scripts.

I've done extensive testing myself, comparing OSH with
bash/dash/mksh/zsh, but I'm sure there are other use cases to be
uncovered.  It will be easier to change the OSH language now rather
than later.

Feel free to send replies to me privately if they're not relevant to
help-bash.  Thanks!

Andy