BASH scripting.

[Kennedy]

#!/bin/sh
/bin/mkdir /somedir
/usr/local/bin/somepgm --output /somedir
cd /somedir
/bin/ls

This doesn't do what you might think it does. The intent of the script is to create a directory, execute a program that dumps the output into that directory, change the current working directory to that location, display the contents, and exit into that directory. This script fails to do this since bash forks and execv's the script, which is then a child process to the shell, then returns the return code of the last program executed in the script.

Is there some way that will allow me to keep the script in the current process stream? I've looked and haven't found anything yet, but again, I'm terrible at searching the web.

Thanks in advance for any assistance you can/will provide.

[Cactus_Hugger]

Try typing:

. ./script.sh

...to start the script, replacing ./script.sh to your script's name. (Note the preceding ". ")
If there's a way to do this inside the script, I don't know about it.

This from the man pages:

. filename [arguments]
source filename [arguments]
Read and execute commands from filename in the current
shell environment and return the exit status of the
last command executed from filename. If filename does
not contain a slash, file names in PATH are used to
find the directory containing filename. The file
searched for in PATH need not be executable. When bash
is not in posix mode, the current directory is searched
if no file is found in PATH. If the sourcepath option
to the shopt builtin command is turned off, the PATH is
not searched. If any arguments are supplied, they
become the positional parameters when filename is exe-
cuted. Otherwise the positional parameters are
unchanged. The return status is the status of the last
command exited within the script (0 if no commands are
executed), and false if filename is not found or cannot
be read.

[Kennedy]

Well, if I alias this out in the profile, I can probably get away with this.

If no one else has anything better, I'm adding `alias mkconfig='source mkconfig'` to the profile. This appears to work, but has its limitations. Namely, if there is a Linux savvy person behind the keyboard, and said person types ./mkconfig, then it fails.

Thanks for the help!

[Salem]

So if they don't end up in /somedir, is that a problem?

You could always add this to detect how the script was invoked.

#!/bin/sh

if [ $SHLVL -gt 1 ]; then
  echo "please run as . $0"
  exit 1
fi

echo "Success"

[Kennedy]

> So if they don't end up in /somedir, is that a problem?
The last command run is ls. The reason that I'm even doing this is these people are going from Dr. DOS to Linux. They don't know Linux commands. I'm attempting to make things as easy as possible for them. I mean, they will already have a brain cramp when they learn that DOS edit is not the program they will use to update the config files -- vi isn't really that hard though, is it?

You could always add this to detect how the script was invoked.

#!/bin/sh

if [ $SHLVL -gt 1 ]; then
  echo "please run as . $0"
  exit 1
fi

echo "Success"

Hmmph. Hadn't thought of that. . . could I not also just do something like

if [ $SHLVL -gt 1 ]; then
  source mkconfig
  exit 0
fi

to keep them from getting _any_ errors. I don't want to blow their minds any more than I already am.

EDIT: Nevermind. . . I just realized how stupid that is. I'd be in the wrong shell level already. . . that wouldn't help me any.

[dwks]

When is this script going to be run? Is it only run once? If so, why not add it to ~/.bashrc or ~/.bash_profile? (I can never remember which is which. Check the man pages.)

[Kennedy]

Cannot say. The script will take a binary data set from a limited (2.5MB) flash memory, expand it into 4KB each "human readable" files ~15 in total for starters. More can be added later. The utility will be invoked by the user that is about to modify this data. I have two scripts, one mkconfig (writes the human readable files) and mksystem (reads back in the files to the data set). The user will be at a command prompt when [s]he plugs in to the serial console. The user will then type mkconfig and have all the files listed for them. Using Cactus_Hugger's idea of source, then writing an alias in /etc/profile is the way to go. We're turning in the project back to the prime tomorrow, so if I get a chance, I may also include Salem's idea about the "don't call me like that, use just mkconfig/mksystem" thing, but I'll try to be a bit more forgiving in the script.

Thanks for all your help! . . . to Cactus_Hugger especially -- that really helped me out.