Tag Info

Hot answers tagged

26

As you stated in your question, the main difference is the environment. sudo su - vs. sudo -i In case of sudo su - it is a login shell, so /etc/profile, .profile and .bashrc are executed and you will find yourself in root's home directory with root's environment. sudo -i is nearly the same as sudo su - The -i (simulate initial login) option runs the shell ...


8

To answer your question directly: no, there is no good reason to do this. Also, sudo su produces two log entries when one would suffice. I've seen many people do this, and when I ask why they don't just run sudo -s, the answer is just that they don't know about the -s flag to sudo, and generally they switch after I point it out. However, to your list of ...


5

Your /etc/bashrc sets PATH by interpreting $JAVA_HOME's value at that moment. It does not get re-interpreted if JAVA_HOME changes later. You'll want to add a line to the 3rd-party shell script that says: PATH=$JAVA_HOME:$PATH so that the 1.7 JAVA_HOME is put into the path before the /etc/bashrc's 1.8 JAVA_HOME.


2

The following command export $PATH=somePath will return not a valid identifier and that is because of the $ before the PATH variable. solution: export PATH=somePath


2

systemd does its own minipalistic shell-style command line parsing of the contents of ExecStart= and other parameters. This minimalistic parsing supports basic environment variable substitution but apparently not things like ${PORT:+port is $PORT}. You will want to prevent systemd from doing that and let the invoked shell handle it. From the documentation: ...


1

Replace echo $branch by echo ${!branch} in your first example.


1

On popular distributions: $ which sh /bin/sh $ readlink -f /bin/sh /bin/dash Or more compact: $ readlink -f $(which sh) /bin/dash However, some (especially embedded systems or initrd builds) have their shell directly compiled as /bin/sh or it's a hardlink (busybox)


1

You can change the settings in /etc/environment which contains a definiton of the $PATH variable, or add an entry to the system-wide bashrc ( /etc/bash.bashrc which is not as universal as changing the environment setting (i.e. only for bash and if the system-wide bashrc is actually loaded).


1

An environment variable is passed to a script. The problem is that COLUMNS is not an environment variable. From a script, you can call a command such as tput to retrieve the terminal dimensions. width=$(tput cols) </dev/zero head -c "$width" | tr '\0' '-'; echo (This script may not be portable beyond Linux.)


1

This is a follow-on to your previous question and we're getting to what it is you want to do. I'm quite sure others have their own styles for this, but perhaps this will get you started. #!/bin/bash SCREEN_WIDTH=`stty size | awk '{print $2}'` echo $SCREEN_WIDTH That echo isn't what you are trying to do, just to demonstrate we've put the value somewhere ...


1

You might try to export COLUMNS See this for an explanation. But you should tell us how is the script called. If it is started by some crontab, it is likely to be executed in an environment without COLUMNS. You might use printenv to check.


1

You need to set default-command: set -g default-command /usr/local/bin/zsh default-shell variable only use to create a login shell, when default-command is empty - which is default value. Or you can simply change your default shell to zsh, in this case, tmux will start a login shell, instead of non-login shell.


1

I know I'm a little late to the party, but to undo exported environment variables, you can use the env command env -i zsh env runs the command given as an argument, and -i gives it a clean environment. Hope that helps someone!


1

Since there don't seem to be any environments where vi or similar would fail, I've taken to setting VISUAL to something that needs an X DISPLAY, and EDITOR to ex. Mostly, that just seems to cause me problems when some program doesn't use VISUAL.



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