From owner-freebsd-questions@freebsd.org Wed May 20 13:13:44 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 045502D9E2E for ; Wed, 20 May 2020 13:13:44 +0000 (UTC) (envelope-from listac@nebelschwaden.de) Received: from mail.worldserver.net (mail.worldserver.net [217.13.200.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.worldserver.net", Issuer "EuropeanSSL Server CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49RtVb0knfz4C3n for ; Wed, 20 May 2020 13:13:42 +0000 (UTC) (envelope-from listac@nebelschwaden.de) Received: from postpony.nebelschwaden.de (v22018114346177759.hotsrv.de [194.55.14.20]) (Authenticated sender: postmaster@nebelschwaden.de) by mail.worldserver.net (Postfix) with ESMTPA id 9B77A26859 for ; Wed, 20 May 2020 15:13:40 +0200 (CEST) Received: from [172.16.37.5] (kaperfahrt.nebelschwaden.de [172.16.37.5]) by postpony.nebelschwaden.de (Postfix) with ESMTP id 0F3A5D9136 for ; Wed, 20 May 2020 15:13:40 +0200 (CEST) Reply-To: listac@nebelschwaden.de Subject: Re: Moving sources (base/ports) from /usr To: freebsd-questions@freebsd.org References: <8d48921e-7af1-9313-0781-4ba4bd9c1f10@nebelschwaden.de> <20200520110833.f47610a48f0f28dd563c13aa@sohara.org> <2c3bd26c-aaa3-9998-e5e5-e3f4f3796ffc@nebelschwaden.de> <0b98639e-e714-412c-950e-7d20be5d1147@hedeland.org> <20200520144555.2e935417.freebsd@edvax.de> From: Ede Wolf Message-ID: <690ef022-1afe-645a-aec9-30f9d84561f6@nebelschwaden.de> Date: Wed, 20 May 2020 15:13:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200520144555.2e935417.freebsd@edvax.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49RtVb0knfz4C3n X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of listac@nebelschwaden.de has no SPF policy when checking 217.13.200.26) smtp.mailfrom=listac@nebelschwaden.de X-Spamd-Result: default: False [2.42 / 15.00]; HAS_REPLYTO(0.00)[listac@nebelschwaden.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.54)[0.539]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.98)[0.979]; RCVD_IN_DNSWL_NONE(0.00)[217.13.200.26:from]; R_SPF_NA(0.00)[no SPF record]; DMARC_NA(0.00)[nebelschwaden.de]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15657, ipnet:217.13.192.0/20, country:DE]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2020 13:13:44 -0000 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. > > >