0

This one different from the others as:

  1. I'm invoking bash (not sh) in the shebang: #! /bin/bash
  2. I'm running it with ./
  3. File permissions are correct: 755

The line in question is:

 formattedTIME=`awk '{printf("Duration:\t%02dh %02dm",($1/60/60%24),($1/60%60))}' $domPATH/duration.seconds`

The content of $domPATH/duration.seconds is 37603

I can run this at the command line:

formattedTIME=`awk '{printf("Duration:\t%02dh %02dm",($1/60/60%24),($1/60%60))}' duration.seconds`

and get the result of Duration: 10h 26m when I echo $formattedTIME

But running it in in the script results in:

./time.sh: line 42: syntax error near unexpected token `('
./time.sh: line 42: `    formattedTIME=`awk '{printf("Duration:\t%02dh %02dm",($1/60/60%24),($1/60%60))}' $domPATH/duration.seconds`'

Extra info: This is on a Raspberry Pi 2 running Jessie.

UPDATE: The error was online 8:

echo 'Cc: xxx@xxxx.xxx,xxx@xxxx.xxx,xxx@xxxx.xxx,xxx@xxxx.xxx'' >> $domPATH/arrive.email

closed as off-topic by Mat, techraf, countermode, Eric Renouf, Jeff Schaller Nov 14 '16 at 13:57

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Mat, techraf, countermode, Eric Renouf, Jeff Schaller
If this question can be reworded to fit the rules in the help center, please edit the question.

  • Works fine when I run it. Can you try to reduce the script to the minimal that is required to exhibit the problem, then post the whole script? I get the feeling you're probably forgetting to close something (perhaps `?) on a line above – Muzer Nov 14 '16 at 11:04
  • It works fine for me, I can only think that the error is somewhere else in your script. – gogoud Nov 14 '16 at 11:07
  • 1
    Possibly you have some unclosed '...' further up in the script, so the first ' on that line closes it, and the next ( after that causes the error. – Stéphane Chazelas Nov 14 '16 at 11:29
  • Thanks for the suggestions guys, @StéphaneChazelas you hit the nail on the head. there was a triple ' on line 8. (Found it while editing the question to include the full script here). – Jim Nov 14 '16 at 11:39
2

A few common trends on why a command doesn't parse properly in a script but is fine when run on its own:

The source of the error is elsewhere

The shell will report an error on the first thing it doesn't expect. Here, it doesn't expect a (, yet it appears it's within a quoted string. A possible explanation is that you're not in a quoted string because the first ' there actually closes an earlier unclosed quote instead of opening a new '...' on like in:

echo It's a bug
formattedTIME=`awk '{printf("Duration:\t%02dh %02dm",($1/60/60%24),($1/60%60))}' $domPATH/duration.seconds

That's actually:

echo It'quoted-string'{printf("Duration:\t%02dh %02dm",($1/60/60%24),($1/60%60))}'...

And that unquoted ( above is unexpected by the shell.

You get similar problems with any structure that is not properly closed or in the wrong format, like a fi without a then...

Backticks

Backticks should really not be used. $(...) should be used instead.

Inside backticks, \ is handled differently.

echo "`
  echo It\\\'s OK
`"

is not OK. Even though echo It\\\'s OK by itself is OK, as inside backticks, the first two backslashes become one, so it ends up being echo It\\'OK.

The $(...) modern form doesn't have those problems.

Aliases

aliases are a bit like macros, their expansion undergoes code interpretation again.

Things like:

alias foo="echo '"
...
foo bar
echo 'baz('

would have the problem hidden in the definition of the foo alias.

There are more subtle ones like:

alias foo='a;b'
cmd | foo

Which without causing syntax errors, cause the parsing to be done in an unexpected way.

Often, functions are more appropriate than aliases

localisation

Some byte sequences can be interpreted differently depending on the locale.

For instance, the 0xa0 byte is the non-breaking space in the ISO-8859-1 character set. And that character happens to be a blank on Solaris, and bash happens to treat all blanks as delimiters (currently only for single-byte characters).

That 0xa0 byte also happens to be part of several UTF-8 characters like à. So you may find that for instance that a script that has:

var=àdo

(with that à written in UTF-8) stops working when run on Solaris in a ISO-8859-1 locale, because that becomes var=X do (where X is the first byte of that à character).

Or you may find that:

echo ε

With that ε written in the BIG5-HKSCS character set stops working when you're not in the zh_HK.big5hkscs locale, as that ε is actually encoded as 0xa3 0x60, where 0x60 in ASCII and all single-byte character sets is the backtick character.

Not the answer you're looking for? Browse other questions tagged or ask your own question.