So I am trying to set environment variables using my shell Script. The script takes some inputs from the user and then i have to set those inputs in the environment variable. I am using two shell Script for the same but i am getting permission denied errors.
Script 1
DEFAULT_NAME="sample"
read -p "Enter your Name: [$DEFAULT_NAME]: " USER_NAME
if [ -z "$USER_NAME" ]
then
USER_NAME=$DEFAULT_NAME
else
USER_NAME=$USER_NAME
fi
source setEnv.sh
Script 2
echo -e "export NAME=${USER_NAME}" >> /etc/profile.d/nameenv.sh
First, the if condition in Script 1 is wrong, you probably want to test $USER_NAME instead.
If you are using bash, you can replace the whole if statement with:
USER_NAME=${USER_NAME:-$DEFAULT_NAME}
In Script 2 are you sure that you want to append a new line to /etc/profile.d/nameenv.sh, every time you execute the script? The last declaration will hide the preceding ones.
Finally, note that you need root privilege to write in /etc/profile.d. Are you running the script as a privileged user?
[Edit] Trying to guess what you are trying to do here. If you need that USER_NAME is redefined for the user's current session (and not system-wide), just replace the last line in Script 1 with:
export USER_NAME
and remove Script 2. If you want to make it permanent (again, for the current user only), modify Script 2 to write the variable declaration in ~/.bash_profile instead.
Related
I am trying to create three BASH scripts to help organize my terminals and workspace on my VM.
Below are the commands that I wish to have parameterized.
1) How to rename the title of a terminal window:
PS1='\[\e]0;TERMINAL NAME\a\]${debian_chroot:+($debian_chroot)}\u#\h:\w\$ '
2) To change the number of workspaces:
gsettings set org.gnome.desktop.wm.preferences num-workspaces "5"
3) To rename the name of Workspaces:
gsettings set org.gnome.desktop.wm.preferences workspace-names "['IntelliJ', 'Cloud Discovery', 'Full Stack', 'Simulators', 'Misc']"
It's been a little while since I have done BASH scripting and I am forgetting how to run a console command via a BASH script.
My initial attempts have all failed. Here is the code that I am written most recently:
#!/bin/bash
export cmd="PS1='\[\e]0;$1\a\]${debian_chroot:+($debian_chroot)}\u#\h:\w\$ '"
echo {$cmd}
./setNewTermName MyName
But when I run the script as above, it is not renaming the terminal. However, when I run the PS1 command above directly on the command like (substituting in the actual name), it works.
Any ideas on what I am doing wrong?
You need to define a local variable that will get the value of the title as an argument as under. Then you will use that local variable (title in this case) in your PS1 variable.
Then, in order to run the script, you need to "source" the script in the current shell so that the variable in the script are visible to the parent shell.
#!/bin/bash
title=$1;
PS1='\[\e]0;${title}\a\]${debian_chroot:+($debian_chroot)}\u#\h:\w\$ '
So, instead of running the script as
./setNewTermName MyName
Run without the / as under. Notice the space after the period:
. setNewTermName MyName
Or as:
source setNewTermName MyName
I have an bash script that will run db2 command (list active databases) and redirect the output to a file then I will use this file in another script.
Script:
/DB2RM1/db2rm1/sqllib/bin/db2 list active databases > /home/occddma/scripts/data
Note: I have put the location to the binaries of db2 before the db2 command to able to run it from crontab.
Then I put the script in crontab job to update datadb file every minute as shown below.
* * * * * /DB2RM1/db2rm1/mon_db2.sh
When I run the script form the command line it works fine but when it runs from the crotab job it redirects the below error to datadb file.
SQL10007N Message "-1390" could not be retrieved. Reason code: "3".
You have not charge the db2profile. This file is in the sqllib directory of the instance's home directory.
Let's suppose your instance is db2inst1, then you need to call:
. ~db2inst1/sqllib/db2profile
Once the db2profile is loaded, you can see the value of the DB2INSTANCE environment variable.
One way to check if the environment is correctly loaded is to check if the DB2INSTANCE is set.
if [[ -z ${DB2INSTANCE} ]] ; then
echo "ERROR"
exit 1
fi
BTW, the 1390 is this error:
SQL1390C The environment variable DB2INSTANCE is not defined or is
invalid.
Most probably you have to load your bash profile in your script. Like:
source /etc/profile
or
source ~/.bash_profile
When creating Bash scripts, I have always had a line right at the start defining the PATH environment variable. I recently discovered that this doesn't make the script very portable as the PATH variable is different for different versions of Linux (in my case, I moved the script from Arch Linux to Ubuntu and received errors as various executables weren't in the same places).
Is it possible to copy the PATH environment variable defined by the login shell into the current Bash script?
EDIT:
I see that my question has caused some confusion resulting in some thinking that I want to change the PATH environment variable of the login shell with a bash script, which is the exact opposite of what I want.
This is what I currently have at the top of one of my Bash scripts:
#!/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
# Test if an internet connection is present
wget -O /dev/null google.com
I want to replace that second line with something that copies the value of PATH from the login shell into the script environment:
#!/bin/bash
PATH=$(command that copies value of PATH from login shell)
# Test if an internet connection is present
wget -O /dev/null google.com
EDIT 2: Sorry for the big omission on my part. I forgot to mention that the scripts in question are being run on a schedule through cron. Cron creates it's own environment for running the scripts which does not use the environment variables of the login shell or modify them. I just tried running the following script in cron:
#!/bin/bash
echo $PATH >> /home/user/output.txt
The result is as follows. As you can see, the PATH variable used by cron is different to the login shell:
user#ubuntu_router:~$ cat output.txt
/usr/bin:/bin
user#ubuntu_router:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
Don't touch the user's PATH at all unless you have a specific reason. Not doing anything will (basically) accomplish what you ask.
You don't have to do anything to get the user's normal PATH since every process inherits the PATH and all other environment variables automatically.
If you need to add something nonstandard to the PATH, the usual approach is to prepend (or append) the new directory to the user's existing PATH, like so:
PATH=/opt/your/random/dir:$PATH
The environment of cron jobs is pretty close to the system's "default" (for some definition of "default") though interactive shells may generally run with a less constrained environment. But again, the fix for that is to add any missing directories to the current value at the beginning of the script. Adding directories which don't exist on this particular system is harmless, as is introducing duplicate directories.
I've managed to find the answer to my question:
PATH=$PATH:$(sed -n '/PATH=/s/^.*=// ; s/\"//gp' '/etc/environment')
This command will grab the value assigned to PATH by Linux from the environment file and append it to the PATH used by Cron.
I used the following resources to help find the answer:
How to grep for contents after pattern?
https://help.ubuntu.com/community/EnvironmentVariables#System-wide_environment_variables
csh:
set a=0
echo "a is $a"
when i do ./my_script.csh output is:
a is
when i do source my_script.csh output is:
a is 0
Why is it so . As i know that ./ execution uses new shell.
That's right, ./my_script.csh starts a new shell, and uses the #! that you should have at the top of the file to select which shell to run (which should be csh in this case).
source my_script.csh runs the script in the current shell.
If the script is incorrectly run in, for example, the bash shell, set a=0 is not the syntax for setting an environment variable in bash, so the code won't work as you expected, because you're using the wrong shell.
Take a look at the #! at the top of the file. Is it correct?
check if variable "a" is set in your current shell:
set | grep '^a='
Remember that once you source script to your current shell,
all it's global variables are there until unset or you exit the current shell.
You may want to start a new shell, source the script, end exit shell to perform valid tests.
I don't know the context of your problem, but you may want to export some key variables to have their copies in every subprocess.
I am facing a situation where I from within my script I have to execute a read-only-script which changes the shell and sets some environment variables. Now I need to access these environment variables from my script.
The situation is like script-A
#!/bin/csh -f
bash
#set some environment variables A,B,C
I do not have write access to script-A and it performs a lot of configurations which are necessary for my Script-B.
I have tried script-B with
#!/bin/csh -f
./script-A
echo $A
However since the shell has changed, I am unable to access $A. Is there some work around such that I can do this.
Ideally the commands in my script-B has to be run in the new environment of script-A. While interacting manually, this is fine as I can first execute script-A and then execute the required commands. However, I have to automate the whole process.
Rewrite your own script in the same shell language as the one you need to execute so that you can execute it with the shell's source command.
If script-A is a csh script, then
source script-A
This works even if script-A contains exit statements:
$ cat x.csh
#!/bin/csh
source y.csh
echo $A - $B
cat y.csh
#!/bin/csh
set A=10
set B=20
exit 1
set B=30
$ ./x.csh
10 - 20
If script-A is in another shell, you need to rewrite script-B to match that shell
Oh, and by the way, DITCH CSH if at all possible: