[SOLVED] bash - diff btwn 'normal' environment variables and VAR=x cmd

Spider.007 · 2014-04-24 11:47:31

I always assumed variables passed like this:

VAR=value cmd

are passed to the program in the same way as environment variables. However; this is not the case; who can explain this?

$ svn commit
svn: E205007: Commit failed (details follow):
svn: E205007: Could not use external editor to fetch log message; consider setting the $SVN_EDITOR environment variable or using the --message (-m) or --file (-F) options
svn: E205007: None of the environment variables SVN_EDITOR, VISUAL or EDITOR are set, and no 'editor-cmd' run-time configuration option was found
$ VISUAL=$VISUAL svn commit
Sending        file
Deleting       file
Adding         file
Transmitting file data ..

Last edited by Spider.007 (2014-04-24 17:55:49)

drcouzelis · 2014-04-24 12:54:24

That... looks really strange.

What is $VISUAL set to when you open a new shell?

Trilby · 2014-04-24 13:04:45

I'm curious too. I could at least *speculate* on how it could go wrong the other way around: if the envoked process spawns a new process that inherits a more general environment than the parent's, the first could work and the second could fail - but these results indeed should not happen.

Test code as evidence that the variables are passed in the same way:

#include <stdio.h>

int main(int argc, char **argv, char **env) {
	char **envp;
	for (envp = env; envp && *envp; envp++) printf("%s\n", *envp);
	return 0;
}

Basically this is a very basic `env'. It shows all environment variables known to the process. No matter how they are set, they are all placed in env.

NOTE: most programs will use getenv() rather than the extra parameter to main(), but this is meant to test what is passed where.

Last edited by Trilby (2014-04-24 13:07:21)

berbae · 2014-04-24 13:07:40

It's not strange if VISUAL is set but not exported with the 'export VISUAL' command; then it is not passed to the command execution environment.
With the syntax 'VISUAL=$VISUAL svn commit', you create a copy of the not exported variable, with the same name, but inside the command execution environment; so it works then.

Trilby · 2014-04-24 13:14:43

I'll be ... I just confirmed the above with my test code. And I just learned something new and important (thanks berbae).

Last edited by Trilby (2014-04-24 13:15:00)

berbae · 2014-04-24 13:32:11

$ VARTEST='abcd'
$ cat >./cmdtest
#!/bin/bash
echo "VARTEST=***$VARTEST***"
$ chmod 755 ./cmdtest
$ ./cmdtest
VARTEST=******
$ export VARTEST
$ ./cmdtest
VARTEST=***abcd***

and

$ unset VARTEST
$ VARTEST='abcd'
$ ./cmdtest
VARTEST=******
$ VARTEST=$VARTEST ./cmdtest
VARTEST=***abcd***

Spider.007 · 2014-04-24 17:55:05

Thanks berbae, I learned something new. You are right; the VISUAL variables is not set as 'exported' and is therefore not passed to new commands. I never realised this works like that, but it does. `set` displays all variables regardless of locality.

Arch Linux

#1 2014-04-24 11:47:31

[SOLVED] bash - diff btwn 'normal' environment variables and VAR=x cmd

#2 2014-04-24 12:54:24

Re: [SOLVED] bash - diff btwn 'normal' environment variables and VAR=x cmd

#3 2014-04-24 13:04:45

Re: [SOLVED] bash - diff btwn 'normal' environment variables and VAR=x cmd

#4 2014-04-24 13:07:40

Re: [SOLVED] bash - diff btwn 'normal' environment variables and VAR=x cmd

#5 2014-04-24 13:14:43

Re: [SOLVED] bash - diff btwn 'normal' environment variables and VAR=x cmd

#6 2014-04-24 13:32:11

Re: [SOLVED] bash - diff btwn 'normal' environment variables and VAR=x cmd

#7 2014-04-24 17:55:05

Re: [SOLVED] bash - diff btwn 'normal' environment variables and VAR=x cmd

Board footer