Environment variables are not transferred to forthcoming commands
r0ller opened this issue · 3 comments
This happens because each human command translated to a shell script gets executed in a child process. So environment variables set in the shell script are specific to that child process environment and there is no way for a child process to set environment variables in its parent process environment so that later on they get inherited in the forthcoming child process.
The solution is that environment variables occuring in a shell script are read/stored in the parent process during translation using getenv() and putenv(). This way, the environment variables are inherited by the child processes and can be used as a communication channel between subsequent commands.
Environment variable transfer has been technically solved but still poses some questions. E.g. if one issues a command 'change directory to abc' then the ev $source is set to 'abc' (source=abc;). But if the next command takes this ev like 'list all files' which refers to the content of the directory just having been set i.e. 'abc', it results in a command like 'ls abc'. However, even if a directory 'abc' exists in the current working directory 'abc' it is not the same that the user refers to. The command should be somehow turned into 'ls .'. The question is how...
Closed the issue accidentally though changes have not been committed yet...
Can be closed finally due to the redesign of the library's scope committed yesterday though not because it got solved but rather due to the different approach the clients have to implement. See the wiki for the details about yesterday's commit.