Is there a way to launch a gnome-terminal from the command line (i.e., using the /usr/bin/gnome-terminal command) and have the new terminal inherit the environment variables and other set variables of terminal from which the command was run? The scenario is thus:
Open a terminal
Set some variables
Set some environment variables
Launch an executable that needs the variables and the environment variables of the current terminal in a new terminal
Thoughts?
This turned out to be a gnome-terminal issue. When launching the gnome-terminal, specifying the --disable-factory option provides the following directive:
"Do not register with the activation name server, and do not reuse an already running GNOME terminal process" (gnome-terminal man page)
Specifying this option was required in order to inherit the environment of the previous shell.
You need to use export against the variables in the other shell if you want child processes to inherit them.
Related
I am new in AWS
I am using an Ubuntu server and I use export in the shell to set environmental variables.
export mykey=value
But when I close the shell and relogin I see that mykey does not available the environmental variable. As far as I search in the net, such way of setting will expire directly after shell is closed. How could I have a permanent environmental variable in AWS then?
Thanks
You could edit the ~/.bashrc file by adding export mykey=value command to have it every time the shell reloads. Environmental variables are not saved when you exit all the instances of the shell. But everytime shell opens, it reads the bashrc file, if you are in a bash shell. For zsh, it would be ~/.zshrc for example.
I open two terminals.
In first terminal:
export CLASSPATH="abc"
printenv CLASSPATH ---> output is abc
then in second terminal:
printenv CLASSPATH ---> no output
why in second terminal I dont have the variable?
It's not going to work because each program inherits environment, that
is a list of environment variables and their values from their parent
process. Environment is not automatically propagated to all other
programs on the system but is only inherited by children of the given
program. To set a global environment that would work in all newly
opened terminals you need set it in the file that is sourced each time
you open the terminal. What file would that be depends on what shell
you use and your system local setup. For example, if you use bash you
should put export CLASSPATH="abc" in ~/.bashrc.
For accessing global variable you need to put $ before it. Are you doing that?
try echo $CLASSPATH
I think you will find this helpful.
Right now, when I log in to Tmux, only ~/.bash_profile gets loaded.
I'd like ~/.bashrc to get called instead.
Is that possible?
You can fix that at the tmux level by explicitly setting the default shell command:
tmux set-option default-command "/bin/bash"
From the tmux manual (emphasis mine):
default-command shell-command
Set the command used for new windows (if not specified
when the window is created) to shell-command, which may
be any sh(1) command. The default is an empty string,
which instructs tmux to create a **login shell** using the
value of the default-shell option.
default-shell path
Specify the default shell. This is used as the login
shell for new windows when the default-command option is
set to empty, and must be the full path of the exe‐
cutable. When started tmux tries to set a default value
from the first suitable of the SHELL environment vari‐
able, the shell returned by getpwuid(3), or /bin/sh.
This option should be configured when tmux is used as a
login shell.
As explained by Chepner in a comment below:
default-shell defaults to your preferred login shell;
default-command defaults to starting a login instance, effectively
$SHELL -l
... and in the case of Bash, a login shell doesn't read ~/.bashrc. By overriding the value of default-command, we can now force tmux to create a non-login shell instead.
This issue is not related to tmux. To solve it make sure to add source ~/.bashrc to .bash_profile and that's it.
You can learn more about bash initialization and which files it loads and in which order here: https://github.com/sstephenson/rbenv/wiki/Unix-shell-initialization#bash
As you can see .bashrc is not even on the list when bash is started in login mode, that's why we source it from the file (.bash_profile) that is on the list.
I want to put below declare in a shell script: proxy_set
declare -x https_proxy="https://192.168.220.4:8080/"
And then I execute it like below.
$ ./proxy_set
But "export" shows nothing happened.
And in another way if I execute it like this:
$ source proxy_set
Then "export" shows it works!
My question is how can I make it work without additional "source" cmd?
Thanks!
You can't. Setting variables in the environment only affects the environment of that shell and any future children it spawns; there's no way to affect the parent shell. When you run it without the source (or .), a brand new shell is started up, then the variable is set in that shell's environment, and then that shell exits, taking its environment with it.
The source reads the commands and executes them within the current shell as if you had typed them.
So if you want to set environment variables in a script, you have to source it. Alternatively, you can have a command generate shell commands as output instead of running them, and then the parent can evaluate the output of the command. Things like ssh-agent use this approach.
Try just adding:
export https_proxy="https://192.168.220.4:8080/"
Then execute your script normally.
I'm trying to interactively test code before I put it into a script and was wondering if there are any things that behave differently in a script?
When you execute a script it has its own environment variables which are inherited from the parent process (the shell from which you executed the command). Only exported variables will be visible to the child script.
More information:
http://en.wikipedia.org/wiki/Environment_variable
http://www.kingcomputerservices.com/unix_101/understanding_unix_shells_and_environment_variables.htm
By the way, if you want your script to run in the same environment as the shell it is executed in, you can do it with the point command:
. script.sh
This will avoid creating a new process for you shell script.
A script runs in exactly the same way as if you typed the content in at a shell prompt. Even loops and if statements can be typed in at the shell prompt. The shell will keep asking for more until it has a complete statement to execute.
As David rightly pointed out, watch out for environment variables.
Depending on how you intend to launch your script, variables set in .profile and .bashrc may not be available. This is subject to whether the script is launched in interactive mode and whether it was a login shell. See Quick Startup File Reference.
A common problem I see is scripts that work when run from the shell but fail when run from another application (cron, nagios, buildbot, etc.) because $PATH was not set.
To test if a command/script would work in a clean session, you can login using:
ssh -t localhost "/bin/bash --noprofile --norc"
This ensures that we don't inherit any exported variables from the parent shell, and nothing from .profile or .rc.
If it works in a clean session and none of you're commands expect to be in interactive mode, then you're good to go!