Support for environment variables

[jovanbulck]

things todo:

• [x] create setenv <name> <value> built_in that calls setenv(3)
• [ ] extend the jsh grammar to include $environment_variables (new level between expr and cmd or at comd level as aliases ??)
• [ ] modify the jsh parsing code to expand $environment_variables according to the grammar
• [ ] support the extern keyword
• [ ] allow syntactic sugar to write env_var="value" instead of env env_var "value"?

[jovanbulck]

Some extra info on this:

1. documentation:

   • https://en.wikipedia.org/wiki/Environment_variable --> very instructive :-)
   • the default behaviour of execve is to pass the child a copy of its environment table, but this can also be explicitly overriden (which we don't need I think)
   • The UNIX env command prints all environment variables that it is passed --> great for testing
   • There's also a set shell built_in command (but I think we don't need to implement this for now?)

   • On export: wikipedia says:

     "In Unix shells, variables may be assigned without the export keyword. Variables defined in this way are displayed by the set command, but are not true environment variables, as they are stored only by the shell and not recognized by the kernel. The printenv command will not display them, and child processes do not inherit them."

2. setting environment variables in the shell:
   • keep an internal table of non-exported environment variables and only call setenv(3) when export is supplied.
   • The setenv(3) syscall will then update the table and the variable will automatically be passed to the child. e.g. as is done in the cd built_in for the PWD env var
3. Some final thoughts on $expansion:
   • maybe expansion can happen before the jsh grammar parsing code, as is done with alias resolving?
   • --> key question: are environment variables valid in any context (analogous to the special ~ alias)? or is this context sensitive, as normal aliases? => I'm not sure, but I think this might be context insensitive, allowing 'easy' substitution. Share your thoughts...
   • we probably want to allow to \$escape env var substitution

[Wanimatrix]

• [x] create unsetenv <name> <value> built_in that calls unsetenv(1)
• For setenv, note: overwrite is always set to true