4

i have a bash script I edit on windows using UltraEdit and save as UTF-8 No BOM, using Unix Line Terminator style, as specified in the "save as" dialog box in UE.

I then upload it to a centos 5 x86 machine running parallels virtuozzo, and everytime, no matter how i upload it (FTP as binary file, or via parallels management console), the script wont work. When i view the script via parallels management console i see that the LAST, and ONLY the last line, has a weird character in it. If i remove the line terminator from the last line (let the script end at the last printable character) everything works fine.

My questions:

A) why is only the LAST line terminator causing problems?

B) how do i avoid this in the future?

thanks!

Gaia
  • 2,872
  • 1
  • 41
  • 59

7 Answers7

2

firstly i would recommend you transfer as binary.. since you seem to know exactly the format you want..

ASCII/text FTP is known for doing line-ending conversion when you dont want it too.

ShoeLace
  • 3,476
  • 2
  • 30
  • 44
  • if that was the problem it wouldnt happen when i transfer via PMC. unless PMC uses some FTP based transfer and which I dont know about ... – Gaia Jul 24 '09 at 18:41
  • transferring as binary doesnt fix, as expected. see comments to sinans answer. – Gaia Jul 26 '09 at 16:59
2

you can just run dos2unix to get rid of them..

ghostdog74
  • 327,991
  • 56
  • 259
  • 343
  • i ran the perl script because dos2unix doesnt seem to be available on my distro? – Gaia Jul 26 '09 at 16:09
  • First of all, you can usually say "file filename" to identify when the file has DOS style CRLF line terminators. Then, if you do not have `dos2unix` you can get it in many forms on line for your platform. – nik Jul 26 '09 at 17:26
2

There are two issues here: First, assuming the editor saves with Unix line endings, you should use binary FTP, not ASCII. Second, and this is puzzling, the editor seems to be inserting a CTRL-Z at the end of the file (which has not been necessary since the late eighties AFAIK).

Do save a file consisting of a single line, transfer it to the Unix system via usual means and use:

xxd myscript.sh

to see if the last byte in the file is 0x1a to verify if my theory is correct.

Sinan Ünür
  • 116,958
  • 15
  • 196
  • 339
  • one line script transferred as binary reported `0000000: 2321 2f62 696e 2f62 6173 68 #!/bin/bash` – Gaia Jul 26 '09 at 16:53
  • two line returns '0000000: 2321 2f62 696e 2f62 6173 680d 0a #!/bin/bash..' – Gaia Jul 26 '09 at 16:55
  • trying to execute the two line shows the extra CR. this is my problem. -bash: ./hello.sh: /bin/bash^M: bad interpreter: No such file or directory (sorry i can't get the backtick right on an internation kbd) – Gaia Jul 26 '09 at 17:02
2

I had a similar issue with the BOM (byte order mark) being set in Ultraedit on all new files saved, even though I had this option unchecked. This wreaked havoc in Linux. The solution was to set the default encoding to ANSII. This setting is in UltraEdit v18 at least.

Advanced > Configuration > Editor > New File Creation

Encoding Type: Create new files as ANSII

Banjer
  • 8,118
  • 5
  • 46
  • 61
2

I used CTRL-H on Ultraedit, which displays the same output as unix's XXD command, and I see the 0D 0A in there, though the file is set to use UNIX line terminators. this is an Ultraedit problem. Im using v 13.20a.

I am new to stackoverflow. should i open a new question or re-tag this one?

thanks to all

Gaia
  • 2,872
  • 1
  • 41
  • 59
1

The next step is to do a hexdump on the file and see what is in there. This sounds very much like there is a bare CR in there. Remember that carriage return means "write the next character in position 0 of the current row". Try running hexdump -C file or even od -t x1 file and look for 0A and 0D (0D=CR, 0A=LF).

D.Shawley
  • 58,213
  • 10
  • 98
  • 113
  • it is a bare CR thats in there (^M) the problem is how does it get there? i am killing all the trailing stuff from the last line, then i insert one more newline and save the file, as per the specs above. – Gaia Jul 24 '09 at 18:40
  • od -t x1 file returns 0000000 23 21 2f 62 69 6e 2f 62 61 73 68 0d 0a 0000015 – Gaia Jul 26 '09 at 17:01
0

you could just edit the script remotely.

emacs/vim/nano etc. works well over putty. if you like emacs, you can also use tramp to edit remote files with the emacs running on whatever machine you happen to be sitting in front of, though I haven't used tramp with windows. komodo-edit as remote editing as well, and while I highly recommend komodo-edit, i haven't used the remote feature.

ryan_m
  • 721
  • 2
  • 7
  • 18
  • sure, but i am trying to find out what is wrong with my current method. it *should* work. thanks – Gaia Jul 26 '09 at 16:15