In message 408CF369.9050907@intracom.gr you wrote:
Well, but how do you present it to the user? Will "printenv" show all variables mixed? So how does the user know which get saved and which not? How do you merge both with the standard CLI and hush in a consistent way? And allthis without (significantly) increasing the memory footprint _and_ keeping the code readable?
Well, will the user care?
I hope you are joking here. Of course he will.
Why should he know that the version or the clock variable is real?
He must know which variables are available when reading the environment under Linux. He must know which variables can be changed (with the changes showing some effect). Etc. etc.
If he tries to change a read only variable it should be denied.
Per definitionem there should be no variables in the environment that cannot be changed. Period.
I know that there is the big exception of "ver" (I had a weak moment when I alloed for that), and there are the smaller exceptions of serial# end ethaddr which are settable only once (usually by the vendor), but this is at least configurable.
Since the variables are present at RAM but not in persistent storage the size of the environment is the same. As for the code footprint this is debatable. If someone needs this "feature" he can enable it explicitly. If not enabled everything should work as it were.
I think the concept of environment variables as we have so far is conceptually pretty clean. What you suggest is different, and does not fit. That does NOT mean that your idea is bad - not at all. BUt such "automatic" variables must be kept separated from the environ- ment. They shall not be mixed in the display of the "printenv" command, and not be settable by "setenv".
Please feel free to implement new "printvar" and "setvar" commands as optional extension, but I really don't see that much benefit. Already now it is pretty ifficult to find a variable definition in a long, multi-page "printenv" output.
Best regards,
Wolfgang Denk