>>>>> On Thu, 13 Sep 2012, Brian Harring wrote: > Note there is a few vars we need to exempt; that list is currently > SANDBOX_* and FEATURES. FEATURES is fine to exempt from this rule. > > For SANDBOX_*, while that's a PM internal, that's a bit of a grey > zone; regardless, we can actually address that via extending the > sandbox functions a bit: > > addwrite [-r|--remove] pathway # for example, to do a removal.
As already discussed on IRC, a -r option may have undesired effects. For example: addwrite /foo/bar # some commands writing to /foo/bar here addwrite -r /foo/bar # try to restore previous state Now if /foo/bar was in SANDBOX_WRITE before, it's now removed from it. Maybe it's better to add a --{save,restore} option pair: addwrite --save /foo/bar # some commands writing to /foo/bar here addwrite --restore # restore last saved state or --{push,pop} to allow for nested calls, but maybe that would be overkill. > For instances where the sandbox needs to be turned off for a command- > we do the same thing we did w/ nonfatal; > > sandboxless <the command and args> To start the bikeshedding: For some reason I associate "less (the pager) in a sandbox" with this. ;-) Maybe "nosandbox" or "sandboxoff"? Ulrich