[9fans] acme g/$/ funny

[9fans] acme g/$/ funny

[roger peppe]

Edit ,x/.*/g/$/a/foo/

shouldn't this append "foo" after every line?

sam gives slightly different behaviour here
(but still questionable) - it appends "foo" after
every empty line.

is this actually a bug, or have i misunderstood the
way that '$' is meant to work?

it does seem strange that in the following edit
command, the guard never matches anything.

Edit ,x/foo$/g/foo$/d

Re: [9fans] acme g/$/ funny

[Charles Forsyth]

>Edit ,x/.*/g/$/a/foo/
>shouldn't this append "foo" after every line?

Edit ,x/.*\n/g/\n/a/foo

or

Edit ,x/.*\n/g/$/a/foo

where the latter gives a little hint about what the code might be doing

Re: [9fans] acme g/$/ funny

[Pietro Gagliardi]

On Jul 17, 2008, at 6:03 AM, roger peppe wrote:
> Edit ,x/.*/g/$/a/foo/
>
> shouldn't this append "foo" after every line?
>
> sam gives slightly different behaviour here
> (but still questionable) - it appends "foo" after
> every empty line.
>
> is this actually a bug, or have i misunderstood the
> way that '$' is meant to work?
>
> it does seem strange that in the following edit
> command, the guard never matches anything.
>
> Edit ,x/foo$/g/foo$/d
>

You misunderstood how Pike regexps work, and it's a bug in sam. The
pattern /./ matches everything EXCEPT a newline, which would be
matched with $. The guard, then, should never work, as the following
proves:

,x/.*/g/$/p

As expected, no output (for sam too). So acme is acting correctly. Why
sam does something, then, with a// is beyond me (a long undiscovered
bug, perhaps?).

The following worked for me for both sam and acme:

,x/$/a/foo/

On Jul 17, 2008, at 8:44 AM, Charles Forsyth wrote:
> Edit ,x/.*\n/g/\n/a/foo
That appends foo at the beginning of the next line. Try i/foo/.

Re: [9fans] acme g/$/ funny

[roger peppe]

On Thu, Jul 17, 2008 at 2:07 PM, Pietro Gagliardi <pietro10@mac.com> wrote:
> ,x/$/a/foo/

i was actually trying to do something slightly different;
my original command was:

  ,x/^[ \t]*let.*/v/in$/a/ in/

and i worked around it by doing

  ,x/^[ \t]let.*\n/v/in\n/x/\n/i/ in/

which wasn't too bad. i just wondered
if the behaviour i saw was actually a bug,
as $ matches the null string at the end of a line,
and i was matching against the null string at the end
of a line. i think i understand why it doesn't work;
but should it work differently?

Re: [9fans] acme g/$/ funny

[Russ Cox]

> On Jul 17, 2008, at 6:03 AM, roger peppe wrote:
>> Edit ,x/.*/g/$/a/foo/
>>
>> shouldn't this append "foo" after every line?
>>
>> sam gives slightly different behaviour here
>> (but still questionable) - it appends "foo" after
>> every empty line.
>>
>> is this actually a bug, or have i misunderstood the
>> way that '$' is meant to work?
>>
>> it does seem strange that in the following edit
>> command, the guard never matches anything.
>>
>> Edit ,x/foo$/g/foo$/d
>>

pietro:
> You misunderstood how Pike regexps work
> ...
> That appends foo at the beginning of the next line. Try i/foo/.

It always brings a smile to my face when you say
things like that to people who have forgotten more
about Plan 9 than you know.  Thank you.


rog:
> Edit ,x/.*/g/$/a/foo/
>
> shouldn't this append "foo" after every line?

I would have expected it to.


pietro:
> The  pattern /./ matches everything EXCEPT a newline,
> which would be matched with $.

This is only half right.  $ matches the empty string before a newline,
not the newline itself.  Don't believe me?  Search for $$.

The real issue here is that inside an x/.*/ loop, the text being
considered has no newline, so the position at the end is no longer
an "empty string before a newline."  (The newline is outside the
search window.)

One possible fix would be to redefine $ to match the end
of the text as well as before newlines.  I've sometimes wanted
that in x loops that don't iterate over whole lines.  That would
have the unfortunate effect that if you had a four-line file like:

	abc\n
	def\n
	ghi\n
	jkl\n

and you ran ,s/$/!/g you would then have the four-and-a-half line file:

	abc!\n
	def!\n
	ghi!\n
	jkl!\n
	!

so you'd have to then define that $ matches the end of the text
unless the last character is a newline.  This is the point where
I usually give up and decide the current semantics are not worth
fiddling with.

Russ