On Sun, May 19, 2024 at 10:58 AM Matheus Afonso Martins Moreira < math...@matheusmoreira.com> wrote:
> > This is not a problem that's introduced by this patch. > People can already do that today. Anyone could write > `alias source='rm -rf --no-preserve-root /*'` right now, > nothing stops them. So I don't see why this would be > a reason against inclusion of this feature. > I was not talking about breakage of a script, anybody knows you can stick an rm -rf anywhere in your script (BTW protection/containers,... mitigate the damages). I was talking of two incompatible package manager, where one can break the other, yours can break mine, mine can't break yours, I was asking for a way to secure the old (current) way for mine. So far I saw typeset -r BASH_SOURCE_PATH='' in my init path, but not even sure it will be enough, beside I don't control my users who may miss the init update but still can mix'n'match the package managers. Here, we are not talking adding one more feature into bash, we are talking about one feature predate (intentionally or not) another one, it is normal that some head's up occurs. > I understand your concern though. Perhaps we can find > ways to work around it or fully address it. > Not too sure about that. > > > Another things that bugs me, why not implementing your invention in a > > dynamically loaded builtin, advertise it on github, and let the one who > > really needs this great thing be their choice download it, and use it. > > I don't really want to maintain such a thing. I'm struggling to find time > to work on my personal projects as it is. We are lucky to have someone > who maintains bash and who is considering this feature for addition. > Strange argument, you want to forward the hot potatoes to someone else regarding maintenance. First of all you claim the feature is tiny, almost bug free in its inception, secondly it is vastly needed. If those assertion are true, then your maintenance workload is almost nil for your feature you can always access on top of bash with dynload. If there is a vast need for it, and if unfortunately a bug shows up, then in this vast population, there will be a good soul providing a pull request for it, your load would be minimal. That's the magic of open software :-) So I think a dynloadable builtin of yours would be a perfect use case of dynload, and a good way to challenge your invention, i.e measure the vast population, bug rate, etc... I think it is a good 'preview' way, before eventually move from dyn load to static load one day. Dynloadable builtins exist, use it. > I don't want to fork bash. I want to be able to download the latest version > with my package manager and get access to this. It is perfectly doable, clone, configure, build, stick you patch and provide it to you (or your users) not a big deal of effort. You can have that today, all that hidden in... bingo a library :-) > If I had to fork bash to > get this, I would simply give up and continue working on my own > programming language instead. > I think this is a great valuable idea! PS : On the citations side, I remember one, a software is bug free when you trash it :-)
