> 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
