Find the answer to your Linux question:
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.
  1. #1
    Linux Newbie
    Join Date
    Apr 2012
    Posts
    112

    Calling a script from inside a script


    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:

    test.env

    Code:
    echo Works!
    delete_correspondence.sh

    Code:
    #!/bin/sh 
    sh test.env
    ..
    echo "Batch Process finished at `date`"
    The problem is that test.env doesn't run from inside delete_correspondence.sh

    Code:
    sh -x delete_correspondence.sh
    + sh $'test.env\r'
    : No such file or directory
    I've also tried with the full path to test.env but to no avail.

    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
    Code:
    echo Works!
    sh test.env
    Any ideas?

    TIA

  2. #2
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,229
    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.

    Sligthly Off-Topic:
    If you want to require a specific shell, but still maintain portability between different unices,
    then write a she-bang like this:
    Code:
    #!/usr/bin/env bash
    - It is ensured by POSIX, that /usr/bin/env exists.
    - 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.
    But beware:
    /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.

    Confused yet?
    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.

  3. #3
    Linux Engineer
    Join Date
    Apr 2012
    Location
    Virginia, USA
    Posts
    794
    Works fine for me....
    Try this instead

    #!/bin/sh
    ./test.env
    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
    print file.

  4. #4
    Linux Newbie
    Join Date
    Apr 2012
    Posts
    112
    Removed the shebang and it works fine now. I guess it was getting confused between default shell (BASH) and Bourne shell.

    with #!/bin/sh

    Code:
    sh delete_correspondence.sh
    and
    Code:
    ./delete_correspondence.sh
    don't work
    Code:
    bash delete_correspondence.sh
    does work

    without #!/bin/sh

    Code:
    sh delete_correspondence.sh
    doesn't work
    Code:
    bash delete_correspondence.sh
    and
    Code:
    ./delete_correspondence.sh
    do work

  5. #5
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,229
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •