Re: autoload variables

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 8/30/21, Anthony Fletcher <anthony@xxxxxxxx> wrote:
> On Mon, 30 Aug 2021 at 12:40, René Neumann <lists@xxxxxxxxx> wrote:
>
>> Am 30.08.21 um 17:22 schrieb Anthony Fletcher:
>> > For instance, one variable is to identify the default uplink
>> > interface
>> >
>> >     export UPIF=$(ip -4 r | sed -n -e '/^default/ s/^default.*dev //;
>> > s/
>> > .*// p;q' )
>> >
>> > Useful when I'm debugging the network but not needed otherwise.
>>
>> Is there a reason you need this as a variable? Would a function
>>
>> upif() { ip -4 r | ... }
>>
>> not suffice?
>>
>> - René
>>
>
> A function would work but then you need to run it every time to get the
> same value..... and of course the variable is for other commands. Thus
>        systemcommand $(upif)
> In this particular case anything to do with the uplink interface (eg
> dump_dhcp6). I guess the function could cache the result for speed.

It's unclear from your examples if these variables actually need to be
in the environment (eg, used by the program automatically), or if
you're naming them on the command line (eg, some_cmd $myvars). In the
latter case, they don't need to be exported at all.

This may be an unpopular suggestion (I would also not use it :)), but
you can abuse global aliases in the latter case as well, if you are
very opposed to typing $(foo) instead of $FOO:
% alias -g '$UPIF=$(echo 123.12.2.15)'
% echo $UPIF
123.12.2.15

(keep in mind the word needs to appear separate from other words and
exactly as specified for this to work, eg not foo$UPIF or ${UPIF}).
(You also don't need the $ at all if you do this, so you could just
call it UPIF too, assuming you don't use this in the literal sense
(although if you did, you could write \UPIF in those cases).).

If you *do* need these in the environment, and assuming that they
don't change very often, you could initialize all of them in .zprofile
instead of .zshrc and they will just persist in your environment at no
extra startup cost. (You can do this for the latter case too,
actually).

-- 
Mikael Magnusson