0

This is a beginner question, I have already checked that Check existence of input argument in a Bash shell script but it doesn't fully explain what I want to do.

gcc -Wall cx17.$1.c -o cx17.$1

if [ -z "$1" ]
  then
    echo "No argument supplied"
else if [ -z "$2"]
    then
        echo "Data file is missing!!"   
else if [ -z "$3"]
    then
        ./cx17.$1 $2 > ./cx17.$1.$2 
else 
    ./cx17.$1 $2 $3 > ./cx17.$1.$2 

fi

So you understand this very basic use case, depending on arguments (if there is 1, 2 or 3) the script will perform a different task.

I know it's really simple that's why I think I'm missing something obvious.

Thanks for your help

The answered I validate gave me some errors but lead me to the right stuff:

if [ -z "$1" ]; then
    echo 'No argument supplied';
elif [ -z "$2" ]; then
    echo 'Data file is missing!!';
elif [ -z "$3" ]; then
    ./cx17.$1 $2 >./cx17.$1.$2;
else
    ./cx17.$1 $2 $3 >./cx17.$1.$2;
fi;
Community
  • 1
  • 1
François Richard
  • 6,817
  • 10
  • 43
  • 78
  • [getopts](https://en.wikipedia.org/wiki/Getopts) – MeetTitan Aug 17 '15 at 20:46
  • What is your question? – John Kugelman Aug 17 '15 at 20:48
  • You don't say anything about what your *problem* is. Unless you want a line-by-line code review, you need to say what happened *instead* of what you were expecting to happen. (I think I understand what you were trying to do.) – zwol Aug 17 '15 at 20:49
  • yes sorry this is so basic I didn't even mention that . – François Richard Aug 17 '15 at 20:50
  • Note also that there is nothing bash-specific about this question, and as a general rule of thumb, if you think your shell script needs to use a feature that only bash provides, that is when you should stop and rewrite the entire thing in a better programming language. – zwol Aug 17 '15 at 20:51

2 Answers2

3

Replace else if with elif:

if [[ -z "$1" ]]; then
    echo 'No argument supplied';
elif [[ -z "$2" ]]; then
    echo 'Data file is missing!!';
elif [[ -z "$3" ]]; then
    "./cx17.$1" "$2" >"./cx17.$1.$2";
else
    "./cx17.$1" "$2" "$3" >"./cx17.$1.$2";
fi;

Other recommendations:

  • Always double-quote words that contain variable substitutions, otherwise word splitting and shell globbing can take effect on the expanded variable content.
  • Always use [[ instead of [, since the former is more powerful, and it's good to be consistent.
  • If interpolation is not required, use single-quotes rather than double-quotes, since single-quotes do not interpolate anything; it's just safer that way.
bgoldst
  • 34,190
  • 6
  • 38
  • 64
  • +0.5 for correcting most (but not all!) of the quoting bugs, -1 for using `[[` (never use shell-scripting features outside the minimal portable set; rewrite in a better language instead); add'l -0.5 for unnecessary semicolons and poor spacing. – zwol Aug 17 '15 at 20:53
  • 1
    @zwol If you don't want to use non-portable constructs, that's your business. It's hardly a reason to downvote an answer for a question explicitly tagged `bash`, though. – chepner Aug 17 '15 at 21:04
  • 1
    1. It is a tradeoff to forgo useful modern features for the sake of greater portability. The question is tagged bash, and bash is so ubiquitous anyway, that the tradeoff easily lands on the side of modernity. IMO. 2. There are no quoting bugs remaining. If you think you've spotted one, you should point it out. 3. See my comment at http://stackoverflow.com/questions/29004672/using-user-defined-for-loop-function-to-construct-a-data-frame/29004774#comment46255846_29004774 for my explanation of why I use semicolons. 4. You're confusing your personal preferences with objective truth. Don't do that. – bgoldst Aug 17 '15 at 21:06
  • @bgoldst re (2), when I wrote that comment, the targets of `>` redirection were not quoted; I see it's fixed now. Probably you were making the edit at the same time as I was making the comment. Sorry about that. – zwol Aug 18 '15 at 16:57
  • @bgoldst re the semicolons, I understand where you're coming from, and might even agree in R, but I think that's the wrong choice *for shell script* because shell syntax is so complex and unpredictable that any departure from idiom makes the reader's brain jar. In other words, by using semicolons in shell when they're not necessary, you make the reader stop and wonder if they *are* necessary for some reason, and then go reread the manpage and tear their hair out. – zwol Aug 18 '15 at 17:02
1

You can dispense with the if statement altogether using the ${var:?msg} construct, which will exit the script if the given variable doesn't have a non-null value.

: ${1:?No argument given}
: ${2:?Data file is missing!}

# $1 and $2 guaranteed to be non-null; the program
# will receive 1 or 2 arguments, depending on how many
# arguments are present in $@ 
./cx17."$1" "${@:2:2}" > "./cx17.$1.$2"
chepner
  • 497,756
  • 71
  • 530
  • 681