Error using Sublime Text to create shell scripts

[phanly]

This is a strange one.

When I create a new bash script using Sublime Text (in Bash Shell mode), it works fine until I create a conditional statement, in this case and IF statement.

The script will not work unless I create the first IF condition using vi on the command line. If I write the first conditional statement using vi on the command line, I can open the script in Sublime Text and write other conditional statements and it works fine.

If I write the following using Sublime text:

#!/bin/bash
echo "checking for the item file"
item="item.txt"
if [ -r $item ]
then
echo "The item file exists and is readable"
else
echo "The item file does not exist or is not readable"
fi_

The echo and variable assignment will run but when I add the IF statement, I get the following error:

user@machine:/mnt/c/scripts$ ./item_file.sh
checking for the item file
./item_file.sh: line 9: syntax error near unexpected token fi' ./item_file.sh: line 9: fi'

If I write the same script using vi on the command line:
#!/bin/bash
echo "checking for the item file with vi"
item="item.txt"
if [ -r $item ]
then
echo "The item file exists and is readable"
else
echo "The item file does not exist or is not readable"
fi

It will run fine:
user@machine:/mnt/c/scripts$ ./item_file_2.sh
checking for the item file with vi
The item file does not exist or is not readable

At this point, I can open the second file with Sublime text and add code and it will run fine:

user@machine:/mnt/c/scripts$ ./item_file_2.sh
checking for the item file with vi
The item file does not exist or is not readable

checking for the item2 file with Sublime Text
The item2 file does not exist or is not readable

I can continue to add code to the file, including conditional statements, using Sublime Text and it will continue to run fine.

I have tried several things in Sublime Text to be able to code the file in this tool from the beginning with the same result. It will fail until I write the first conditional statement in vi on the command line. Once I do that, I can open the script in Sublime Text and it will be fine to use.

Windows Build: Microsoft Windows [Version 10.0.15063]

strace.txt

Thanks for help,
Pat

[therealkenc]

I assume you are talking about Windows Sublime Text using interop in "bash mode". If so, this is probably a variation of #2318. Basically same as this. Check your end-of-line convention in Sublime. You want explicit Unix style. I speculate in your "... continue to add code to the file ... runs fine" scenario, Sublime has kicked in some kind of auto-detection of Unix EOL convention and goes with the flow thereon.

For a while now I have been wanting to share this old (and long addressed) VSCode github post for comedic value.

[phanly]

Thanks for the reply and yes, I do mean Windows Sublime Text. When I referred to "bash mode", I was referring to Sublime's default syntax for the session I was working in. I certainly considered end-of-line conventions in Sublime so I tried different things to test for that but I could not identify it. The strange thing is that it only happened when writing the first conditional statement. If I do that in vi on the command line, I can reopen the file and write many other IF's without an issue.

You might be right about the Sublime's potential "auto-detection of Unix EOL conventions" but I would have thought I would see that with other statements. I will take a look at #2318. Thanks.

[therealkenc]

I would have thought I would see that with other statements

"It's complicated". In Bash (as a scripting language), carriage return is syntactically correct in some contexts. This is a perfectly legal bash script:

$ printf "echo \"hello\"\r\necho \"world\"\r\n" > hello.sh
$ hexdump -C hello.sh
00000000  65 63 68 6f 20 22 68 65  6c 6c 6f 22 0d 0a 65 63  |echo "hello"..ec|
00000010  68 6f 20 22 77 6f 72 6c  64 22 0d 0a              |ho "world"..|
0000001c
$ bash hello.sh
hello
world

That script is outputting invisible carriage returns to stdout as well as the newlines. But it is technically different output than a script without the carriage returns.

At the end of the day, Cygwin's set -o igncr needs to be upstreamed. Or maybe someone who has pull with people at Canonical can get the patch included in Ubuntu's distro. But even that is basically a hack to work around the more fundamental problem. [Fighting words] Languages that are sensitive to whitespace are broken (looking at you too, Python).

[ghost]

Languages that are sensitive to whitespace are broken (looking at you too, Python).

I think even guido once said that if he were to change one thing about python, he would change this part. :)

[therealkenc]

The behaviour here was explained by CRLF problems that would manifest on Real Linux.