Moving sources (base/ports) from /usr

Ede Wolf listac at nebelschwaden.de
Wed May 20 13:13:44 UTC 2020


Hi all,

Mea culpa. I think I have found my mistake. In /etc/profile I forgot to 
actually export the variable.
It was just defined, even though I would have sworn to death, I've done 
this.
Polytropons post made me recheck, however.

So exporting the variable in /etc/profile as it should have been done in 
the first place makes at least "env | grep SOURCEDIR" work and also 
explaines, why it did not get handed down to mergemaster.
Makes perfectly sense even with my old view of variables and environment.

Rebuilding world now, will take a good day, but I am confident, it will 
now work as expected.

Thanks all for your time an in depth explanations and sorry for the 
noise on this one. Should have checked before, but I was absolutely 
shure I had done the export, because I always do. Well...

Nietzsche holds true again:

"Convictions are more dangerous enemies of truth than lies."



Am 20.05.20 um 14:45 schrieb Polytropon:
> On Wed, 20 May 2020 13:49:19 +0200, Ede Wolf wrote:
>> Sometimes, being pedantic helps quite a bit:
>>
>> ... (fresh login)
>> # echo $SOURCEDIR
>> /clutter/src
>> # env | grep SOURCEDIR
>> #
>> # SOURCEDIR="/clutter/src"
>> # export SOURCEDIR
>> # env | grep SOURCEDIR
>> SOURCEDIR=/clutter/src
>>
>> Even if this distinction is currently raising more question than it
>> answers, it at least explains the behaviour.
> 
> It does. My assumption (and therefore not thinking about this
> possibility) was that you had set and exported (!) the variable
> to the environment. The common forms
> 
> 	FOO="bar"
> 	export FOO
> 
> and
> 
> 	export FOO="bar"
> 
> are the forms typically found when you want to modify tne
> environment, and _that_ is what's being passed from one instance
> of the shell to the next instance (subshell). Regular variables
> do not get passed that way:
> 
> 	$ FOO=bar
> 	$ echo $FOO
> 	bar
> 	$ sh
> 	$ echo $FOO
> 	
> 	$ _
> 
> If you use "export" here, you can easily see the difference:
> 
> 	$ FOO=bar
> 	$ echo $FOO
> 	bar
> 	$ export FOO
> 	$ sh
> 	$ echo $FOO
> 	bar
> 	$ _
> 
> The mentioned form
> 
> 	$ export FOO=bar
> 
> would lead to the same effect. Checking with "env" is a good
> idea if you want to explicitely (!) confirm that a certain
> variable is set in the environment, not just as a mere shell
> variable.
> 
> This doesn't just apply to shell scripts invoked by shell scripts,
> but also to program that query *envp[], the (optional) third
> parameter of the standard main() function.
> 
> 
> 
>> And I know I need to rethink my understanding of shell vs. environment
>> variables (and the corresponding files).
> 
> The files can set shell variables and environmental variables.
> The case for _which_ kind of shell this applies (login shell,
> interactive shell, scripting shell) depends on the file name,
> as explained in "man sh", section "Invocation".
> 
> 
> 
>> Thanks for the heads up, with that in mind I'll reread the comment on
>> sh(1) and .shrc from before and, well, have a talk with my favourite
>> search enginge.
> 
> It's a search engine, not a listening engine. ;-)
> 
> However, it is not a bad idea to visit fundamental knowledge
> and shell basics from time to time. It makes life easier,
> especially for those corner cases where you expect a certain
> behaviour, but it strangely does not happen.
> 
> 
> 



More information about the freebsd-questions mailing list