Hi Jonathan, On 2011-07-21 12:48:17 -0500, Jonathan Nieder wrote: > Could you elaborate? Currently "run-mailcap" only reads $DISPLAY and > does not write $XAUTHORITY or any other variable, and that actually > seems sensible to me.
My bug report was about the mailcap(5) man page (which describes mailcap files, independently of run-mailcap: run-mailcap is cited only in the "SEE ALSO" section), not about run-mailcap itself. Mutt uses the mailcap files, but not run-mailcap (though it more or less reimplements run-mailcap). The consequences can be very similar, though. The problem is that when Mutt or run-mailcap is run, the value of $DISPLAY (and $XAUTHORITY) may be incorrect, and it is unavoidable. The reason is that these environment variables are inherited when the process is started, and when a new X session is started, the values of these variables are no longer valid (they no longer reflect the parameters of the X session), and an external process can't change their values to correct them. So, one solution is to do the correction by the shell that will run the programs specified in the mailcap file. However, if it specified that the shell is /bin/sh, this is not possible. > By using system(3), run-mailcap leaves the option open of bypassing > the shell and using execve(3) directly when no metacharacters appear, Using execve(3) directly when no metacharacters appear is incorrect as there may be shell constructs, e.g. . /path/to/rcfile && some_command %s Also, even with a simple command, there may be differences between /bin/sh and execve if the command is also implemented as a shell builtin (e.g., "test"). > or compiling mailcap files to bytecode to speed up more complex > entries. I don't know if either of those would be a net win; I just > mention them to explain why I think that _not_ respecting $SHELL is a > good abstraction. > > It sounds to me like your usecase would be better served by teaching > run-mailcap to use some hook to update the environment That's another possibility. > (but why run-mailcap and not all the other tools that might launch > an X program, like xdg-open?) This wouldn't be specific to run-mailcap. I've cited the case of Mutt. In fact, concerning Mutt, there are other places when one wants to update the environment (e.g. when it starts an editor to compose a message). For thi reason, I've recompiled it to run a /bin/sh wrapper instead of /bin/sh directly. But this also means that it no longer follows the description in the mailcap(5) man page. That's why the mailcap(5) man page needs to be less specific about the shell. > or a more rich mailcap syntax that allows > ~/.mailcap to override /etc/mailcap in a more complex way. Or > something like that --- it's not obvious to me since I don't > understand the context yet. In the mailcap files, there could be some command to specify the shell to use when running a command. ~/.mailcap would have the precedence as usual, and the shell specified would be used on all entries, even if they come from a different mailcap file. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
