Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux.slackware > #26042

Re: grep in non linux EOL?

Cross-posted to 3 groups.

Followups directed to: alt.os.linux.slackware, comp.os.linux.misc, alt.os.linux.debian

Show all headers | View raw

In article <n5nsdn$630$1@dont-email.me>, Rich <rich@example.invalid> wrote: 

> In alt.os.linux.slackware no.top.post@gmail.com wrote:
> > It's OK if you want to donate your much-better-version. But what I
> > really need to know is the REASONING BEHIND why my version fails.
> 
> Because you have 'mixed' three different text file line endings
> together.  Don't do that.  Convert the 'dos' and 'classic mac' line
> ending files to unix style before applying grep to them.
> 
> > With dir-trees having mixed-format text-files: 3 types:
> > *nix, DOS, EOL=x0d, I need to find files containing a string: $1
> >   Testing LEOfind:-
> > #!/bin/bash
> > find  /sa5/Legal/CIPC  -exec grep  "$1" {} \; 2>/dev/null | fold | grep $1
> >     with ./LEOfind Gates , gives me also some lines which do NOT contain
> >     "Gates".
> > Surely `<any command> | grep Gates`
> >  must consist of lines, each containing "Gates"
> 
> Classic Mac files end lines with 0x0d (carriage return).  Carriage
> return on Linux is an "overprint current line" signal for the terminal.
> 
> So, if one of your Mac files has this:
> 
> line # 1 Gates\rline # 2 something \rline # 3 someting else\r\n
> 
> where \r is the Mac carriage return, a Classic Mac would see three
> lines, but grep will see all of the above as one single line (because
> grep only ends 'lines' when it finds a \n character).  And grep will
> print all of the above to the terminal (because "Gates" does occur
> within the 'line' as grep understands it.  But, after printing the
> above to the terminal, you will only see:
> 
>   line # 3 something else
> 
> Because each of #1 and #2 was overlaid by the Mac 'line' that came
> after it.
> 
OK !!
That's not the first time I've been fooled by the <overwriting>.
Thanks.
So, since I want to know which file the string is in,
you'd usually use `grep -l "$1" {} \; 
and wouldn't get the problem.
But if I wanted to SEE the line containing the found string, 
it's not much good <cleaning> it after it's been found, 
because it may be a mile long. 
So perhaps I can fold it and then <clean> it:

find  $Dir  -exec grep  "$1" {} \; 2>/dev/null \
| fold | o2u | dos2u | grep $1

??

OTOH translating all 0x0d to 0x0a
will fit in nicely with this one which I often use:----
#!/bin/bash
echo ' find files here containing $ 1, $ 2 and $ 3'

    find . -type f -print0 | \
    xargs -0 grep -l $1 | tr "\n" "\0" | \
    xargs -0 grep -l $2 | tr "\n" "\0" | \
    xargs -0 grep -l $3

Perhaps?  
I'll test it, after resting from S.hemisphere heat.

Back to alt.os.linux.slackware | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

grep in non linux EOL? no.top.post@gmail.com - 2015-12-26 23:01 +0000
  Re: grep in non linux EOL? Rich <rich@example.invalid> - 2015-12-27 05:19 +0000
    Re: grep in non linux EOL? no.top.post@gmail.com - 2015-12-29 20:05 +0000
    Re: grep in non linux EOL? no.top.post@gmail.com - 2015-12-30 02:05 +0000
  Re:grep in non linux EOL? Doug Laidlaw <laidlaws@hotkey.net.au> - 2015-12-28 20:31 +1100
  Re:grep in non linux EOL? Doug Laidlaw <laidlaws@hotkey.net.au> - 2015-12-28 20:47 +1100
    Re: grep in non linux EOL? The Natural Philosopher <tnp@invalid.invalid> - 2015-12-28 10:18 +0000
      Re: grep in non linux EOL? floyd@apaflo.com (Floyd L. Davidson) - 2015-12-28 04:05 -0900

csiph-web