Prev: compare 10th column from file1 to file2
Next: aborting a bash script with control-c
From: Ben Bacarisse on 28 May 2010 09:25
Ed Morton <mortonspam(a)gmail.com> writes:

> On 5/28/2010 3:18 AM, pk wrote:
>> Ben Bacarisse wrote:
> <snip>
>>> Is
>>> there such a things as bad sed style? :-)
>>
>> Some people on this list say that using sed for anything else than simple
>> substitutions on the same line is bad, so we better stop it here :-)
>
> Maybe it's just me, but I think this thread with it's many iterations
> of sed attempts:

<snip horrid sed!>

> each with arcane configurations of single-character commands and each
> attempting to solve non-obvious problems that the others have with
> some input sets, pretty well underscores the point that you shouldn't
> attempt to use sed to do anything with input that spans lines.
<snip>
> The awk solution, on the other hand:
>
> awk -v RS= '{sub(/string1\nstring2/,"string3\nstring4")}1'
>
> is pretty clear and only took one attempt to get right.

Nope. Let's call that attempt 1 shall we? Maybe you got confused by
the arcane function names. :-)

Of course I am joking, but if you are going to present a tool that makes
it easy to get the right answer, you need to get the right answer! Awk
*is* often easier for this sort of thing but it won't always be able to
stream the data in this case. We don't know of that matters of course,
but it might.

I post sed for fun, BTW; I am rarely advocating its use for anything
but simple cases. The reader can choose if they like the
readability/functionality of the result.

--
Ben.
From: Ed Morton on 28 May 2010 09:44
On 5/28/2010 8:25 AM, Ben Bacarisse wrote:
> Ed Morton<mortonspam(a)gmail.com> writes:
>
>> On 5/28/2010 3:18 AM, pk wrote:
>>> Ben Bacarisse wrote:
>> <snip>
>>>> Is
>>>> there such a things as bad sed style? :-)
>>>
>>> Some people on this list say that using sed for anything else than simple
>>> substitutions on the same line is bad, so we better stop it here :-)
>>
>> Maybe it's just me, but I think this thread with it's many iterations
>> of sed attempts:
>
> <snip horrid sed!>
>
>> each with arcane configurations of single-character commands and each
>> attempting to solve non-obvious problems that the others have with
>> some input sets, pretty well underscores the point that you shouldn't
>> attempt to use sed to do anything with input that spans lines.
> <snip>
>> The awk solution, on the other hand:
>>
>> awk -v RS= '{sub(/string1\nstring2/,"string3\nstring4")}1'
>>
>> is pretty clear and only took one attempt to get right.
>
> Nope. Let's call that attempt 1 shall we? Maybe you got confused by
> the arcane function names. :-)
>
> Of course I am joking, but if you are going to present a tool that makes
> it easy to get the right answer, you need to get the right answer! Awk
> *is* often easier for this sort of thing but it won't always be able to
> stream the data in this case.

Sounds like you can see a problem with the awk solution. I don't see it - what
do you mean "it won't always be able to stream the data in this case."?

We don't know of that matters of course,
> but it might.
>
> I post sed for fun, BTW; I am rarely advocating its use for anything
> but simple cases. The reader can choose if they like the
> readability/functionality of the result.

I think that's true of most people who post sed solutions, it's more that it's
interesting and challenging to see if they can solve the puzzle using sed than
that they'd really suggest using it. I understand that but I think it can be
confusing for the OP if it isn't specifically stated.

Ed.
From: Ben Bacarisse on 28 May 2010 13:06
Ed Morton <mortonspam(a)gmail.com> writes:

> On 5/28/2010 8:25 AM, Ben Bacarisse wrote:
<snip>
>>> The awk solution, on the other hand:
>>>
>>> awk -v RS= '{sub(/string1\nstring2/,"string3\nstring4")}1'
>>>
>>> is pretty clear and only took one attempt to get right.
>>
>> Nope. Let's call that attempt 1 shall we? Maybe you got confused by
>> the arcane function names. :-)
>>
>> Of course I am joking, but if you are going to present a tool that makes
>> it easy to get the right answer, you need to get the right answer! Awk
>> *is* often easier for this sort of thing but it won't always be able to
>> stream the data in this case.
>
> Sounds like you can see a problem with the awk solution. I don't see it

It doesn't work (at least for me):

$ cat eg
string1
string2
xxxx
string1
string2
xxxx
$ awk -v RS= '{sub(/string1\nstring2/,"string3\nstring4")}1' <eg
string3
string4
xxxx
string1
string2
xxxx

should not the second pair also be replaced?

> - what do you mean "it won't always be able to stream the data in
> this case."?

That's another issue. If your input has one record (maybe many MB) then
no output will be produced until the input has been consumed. I some
cases it can be useful if output can be processed before the input is
consumed. This is a (small) fault with almost all awk scripts that set
RS to something that may not occur frequently in that input.

<snip>
--
Ben.
First  |  Prev  | 
Pages: 1 2 3
Prev: compare 10th column from file1 to file2
Next: aborting a bash script with control-c