error 152 unexpect fi

[Goddard]

ran it and everything seemed to work fine, but got the error in the title.

[glenpike]

Can you tell me what OS / environment / shell you are running please?

[malko]

Ubuntu 16.10 gave me this:

sh: 74: [: ];: unexpected operator
sh: 77: [: ];: unexpected operator
sh: 90: Syntax error: "fi" unexpected (expecting "then")

[oleersoy]

Same here on Ubuntu 17.10

removed 668 packages in 3.567s
sh: 74: [: ${DEBUG}: unexpected operator
sh: 77: [: ${DEBUG}: unexpected operator
sh: 90: Syntax error: "fi" unexpected (expecting "then")

[glenpike]

@oleersoy - can you tell me what shell you are running with the following:

which sh | xargs ls -al

I'm also struggling to match up line "90" from the error message to a corresponding line in the script - I'm guessing that maybe the shell ignores comments, but I'm not sure.

Also, can you make sure you are downloading the script, then executing it, e.g.

wget -O- https://raw.githubusercontent.com/glenpike/npm-g_nosudo/master/npm-g-nosudo.sh >npm-g-nosudo.sh && chmod 755 npm-g-nosudo.sh && ./npm-g-nosudo.sh

[uberjay]

There are a number of issues in this shell script (give it a run through shellcheck -- https://www.shellcheck.net/).

A few things to think about:

1. Many missing quotes around string variables.
2. Use echo instead of printf "...\n".
3. Insecure creation/use of tempfile with a deterministic name.
4. Executing STDIN line-by-line. Typically, if a shell script is intended to be executed in the curl ... | sh pattern, the script should define a function which is executed in the last line of the script. This way, if the connection in interrupted part way through, the script will have no effect.
5. Incorrect use of read builtin. (Ok, it's not incorrect, it's just incompatible with piping a script into a shell's STDIN!)

I think the main issue that's causing confusion is the use of the read builtin. In particular, when piping a script via STDIN to the shell (i.e., wget ... | sh), standard input is the script itself, and read will consume a line of your shell script instead of prompting the user.

So for example, this sequence:

read -r yn
case "$yn" in
    [Yy]*)
        echo 'yes'
        ;;
    [Nn]*)
        echo 'nope'
        ;;
    *)
        echo "Invalid choice"
        ;;
esac

If this script is executed (./wat.sh), then it prompts and correctly executes the following case statement. On the other hand, if you pipe this script to stdin (cat wat.sh | sh), the read statement actually consumes the following line (case "$yn" in) from stdin, causing a subsequent syntax error.

One thing you could do is only prompt if you know stdin is a tty... something like this works correctly when piped and executed directly:

if [ -t 0 ]; then
    read -r -p "(y/n)? " yn
else
    yn="n"
fi
case "$yn" in
    [Yy]*)
        echo 'yes'
        ;;
    [Nn]*)
        echo 'nope'
        ;;
    *)
        echo "Invalid choice"
        ;;
esac

If you look at the test man page:

       -t FD  file descriptor FD is opened on a terminal

Testing FD 0 (STDIN) correctly differentiates between terminal and piped input.

[glenpike]

Thanks very much @uberjay - I will look into that and see if I can resolve this issue...