You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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."
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
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
things todo:
setenv <name> <value>
built_in that callssetenv(3)
extern
keywordenv_var="value"
instead ofenv env_var "value"
?The text was updated successfully, but these errors were encountered: