Results 1 to 5 of 5
I got roped in to help a colleague at work and I'm a total bash newbie. I'm trying to invoke a script from inside another script Here are the scripts: ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 07-06-2012 #1
- Join Date
- Apr 2012
Calling a script from inside a script
Here are the scripts:
#!/bin/sh sh test.env .. echo "Batch Process finished at `date`"
sh -x delete_correspondence.sh + sh $'test.env\r' : No such file or directory
This is not a homework question, test.env will set up the environment variables but my colleague doesn't have that information yet, not sure why.
Oddly enough, for me anyway, this works. In other words, it displays Works! in a loop
echo Works! sh test.env
- 07-06-2012 #2
Your script runs on your machine, but not on his. Did I get this right?
If yes, then it may be possible, that his shell is not bash.
You see, "/bin/sh" was traditionally the Bourne Shell.
Or to be precise: POSIX requires a bourne shell compatible shell (or softlink to one) there.
Today and on linux systems, this is usually the Bourne again shell
But it may also be e.g. zsh
This may explain the different behaviour between your and his machine.
A different env may also be involved, but tbh: The error above doesnt ring a bell on a specific variable.
If you want to require a specific shell, but still maintain portability between different unices,
then write a she-bang like this:
- env can call a command
Essentially, you call "bash" based on the env ($PATH) on a system.
So it doesnt matter, if bash is in /bin or /usr/local/bin, as long as the env is setup correctly.
Back to topic:
There might be better ways to set env variables.
1) User specific:
- Add it to ~/.bash_profile to parse your variables _once_ directly after a login (via gui or console or ssh). This is the beginning of a session.
- Add it to ~/.bashrc to parse them for every new bash console/terminal. (ie: within a running session)
2) App specific:
From a bash script, you could use "source <path_to_your_env_file>/test.env"
You can replace source with a dot. ". <path_to_your_env_file>/test.env"
The advantage is, that the env variables are valid for the context of your script.
3) System wide:
Place your env script in /etc/profile.d/ and make sure, the suffix is .sh
On older systems, there might not be a /etc/profile.d.
In that case, add your variables to /etc/bashrc.
/etc/bashrc is under package control.
That means, if you change this file, then it will be overwritten on the next update.
Or not, if it is marked as a config file in rpm. But in this case it will not be updated, which may result in problems for the updated app.
The bottom line is: The package controll vs need for individual modifications lead to the introduction of "<XY>.d/" directories for multiple services in the last years.
ie: Dont touch the package controlled system wide config files, but instead do whatever you want in <XY>.d/
Last edited by Irithori; 07-06-2012 at 05:23 PM.You must always face the curtain with a bow.
- 07-06-2012 #3
- Join Date
- Apr 2012
- Virginia, USA
Works fine for me....
Try this instead
echo "Batch Process finished at `date`"
You likely have something else broken in your delete script, and the shell is just trying to trick you
When you're just starting out, write each part of the script, then test (I use an echo with the expected output/result at each stage). Don't write it all at once and try to track down the problem.
So, if I'm reading in 2 variables, then adding them, then printing a file with name myfileX where X is the value of the sum.
..read in numbers (1, 2).. echo back numbers : 1, 2
add numbers (1+2).. echo back sum : 3
..echo back name: myfile3
- 07-09-2012 #4
- Join Date
- Apr 2012
Removed the shebang and it works fine now. I guess it was getting confused between default shell (BASH) and Bourne shell.
- 07-09-2012 #5
Your script needs features or syntax from bash.
This would explain all the results above.
Also, it seems the program loader assumes bash if there is no shebang (last result).
I didnt know that
There is nothing wrong with requiring a specific shell for a script.
However, I would suggest to explicitly state so and not rely on some magic.
The above outlined "#!/usr/bin/env bash" shebang can do that.You must always face the curtain with a bow.