readme: why to use? highlight pain points of bash, where oh shines and where not

[Jan Ph. H.]

why to use (and not bash)?

1. how to use lists instead of the painful IFS or heredoc.
2. no second prompt, I guess?!
3. No ${var} to prevent $var from being expanded with $va + r
4. No ${var[?|-|+|=]} to handle undefined values or null.

why not to use? (assuming the worst possible answer due to missing docs)

1. No documentation on how multiple files can be used and what constrains/introspection of call history is possible (or if the same limitations as POSIX shell apply, ie no tracking of how and from where a script was called and a pile of other stuff.
2. create file1 and file2 with setting different variable. Reusing those variables within file3 is cumbersome (either need to be exported or each variable transferred).
3. (quite unfair, but for reusing efficient programs) It remains unclear, how to utilize faster programs or other languages for (frequent) computing of arithmetic stuff/data mutation.

Personally I think a shell should be a REPL with hacking convenience(piping, path hackery, job control) and control flow introspection, which includes to me leveraging external programs to compute stuff similar how "cyclic scanning mode" works (have the option to kill program used for externalizing execution after timeout).
Unfortunately shells need weird quirks to reuse program results for 3, even though (unless in superuser mode) a program execution may hijack shell sessions leading to no significant security gains on separation.

Any thoughts from you?

[Michael MacInnis]

Correct that oh only has the one prompt and does not support parameter expansion. Variables can be resolved with either the $var or ${var} syntax. Agreed that better documentation is needed. As to some of your other points, you may be assuming a shared context that does not exist and the result is that it feels like reading someone else's shorthand. For example, I'm not following your points about multiple files or reusing variables and how other shells (or programming languages) handle this well/better/differently. Also, could you be more explicit and describe what weird quirks shells need to resuse program results?

[Jan Ph. H.]

Agreed that better documentation is needed.

I was working on ion shell, from which you could take the structure.
Unfortunately the server seems to be down currently.
Ideally there would be a test framework, which can test the documentation in go/the documentation can be generated from importing test code.

There are 3 remaining things I dont understand on how scripts interact:

1. How are symbol clashes handled (symbols getting redefined)?
2. Am I forced to be explicit on recursive shell script invocation without introducing much boilerplate?
3. was explained in the talk. Reusing variables defined in script1 in script2 works with export. This still makes me wonder: Are files automatically invoked as "global module" ?
   Zig does it more explicitly, so I would expect ./script1.sh be a shorthand for something like set mod = @import(script1.sh); @exec(mod). And mod::symbol1 be accessible from within the caller script. Is this, how it works currently?

Also, could you be more explicit and describe what weird quirks shells need to resuse program results?

Interpreter-related
If you call a program to reuse the result within the shell script (you must store stdout and stderr for robustness), it becomes an ugly mess or outright aweful complex.

REPL-related
The other problem is how to proide a shell-independent tab/auto-completion. some suggestion, which uses a DSL, but one could also think of letting the program provide context-dependent completion.

[Michael MacInnis]

The scripts in the bin/doctest directory are oh test scripts. They are also used to produce the (currently very minimal) doc/manual.md.

If, when invoking oh recursively, you don't see the behavior you expect, please create an issue and document what you expected and what happened instead.

As to your other questions, if you don't find the answer in what documentation currently exists or the oh scripts in this repo, your best bet is to try things out. Oh doesn't go out of its way to be strange so if you see something that isn't what you expect, again, it would be great if you created an issue and documented what you expected and what happened instead.

[Jan Ph. H.]

sounds good. I will file individual issues after playing around.