> How is this any different than
The main advantage would be availability of this mechanism
by default in all new versions of bash. This would make it
"native" to the language, the path of least resistance to
reusing bash code. Users will be able to just place the
scripts in the appropriate locations and import them.
> You could force the latter if you are sure that the sourced files will
> not attempt to run external commands.
This is also a big advantage: the proposed builtin does not
have this limitation. It preserves PATH and so it can import
the reusable shell scripts from the library locations while
commands and the source builtin continue to work as normal.
> You could even make this an alias if you want.
Yes, but then it would require every user to program
this facility into their shells. I think it would be great
if this requirement could be avoided. Building it into
bash would make it very ergonomic.
One of the issues raised in the ensuing discussion
was the fact POSIX enumerates the words which
shells are allowed to interpret specially, and the
fact that "import" is not among them. Indeed,
it looks like others have developed shell scripting
frameworks which also use the word "import" to
implement similar functionality. I agree that it is
a major issue and in response I suggested changing
the patch from a new builtin to an option for source:
source -i some-file
source --import some-file
When given this option, source would behave identically
to this new builtin: it will search for some-file in the paths
designated by BASH_IMPORT_PATH only, preserving PATH.
This solution does not introduce a new builtin and preserves
backwards compatibility fully since the new behavior is only
enabled when the --import option is passed.
As the maintainer of GNU bash, do you think this is a good idea?
Should I implement this and submit an updated patch set for
community review and comments?
Thanks for the feedback,
Matheus
