Re: Re: [PATCH 0/4] Add import builtin

[Matheus Afonso Martins Moreira]

>  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