Tag Info

New answers tagged

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


0

Edit your ~/.bashrc file and add your export PATH line to it.


0

Try using the -E parameter on sudo: -E, --preserve-env Indicates to the security policy that the user wishes to pre‐ serve their existing environment variables. The security policy may return an error if the user does not have permis‐ sion to preserve the environment.


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


0

I'm not sure I'm aware of what I'm doing. Any comments or suggestions will be appreciated. $ cat java7 #!/bin/sh alternative=java-7-oracle sudo update-java-alternatives -s $alternative export JAVA_HOME=/usr/lib/jvm/$alternative $ cat java8 #!/bin/sh alternative=java-8-oracle sudo update-java-alternatives -s $alternative export ...


0

I spoke with my system administrator and he suggested that the terminal session somehow inherits the environment variable from the current login process/session(?) and recommended I completely log out and log back in again (which I desperately wanted to avoid doing as I have a lot of important terminal sessions in various workspaces I didn't want to waste ...


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


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


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.


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

sudo just executes a command as another user. As a result current environment is used. However su changes user ID or become superuser. If you haven't set a password to root user, you run sudo su in order to become superuser. And when you become superuser, naturally environment is changed.


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.


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


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


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.


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.


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


0

Please have a look at man bash section FILES where the difference is explained on bash_profile and bashrc: ~/.bash_profile The personal initialization file, executed for login shells ~/.bashrc The individual per-interactive-shell startup file It looks like you are starting a new shell and that the entries you've put in ...


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


0

In your script, these two lines close to the top should do the trick: LD_LIBRARY_PATH="$(pwd)/lib" export LD_LIBRARY_PATH Although bash allows you to set and export a variable in a single statement, not all shells do, so the two step approach is more portable, if that's a concern. If this isn't working for you, check that you are running the script from ...


0

you should execute you program in this way: LD_LIBRARY_PATH=$(pwd)/lib/ <your_executable_here>


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


0

Please see http://askubuntu.com/a/614714/398785 for my detailed answer on why I think TERM=xterm-color is the wrong approach and Ubuntu's .bashrc is obsolete. I recommend that you go with TERM=xterm-256color (which is the default since gnome-terminal 3.16, but also safe to use with older gnome-terminals), and adjust your .bashrc accordingly.


0

Yes: $ export TEST=`script.py` $ echo $TEST 5 You need to tell the shell to set test to the result of running script.py, which is what the backticks do for you. There are alternate shell constructs that will do the same thing, like $(script.py), but I almost always use backticks.



Top 50 recent answers are included