I have the following script in ~/bin/ in order to override the default command for gnome-terminal:
#!/usr/bin/env bash
XDG_CONFIG_HOME=~/.config/darkthemesettings /usr/bin/gnome-terminal
I am trying to make the XDG_CONFIG_HOME variable only get seen by gnome-terminal, but in terminal that appears, if I run any other program, the variable is also set in that program. Running echo $XDG_CONFIG_HOME from the terminal gives
/home//.config/darkthemesettings
I understood that if one sets an environment variable without using export, that variable is only available in the script that sets it, not in any child processes. Am I incorrect? How can I achieve what I want here? Thanks
You can use env to unset the variable for the command run inside the terminal, like this:
XDG_CONFIG_HOME=~/.config/darkthemesettings gnome-terminal -x env -u XDG_CONFIG_HOME bash
The assignment XDG_CONFIG_HOME=~/.config/darkthemesettings before the command gnome-terminal sets the variable for the terminal. The terminal will run the arguments after the -x option as shell command. That shell command bash is prefixed by env -u XDG_CONFIG_HOME which unsets the variable in the environment for running bash.
Your understanding is incorrect. Without export they are bash variables. export "promotes" them to environment variables.
You will need to have gnome-terminal run a script that unsets the variables before running the shell.
Related
I have a bash script where I am trying to use values of some environment variables. Those variables are defined - I see the keys and values if I run printenv.
Also, these variables are defined and exported like
export FOO="bar"
in both ~/.bash_profile and ~/.bashrc.
I am trying to execute the script via ./script-name which fails to get the environment variables. If I run sudo -E ./script-name, that somehow gets the script the variables it needs.
Confused as to why these variables aren't available to the script even when they are exported in above files.
The only thing I can think of, is that for some reason, the shell process which you are calling to run the script, does not have full read access to your current environment.
ls -al /usr/bin/bash
ls -al /bin/sh
Assuming neither of them are symlinks, make sure that your current user has read and execute priveleges. A safer (in security terms) option, would be for you to install bash in ~/opt, and use #!~/opt/bin/bash as your shebang line.
I've searched for an answer and read about different ways to do that in Mac but some of them are not relevant for Mojave or just didn't work for me.
I need to set Environment variable in terminal (bash), run script that creates processes, and I would like those processes to know the value of those environment variables.
How can I do that?
btw - writing export ENV_NAME=ENV_VAL in .bashrc or in .bash_profile didn't work.
Works for me. Have you RTFM? For example, ~/.bashrc is only read by interactive shells, not shell scripts. And ~/.bash_profile is only read by login shells. Again, shell scripts don't usually use the -l flag that would make them login shells. Also, if you put an export VAR=value statement in your ~/.bashrc it won't affect your current interactive shell. You need to start a new shell; e.g., by typing exec bash. Once you do that you should find the env var is defined. And it will be inherited by any process, including a shell script, you launch from that interactive session.
Note that if you run your script via crontab, for example, then you'll need a different means of setting the env var. For example, by using the --init-file flag or the BASH_ENV env var.
ksh
export name="bhargav"
csh setenv name bhargav
Trying like this and from windows Iam using plink command to get the variable value. But it showing the error undefined variable
For the target-user, does Linux have bash or ksh as the shell for that user? If Linux is configured with bash as the shell, then ensure that the ~/.bashrc exports that variable. If Linux is configured with ksh as the shell for the user account (instead of bash), try exporting the variable in ~/.profile
I am trying to set an environment variable for Bash. However, I need this to be set before any of the shell's startup scripts (including /etc/profile), because /etc/profile acts differently based on the value of this variable.
Specifically, I want to create a shortcut to MinTTy that works like git-bash, but I need to set the MSYSTEM environment variable before the shell starts, or at least before it starts processing any startup scripts.
A solution that has MinTTy setting the environment variable before it starts the shell will also be accepted.
Edit:
What I am really looking for is sort of a command-line option to BASH that will set an environment variable, somewhat akin to the -D option to most C (and other) compilers. This would be a "general case" solution. Alternatively, a similar option (command line or configuration) to MinTTy will also do the job.
For my specific need, I have an idea for a potential work-around: Run a BASH script - with no startup scripts - that sets my required variable and execs another shell as a login shell.
Define the target of your shortcut file as follows:
C:\cygwin64\bin\mintty.exe /bin/bash -l -c "MSYSTEM=MINGW64 exec -l bash"
This command:
invokes bash directly as a login shell (-l)
passes it a command (-c) that defines the environment variable of interest (MSYSTEM=MINGW64) and then invokes a new copy of bash (exec -l bash), which inherits the existing environment, plus the new definition, but sources the profile(s) again, due to -l
(and prepends - to the executable name reported in $0 (-bash), as would happen if you started Mintty with just -, which is what the regular Cygwin64 Terminal shortcut does).
An alternative is to set the environment variable in Windows first.
[Not an option for the OP] If the environment variable should always have the same value, set it persistently as follows: run sysdm.cpl, go to the Advanced tab, click on Environment Variables... and define variable MSYSTEM as needed.
To define the variable ad-hoc, create a batch file as follows and make the shortcut target that batch file:
#echo off
# Define the env. variable with the desired value.
set "MSYSTEM=MINGW64"
# Invoke Mintty with a login shell, which will now see the env. variable.
# Adjust the path to mintty.exe as needed.
c:\cygwin64\bin\mintty.exe -
Note: Opening the batch file from a shortcut briefly opens a regular console window before opening Mintty, which may be undesired.
A simple helper WSH script, as demonstrated in this answer of mine, can prevent this.
You should just be able to do the same as you do in command prompt. Therefore, you can do:
set VAR=VarContents
Although I already accepted an answer above, I found this link that specifically addresses the second part of my question (Mintty specific) or an alternative way of setting an environment variable before running a command.
The contents of the Windows shortcut can be:
C:\cygwin64\bin\mintty.exe -t "Title" /bin/env "MSYSTEM=MINGW64" /bin/bash -l
(Suggested by Mintty Tips:Setting environment variables.)
I have a strange situation where I'm using zsh full-time, and any bash scripts I run are not picking environment variables properly. Obviously I don't expect bash to pick up env vars that are defined in zsh's environment, so I am using ~/.bashrc and ~/.bash_profile, but that doesn't work either.
For example, here's a test script:
#!/bin/bash
echo $MYTEST
I've added this line to both ~/.bashrc and ~/.bash_profile to cover my bases:
export MYTEST="hello"
I just get a blank line when running the script.
PS: I know running . ./testscript will work, but that's not an option since it's a system-wide script that's failing to pull env vars.
Oops. Maybe I should try having export VAR=val in my ~/.oh-my-zsh/custom/vars.zsh instead of just VAR=val!