Environment Variables - Defining default Variables

Ever seen mention of sudoedit? Ever wanted to use pacdiff with something other than vim -d ?

We can use Environment Variables

First lets understand how they work, the ways we can define them, and what the differences are.

The ArchWiki goes into detail here:
https://wiki.archlinux.org/index.php/Environment_variables#Defining_variables

Variables can be defined for each command we run. In the sudoedit example that means we can manually tell it to use our choice of editor by doing something like this:
SUDO_EDITOR=nano sudoedit /path/to/file

But what about setting a default for when we just type sudoedit?

We can use certain locations to define variables globally for the whole system or per-user.
But each location works a little differently, and you may have reason to use one over the other. Refer to the wiki article to make an informed decision, but due to limitations of other files I will be using /etc/environment here.

/etc/environment sets these variables globally and accepts “KEY=VAL” entries. One on each line.

So, in the example of sudoedit it would look like this:
SUDO_EDITOR=nano
There are also a few other related variables. And many more for a whole range of options.

I will leave here an example of my /etc/environment

GDK_SCALE=1.25
DIFFPROG=/usr/bin/meld
EDITOR=/usr/bin/micro
VISUAL=/usr/bin/micro
SUDO_EDITOR=/usr/bin/micro

These variables are my defaults now, and will be used anywhere applicable. As examples, whenever I want to use sudo -e or sudoedit then micro will automatically be used, pacdiff will use meld by default, and I’m setting the GTK items on my KDE desktop to scale 1.25x .

15 Likes

your approach should work fine.
but you can also set these variables in your .bashrc / .zshrc file.

i have the following line in my .zshrc file (do the same for the other 2 variables):

[[ -f /usr/bin/micro ]] && export SUDO_EDITOR="/usr/bin/micro" || export SUDO_EDITOR="/usr/bin/nano"            
# set minimal sudo text editor globally as environment variable. this gets used e.g. by "visudo"

this command checks, whether “micro” is installed and then sets the SUDO_EDITOR variable. if micro is not installed, “nano” is set as default sudo editor.

2 Likes

Nice.
One of the main reasons I even started writing this / sudoedit stuff is because it seems some form of some of these could be ripe for feature request

Indeed that’s where I usually put those, but /etc/environment has the benefit of being applicable to all existing and newly created users.

2 Likes

Well, that sure is fancy. Would this work if meld was not installed?

[[ -f /usr/bin/meld ]] && export DIFFPROG="/usr/bin/meld" || export DIFFPROG="/usr/bin/diff"

EDIT: @cscs You might want to add that user-specific environment variables can be placed in ~/.profile .

1 Like

They can also go in
~/.config/environment.d/*.conf
and a few other places … thats why I left the link so folks can decide what to use.

Nope:

==> ERROR: Cannot find the /usr/bin/meld binary required for viewing differences.

Triggered by this...
is the bellow issue valid?

In a multi-user system, there can be more than one sudo users (co-admins), with different preferences. (diff, meld, kdiff, kompare...).
If using sudo, I need to use local environment variables and sudo -E, as I interpret. OK, this is a question :blush:.

Edit: I just tested...
It works in terminal , whatever with sudo, without, or sudo -E.

As indicated by the linked archwiki these variables can be set globally or per-user, in a number of ways.
/etc/environment is global for the system.
Something like ~/.profile would be per-user.

[oh, I see! remember ... 'root' (or sudo .. meaning root) is actually a user, technically. I hope that makes some sense. If you need more help for how to fine-grain default environment variables while using sudo for different users ... then that is a different question .. but I am sure we can help .. maybe ?]

(PS - oh crap. Torvalds might murder me in my sleep if I dont right this wrong .. OK sudo doesnt equal root ... sudo is a command to be able to run a command, to do something, as a different user. Its just that the 'user' it defaults to is 'root' - ie: 'sudo dosomestuff' means 'i am root doing this stuff' ... but sudo is equally capable of, and used for, 'i am user:bob doing this stuff')

1 Like

Here are my test results:

echo $DIFFPROG
meld
sudo echo $DIFFPROG
meld
sudo pacdiff
==> ERROR: Cannot find the vim -d binary required for viewing differences.
sudo -E pacdiff
==> pacsave file found for /etc/default/grub
:: (V)iew, (S)kip, (R)emove pacsave, (O)verwrite with pacsave, (Q)uit: [v/s/r/o/q] s
==> WARNING: Ignoring /var/lib/PackageKit/transactions.db.pacsave.1

The plot:
I had in my ~/.profile

export DIFFPROG=/usr/bin/meld

which never worked with pacdiff, or sudo pacdiff.
Due to this discussion, I RTFM your and my sources.
I added at the end of my ~/.bash_profile

export DIFFPROG=meld

Re-logged in and tested (the above posted terminal output).

My conclusion is "for user level sudo ENVVARs to work, I/we need sudo -E.

How does it sound?


Edit: There is no any alias with sudo in my ~/.bashrc

1 Like

Environment variables are one of the most difficult things to get right when writing some services. Usually the display and Xauthority variables are sufficient, and other times I have to list far more variables to get a service to work correctly. It is rather like black magic to figure out what is required sometimes.

Yes .. this is correct.
Above I used sudo -e (note its lower case) to denote editing .. sudo -e = sudoedit
sudo -E on the other hand .. 'preserves environment' as per its man page.
[ man sudo ]
It quite makes sense that would pick up your variables, as opposed to sudo in general .. which again, as a different or even 'global' user .. is not defined by mere 'user' profile variables. But, something 'global' would be picked up by sudo, such as if you used /etc/environment

Yes. your example brings this a bit into question ... I am sorry .. but the closest I can come to an explanation is that echo doesnt give a hoot, and knows its never run by sudo. [why the heck would root ever need to echo anything?] But dont quote me.

I am not authoritative on this subject [or any other, c'mon, lets be fair] ... so its entirely possible there is a better explanation out there that I didnt take the time to copy here.

3 Likes

Forum kindly sponsored by Bytemark