> I fail to see how this could possibly save "thousands and thousands > of lines of code".
How many lines of code were needed to implement the module managers? Probably a lot of lines. I guessed it was in the "thousands of lines" ballpark. However many lines that is, this feature would allow me to reduce them all to zero by not actually needing a module manager. And the benefit would be multiplied by all the users of bash which is probably the most ubiquitous shell there is. That's a lot of benefit. At the very least, it will save users from having to implement an import function themselves. They could still do it but they won't have to. > You keep talking about this proposal as if it would spark a huge > sea change in script maintenance, but I just don't see it, at all. A native way to source libraries. Built into bash, available to all users. With the ergonomics you expect it to have. With good defaults, no setup. That's an incredibly huge change. Especially considering how little code was required to make it happen. People see bash as a language that scales down instead of up. The shellcheck tool helps a lot with shell script development but managing complexity is still quite difficult. This could really change that. > AFAICT the only thing this proposal addresses is your personal > hangup about using PATH to find sourced files It's not a personal hangup. Manipulating the PATH has consequences. Either you add the library directories to the PATH and risk false positives, or you delete the other directories and make sourced scripts unable to run commands. Alternatively, you reinvent part of the functionality of source by resolving the path yourself and giving it an absolute path. None of these solutions seem right to me. I think the best solution is to just avoid all that by adding another variable. This approach resolves all the above concerns. It also reuses bash's pathname resolution code and has the added benefit of being native to bash and available to all users, eliminating the requirement that they implement this themselves or install an external dependency just to load libraries. > The sourced files that can be written with your feature available > are exactly the same as the ones that can be written right now. It's possible but it's not as easy or ergonomic as it could be. > Much like the periodic requests for XDG-organized startup files I think I deserve at least a little more credit than that. This was not some simple drive-by feature request. I implemented the feature, debugged the code, tested it and sent a patch with my full rationale. I did so after asking the community what they thought about this and after _the bash maintainer_ replied to my email saying he thought it was a reasonable feature. I interpreted that as a strong signal that this would be a welcome contribution. In my very first email ever to these lists, I made it clear that I intended to contribute this patch. I was not requesting it, I intended to show my work from the outset. Now I'll be the first to admit that this first iteration was not perfect. People raised issues and concerns, they were absolutely valid and I tried to address them in good faith to the best of my ability. I even learned new things from these replies and I'm thankful for that. But I don't think it's fair at all to just dismiss it as a "request". The code has been written and as far as I can tell it works and makes bash better than it used to be. I even made sure to separate the commits into logical changes so that the the maintainer would be able to cherry pick the general refactoring improvements even if the overall feature was rejected in the end. It was my intention to do at least some good even if this turned out to be a stupid idea in the end. My only request here is that you seriously consider the work of a fellow software developer for merging into master. That's all. > BASH_SOURCE_PATH might be convenient > but is not groundbreaking and probably > doesn't merit significant changes to the shell. I can't speak for others but I'd say this feature is going to be quite ground breaking for me. It's going to significantly and permanently change the way I use bash. I'm going to write lots of little libraries. I'll release them as free software too. My dotfiles repository is AGPLv3. > even convinced it merits a new "source" option. Why not? The addition of this new builtin turned out to be a significant change, much bigger than I anticipated. I quickly agreed that it would be better as an option to the existing source builtin which is a much more conservative solution. I've even sent the new patchset. It is no longer a significant change. It's not even a significant amount of code. It adds a useful feature, and does so in a way that does not cause any incompatibility. Yet the feature has been described as "irritating"! I really don't understand the cause for this and it's making me feel really unwelcome.
