Tag Info

Hot answers tagged

5

From your one sample line, it looks like your file may be in Bourne-like shell syntax. So as your shell seems to be of the Bourne-type, you can just source the file after having issued a set -a so each new variable definition be automatically exported (assuming you do want them exported): set -a . ./.env set +a


5

Pro tip: There is never really a good reason to run sudo su. To run a command as a different user, use sudo -u username command. If you want a root shell, run sudo -i or sudo -l. If you have activated the root account, you can also run su alone, but sudo su is just not useful. And yes, I know you see it everywhere. That said, sudo has the -E switch which ...


4

The environment variable expansion is done by the shell so the command you're actually running is "sudo echo tim". This is all done before sudo is run.


4

sudo sanitizes the environment so potentially harmful variables are not passed to the process running as the superuser. You can change this behavior with the -E or --preserve-env flag to sudo.


3

With sudo, you can set variable for command in form var=value, try: sudo TEXMFVAR=/usr/local/texlive/2014/texmf-var \ /usr/local/texlive/2014/texmf-dist/scripts/pax/pdfannotextractor.pl --install -E option won't work with some variables like LD_LIBRARY_LOAD or LD_PRELOAD for security reason.


3

You can do it without calling login shell: sudo DUMMY=dummy su ec2-user -c 'echo "$DUMMY"' or: sudo DUMMY=dummy su -p - ec2-user -c 'echo "$DUMMY"' -p option make sudo preserve environment variables.


2

No, there's no way to filter variables by date or who owned it. You COULD set all existing variables to read-only and then later you use declare -p to filter those out. But a more common way to solve this is to prefix all your vairables with __project_ (where project is whatever). The variables get lengthy, but that seems to be the safest way. Your idea of ...


2

It's readable by remote_user and root. None other, unless remote_command is writing it to a globally readable file or something like that. You can inspect the environment of a process in the /proc filesystem in /proc/$pid/environ. You either need to be the same user as the euid of $pid or you need to be root, as the permissions of that file seem to default ...


2

It can be done by adding custom actions to policykit. If you want to run gedit as root with pkexec you have to create new file /usr/share/polkit-1/actions/org.freedesktop.policykit.gedit.policy for example: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" ...


2

My environment variables are set in ~/.bashrc. There's your problem. Then your environment variables are only set in applications that you start from a terminal, they are not set in applications started from a GUI menu. I am aware of the intricacies of login and non-login shells (interactive or not) and I've checked that my ~/.bashrc is run ...


1

You can add the line to the /etc/enviroment file like this: PATH=$PATH:~/root/scripts or Edit your ~/.bashrc and add your line here like this: export PATH=$PATH:~/root/scripts


1

The variable expansion is performed by your interactive shell. You're running the command sudo with the arguments echo and tim. If you want the expansion to happen in the shell invoked by sudo, tell it to run a shell and pass the string echo $ME to that shell: sudo sh -c 'echo $ME' sudo removes most variables from the environment, because they can be a ...


1

I see in my crystal ball that you're editing the file on a Windows machine. Windows and Linux have different ways of representing line breaks. On Linux (like any unix system), a line consists of a series of characters which ends with a line feed (LF = \n = Ctrl+J) character. On Windows, lines are separated by a two-character sequence: carriage return, then ...


1

Since you're using "su -" the shell being executed is pretending like it's a login shell (executing the system's /etc/profile, the user's profile, such as .profile or .bash_profile, and so on). One of those scripts is generating the escape sequence (the Esc]P string) and printing that result to stdout. It shouldn't do that. What it should be doing is ...


1

In shell, when you set a variable (both environment variable or unexported parameters) there is no difference going forward between that new variable and any that were already set before. Hence, (variations on) the two solutions you have thought of, which are: Use a naming convention to describe which ones you are interested in (uppercase vs. lowercase) ...


1

If for some reason sudo is rejecting the environment variables "directly" specified per cuonglm (perhaps because of policy reasons), you can just use env ... assuming you have sudo policy to use it. sudo env TEXMFVAR=/usr/local/texlive/2014/texmf-var /usr/local/texlive/2014/texmf-dist/scripts/pax/pdfannotextractor.pl --install



Only top voted, non community-wiki answers of a minimum length are eligible