Create shopt settings during tab completion (Allow running bash-completion in YSH)

[andychu]

This is problematic now because shopt flags are global.

I think there should be a mode to tag functions with them.

Note that this applies to the echo builtin, which is affected by shopt -s simple_echo. I think the function-specific options would work there.

[andychu]

Instead of procs and functions having tags #1147 , we could do something like

shopt --completion --unset oil:all  # global setting, what do you run with TAB?

Or maybe?

complete --set-options
complete --unset-options

[bar-g]

Um, I don't seem to understand the solution you posted, but I think you mentioned this issue in conjunction with calling functions from sourced libraries. I think that is an important feature. Does your idea help in doing that?

[andychu]

So I believe that problem is impossible in general ... consider this:

proc p

f1() { ... }
f2() { ... }

Now you have two different call stacks:

p -> f1
f2 -> f1

Now you have a choice.

1. f1 gets its options from its caller. Problem: you have two different behaviors for f1.
2. f1 is tagged with the original options it was defined with. I think the problem is errexit . p is supposed to fail on errors, but p calls f1, and f1 doesn't fail. Errors go up the stack.

You might be able to argue that behavior 2 is OK.

However my feeling now is that it's simply too confusing.

---

The reason that completion works is that when you hit <TAB> you essentially invoke the interpreter from SCRATCH AGAIN. It's a callback.

Also, completion codebases are self-contained. They don't really interact with other shell scripts.

---

I believe the best way to interface OSH and Oil functions is by using the $0 dispatch pattern and separate processes

Having a mixed call stack is way too confusing.

With separate processes you have one set of options for the whole call stack

And yes completion is almost like a different process -- it has a different call stack. A new one is created on every <TAB>

[andychu]

I guess a shorter way of saying this is that I don't want to debug any code with a mixed call stack :-/

It is not a gradual upgrade -- you can't just upgrade some functions, not upgrade other functions, and then call them altogether.

That is madness :)

---

Instead you have to shopt --set oil:upgrade and deal with the fallout. The main changes are no word splitting (generally easy), and better error handling (also easy if that's what you want).

So you go from one error handling paradigm to the other. Mixing them is bad

You don't want to have some functions relying on ls /bad to fail, and others are doing ls /bad || die everywhere. We don't want to make a big mess