unexpected EOF : BASH

i'm writing a bash script that uploads a file to my server but it keeps saying unexpected EOF... i cannot see the problem with it, and it worked before i edited the script to work on my ipod touch as well. Here is the troublsome code...

if [ "$SYSTEM" = "Mac OS X" ]; then 
  tar -czf "file(Mac).tar.gz" "/folder" > /dev/null 2>&1
  USER="username"
  PASS='password'
  FTPSERVER="myserver.com" 
  FILE="/file(Mac).tar.gz" 
  ftp -i -n $FTPSERVER << EOF #> /dev/null 2>&1
  user $USER $PASS
  bin
  pwd
  put $FILE
  bye
  EOF
fi
if [ "$SYSTEM" = "iPhone OS" ]; then
  tar -czf "file(iPhone).tar.gz" "/var/mobile/" > /dev/null 2>&1
  USER="username"
  PASS='password'
  FTPSERVER="myserver.com" 
  FILE="/var/mobile/file(iPhone).tar.gz" 
  ftp -i -n $FTPSERVER << EOF #> /dev/null 2>&1
  user $USER $PASS
  bin
  pwd
  put $FILE
  bye
  EOF
fi

as i said, before i expanded it to include support for my ipod, it worked fine... but now it says unexpected EOF! any ideas? Much Appreciated.

I believe the lines with EOFs need to start at column 1. Don't indent them. At least that is how it works in ksh.

You can indent them, but only if you use the <<- operator and only if the only characters preceding the EOF (or whatever is chosen as the here-doc delimiter) are tabs.

Regards,
Alister

This section worked fine, before i expanded it to allow both systems to use it...

tar -czf "file(iPhone).tar.gz" "/var/mobile/" > /dev/null 2>&1
  USER="username"
  PASS='password'
  FTPSERVER="myserver.com" 
  FILE="/var/mobile/file(iPhone).tar.gz" 
  ftp -i -n $FTPSERVER << EOF #> /dev/null 2>&1
  user $USER $PASS
  bin
  pwd
  put $FILE
  bye
  EOF

DuskFall, not clear how that works.. :confused: Is it still failing after removing the indents or trying the change suggested by alister?

Do you mean the indents at the beggining of the lines? ill try removing those...

Yes.. Remove leading spaces/tabs in front of EOF.

it kinda works, i have no error anymore, in fact i have nothing because it stopped working... any ideas why that happened? i believe it skipped the command... how will i be able to tell if it skips the command?

---------- Post updated at 08:19 PM ---------- Previous update was at 08:15 PM ----------

whoo! no error.. excpet now i believe it is now skipping the command somehow, any idea how to check?

Given the limited information, my guess as to what was happening follows. I've highlighted in red what's being treated as standard input to the ftp command.

You weren't intending to send an actual string of "EOF" into the ftp client, but that's what was happening. You were just getting lucky. While you intended "EOF" to mark the end of standard input to the ftp command, since there's a space before "EOF" it wasn't being recognized as the delimiter. Instead, the end of the standard input stream to the ftp command was actually occurring at the end of the script file itself, just after "EOF". The ftp client either silently ignored the "EOF" input it was given or it wrote an error message which was missed or redirected to /dev/null. At a higher level, the shell itself did not complain because it had nothing pending when it reached the end of the script; it simply closed the standard input to the ftp command and exited. As far as the shell is concerned, there's no syntax error.

With your newer version, however, the shell sees a problem.

The if statement at the very top, beginning with the "if" keyword highlighted in blue, is unterminated when the shell reaches the end of the file.

With this version, beginning with the first line after the first "<< EOF" here-doc redirection, everything that follows is being treated as standard input to the ftp command. When the shell reaches the end of the script, it treats that as the end of the standard input stream to ftp. However, all of this is occuring within an if statement. The shell's parser, upon encountering the end of the script file, complains about the unexpected end of file because it's still looking for the if-statement's terminating "fi".

---------- Post updated at 04:42 PM ---------- Previous update was at 04:41 PM ----------

You can use "set -x" near the top of the script to see what the shell is doing. This enables tracing. Once you figure out what's going on, remove it.

Regards,
Alister

Thanks so much, but how do you suggest i fix it? the file was uploading fine before, leading me to believe that it was fine before, but it doesnt now.. and i am simply unable to see any way of fixing...

You could help us help you by posting the code in its current form, exactly as you're using it. Tell us how you're calling the script. Add a line with 'set -x' at the top of the script (after any shebang line if any, such as #!/bin/sh). Post the resulting output and all error messages. Describe in full what occurred and how that differs from what you expected.

Otherwise, it's all just shots in the dark.

Regards,
Alister

---------- Post updated at 05:02 PM ---------- Previous update was at 04:58 PM ----------

Obviously, you'll want to obfuscate any sensitive info that you'd rather not share, such as usernames, passwords, hostnames, etc.

1 Like

Thanks for the help alister with the set -x