Tag Info

Hot answers tagged

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

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.


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.


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 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

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


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 lots of places, depending On virtual terminals and real terminals, the TERM environment variable is set by the program that chains to login, and is inherited all of the way along to the interactive shell that executes once one has logged on. Where, precisely, this happens varies from system to system, and according to the kind of terminal. Real, ...



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