> Your proposition could not be 'builtin', you want a new 'model' with > 'packages/module'
Yes. However, that was because I did not really know bash module managers existed. I immediately adopted a conservative approach once I was informed of their existence. I do not intend to develop the import builtin patch set anymore, I have switched to the source option patch set. > Another option is to create a fork of a project (here bash) implement your > hack, > provide it (github kind) then see the stats, if your new bash skyrocket, > may be your hack will be back ported. Forking bash is not an option for me. Its ubiquitousness is a major reason why I use it. > All that to say, I am not too sure that distro (and installer of all sort) > will be willing to get a fatter bash for higher risk of bugs, hack, secu, > name it, > and would surely ask this feature to be optional, > then always requiring an init line to enable it. Making it optional is definitely possible. I'll work on that if needed. I have made the defaults compile time configurable. I think including the user's home directory is very useful, it certainly can't be worse than including the current directory. However, I made it easy to change should anyone want or need to do so. I'd like to note that bash has a restricted shell mode which disallows many things, including the sourcing of files via their absolute paths. I made sure that both the import builtin and source --library supported that. I was told that many bash module managers supply an absolute path to source, making them incompatible with restricted shells. Reading the documentation now, it says that restricted mode also disallows overriding PATH. I can also make it so that setting or unsetting BASH_LIBRARIES_PATH is also prohibited. This should make this solution attractive from a security perspective. Administrators can set the bash libraries path and disallow changes to it.
