I'm not sure if you want to include such details here, but the visudo manpage has an explanation why your EDITOR isn't the one used to edit when using visudo:
There is a hard-coded list of one or more editors that visudo will use set at compile-time that may be overridden via the editor sudoers Default variable. This list defaults to "/usr/bin/vi". Normally, visudo does not honor the VISUAL or EDITOR environment variables unless they contain an editor in the aforementioned editors list. However, if visudo is configured with the --with-env-editor option or the env_editor Default variable is set in sudoers, visudo will use any the editor defines by VISUAL or EDITOR. Note that this can be a security hole since it allows the user to execute any program they wish simply by setting VISUAL or EDITOR.
-- Karol 18:58, 30 May 2011 (EDT)
- Thanks for the info Karol. I have my editor for manipulating the sudoers file set to Nano. To be honest, I don't really remember the details other than setting EDITOR to nano somewhere..... Would you please add the above info as you see appropriate, into the EV page? Also jump in and help out where ever else you'd like - jeff story
The article mentions putting your environment variables in /etc/profile. /etc/profile seems to source from the files in /etc/profile.d which seems like a less disruptive place to put your new variables, similar to the way modules-load.d works these days TheCycoONE (talk) 12:56, 15 September 2012 (UTC)
- Certainly a bit late, but I totally agree with the need to mention
/etc/profile.d/for globally defined environment variables, as well as
- Quite a few packages place their files there (have a go at
$ pacman -Qo /etc/profile.d/*, two packages from [base] (
perl) place files there, without mentioning other common desktop packages such as
libreoffice-common), and it appears it can also help environment variables to take effect in graphical applications (see my note in VDPAU#Configuration).
- I checked the Talk page as I was about to add that info, because it seems surprisingly difficult to have a definitive answer on "where to put environment variable for graphical applications to inherit them" (while not using xinitrc, as per Environment_variables#Graphical_applications).
- If no comments or objections are made within one week, I'll try to make some edits on this.
- -- Neitsab (talk) 18:09, 15 May 2014 (UTC)
env var editor?
Does anybody know of a little utility that makes it easy to add/remove/modify frequently-modified env vars? e.g. sometimes I want to define one of several LD_LIBRARY_PATH values for my own purposes, or set CXXFLAGS/CFLAGS with some platform-specific optimizations, or change my path to either use icecream or don't use it. So I was thinking a little ncurses utility that turns my favorite frequently-toggled env var choices into a set of checkboxes would be handy to save typing.
- CentOS and similar commonly use Environment Modules for this purpose, though it is far from little. -- Lahwaacz (talk) 16:50, 6 December 2016 (UTC)
Consistently setting variables across systemd units & regular sessions
Here is an example on how to set the same environment variables in both systemd user units and regular sessions. Define the variables in
~/.config/environment.d/, then add the following snippet to
ENVIRONMENTD="$HOME/.config/environment.d" set -a if [ -d "$ENVIRONMENTD" ]; then for conf in $(ls "$ENVIRONMENTD"/*.conf) do . "$conf" done fi set +a