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

[Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx>]

On 2009-01-10 at 16:28 -0500, Greg Klanderman wrote:
> >>>>> Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx> writes:
> > Grotesque and there's probably a more elegant way which I'm missing, but
> > you could rebind ^M from accept-line to a custom widget which does some
> 
> I guess I could just stuff the killring (I'd even be happy with just
> CUTBUFFER) into an exported environment variable unconditionally for
> every command.  Both ways I normally su preserve the environment.
> 
> Is the only way to do that to replace accept-line and friends with
> custom widgets?  Could I instead use zle from a preexec hook somehow?

Pass.  ZLE is an area I've stayed away from, more than I should.  You
could always send zsh-users a patch to add the variables you want to the
zsh/zleparameter module.  :)  If you do that, then it's much easier,
since you just do something like:

 if is-at-least 4.3.10 ; then
   zmodload -i zsh/zleparameter
   function su { PARENT_CUTBUFFER="$CUTBUFFER" command su "$@" }
 fi

> When not preserving the environment, you'd have the problem that each
> user's shell startup needs to be hacked appropriately to look for and
> slurp in the killring/CUTBUFFER; probably not worth it.
> 
> > check if the file is less than a minute old and, if so, source it.
> 
> Can you be more specific about how to slurp the killring/CUTBUFFER
> back into the su'd to shell?

If not using an environment variable?

Hrm.  I was just thinking of having it be available in a variable to
reference, not to initialise the new killring with it.  Sorry.  You'd
probably want to add an init API to zsh/zleparameter too.  Unless
someone else points out an approach I'm missing.

I only realised this was probably what you meant when I was thinking
about what could be done if extending zsh/zleparameter anyway, so had
already written a bunch of reply which I now suspect is beneath the
level you are at, but I'll include it here in case I'm wrong or it helps
someone else.  *cough*

Regards,
-Phil

[....]
The actual slurp would just be a source, since typeset -p would have
emitted shell commands to set variables, dealing with all quoting.  Thus
the importance of checking paths appropriately.

Hrm, I tend to just have zsh/stat and zsh/datetime loaded, so I'd do it
with something like:

  function grab_killring {
    local krstat timediff fn
    fn="/home/$1/.killring"
    zstat -L -H krstat "$fn"
    [[ $? -ne 0 ]] && return 0
    if [[ -n $krstat[link] ]]; then
      print -u2 "Not reading symlink killring: $fn"
      return 1
    fi
    (( timediff = $EPOCHSECONDS - $krstat[mtime] ))
    if [[ $timediff -gt 0 && $timediff -le 60 ]]; then
      # if file can't be read, just let . report that
      . "$fn"
    fi
  }
  # ...
  case $SUDO_USER in
    fred|wilma) grab_killring $SUDO_USER ;;
  esac

This treats absence of a file (or parent dir access problems) and a
too-old file as silent non-issues and a symlink or unreadable file as
reportable ones.  The ACL checks for permitted users can then be done
separately -- I tend to use sudo, thus $SUDO_USER.

Creating a file I/O operation for _every_ command executed would not be
my preferred method, thus the dispatch based on command-type, but as
long as there's never sensitive data in the killring that shouldn't be
exposed via the process env of run commands (or you have an OS that
restricts who can see the process env) then you should be fine with your
approach.

-Phil