I am trying to use a script that takes in some parameters inside my .profile file. The script is basically to execute a particular operation(from a set) on a list of jobs. So I execute the script like this.
sh bulkCommandProcessor.sh commandName job1 job2 job3...
Since the number of commands that can go in as the first argument is only 7, I would like to have aliases for each of it in my .profile file. I tried the following.
alias bjr='sh /home/vijay/scripts/bulkCommandProcessor.sh jr'
However, this doesnt seem to work. The error handling part of my code gets displayed when I source the .profile file which says something like this.
usage: /home/vijay/scripts/bulkCommandProcessor.sh cmd Job_name1 Job_name2 Job_name3 ..
Is there a way to achieve what I intend? That is use a script that accepts variable length of arguments within the .profile file.
First I think you need to make sure that your script bulkCommandProcesor.sh has the right permissions, that it is in the right path and that your are correctly parsing arguments for your script. I think that the following template might work:
#!/usr/bin/ksh
# .profile example
alias bjr='sh /home/vijay/scripts/bulkCommandProcessor.sh jr'
#variable length arguments in jobs
#where you previously get job1,job2 for example
jobs="$job1 $job2"
#And finally calling your script
bjr $jobs
Related
I am trying to have a variable execute 2 commands when typed in the terminal, namely change to a specific directory and run an executable. However when executed it returns
bash: cd: too many arguments
This is how I defined the variable in .bashrc
export FOO='cd "/path/to/directory" ; /path/to/executable'
When I input this line directly it works fine. So what is the proper way of defining such a variable?
After the suggestion by Barmer and Gordon and a quick search I managed to achieve the result I wanted using functions.
I would like to write a script that has several commands of the kind
> export PATH=$PREFIX/bin
Where
> $PREFIX = /home/usr
or something else. Instead of typing it into the the Shell (/bin/bash) I would run the script to execute the commands.
Tried it with sh and then with a .py script having the line,
> commands.getstatusoutput('export PATH=$PREFIX/bin')
but these result into the error "bad variable name".
Would be thankful for some ideas!
If you need to adjust PATH (or any other environment variable) via a script after your .profile and equivalents have been run, you need to 'dot' or 'source' the file containing the script:
. file_setting_path
source file_setting_path
The . notation applies to all Bourne shell derivatives, and is standardized by POSIX. The source notation is used in C shell and has infected Bash completely unnecessarily.
Note that the file (file_setting_path) can be specified as a pathname, or if it lives in a directory listed on $PATH, it will be found. It only needs to be readable; it does not have to be executable.
The way the dot command works is that it reads the named file as part of the current shell environment, rather than executing it in a sub-shell like a normal script would be executed. Normally, the sub-shell sets its environment happily, but that doesn't affect the calling script.
The bad variable name is probably just a complaint that $PREFIX is undefined.
Usually a setting of PATH would look something like
export PATH=$PATH:/new/path/to/programs
so that you retain the old PATH but add something onto the end.
You are best off putting such things in your .bashrc so that they get run every time you log in.
I use a lot of computing clusters and these often use a module system for making software packages available. Basically, you use the module command like module load sample_software and the sample_software path is added to $PATH. On a cluster, this command can be invoked during interactive usage and job submission usage.
I have a linux box with PBS/Torque queueing system installed so that I can sandbox software for later use on clusters. I need a very similar module system on this box. I started by making a file called modules.sh in my `/etc/profile.d/ directory that looks like this:
module()
{
if [ $2 == "softwareX" ]; then
PATH=$PATH:/home/me/dir/softwareX
export PATH
fi
}
I then put the following line in my .bash_profile script:
source /etc/profile.d/modules.sh
Now, this works great for the following usages: 1) If I submit a job and my job script uses module load softwareX, no problem, the job runs perfectly. 2) If I am working interactively on the command line and I type module load softwareX, then the path to softwareX is loaded into my $PATH and everything works great.
However, this doesn't work for the following situation: If I make a simple bash script that contains the line module load softwareX, when the bash script executes I get an error. For example, here is my bash script:
#!/usr/bin/env bash
echo $PATH
module load softwareX
echo $PATH
When I execute this I receive the error script.sh: line 3L module: command not found
...and the $PATH never changes. Does anyone know how I can solve this problem to work in all three situations? Thanks for any help!
A bash script won't invoke your startup files. You have to do that explicitly.
See http://www.gnu.org/software/bash/manual/bashref.html#Bash-Startup-Files
Invoked non-interactively
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.
As noted above, if a non-interactive shell is invoked with the --login option, Bash attempts to read and execute commands from the login shell startup files.
When you create a sub-shell, you create a new environment. When you exit back to your existing shell, you lose that environment.
I suspect this is what is going on with your module function call. If you added echo $PATH to the bottom of your module function, do you see the PATH get changed while inside the function, but changes again when you leave the function? If so, the problem is a sub-shell issue:
What you SHOULD do is have your module function print out the new path, and then do this:
PATH=$(module load softwareX)
I have a Script inside my Home Directory. The Script just provides a single message as an output. I'm trying to have my: .profile execute the Script so I can see this message.
I'm trying to use my profile as a log. So I can find the error.
My question is this, Since the Script invokes a basic echo request do I have to pass my message into a variable so it can be passed to that .profile?
When I implement ISPOD = Home/isProd export ISPROD to source it to my .profile the message does not exists. How can I solve this issue.
There are several things to consider here.
When you do
ISPROD=$HOME/isProd
the actual content of your variable is the isProd path, and not its output.
If you want to execute the command and catch the output then try $(command) or `command`.
ISPROD=$($HOME/isProd)
or
ISPROD=`$HOME/isProd`
at this point ISPROD will contain the output of the script. But you still need to show the content, hence you need to add
echo "$ISPROD"
But the same behaviour can be achieved just by executing the command without capturing the output and then echoing it.
Try with putting directly
$HOME/isProd
in the .profile and source it.
Also, make sure that .profile is the actual file that the shell sources at login time (bash for example uses .bash_profile).
I have some proxy settings that I only occasionally want to turn on, so I don't want to put them in my ~/.bash_profile. I tried putting them directly in ~/bin/set_proxy_env.sh, adding ~/bin to my PATH, and chmod +xing the script but though the script runs, the variables don't stick in my shell. Does anyone know how to get them to stick around for the rest of the shell session?
Use one of:
source <file>
. <file>
In the script use
export varname=value
and also execute the script with:
source set_proxy_env.sh.
The export keyword ensures the variable is marked for automatic inclusion in the environment of subsequently executed commands. Using source to execute a script starts it with the present shell instead of launching a temporary one for the script.
Did you try this:
. ~/bin/set_proxy_env.sh
Running it by itself opens a separate subshell (I think) and sets the variable there. But then the binding is lost after exiting back into your shell. The dot at the front tells it to run it within the same shell.
Also, don't forget to export the variables you need like so: export MYVAR=value