This question already has answers here:
Changing PS1 prompt in a Bash parent shell
(3 answers)
Closed 6 years ago.
I wanted to write a tiny shell script that shortens the commmand prompt when it gets too long. Setting the PS1 variable in bash works fine. When I try the same command directly in a script and run it, nothing happens.
#!/bin/bash
PS1='\u:\W\$ '
I tried eval "PS1='\u:\W\$ '" , export PS1='\u:\W\$ ' and exec PS1='\u:\W\$ ' without any result.
How can I achieve the same result as a direct input in the bash?
Thank you in advance
In general, in UNIX, a process can only change variables for itself and its children -- not its parent ("its parent" being the process that invoked it).
You need to source a script, not execute it, for it to be able to effect your interactive shell's variables. This executes all commands inside the script inside your current shell, not a new shell started as a child process (whose variables' values are thrown away on exit).
# in bash
source yourscript
# or in POSIX sh
. yourscript # mind the space!
In this usage, the shebang does nothing; similarly, the +x permission isn't needed either. It's also typical to name scripts intended to be sourced rather than executed with an extension mapping to the shell they're intended to be used by (yourscript.bash for bash, yourscript.sh for a script which can be sourced by any POSIX shell), whereas scripts intended to be executed rather than sourced should have no extension.
Related
This question already has answers here:
Can I export a variable to the environment from a Bash script without sourcing it?
(13 answers)
Closed 3 years ago.
I have created a virtual environment on my debian system and i made a script that activates it (should).
However when i execute the script nothing shows up, not even an error, my guess is that it is running in a different shell or something but I don't know how to solve it.
Here is the code of the script
#!/bin/bash
source ~/PythonEnv/environments/my_env/bin/activate
I have changed the permissions already with chmod u+x, so that is not a problem.
When i execute the script nothing shows up at all. Any thoughts???
Add set -x at the beginning of your bash script will do the trick.
-x Print commands and their arguments as they are executed.
You can see more bash options here
http://linuxcommand.org/lc3_man_pages/seth.html
Adding x-permissions is not necessary, since you are using source with an absolute path. Of course this sets the environment only which is executed by the shell script which you have posted here. If you want the changes in your interactive shell, it is pointless to do it inside a script. You have to source the activate script in your shell (respectively inside that process where you want the environment to be modified).
This question already has answers here:
Why can't I change directories using "cd" in a script?
(33 answers)
Closed 6 years ago.
I am new to bash scripting. This might be obvious to many. please bear with me.
I have a shell script as follows:
#!/bin/bash
echo `pwd`
cd /home/foo/bar
echo `pwd`
Let's say I am currently in dir : /home/foo1
If I execute the above script it prints:
/home/foo1
/home/foo/bar
But once the script completes execution, I have seen that it still remains in dir /home/foo1
I have also seen some scripts where there are explicit commands to reset the working dir using 'cd -' command.
If bash executes all the lines in the script as commands, why does it again reset the working dir?
When you are running an interactive session of bash, and from it, you execute a script (e.g. ./myscript.sh), then bash creates a new bash process to execute the script. Initially, that process get copy of the same environment as the original process (e.g. the current working directory, or environment variables), but if the script modifies the environment somehow, this changes only affect the new process, not the original one. So when the scripts exits, you go back to the original process which retains the original environment. So it is not possible to modify the current directory of the original shell from a script.
As a side note, the following line
echo `pwd`
does not make much sense. You either have to do echo $PWD or simply pwd.
This question already has answers here:
What is the difference between "./somescript.sh" and ". ./somescript.sh"
(4 answers)
Closed 8 years ago.
What I know is when I am having two script files lets say a.sh and b.sh and to use the variable or function defined in script a.sh, then . ./a.sh works but ./a.sh doesn't works. While running a shell script both ./script.sh and . ./script.sh works fine. What is the difference between running a script with ./script.sh and . ./script.sh?
. path/to/script sources the file (executes it in the same shell). The other call forks a new shell process which executes the script.
Invoking a script in a child process will make its variables not available to the parent process. Sourcing a script will introduce and change variables in the same parent process.
The notation . ./a.sh is short for source ./a.sh. source is a built-in command of the executing shell to read the given file line-by-line and execute all that is written there as if it was typed in the shell directly. As a consequence, if there is an exit statement in a.sh, it will close the shell which sources this; typically, the xterm window closes then.
The notation ./a.sh, however, starts a new process; this is done by the current shell forking itself and then making the forked child executing the given program. This is, in this case, a shell script again, so a new shell will be executed. Everything this new shell does will not influence the original (parent) shell. If the child is not sent to the background, the parent then waits for the child to terminate.
This question already has answers here:
How to Share ENV Variables Among Perl Scripts
(2 answers)
Closed 5 years ago.
I am trying to set an environment variable, LD_LIBRARY_PATH, through a Perl script in the following way:
I have created .profile under /root
.profile has an export command say:
export LD_LIBRARY_PATH=/
My Perl script is test.pl and it has:
#!/usr/bin/perl
system(". /root/.profile");
When I execute ./test.pl, LD_LIBRARY_PATH doesn't change.
What am I doing wrong?
Your current script doesn't even change an environment variable in the Perl script itself. Rather, it invokes a shell as a subprocess; that shell process executes . /root/.profile, which updates $LD_LIBRARY_PATH only in that shell process.
You can change an environment variable in a Perl script (more precisely, in the process running the Perl script) by updating %ENV:
$ENV{LD_LIBRARY_PATH} = '/'; # or some more reasonable value
As perldoc -v %ENV says:
%ENV The hash %ENV contains your current environment. Setting a value in "ENV" changes the environment for any child processes you subsequently "fork()" off.
But that probably still won't do what you want; it won't (and can't) affect the environment of the process that invokes the Perl script (your interactive shell), only the Perl process itself and anything it invokes.
I'll assume you want to update $LD_LIBRARY_PATH in your current interactive shell process. To do that, you can have you Perl script print a shell command that will update $LD_LIBRARY_PATH. Then, rather than simply running your Perl script, you can execute it and then evaluate its output. For example:
$ cat env.pl
#!/usr/bin/perl
use strict;
use warnings;
print "export LD_LIBRARY_PATH=/\n";
$ ./env.pl # just prints the command without executing it
export LD_LIBRARY_PATH=/
$ eval $(./env.pl) # executes the command in the current shell
$ echo $LD_LIBRARY_PATH
/
$
This assumes that your current shell is bash or something similar.
Another option: After modifying %ENV, your Perl script can invoke another command, even a new interactive shell. The new process will inherit its environment from the Perl script. This can be a bit cumbersome, though; for example, if the new process is an interactive shell, it won't inherit unexported variables or history from the parent shell.
(One note, not directly related to your question: The fact that you're messing with /root/.profile implies that you're doing things as root (superuser). This can be dangerous. Use the root account (either by logging into it or via sudo only for things that actually need root privileges. For anything else, use a personal user account.
To change the environment in a Perl script, assign to the %ENV hash:
$ENV{'LD_LIBRARY_PATH'} = '/';
If you want to write a program that's used by a shell to change its environment, the way this is generally done is to have the script write shell commands to stdout. The shell then executes this with command substitution and uses eval to execute the resulting commands:
Perl script:
#!/usr/bin/perl
print 'LD_LIBRARY_PATH=\n';
Shell script:
eval "$(/path/to/perlscript)"
For examples of commands that work like this, see tset and ssh-agent.
system starts a new process, and changing the environment there won't affect the environment in the process of your script (usually—there are generally os-dependent means of changing other processes' environments).
The environment in a perl program is associated with %ENV, which is kind of like (it isn't actually) a tied hash to the environment: changing it will change the environment. Thus:
$ENV{LD_LIBRARY_PATH} = '/';
This can now be done with the Env::Modify module:
use Env::Modify 'source';
source("/root/.profile");
... env settings of .profile are now available to Perl ...
You can't do it.
This is from the Perl FAQ:
In the strictest sense, it can't be done--the script executes as a different process from the shell it was started from. Changes to a process are not reflected in its parent--only in any children created after the change. There is shell magic that may allow you to fake it by eval()ing the script's output in your shell; check out the comp.unix.questions FAQ for details.
Recently I have been asked a question. What are the different ways of executing shell script and what is the difference between each methods ?
I said we can run shell script in the following methods assuming test.sh is the script name,
sh test.sh
./test.sh
. ./test.sh
I don't know the difference between 1 & 2. But usually in first 2 methods, upon executing, it will spawn new process and run the same. Whereas in the last method, it won't spawn new process. Instead it runs in the same one.
Can someone throw more insight on this and correct me if I am wrong?
sh test.sh
Tells the command to use sh to execute test.sh.
./test.sh
Tells the command to execute the script. The interpreter needs to be defined in the first line with something like #!/bin/sh or #!/bin/bash. Note (thanks keltar) that in this case the file test.sh needs to have execution rights for the user performing this command. Otherwise it will not be executed.
In both cases, all variables used will expire after the script is executed.
. ./test.sh
Sources the code. That is, it executes it and whatever executed, variables defined, etc, will persist in the session.
For further information, you can check What is the difference between executing a bash script and sourcing a bash script? very good answer:
The differences are:
When you execute the script you are opening a new shell, type
the commands in the new shell, copy the output back to your current
shell, then close the new shell. Any changes to environment will take
effect only in the new shell and will be lost once the new shell is
closed.
When you source the script you are typing the commands in your
current shell. Any changes to the environment will take effect and stay in your current shell.