From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8317 invoked by alias); 4 Nov 2013 19:30:29 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 18091 Received: (qmail 10000 invoked from network); 4 Nov 2013 19:30:14 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 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== MIME-Version: 1.0 X-Received: by 10.152.29.38 with SMTP id g6mr5993189lah.25.1383593409925; Mon, 04 Nov 2013 11:30:09 -0800 (PST) In-Reply-To: <131030092555.ZM8077@torch.brasslantern.com> References: <131030092555.ZM8077@torch.brasslantern.com> Date: Mon, 4 Nov 2013 17:30:09 -0200 Message-ID: Subject: Re: Fish-like autosuggestions From: Thiago Padilha To: Bart Schaefer Cc: Zsh-Users List Content-Type: multipart/alternative; boundary=089e0158c004b658d904ea5ef100 --089e0158c004b658d904ea5ef100 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 30, 2013 at 1:25 PM, Bart Schaefer 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. --089e0158c004b658d904ea5ef100--