Re: [Sheflug] Apologies for long line length and a newline problem

[Lesley Anne Binks <lesley.binks [at] xxxxxxxxx>]

Chris J <cej [at] nightwolf.org.uk> wrote :

> And Lo! The Great Prophet Lesley Anne Binks uttered these words of wisdom:
> >
> > Now in Windows 0x0D 0x0A is the carriage return line feed
> > and on Linux boxes I've always understood it's 0x0D only.
> > Emacs showed the  newlines not as newlines but as ^M 
> > which translates to 0x0D.  Obviously this caused problems on 
> > a search and replace.
> 
> Linux (and UNIX in general) lines end with a linefeed -- LF (0x0A). If 
> you're used to using text files on a mac, then text files there end in CR
> (0x0D) only. Microsoft does (arguably) the right thing treating CR and LF
> as two copletely seperate functions.
> 

Which at least explains why there is only an '0x0D' in the 
original text file.  Forensic computing anyone ;-)

> However arguing about that is beyond the scope of this email :-)

Indeed, but worth noting they come from the days of 
teletypewriters as data ouput, where one only would have
caused 'interesting' output.
> 
> > Anyone else come up against this kind of problem ? What's 
> > the fix, bar going through the extracted text files and 
> > making the relevant replacements by hand?
> 
> In ksh/sh/bash, this will process /all/ files in the current directory.
> 
> 	for i in *
> 	do
> 		if [ -f $i ]; then
> 			mv $i /tmp/workfile
> 			tr -d '\r'  $i
> 		fi
> 	done
> 
> should do the job (untested). There may be a way to do it in perl using its 
> in-line editing (so you don't need to make a temporary file), but I'll 
> leave that for the perl monks.
> 

TYVM

Lesley






___________________________________________________________________

Sheffield Linux User's Group -
http://www.sheflug.co.uk/mailfaq.html

  GNU the choice of a complete generation.