Hi, I think this is probably kind of an unusual request, but you don't get anything you don't ask for, right? So I figure it's worth a shot.
Basically, I am working on a library called shell-pepper (it's not too far along at this point) - the general concept is that it's like a grab-bag of functionality I'd like to have in the shell, implemented as loadable "builtins" (when necessary), shell functions, and ordinary executables. My ultimate aim is to provide some useful functionality in fairly consistent ways across a few different shell implementations, and maybe also serve as a useful example of how to write non-trivial shell builtins. I was hoping to use the "dynamic variable" mechanism as the basis for a rudimentary "object" system. The main benefit of such a system would be some degree of automated control over the lifetime of these "objects" - in particular, they can be tied to the lifetime of "local" variables within a function, or used to trigger actions when a script terminates - basic RAII type stuff. My goal with this functionality in the library is to use it as a starting point to extend the shell in non-invasive ways, use variable lifetimes to control subprocess lifetimes, that sort of thing. Obviously asking for a code change in one of the shells I plan to support is pretty "invasive"... But in this case it's the only way I can come up with to provide this kind of functionality. So there's basically these two fundamental limitations in Bash variables that prevent this plan from working: 1: Variables can't really carry data other than what's in SHELL_VAR.name, .value, and .exportstr, and those already have defined meanings. Even in the case of dynamic variables, the dynamic_value() function is expected to populate SHELL_VAR.value (at least, that's my understanding), so the options for storing object data in a variable are rather limited. (Best I could come up with, is store some data in .value after the end-of-string marker. But that could be problematic, too, if some piece of code somewhere assumes that .value ends with that null byte... copy_variable() does this but as far as I can tell it's not called. So it could work, it just seems a bit risky..) 2: The dynamic variable implementation receives no notification when the variable binding is destroyed (as with unset, or end-of-scope for a local variable, etc.) - this means the implementation backing a dynamic variable has no way of knowing when data associated with a dynamic variable is no longer needed. For the dynamic variables implemented in the shell this isn't a significant issue (because they use global variables for their state, and don't support multiple instances - they are implementations of dynamic variables, not implementations of *classes* of dynamic variables.) but for my purposes, in which I would ultimately have commands that create dynamic variables, it's a problem. So the code change would go something like this: - Add a new pointer field in "struct variable", "void *state_data" or some such. The pointer is initialized to zero when a variable is created, and otherwise the value of the pointer and the allocation/deallocation of the data it points to is the responsibility of the dynamic variable implementation associated with the variable. - Add a new function pointer field in "struct variable", called "unset_func". If the function pointer is nonzero, then it is called as a function (with the variable struct as an argument) prior to destroying a variable binding. Offhand, I can anticipate a few potential down-sides to this idea: - Increasing the memory footprint of all variables by two pointers (whether they're dynamic variables or not) - Potentially breaking existing third-party loadable "builtin" code by changing the variable structure - Introducing maintenance burden for a feature that is not presently needed for Bash itself Anyway, I thought I'd float the idea and see if it might be a possibility.
