#!/bin/bash
A=abcd
B=12
echo $A$B

Also, redirecting any output into a file results in a new folder and an new empty file, both with a weird name. Ex.:

[shell] DIR=/volume1/sharedFolder/
FILENAME=${DIR}outputFile
echo Hello World > $FILENAME
[/shell]

results in a file named “outputFile” and a folder named “” ( beeing displayed as ‘dots’ in Windows Explorer!). Both are well located under /volume1/sharedFolder/ and visible in Windows Explorer. However the folder does not appear when executing ‘ls -la’ in a console on the NAS (only the file appears) and the only way to delete this folder is to execute ‘rm -R /volume1/sharedFolder’ in the console.

I quickly realized that this behavior was a consequence of creating the file on a Shared Folder of the NAS using the Windows Explorer’s contextual menu “New”>”Text Document”… Creating an empty file with the command “touch” directly in a console on the NAS does not suffer the same issues.

There is indeed at least one difference that I know between the file format of Unix and DOS: the return character which is 0x0A in Unix, while it is 0x0A, 0x0D in DOS (a.k.a /n in Unix and /r/n in DOS)

I realized that this was the issue because each empty line in the script was resulting in an error: “: not founde x:”, x being the line number. Meaning that the “empty lines” were actually not empty (due to the /r).

Notice that the magic “touch” only works because I use next Notepad++ to edit the file. Indeed, this great freeware preserve the Unix file format while NotePad, WordPad, etc…, do not.

I did use the Windows Explorer’s contextual menu to create the empty file because I was too lazy to create a new file with notepad++ and browse next for the target subfolder on the NAS where I had to save it 🙁

Otherwise, with the “Save As” of NotePad++, I would have been able to pick the right format: “Unix Script File” 🙂