Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Fish-like autosuggestions
- X-seq: zsh-users 18091
- From: Thiago Padilha <tpadilha84@xxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Subject: Re: Fish-like autosuggestions
- Date: Mon, 4 Nov 2013 17:30:09 -0200
- Cc: Zsh-Users List <zsh-users@xxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gturXylEuZU1DJGgm1AjkKMgYV3tBOyIX8c+sBsIpAk=; b=J6ZaF8JT8LPpOXZ9scrWIzyQg1HkTv2nNTBQZA0109uudQfvgvfud5oiNEQPW8q+qt B4Z9sewWsEprTWae/h3xypnbsUsAkEattBG6rwaoLFfS42VVQddyqrG1S79ipx+IEj4n RYBkPNqh1q1ISiovEuZNJK1MVt5LQzO+cYcAk4InquHyVuiOv8JLAzt880V9mdCRRhIO 0WtIzPXj9GQNdDzK/WffbmHvLVSuJrziWN1XUeF9nhdboL47S6sElFvjX0bM7rseNa45 CLxOW6PJH3oAEJ4p1H3VupLNeuivJqYsPX4Esq3Kqk7lsHdYSExSyjo1QJngWIjbtveP qCtg==
- In-reply-to: <131030092555.ZM8077@torch.brasslantern.com>
- List-help: <mailto:zsh-users-help@zsh.org>
- List-id: Zsh Users List <zsh-users.zsh.org>
- List-post: <mailto:zsh-users@zsh.org>
- Mailing-list: contact zsh-users-help@xxxxxxx; run by ezmlm
- References: <CAAq2XdpaRKOnDe1LBafsq+Ln6wU0_9RL71exrOEyboi1PWcx3w@mail.gmail.com> <131030092555.ZM8077@torch.brasslantern.com>
On Wed, Oct 30, 2013 at 1:25 PM, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>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.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author