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

Groups > alt.os.linux.debian > #7538 > unrolled thread

grep in non linux EOL?

Back to article view | Back to alt.os.linux.debian

Contents

  grep in non linux EOL? no.top.post@gmail.com - 2015-12-26 23:01 +0000
    Re: grep in non linux EOL? mm0fmf <none@mailinator.com> - 2015-12-26 23:44 +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
          Re: grep in non linux EOL? Alastair Black <abqab.nemo@example.net> - 2015-12-28 09:17 -0700

#7538 — grep in non linux EOL?

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.

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"

==TIA.

[toc] | [next] | [standalone]

#7539

On 26/12/2015 23:01, 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.
>
> 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"
>
> ==TIA.
>
How is this specific to Debian? Stop crossposting.

[toc] | [prev] | [next] | [standalone]

#7540

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.

[toc] | [prev] | [next] | [standalone]

#7588

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.

[toc] | [prev] | [next] | [standalone]

#7601

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.
> 
No! That's like saying you can't extract the last 2 words before
"dog", "cat" or "cow".
What fooled me was the <line overwriting>, so you don't
"get what you see". 

Perhaps it's easier to convert the output to *nix?
Well no: having the whole file as one-line is a disaster for
`grep`, which is line based. 

So perhaps the sequence should be:
Find | xarg Tr x0d -> x0a | Grep
?

[toc] | [prev] | [next] | [standalone]

#7546

no.top.post@gmail.com Wrote in message:
> 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.
> 
> 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"
> 
> ==TIA.
> 
> 

I would put it this way, but I could be wrong:

grep looks line by line. To define a line, it looks for a Linux EOL.
If it finds the EOL from a different OS, it ignores that and keeps
going.  I have had bad EOF messages because the last 
character in the file was not an EOL.

Doug. 
-- 

[toc] | [prev] | [next] | [standalone]

#7547

no.top.post@gmail.com Wrote in message:
> 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.
> 
> 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"
> 
> ==TIA.
> 
> 

Your "grep Gates" may be looking at one big long line that
 displays word-
wrapped, but really isn't. 

The concepts involved do puzzle me, but I can use them.

What does a typewriter do?  It goes to the next line (that is <LF> )
and the carriage goes back (that is <CR> ).  Those two codes
are used together only in Windows.  In Linux and the
Mac, only one marks the end-of-line, but both happen.

Doug. 
-- 

[toc] | [prev] | [next] | [standalone]

#7548

On 28/12/15 09:47, Doug Laidlaw wrote:
> no.top.post@gmail.com Wrote in message:
>> 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.
>>
>> 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"
>>
>> ==TIA.
>>
>>
>
> Your "grep Gates" may be looking at one big long line that
>   displays word-
> wrapped, but really isn't.
>
> The concepts involved do puzzle me, but I can use them.
>
> What does a typewriter do?  It goes to the next line (that is <LF> )
> and the carriage goes back (that is <CR> ).  Those two codes
> are used together only in Windows.  In Linux and the
> Mac, only one marks the end-of-line, but both happen.
>
It all harks back to the days of teletypes and mecahnical printers.

By the time UNIX was developed, CRT displays and monitors were common place.

DOS owes its heritage to CP/M and that harks back in turn to I think an 
INTEL operating system used on their 8080 development platform



> Doug.
>


-- 
the biggest threat to humanity comes from socialism, which has utterly 
diverted our attention away from what really matters to our existential 
survival, to indulging in navel gazing and faux moral investigations 
into what the world ought to be, whilst we fail utterly to deal with 
what it actually is.

[toc] | [prev] | [next] | [standalone]

#7555

The Natural Philosopher <tnp@invalid.invalid> wrote:
>On 28/12/15 09:47, Doug Laidlaw wrote:
>> no.top.post@gmail.com Wrote in message:
>>> 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.
>>>
>>> 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"
>>>
>>> ==TIA.
>>>
>>>
>>
>> Your "grep Gates" may be looking at one big long line that
>>   displays word-
>> wrapped, but really isn't.
>>
>> The concepts involved do puzzle me, but I can use them.
>>
>> What does a typewriter do?  It goes to the next line (that is <LF> )
>> and the carriage goes back (that is <CR> ).  Those two codes
>> are used together only in Windows.  In Linux and the
>> Mac, only one marks the end-of-line, but both happen.
>>
>It all harks back to the days of teletypes and mecahnical printers.
>
>By the time UNIX was developed, CRT displays and monitors were common place.

In 1969???  Not at all.  UNIX was developed using
teletype machines printing on paper for IO.  And
incidentally, UNIX did not invent the idea of using a
single character for a newline, the Teletype Corporation
did!

This URL has a picture of Ken Thompson and Dennis Ritchie
working with UNIX on a PDP-11 at Bell Labs.

https://en.wikipedia.org/wiki/Ken_Thompson#/media/File:Ken_Thompson_(sitting)_and_Dennis_Ritchie_at_PDP-11_(2876612463).jpg

>DOS owes its heritage to CP/M and that harks back in
>turn to I think an INTEL operating system used on their
>8080 development platform

CP/M was developed on Intel hardware, and the reason
for developing it was a total lack of any kind of
an OS. Gary Kildall came up with CP/M in 1973.  He
offered it to Intel, but they were not interested
because they were working on an OS of their own.

Note that there is a significant distinction in what
UNIX and CP/M were intended for.  UNIX was a research
project to develop a multi-user fully functional OS on a
"small" *computer* the size of several racks of equipment.
CP/M was meant to provide the absolute bare minimum of
management for a single user working with a *device*
*controller* to simulate some functions of a "real"
computer.  It all sat on a desktop, and the true marvel
was that an 8080 device controller could do anything
useful at all!

Intel did not see their device controllers as "micro
computers".  A group of engineers broke off and formed
Zilog to do just that.  Intel continued to produce
device controllers right up to the 80186.  The 80286
was the first nod to a computer, and the 80386 was
their first "real" computer chip.

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#7562

On 12/28/2015 06:05 AM, Floyd L. Davidson wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 28/12/15 09:47, Doug Laidlaw wrote:
>>> no.top.post@gmail.com Wrote in message:
>>>> 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.
>>>>
>>>> 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"
>>>>
>>>> ==TIA.
>>>>
>>>>
>>>
>>> Your "grep Gates" may be looking at one big long line that
>>>    displays word-
>>> wrapped, but really isn't.
>>>
>>> The concepts involved do puzzle me, but I can use them.
>>>
>>> What does a typewriter do?  It goes to the next line (that is <LF> )
>>> and the carriage goes back (that is <CR> ).  Those two codes
>>> are used together only in Windows.  In Linux and the
>>> Mac, only one marks the end-of-line, but both happen.
>>>
>> It all harks back to the days of teletypes and mecahnical printers.
>>
>> By the time UNIX was developed, CRT displays and monitors were common place.
>
> In 1969???  Not at all.  UNIX was developed using
> teletype machines printing on paper for IO.  And
> incidentally, UNIX did not invent the idea of using a
> single character for a newline, the Teletype Corporation
> did!
>
> This URL has a picture of Ken Thompson and Dennis Ritchie
> working with UNIX on a PDP-11 at Bell Labs.
>
> https://en.wikipedia.org/wiki/Ken_Thompson#/media/File:Ken_Thompson_(sitting)_and_Dennis_Ritchie_at_PDP-11_(2876612463).jpg
>
>> DOS owes its heritage to CP/M and that harks back in
>> turn to I think an INTEL operating system used on their
>> 8080 development platform
>
> CP/M was developed on Intel hardware, and the reason
> for developing it was a total lack of any kind of
> an OS. Gary Kildall came up with CP/M in 1973.  He
> offered it to Intel, but they were not interested
> because they were working on an OS of their own.
>
> Note that there is a significant distinction in what
> UNIX and CP/M were intended for.  UNIX was a research
> project to develop a multi-user fully functional OS on a
> "small" *computer* the size of several racks of equipment.
> CP/M was meant to provide the absolute bare minimum of
> management for a single user working with a *device*
> *controller* to simulate some functions of a "real"
> computer.  It all sat on a desktop, and the true marvel
> was that an 8080 device controller could do anything
> useful at all!
>
> Intel did not see their device controllers as "micro
> computers".  A group of engineers broke off and formed
> Zilog to do just that.  Intel continued to produce
> device controllers right up to the 80186.  The 80286
> was the first nod to a computer, and the 80386 was
> their first "real" computer chip.
>

So where does Eric Isaacson fit into all that?

Alastair

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.linux.debian

csiph-web