AW: [Gate-users] Cause of problems in reading text files (e.g. GATE macros) at Linux OS after they have been read or written at Windows platform - Solution provided using command "tr"

Wed May 28 13:27:54 CEST 2008

Hi Wolf,

I am forwarding your e-mail to the GATE-users mailing list

yes indeed  dos2unix is another command someone can use to deal with 
this problem.
I have tested it and works fine. This is a more straightforward way to 
convert the native format of text files into Linux format.

I have included some basic usage examples for quick reference.

If anyone would like to convert PET_Ecat_System.mac into a new file 
named PET_Ecat_System_unix.mac, which supports the Linux format, one 
should type:
dos2unix -n PET_Ecat_System.mac PET_Ecat_System_unix.mac

Moreover if anyone wants to replace the old macro with a new one with 
the same filename, one should simply type:
dos2unix PET_Ecat-System.mac

Thanks for your contribution Wolf

Best regards
Nicolas

Stiller Wolfram wrote:
> Hello Nicolas,
>  
> unfortunately, my mails to the gate-users maling list are always rejected, I seem to have no rights there although I have registered as a gate user... For this reaon I write to you directly in reply of your message on the incompatibility of windows and linux text files.
>  
> I just would like to mention that there is a simple command called "dos2unix" which performs exactly the described deletion of line end characters added to text files by windows editors. Just give your macro file name as an argument and everything is taken care of. If the file is already linux-compliant, nothing will happen since nothing needs to be changed. This command should be available for all linux distributions. Hope this helps.
>  
> Best regards
>  
> Wolf
>  
>  
>  
> Diplom-Physiker Wolfram Stiller
>  
> German Cancer Research Center - DKFZ
> Medical Physics in Radiology (E020)
> Im Neuenheimer Feld 280
> 69120 Heidelberg
> Germany
>  
> E-mail: w.stiller at dkfz-heidelberg.de <mailto:w.stiller at dkfz-heidelberg.de> 
>  
> Tel.: +49 (0) 6221 42 2468
> Fax: +49 (0) 6221 42 2572
>  
>  
>  
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder
> diese E-Mail irrtümlich erhalten haben, informieren Sie bitte
> sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte
> Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht
> gestattet.
>
> This e-mail may contain confidential and/or privileged information.
> If you are not the intended recipient (or have received this e-mail
> in error) please notify the sender immediately and destroy this e-mail.
> Any unauthorized copying, disclosure or distribution of the material
> in this e-mail is strictly forbidden.
>
>
> ________________________________
>
> Von: gate-users-bounces at lists.healthgrid.org im Auftrag von Nicolas Karakatsanis
> Gesendet: Di 27.05.2008 23:58
> An: gate-users at lists.healthgrid.org; Sonal Ambwani
> Cc: george loudos
> Betreff: [Gate-users] Cause of problems in reading text files (e.g. GATE macros) at Linux OS after they have been read or written at Windows platform - Solution provided using command "tr"
>
>
>
> Dear GATE users,
>
> I had encountered in the past minor but annoying problems when I was
> trying to use GATE  macro files on a Linux distribution that has
> been previously opened or written using Windows OS.
>
> The problem is caused by a hidden end of line character (EOL) at the
> text files, which is added from Windows in order to indicate change of line.
>
> Most of the times Windows add the hidden characters CR (carriage return)
> and LF (line feed) to seperate lines between them.
> That means that whenever an editor on Windows sees the sequence CR+LF
> will place the next character on the next line.
> However the equivalent line seperator for Linux is LF only. CR is not a
> special character for Linux!
>
> Therefore when GATE (or any other Linux application) tries to read the
> text files, it interprets CR as a part of the command line and NOT as a
> special character. A Linux text editor will read the special
> character LF , after the character CR, and change line in the text file.
> Therefore all the command lines ends with a non-special character CR
> (you can see it as ^M or \r in some advanced Linux text editors)
> If we delete those characters and leave LF intact then Linux will be
> able to read them properly.
>
> Some macro files however are quite long and therefore it is impractical
> to repeat that tedious procedure for every line of every macro file we
> import from Windows.
>
> The solution is simple and comes directly from what is mentioned above...
>
> There is a simple Unix command which is supported by all Linux
> distributions, which performs basic operations to the ASCII characters
> of a text file... this command is tr...
>
> If your text file has been read or written in Windows then the line
> separator will be the sequence of CR+LF characters. Therefore you simply
> need to delete the CR character (or \r) and leave the LF character (\n)
> intact. To do that just type:
>
> tr -d `\r` <input_filename> output_filename
>
> For example if someone sent you a Macrofile with the name :
> Lu_spectrum.mac and you have error messages in GATE like:
> command ignored, command not found
> then simply go to the directory where the Macrofile is located and try
> typing:
> tr -d `\r` <Lu_spectrum.mac>  Lu_spectrum.mac
>
> If for some reason the line separator of your text files is only CR then
> you need to replace CR with LF  to read it correctly at Linux. In that
> case type
> tr `\r` `\n` <input_filename> output_filename
>
>
>
> Some additional advices based on the following problem:
>
> 1) Avoid using Notepad when reading Linux files... you might get a text
> file with just one line (no line seperators)
> Fortunately the windows application of Wordpad does not have such problem
>
> 2) Always type <Enter> right after the end of the last line of your
> Linux text file. This way you make sure the file ends up with a line
> seperator and no problems will occur with the execution of the last
> command. Some applications find it difficult to distinguish between
> EndOfFile (EOF) and EndOfLine(EOL) characters. By placing an EOL at the
> very end of your text file you make sure that there will be no problems.
>
>
> Best regards
> Nicolas
>
>
>
> ___________________________________________________
> Nicolas Karakatsanis, PhD Candidate
> Biomedical Simulations and Imaging Technologies Laboratory
> School of Electrical and Computer Engineering
> National Technical University of Athens, Greece
>
>
> _______________________________________________
> Gate-users mailing list
> Gate-users at lists.healthgrid.org
> http://lists.healthgrid.org/mailman/listinfo/gate-users
>
>
>
>
>
> __________ NOD32 3137 (20080527) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>   