LinuxQuestions.org - [SOLVED] bash script unexpected end of file

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - bash script unexpected end of file (https://www.linuxquestions.org/questions/linux-newbie-8/bash-script-unexpected-end-of-file-4175416073/)

bash script unexpected end of file

Hello

I'm trying to run a simple script that I made about 2 years ago. It used to work fine and I don't think anything has changed (same distro and version too) but now I recieve 'unexpected end of file' when I run the script.

Code:

#!/bin/bash



i=1

while [ $1 -le 20 ]

do

sleep 5

xwd -root > ./xwd/`echo $1`.xwd

i=`expr $1 + 1`

done

I can't see the problem. Please help

That script doesn't make sense. you do a while checking $1 but $1 will *never* change... you only change $i. surely this has never worked?? There's a hell of a lot of redundant code for a simple script. your logic is a little vague, but this seems to be what you want, and you've somehow got your i's and 1's mixed up:

Code:

#!/bin/bash



for i in $(seq 1 20)

do

sleep 5

xwd -root -out ./xwd/$i.xwd

done

Quote:

Originally Posted by acid_kewpie (Post 4724754)

Code:

#!/bin/bash



for i in $(seq 1 20)

do

sleep 5

xwd -root -out ./xwd/$i.xwd

done

totally agreed with this.

anyhow, i copied/pasted the script and it worked without issues here. it seems the script contained DOS newlines or characters and that's why it may be failing with 'unexpected end of file'.

I tried to

Code:

perl -pi -e 's#\n#\r\n#g' /tmp/testLQ

and it failed with the same error message.

then again, replaced DOS newlines to *NIX and it worked

Code:

perl -pi -e 's#\r\n#\n#g' /tmp/testLQ

Yes, perhaps DOS newlines could be the problem. I edited the path of the redirect in windows just prior to using the script.

The I's and 1's were from me typing the code here instead of copy/pasting

Thanks. I'll try it in a bit

No arguments here

Just wanted to say that the preferred way to eliminate those DOS line endings would be to run 'dos2unix' against the file.

Quote:

Originally Posted by acid_kewpie (Post 4724754)

Code:

#!/bin/bash



for i in $(seq 1 20)

You don't even need seq here. bash can generate the numbers internally with brace expansion or a c-style for loop.

Code:

for i in {1..20}; do

        ....

done



for (( i=1 ; i<=20 ; i++ )); do

        ...

done

Edit:
expr, as used in the OP, is also unneeded. bash has full integer arithmetic ability built-in.

And $(..) is highly recommended over `..`

yep, that's 3 characters saved! Some built-ins i just can never remember.

Always nice, but about saved characters......

It is rarely a bad thing to save characters, but in this case that is trivial. The more important factor in using the full power of your shell instead of external tools is reduced load on disk I/O, memory, and CPU. Not having to load external programs during a shell script run means not having to load that file from disk, not having it in memory, not having to load off parameters and return results, and not having to take the TIME for those operations.

Before BASH got so good, this was a fair reason for automating using PERL rather than shell scripts: you could do everything within the PERL script because of the engines POWER! BASH has gotten good enough to have many of the same advantages.

For a one-off script running once the difference may not matter. If you may end up running the script in a loop, under schedulers, thousands of times per day, the difference is significant.

Additional advantages of proper scripting are robustness (you cannot break the script by renaming an external tool, if it does not CALL that external tool) and portability (it should run anywhere a near version of that shell is available) without regard to the behavior changes or version differences of the external tools.

Perhaps most important: the habits of mind. When the person making the script finds value in making his (or her, or its) scripts self-sufficient, correct, and efficient they do better work and are likely to find better ways to solve problems.

On longer scripts you will want to spend off some characters to comment your script to make it easily maintainable, and that is a good thing. You will not want to make it less efficient or less correct, even if that were to save characters.