> This is debatable. Augmenting PATH with a directory containing > nonexecutable scripts for sourcing is IMO not that confusing.
That was my original intention but there were objections to overloading the source builtin with even more behavior. I thought it was a good point so I decided to prototype this feature as a new builtin, which avoids that issue but also comes with its own tradeoffs. > I really don't think "'source' with a different search path" merits > a separate builtin. There is one advantage: the behavior will be clear to every user. Since it's a new bash-specific builtin, its behavior does not vary depending on the POSIX compatibility modes. It can also evolve different semantics than the source builtin. > Perhaps "source" could diverge from "." on this, > in which case there wouldn't be a POSIX conformance issue. I agree. If this does get implemented on top of source, I think it would be great if the dot operator was unaffected. > If "import" were qualitatively different from "source" (say it > integrated some sort of namespace functionality), then it would be > more compelling. I was hoping this point would be brought up during discussion. It's something I wanted to do but I don't have a fully formed idea yet and I'm also not sure how to implement it either. I was thinking about extending the restricted shell semantics when importing rather than sourcing. For example, make all variables local to the script being evaluated, but bind the functions to the calling script's namespace. Import could have flags to control which names/types get imported and which don't which I think could be very useful. Thanks for the feedback, Matheus
