redirecting echo with undefined variable

353 views Asked by At

I'm running a script in solaris 11 with different results depending of the shell used.

The script has an echo redirecting to a file given by an environment value:

echo "STARTING EXEC" >> $FILE

ps. EXEC is just the message the script show, it's not using exec command.

If I execute the script without the variable FILE defined (using /usr/bin/ksh):

./start.sh[10]: : cannot open

and the script continue the execution.

The flags for ksh are:

echo $-

imsuBGEl

But if I change to /usr/xpg4/bin/sh, the script show me the echo in stdout and there is no error shown.

The flags for xpg4 sh are:

echo $-

imsu

I tried to change the flags with set +- (I can't remove El flags, but BG are removed ok), but can't get the same behavior.

Is there anything I can do to get the same result using ksh without cannot open error?

/usr/bin/ksh --version

version         sh (AT&T Research) 93u 2011-02-08

I'll want the script keep going, showing the message in stdout, instead of showing the error just like it does now.

Like shellter said in the comments, the good thing to do is to check if the FILE variable is defined before doing anything. This is a script migration from an HPUX to a SOLARIS environment, and client think they must have the same result as before (we unset FILE variable before execution to test it).

2

There are 2 answers

0
jlliagre On

You are likely running Solaris 11, not Solaris 64.

Should you want to have your scripts to work under Solaris 11 without having to search everywhere the bogus redirections, you can simply replace all shebangs (first line) by #!/usr/xpg4/bin/sh.

0
Javier Gutierrez On

The final solution we are going to take is to install the ksh88 package and use it like default shell (/usr/sunos/bin/ksh). This shell have the same behavior the client had before, and we can let the scripts with no modifications.

The ksh used in solaris 11 is the 93 (http://docs.oracle.com/cd/E23824_01/html/E24456/userenv-1.html#shell-1)

Thanks @jlliagre and @shellter for your help.