Re: [PATCH v2 5/8] builtins/source: parse the -i option

[Matheus Afonso Martins Moreira]

> The issue is that what you want, and what I want,
> and what konsolebox wants (and everyone else)
> are all slighty different.

The option solution which I proposed is not really in opposition
to anything that anyone else wants. It will not break anything,
it supports the same inputs and use cases as before, including
the absolute path case you cited.

On the other hand, the variable solution which everyone else
seems to favor _does_ get in the way of what I want to do. 

> And as konsolebox's functions show, all this can be implemented,
> reasonably easily, outside of the bash source code

No. By discussing this I ended up discovering additional reasons
why it should actually be in bash as a builtin feature.

Pure bash solutions have two choices and both of them break stuff.
Either they clobber PATH, or they resolve the file's path on their own
and pass an absolute path to the source builtin. If you clobber PATH,
sourced scripts can't easily find commands anymore. That completely
changes the way that scripts work and therefore the way they must
be written. If you resolve the path, you're just reinventing the source
builtin. It also depends on source actually accepting the absolute path
which renders it incompatible with restricted shells.

The option solution completely avoids all that. It leaves PATH alone,
and as a builtin it can integrate with restricted shells. I even made
BASH_SOURCE_PATH be read only in that context, just like PATH.
And it accomplishes all that in a compatible way that's fully opt in,
anyone who does not want it can simply not use it. Existing code
is not impacted because existing code simply does not pass -i
as an option to the source builtin.

I don't really understand why there seems to be so much
opposition to this. Ability to do something in pure bash is
not an argument against this feature, especially since it
overcomes limitations present in the pure bash solutions.
Those are _real_ limitations, not some "personal hangups"
as others called it. The pure bash solutions simply _cannot_
both of these things, they must sacrifice one of them.

Even if that wasn't the case, it wouldn't be an argument.
By this logic, the source builtin itself should not have been
added either. I mean it's just read and eval, and bash has
both of those primitives built into it already. There's a
comment which even explains source in these terms:
it reads in the file into a string and just evaluates it.
So why add the source builtin to begin with?

> if I needed something like that, I could write my own, similar ones.

And you would run into the limitations described above.

> I think all this just shows that there's no real need to add any
> code to bash at all for this

I don't know about "need" but there are certainly advantages.

> use full path names instead

Incompatible with restricted shells.

  -- Matheus