> distros, sysadmins, and users can already break your scripts > in plenty of ways -- changing existing shell variables, setting > shopts your scripts don't account for, etc.
Existing footguns doesn't justify addition of new ones. We have the ability to prevent a lot of breakage here. Shouldn't we take that opportunity? > By this logic, ALL future shell variables ought to be gated similarly. Maybe. I haven't really thought that far but it would probably be a good thing. > it seems a bit heavy-handed Why? Most if not all of the other builtins have options. > Note that "source -i" precludes a sort of mirror situation. > Someone who sourced scripts via PATH but wanted to > switch to BASH_SOURCE_PATH would not be able to > simply move the relevant directories from one variable > to the other but would have to modify all sourcing scripts > -- including third-party ones -- to use "source -i". Yes, that's intentional. This ensures that users who wrote code expecting PATH semantics actually get those semantics. Then the new variable can be set in the environment without impacting those users and their scripts. > If they declined to do this, then they'd have to keep using > PATH for at least some scripts, possibly indefinitely. Those should continue to work without any changes. They should even be compatible with each other: there should be no problems with sourcing -i a script which then sources another script normally or uses one of the module management solutions. -- Matheus
