Re: some way to inherit kill ring in su'd shell?

Re: some way to inherit kill ring in su'd shell?

[Greg Klanderman]

[redirected from zsh-users]

>>>>> Bart Schaefer <schaefer@brasslantern.com> writes:

> On Jan 11,  8:58pm, Greg Klanderman wrote:
> }
> } Is an enhancement something like this acceptable?
> } 
> } +tindex(zle-line-finished)
> } +item(tt(zle-line-finished))(
> } +This is similar to tt(zle-line-init) but is executed every time the line
> } +editor is finished reading a new line of input.
> } +)

> In concept this is OK (though there might be a better suffix than
> "-finished", maybe even just "-finish")

Yep, whatever you guys like is fine by me..

> but I don't think your patch
> follows through some possible ramifications.  For example, it might
> be preferable to save/restore errflag and retflag so that the values
> from the end of zlecore() are preserved, and it's possible that the
> zle-line-finish widget should not run when errflag != 0.

Those sound like good things to worry about getting right.

> I don't know all the ramifications of the values of various globals
> at the end of zlecore().  PWS?

Right, I certainly don't either..

Anyway, here's a new version of my previous code using this
enhancement which also preserves the kill ring.  There isn't
a builtin module for base64 encoding is there?  :-)


function zle-encode-strings () {
  python -c '
import base64, sys
sys.stdout.write(":".join(map(lambda v: base64.encodestring(v).replace("\n", ""), sys.argv[1:])))
' $@
}

function zle-decode-string () {
  python -c '
import base64, sys
sys.stdout.write(base64.decodestring(sys.argv[1]))
' $1
}

function zle-line-init () {
  local v i=0
  if [[ ${ZLEKILLRINGPID-} != $$ && -n ${ZLECUTBUFFER-} ]] ; then
    CUTBUFFER="$(zle-decode-string $ZLECUTBUFFER)"
    for v in ${(s-:-)ZLEKILLRING} ; do
      killring[((i++))]="$(zle-decode-string $v)"
    done
  fi
}
zle -N zle-line-init

function zle-line-finished () {
  export ZLEKILLRINGPID=$$
  export ZLECUTBUFFER="$(zle-encode-strings $CUTBUFFER)"
  export ZLEKILLRING="$(zle-encode-strings $killring[@])"
}
zle -N zle-line-finished


cheers,
Greg

Re: some way to inherit kill ring in su'd shell?

[Bart Schaefer]

On Jan 11, 11:00pm, Greg Klanderman wrote:
}
} There isn't a builtin module for base64 encoding is there?  :-)

Not at present.

One problem you're eventually going to run into, probably when you least
want to, is the environment not permitting enough space to pass all the
(expanded-30%-by-base64) text in the killring through it.  Finding a
secure place to pass it through a file is probably most foolproof, even
if you have to gpg the file or something.

Re: some way to inherit kill ring in su'd shell?

[Greg Klanderman]

>>>>> Bart Schaefer <schaefer@brasslantern.com> writes:

> One problem you're eventually going to run into, probably when you least
> want to, is the environment not permitting enough space to pass all the
> (expanded-30%-by-base64) text in the killring through it.

I suspect 64k will be sufficient, and I can always gzip.

greg

Re: some way to inherit kill ring in su'd shell?

[Richard Hartmann]

On Mon, Jan 12, 2009 at 20:33, Greg Klanderman <gak@klanderman.net> wrote:

> I suspect 64k will be sufficient, and I can always gzip.

64{0,} kiB should be enough for everyone.


Scnr,
Richard

PATCH: add zle-line-finish special widget

[Greg Klanderman]

Hi, I'm re-submitting my previous patch having addressed some of
Bart's concerns.  In particular, I have renamed the special widget to
"zle-line-finish" (was zle-line-finished) and have added code to
save/restore errflag and retflag so that the values from the end of
zlecore() are preserved.

Bart also made the following comments on my original patch which I
have not addressed:

> it's possible that the zle-line-finish widget should not run when
> errflag != 0.

> I don't know all the ramifications of the values of various globals
> at the end of zlecore().  PWS?

Peter, could you comment?

cheers,
Greg


Index: Doc/Zsh/zle.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/zle.yo,v
retrieving revision 1.75
diff -u -r1.75 zle.yo
--- Doc/Zsh/zle.yo	9 Dec 2008 17:37:01 -0000	1.75
+++ Doc/Zsh/zle.yo	16 Jan 2009 23:36:37 -0000
@@ -870,6 +870,11 @@
 (The command inside the function sets the keymap directly; it is
 equivalent to tt(zle vi-cmd-mode).)
 )
+tindex(zle-line-finish)
+item(tt(zle-line-finish))(
+This is similar to tt(zle-line-init) but is executed every time the
+line editor has finished reading a line of input.
+)
 tindex(zle-keymap-select)
 item(tt(zle-keymap-select))(
 Executed every time the keymap changes, i.e. the special parameter
Index: Src/Zle/zle_main.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_main.c,v
retrieving revision 1.121
diff -u -r1.121 zle_main.c
--- Src/Zle/zle_main.c	9 Dec 2008 17:37:01 -0000	1.121
+++ Src/Zle/zle_main.c	16 Jan 2009 23:36:37 -0000
@@ -1212,6 +1212,18 @@
 
     zlecore();
 
+    if ((initthingy = rthingy_nocreate("zle-line-finish"))) {
+	int saverrflag = errflag;
+	int savretflag = retflag;
+	char *args[2];
+	args[0] = initthingy->nam;
+	args[1] = NULL;
+	execzlefunc(initthingy, args, 1);
+	unrefthingy(initthingy);
+	errflag = saverrflag;
+	retflag = savretflag;
+    }
+
     statusline = NULL;
     invalidatelist();
     trashzle();

Re: PATCH: add zle-line-finish special widget

[Peter Stephenson]

On Fri, 16 Jan 2009 18:54:03 -0500
Greg Klanderman <gak@klanderman.net> wrote:
> > it's possible that the zle-line-finish widget should not run when
> > errflag != 0.
> 
> > I don't know all the ramifications of the values of various globals
> > at the end of zlecore().  PWS?

I suspect if you don't set errflag to 0 at that point (and it's
non-zero) it might not run anyway, but I haven't looked (I would have to
trace the code or test it, which you can do if you feel inclined).
I don't know if this is correct or not---it really depends what
zle-line-finish is designed to do.  If it's a catch-all tidy up, it
probably *should* run and then you probably should set errflag to 0
after saving the surrounding value.

You might want to check if Bart's recent comments on zle-line-init are
relevant.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: PATCH: add zle-line-finish special widget

[Bart Schaefer]

On Jan 16,  6:54pm, Greg Klanderman wrote:
}
} Bart also made the following comments on my original patch which I
} have not addressed:
} 
} > it's possible that the zle-line-finish widget should not run when
} > errflag != 0.
} 
} > I don't know all the ramifications of the values of various globals
} > at the end of zlecore().  PWS?
} 
} Peter, could you comment?

One thing related to another thread is that zle-line-finish will run
when push-line-or-edit is used, between the push-input and get-line
stages.  zle-line-finish will also run *after* send-break, i.e., it
will run even if you interrupt editing with ^C.

Both of those would be avoided if zle-line-finish runs only when
errflag != 0.  Refreshing my memory of the code a bit, I'm coming
to the conclusion that the test should be:

    if (done && !exit_pending && !errflag &&
    	(initthingy = rthingy_nocreate("zle-line-finish"))) {

At the very least it should check (done && !exit_pending), even if
it ignores the state of errflag.

Re: PATCH: add zle-line-finish special widget

[Greg Klanderman]

>>>>> Bart Schaefer <schaefer@brasslantern.com> writes:

> Refreshing my memory of the code a bit, I'm coming
> to the conclusion that the test should be:

>     if (done && !exit_pending && !errflag &&
>     	(initthingy = rthingy_nocreate("zle-line-finish"))) {

> At the very least it should check (done && !exit_pending), even if
> it ignores the state of errflag.

Either of those should be OK by me.. would you like me to
test one or the other a bit and re-submit the patch?

>>>>> Peter Stephenson <p.w.stephenson@ntlworld.com> writes:

> I don't know if this is correct or not---it really depends what
> zle-line-finish is designed to do.  If it's a catch-all tidy up, it
> probably *should* run and then you probably should set errflag to 0
> after saving the surrounding value.

Right.. for my current use case it doesn't really matter whether it
runs in the error case or not.  I'm not sure which semantics is best
in general.  If one wanted to use it for some cleanup, or messing with
font colors or whatever, you might want it to run always.

thanks,
Greg

Re: PATCH: add zle-line-finish special widget

[Peter Stephenson]

On Thu, 22 Jan 2009 19:50:51 -0500
Greg Klanderman <gak@klanderman.net> wrote:
> >>>>> Bart Schaefer <schaefer@brasslantern.com> writes:
> 
> > Refreshing my memory of the code a bit, I'm coming
> > to the conclusion that the test should be:
> 
> >     if (done && !exit_pending && !errflag &&
> >     	(initthingy = rthingy_nocreate("zle-line-finish"))) {
> 
> > At the very least it should check (done && !exit_pending), even if
> > it ignores the state of errflag.
> 
> Either of those should be OK by me.. would you like me to
> test one or the other a bit and re-submit the patch?

That what probably be sensible

> >>>>> Peter Stephenson <p.w.stephenson@ntlworld.com> writes:
> 
> > I don't know if this is correct or not---it really depends what
> > zle-line-finish is designed to do.  If it's a catch-all tidy up, it
> > probably *should* run and then you probably should set errflag to 0
> > after saving the surrounding value.
> 
> Right.. for my current use case it doesn't really matter whether it
> runs in the error case or not.  I'm not sure which semantics is best
> in general.  If one wanted to use it for some cleanup, or messing with
> font colors or whatever, you might want it to run always.

For now it sounds like you should leave it as it is.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: PATCH: add zle-line-finish special widget

[Greg Klanderman]

[-- Attachment #1: Type: text/plain, Size: 117 bytes --]


Hi Peter and Bart,

Here is an updated version of the patch for this feature.

thanks for your help on this,
Greg



[-- Attachment #2: zsh-finish.patch --]
[-- Type: text/plain, Size: 1455 bytes --]

Index: Doc/Zsh/zle.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/zle.yo,v
retrieving revision 1.76
diff -u -r1.76 zle.yo
--- Doc/Zsh/zle.yo	19 Jan 2009 17:57:43 -0000	1.76
+++ Doc/Zsh/zle.yo	28 Jan 2009 04:26:36 -0000
@@ -871,6 +872,11 @@
 (The command inside the function sets the keymap directly; it is
 equivalent to tt(zle vi-cmd-mode).)
 )
+tindex(zle-line-finish)
+item(tt(zle-line-finish))(
+This is similar to tt(zle-line-init) but is executed every time the
+line editor has finished reading a line of input.
+)
 tindex(zle-keymap-select)
 item(tt(zle-keymap-select))(
 Executed every time the keymap changes, i.e. the special parameter
Index: Src/Zle/zle_main.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_main.c,v
retrieving revision 1.121
diff -u -r1.121 zle_main.c
--- Src/Zle/zle_main.c	9 Dec 2008 17:37:01 -0000	1.121
+++ Src/Zle/zle_main.c	28 Jan 2009 04:26:36 -0000
@@ -1212,6 +1212,19 @@
 
     zlecore();
 
+    if (done && !exit_pending && !errflag &&
+	(initthingy = rthingy_nocreate("zle-line-finish"))) {
+	int saverrflag = errflag;
+	int savretflag = retflag;
+	char *args[2];
+	args[0] = initthingy->nam;
+	args[1] = NULL;
+	execzlefunc(initthingy, args, 1);
+	unrefthingy(initthingy);
+	errflag = saverrflag;
+	retflag = savretflag;
+    }
+
     statusline = NULL;
     invalidatelist();
     trashzle();