From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19984 invoked by alias); 2 Sep 2013 13:56:23 -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: 17965 Received: (qmail 5831 invoked from network); 2 Sep 2013 13:56:16 -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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at samsung.com does not designate permitted sender hosts) X-AuditID: cbfec7f4-b7f0a6d000007b1b-e5-5224969b248a Date: Mon, 02 Sep 2013 14:46:01 +0100 From: Peter Stephenson To: zsh-users@zsh.org Subject: Re: mailcap configuration in zsh can't open .bk files Message-id: <20130902144601.4930cb81@pwslap01u.europe.root.pri> In-reply-to: References: <130830101018.ZM26161@torch.brasslantern.com> <201309011711.r81HBEEF002418@pws-pc.ntlworld.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42I5/e/4Fd3Z01SCDN6esrDYcXIlowOjx6qD H5gCGKO4bFJSczLLUov07RK4MqbO28FaMJWv4v3NVcwNjO+5uhg5OSQETCRWLWlnhLDFJC7c W8/WxcjFISSwlFGiY/VlRiiHSeLxkqPMIFUsAqoSPy4/ZQOx2QQMJaZumg3WLSIgKrF8xWZ2 EFtYwE7i66mTTCA2r4C9xMQJb8FsToFgiQevT7FCDL3EKHF22ScWkAS/gL7E1b+fmCDOsJeY eeUMI0SzoMSPyffAapgFtCQ2b2tihbDlJTavecs8gVFgFpKyWUjKZiEpW8DIvIpRNLU0uaA4 KT3XUK84Mbe4NC9dLzk/dxMjJAy/7GBcfMzqEKMAB6MSD2/FCuUgIdbEsuLK3EOMEhzMSiK8 vyerBAnxpiRWVqUW5ccXleakFh9iZOLglGpgFM3IuzvBdda21tulvNa6G95I1ryUswy7LHb+ 8ca+hfUHPprPba45a9nN+CWoO23N0VBPWdfv7jI+2QVGR9n7trSFWn5k2T2360ZNBrfK7N9d s9WluXv6Z8utSP7zPGP/cw/+iXuL3rN+mMPCFfVovtZBqX6pf9KSm9Y+4rnldZOzz3qiv1KC EktxRqKhFnNRcSIA8qH80CECAAA= On Mon, 02 Sep 2013 09:28:26 +0800 vinurs wrote: > It's not intelligent deciding filetype by suffix only, I'd like to write > functions to open flles using 'file --mime-type' You're on your own here -- the zsh system isn't going to do this --- and it looks like you've got problems. The shell allows you to define a command to handle other commands that aren't found, but it doesn't allow you define a command to handle other errors, in particular "permission denied", which is what you'd get if you tried to "execute" a non-executable file that wasn't aliased by one means or another. Your best bet might be to do it in ZLE as a zle-line-finish hook. It's going to be a bit of a guess, but if you determine that the word in command position is a file but isn't executable, then you've got the basis for something workable. You'd then need to insert the handler back in the command line at the start of BUFFER. I haven't tried the following, so there may be trivial bugs, but you ought to be able to whip it into shape with enough effort. zle-line-finish() { local REPLY REPLY2 handler local -a reply autoload -Uz split-shell-arguments split-shell-arguments local fname=$reply[1] # Tests here could be a bit more stringent if [[ -n $fname && -f $fname && ! -x $fname ]]; then # Should replace the case with a look-up similar to zsh-mime-handler # but based on type not suffix. case ${$(file --mime-type $fname)##*:} in # HERE: match types, e.g. (application/pdf) handler=okular ;; esac fi # HERE: cleverness for backgrounding, etc, also similar to # zsh-mime-handler. if [[ -n $handler ]]; then BUFFER="$handler $BUFFER" fi } zle -N zle-line-finish pws