I have a program that was installed under "/home/user" and whose commands ONLY work if I execute them from the command line like so:
root#server:~# su - user
user#server:~# command
However, I am trying to script these commands like so:
su - user -c 'command'
Although the script executes and command is 'run", parts of the program do not work correctly.
I made sure the $PATH variable was the same between "root" and "user", and added a couple environmental variables that were in /home/user/.profile to the root one. Still, something is missing.
What is special about "su - user" from command line vs in a script, and how can I account for what's missing?
I cannot say for sure what is different in the hidden parts of your command. But I would like to point out things that may help:
Consider the difference between single and double quotas: 'command' and "command". The latter will expand content: http://www.howtogeek.com/howto/29980/whats-the-difference-between-single-and-double-quotes-in-the-bash-shell/ So if I write in my shell su - myname -c 'echo $PATH', I see a very different path than with su - myname -c "echo $PATH".
Try to find out more by "debugging" like su - myname -c "echo SHOW_ME_SOMETHING". Maybe you can observe subparts of your command working differently.
Handling of the path is tricky, meaning there is login emulating with different reset states on different systems. Have a look here: https://superuser.com/questions/193277/what-happens-to-the-environment-when-you-run-su-c
Hope this helps.
Related
In the root folder of my project next to main.tf, I have a script called load_env.fish containing these two lines:
set -U AWS_SHARED_CREDENTIALS_FILE "~/path/to/file"
set -U AWS_PROFILE "my_profile"
I run that, then I run the command terraform import foo bar. It gives me Access Denied.
However, if I use bash instead of fish, and I set up the same environment variables, then terraform import foo bar works.
And I can even get it to work in fish if I do this:
from bash, set up environment variables
start the fish shell from bash
now in the fish shell, run terraform import foo bar
So,
Why does it work if I use bash and not fish? And why does it work in fish if the fish shell is opened from a bash shell that has the correct environment variables set?
How can I use terraform in the fish shell without having to open nested bash and fish shells?
Universal variables are shared between all fish sessions, but they are not automatically exported to subprocesses.
I simply changed all instances of set -U ... to set -Ux ... and everything worked.
EDIT: After seeing KurtisRader's comment concerning the downside of set -Ux and reading a bit more, I realize now that fish has the source command just like bash. So, inside the script I can just use
set -x foo bar
Then I can
$ source load_env.fish
instead of just
$ ./load_env.fish
When using bash, if I have an environment variable called SOMEPATH which contains a path (e.g. SOMEPATH=/usr/local/lib), then if I type
ls $SOMEPATH/
and hit tab then bash expands the environment variable so my command line now says
ls /usr/local/lib/
If I do the same thing in zsh it instead escapes the $ sign so after tab completion the command line looks like
ls \$SOMEPATH
How can I get zsh to behave like bash does in this regard?
I've done a lot of googling but I haven't managed to find anything that exactly addresses this issue. I've also tried reading the zsh documentation but again I couldn't find anything that obviously relates to this.
Thanks for any pointers.
Let us say that I have environment variable PO, with value 1.If I use the LINUX echo command I get:
>echo $PO
1
However, if I use TCL and exec, I do not get interpolation:
>exec echo "\$PO"
$PO
Now, if I do something more elaborate, by using regsub to replace every ${varname} with [ lindex array get env varname ] 0 ], and use substr, it works:
>subst [ regsub -all {\$\{(\S+?)\}} "\${PO}/1" "\[ lindex \[ array get env \\1 \] 1 \]" ]
1/1
I have some corner cases, sure. But why is the exec not giving back what the shell would do?
why is the exec not giving back what the shell would do?
Because exec is not a shell.
When you do echo $PO from a shell, echo is not responsible for resolving the value. It is the shell that converts $PO to the value 1 before calling echo. echo never sees $PO when calling it from the shell.
If you are trying to emulate what the shell does, then you need to do the same work as the shell (or, invoke an actual shell to do the work for you).
Tcl is a lot more careful about where it does interpolation than Unix shells normally are. It keeps environment variables out of the way so that you don't trip over them by accident, and does far less processing when it invokes a subprocess. This is totally by design!
As much as possible (with a few exceptions) Tcl passes the arguments to exec through to the subprocesses it creates. It also has standard mechanisms for quoting strings so that you can control exactly what substitutions happen before the arguments are actually passed to exec. This means that when you do:
exec echo "\$PO"
Tcl is going to do its normal substitution rules and get these exact arguments to the command dispatch: exec, echo, and $PO. This then calls into the exec command, which launches the echo program with one argument, $PO, which does exactly that. (Shells usually substitute the value first.) If you'd instead done:
exec echo {$PO}
you would have got the same effect. Or even if you'd done:
exec {*}{echo $PO}
You still end up feeding the exact same characters into exec as its arguments. If you want to run the shell on it, you should explicitly ask for it:
exec /bin/sh -c {echo $PO}
The bit in the braces there is a full (small) shell script, and will be evaluated as such. And you could do this even:
exec /bin/sh -c {exec echo '$PO'}
It's a bit of a useless thing to do but it works.
You can also do whatever substitutions you want from your own code. My current favourite from Tcl 8.7 (in development) is this:
exec echo [regsub -all -command {\$(\w+)} "\$PO" {apply {- name} {
global env
return $env($name)
}}]
OK, total overkill for this but since you can use any old complex RE and script to do the substitutions, it's a major power tool. (You can do similar things with string map, regsub and subst in older Tcl, but that's quite a bit harder to do.) The sky and your imagination are the only limits.
I'm trying to write (what I thought would be) a simple bash script that will:
run virtualenv to create a new environment at $1
activate the virtual environment
do some more stuff (install django, add django-admin.py to the virtualenv's path, etc.)
Step 1 works quite well, but I can't seem to activate the virtualenv. For those not familiar with virtualenv, it creates an activate file that activates the virtual environment. From the CLI, you run it using source
source $env_name/bin/activate
Where $env_name, obviously, is the name of the dir that the virtual env is installed in.
In my script, after creating the virtual environment, I store the path to the activate script like this:
activate="`pwd`/$ENV_NAME/bin/activate"
But when I call source "$activate", I get this:
/home/clawlor/bin/scripts/djangoenv: 20: source: not found
I know that $activate contains the correct path to the activate script, in fact I even test that a file is there before I call source. But source itself can't seem to find it. I've also tried running all of the steps manually in the CLI, where everything works fine.
In my research I found this script, which is similar to what I want but is also doing a lot of other things that I don't need, like storing all of the virtual environments in a ~/.virtualenv directory (or whatever is in $WORKON_HOME). But it seems to me that he is creating the path to activate, and calling source "$activate" in basically the same way I am.
Here is the script in its entirety:
#!/bin/sh
PYTHON_PATH=~/bin/python-2.6.1/bin/python
if [ $# = 1 ]
then
ENV_NAME="$1"
virtualenv -p $PYTHON_PATH --no-site-packages $ENV_NAME
activate="`pwd`/$ENV_NAME/bin/activate"
if [ ! -f "$activate" ]
then
echo "ERROR: activate not found at $activate"
return 1
fi
source "$activate"
else
echo 'Usage: djangoenv ENV_NAME'
fi
DISCLAIMER: My bash script-fu is pretty weak. I'm fairly comfortable at the CLI, but there may well be some extremely stupid reason this isn't working.
If you're writing a bash script, call it by name:
#!/bin/bash
/bin/sh is not guaranteed to be bash. This caused a ton of broken scripts in Ubuntu some years ago (IIRC).
The source builtin works just fine in bash; but you might as well just use dot like Norman suggested.
In the POSIX standard, which /bin/sh is supposed to respect, the command is . (a single dot), not source. The source command is a csh-ism that has been pulled into bash.
Try
. $env_name/bin/activate
Or if you must have non-POSIX bash-isms in your code, use #!/bin/bash.
In Ubuntu if you execute the script with sh scriptname.sh you get this problem.
Try executing the script with ./scriptname.sh instead.
best to add the full path of the file you intend to source.
eg
source ./.env instead of source .env
or source /var/www/html/site1/.env
whenever I switch directory in my terminal, I have to run the command "/bin/bash --login" before I can run rails/rake related commands. If I don't, I get an error saying "the program "rails" can be found in the following packages: ..."
Any advice?
By default some servers do not allow this due to permissions reason. You can place this in
~/.bashrc and it will automatically work when you open a new terminal
As per bash man page.
When an interactive shell that is not a login shell is started, bash
reads and executes commands from ~/.bashrc, if that file exists. This
may be inhibited by using the --norc option. The --rcfile file option
will force bash to read and execute commands from file instead of
~/.bashrc.
When bash is started non-interactively, to run a shell script, for
example, it looks for the variable BASH_ENV in the environment,
expands its value if it appears there, and uses the expanded value as
the name of a file to read and execute. Bash behaves as if the
following command were executed:
if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi but the value of the
PATH variable is not used to search for the file name.
The file is just shell commands. It is typically used to change prompts, set environment variables, and define shell procedures. Traditionally, the file .profile is used for this purpose, but bash has so many extensions that it needs its own startup file for users that want to put bashisms in startup files.
Easy solution:
Just open terminal. GO to Edit menu from terminal navigation bar, Select "Profile Preferences", It will open "edit profile pop-up". Select "Title and Command" button and "check Run Command as login shell"
ctrl + alt + t -> Edit -> Profile Preferences -> Title and Command -> Check Run command as login shell
Close the terminal and open again. Next time you don't need to "/bin/bash --login"