On 2016/04/13 13:50, Frederic Cambus wrote: > On Tue, Mar 29, 2016 at 04:32:40PM +0100, Stuart Henderson wrote: > > I've run into a slight problem with the lynx pledging. If there's a > > ~/.mailcap entry for a mimetype, lynx uses it to try and display the > > file, for example I have > > > > application/pdf; mutt_bgrun mupdf '%s'; nametemplate=%s.pdf > > > > (mutt_bgrun is the old script from > > http://www.spocom.com/users/gjohnson/mutt/mutt_bgrun) > > so with this, following a link that ends up in a pdf results in lynx > > being killed by pledge. > > > > Indeed, I was able to reproduce the issue locally, and that's something > I initially missed. It doesn't seem to be possible to disable this > behavior using an hardcoded boolean like in the previous patches. > > What we could do is return early in the LYSystem function so that no > external command is ever called. It's not perfect as in the case you > mentioned, there is no error message reported and lynx doesn't offer > to save the file on disk.
I'd actually prefer the crash over this, because it shows clearly that there is something we need to handle, and points to the area of code that's needed. I didn't look at the code but might it be an option to just avoid reading mailcap (pretend that the file doesn't exist) ..? > Here is a patch hardcoding 'no_editor = TRUE' before calling pledge > so calling the editor is disabled with a proper error message That makes sense. In decreasing order of preference: - fallback behaviour (e.g. download for unhandled mime-types) - nice error - hard crash - silently don't do what is supposed to happen
