zsh-users
 help / color / mirror / code / Atom feed
From: Thiago Padilha <tpadilha84@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh-Users List <zsh-users@zsh.org>
Subject: Re: Fish-like autosuggestions
Date: Mon, 4 Nov 2013 17:30:09 -0200	[thread overview]
Message-ID: <CAAq2Xdos6Xdt-XunRuWToDkoaubwztRP8tesPyByU8CWc3FR=Q@mail.gmail.com> (raw)
In-Reply-To: <131030092555.ZM8077@torch.brasslantern.com>

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

On Wed, Oct 30, 2013 at 1:25 PM, Bart Schaefer <schaefer@brasslantern.com>wrote:

> I have some concerns about the client/daemon model (for example what
> prevents a malicious program from connecting to the daemon and sending
> input that would cause the zpty shell to execute a command?) but I
> haven't studied it very closely.
>

I dont understand how a zpty instance could be accessed from outside the
process that started it(I'm assuming its not accessible) but it shouldn't
be possible run commands as the daemon never sends any input that could
cause 'accept-line' to be run. I would also use the following arguments to
defend the security of the model:

1 - There's one daemon per user and the socket is writable only by the user
that started the daemon
2 - The socket lives in a user-restricted (700) temporary directory
3 - If there's malicious code running in the user context, why would it
need to connect to the daemon or a pty in order to damage the system?


> Since you're already doing "zle recursive-edit", you might want to look
> into creating your own keymap instead of changing widget bindings in
> the main keymap.  There are some examples and helper code for this in
> Functions/Zle/keymap+widget in the distribution.
>

I've been playing with keymap+widget but I'm still deciding whether it is
the best solution for the following reasons:

- I'm only using recusive-edit because I couldn't do asynchronous updates
to the zle RBUFFER using 'zle -F'(I started from the 'predict-on' code)
- Sometimes I have to deactivate the autosuggestions feature and
consequently some of the widget hooks(eg: editing the middle of the line or
in vi normal mode)

With the current issues in mind I have a few more questions:

- Is it possible to update the zle RBUFFER from outside a widget? The hook
set with 'zle -F' was being executed outside recursive-edit but it couldnt
modify the RBUFFER variable in that case. In the IRC channel Valodim
mentioned that the hook was not being executed inside zle's context. If so,
is there a way to enter zle's context from a hook set with 'zle -F' ?
- Can the keymap+widget feature be used outside recursive-edit? From what I
understood it will be in effect whenever a [keymap]+[widget] function is
defined and [keymap] is active, if thats the case I can simply switch
keymaps with 'zle -K [keymap]' whenever I need a set of widget hooks to be
active right?
- Whats the best way to modify RBUFFER before a completion widget is
executed? I've tried the comppostfuncs but the RBUFFER variable is
read-only in that context.

  reply	other threads:[~2013-11-04 19:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-29 17:52 Thiago Padilha
2013-10-30 16:25 ` Bart Schaefer
2013-11-04 19:30   ` Thiago Padilha [this message]
2013-11-05 15:57     ` Bart Schaefer
2013-11-05 16:18       ` Peter Stephenson
2013-11-05 19:46         ` Bart Schaefer
2013-11-05 20:40           ` Bart Schaefer
2013-11-06 20:07             ` Peter Stephenson
2013-11-07  0:04               ` Bart Schaefer
2013-11-07  9:44                 ` Peter Stephenson
2013-11-07 18:07                   ` Thiago Padilha
2013-11-07 18:12                     ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAq2Xdos6Xdt-XunRuWToDkoaubwztRP8tesPyByU8CWc3FR=Q@mail.gmail.com' \
    --to=tpadilha84@gmail.com \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).