Bug#656657: manpages: environ(7): Please clarify the usage of $PAGER and $EDITOR with regards to whitespace
On Wed, Jan 20, 2021 at 10:16:03AM +0100, Michael Kerrisk (man-pages) wrote: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866060 > seems to be related, and maybe the changes in the patch for that bug > are sufficient to address the concerns in this bug? (That patch as > just been taken upstream.) JFTR, that patch was added to man-pages-5.11, the Changes list | environ.7 | Bastien Roucariès | Reorder the text | Move the text describing how to set environment variable before | the list(s) of variables in order to improve readability. | Bastien Roucariès | Document convention of string in environ | Document the name=value system and that nul byte is forbidden. | Bastien Roucariès | Document that HOME, LOGNAME, SHELL, USER are set at login time | and point to the su(1) manual page. | Bastien Roucariès | Add see also ld.so(8) for LD_ variables | Michael Kerrisk [Bastien Roucariès] | Improve the description of PATH | Add more details of how PATH is used, and mention the legacy | use of an empty prefix. | Bastien Roucariès [Alejandro Colomar, Bastien Roucaries, Vincent Lefevre] | Document valid values of pathnames for SHELL, PAGER and EDITOR/VISUAL | Michael Kerrisk [Bastien Roucariès] | Note the default if PAGER is not defined | Michael Kerrisk | Be a little more precise when discussing 'exec' | Say "execve(2)" instead of "exec(3)", and note that this step | starts a new program (not a new process!). | Michael Kerrisk [Bastien Roucariès] | Relocate and reword the mention of _GNU_SOURCE and the man page now reads | PAGER |The user's preferred utility to display text files. Any |string acceptable as a command-string operand to the sh -c |command shall be valid. If PAGER is null or is not set, then |applications that launch a pager will default to a program such |as less(1) or more(1). | | EDITOR/VISUAL |The user's preferred utility to edit text files. Any string |acceptable as a command_string operand to the sh -c command |shall be valid. So this bug can be closed once that version enters Debian. Cheers, Flo signature.asc Description: PGP signature
Bug#656657: manpages: environ(7): Please clarify the usage of $PAGER and $EDITOR with regards to whitespace
Hi Michael, Michael Kerrisk (man-pages) wrote: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866060 > seems to be related, and maybe the changes in the patch for that bug > are sufficient to address the concerns in this bug? (That patch as > just been taken upstream.) Indeed it is, thanks, also to Bastien (Cc'ed). So now we can start filing bug reports against tools which say "'emacsclient -a emacs': No such file or directory". ;-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#656657: manpages: environ(7): Please clarify the usage of $PAGER and $EDITOR with regards to whitespace
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866060 seems to be related, and maybe the changes in the patch for that bug are sufficient to address the concerns in this bug? (That patch as just been taken upstream.) Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Bug#656657: manpages: environ(7): Please clarify the usage of $PAGER and $EDITOR with regards to whitespace
Package: manpages Version: 3.35-0.1 Severity: wishlist Hi, In several other bug reports[1][2] (I ran into [1]) there are uncertainties about the handling of whitespace (and other shell special characters) in the values of the $PAGER and $EDITOR environment variables. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550843 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289745 Unfortunately environ(7) does not mention how programs should interpret whitespace in values of $PAGER and $EDITOR. It was hard to find an authorative definition for this issue (well, it was even hard to find a definition at all :-) and I found it not exactly where you would look for it, but closeby. In the POSIX specification of mailx[3] and man[4], there is declared: PAGER Determine a string representing an output filtering or pagination command for writing the output to the terminal. Any string acceptable as a command_string operand to the sh -c command shall be valid. [3] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mailx.html [4] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/man.html So at least for $PAGER some parts of POSIX expect the value of the variable to be handle like shell code. I though found no such declaration for $EDITOR or $VISUAL in that document, though. Nevertheless I'd expect those variables to be handled identically. Unfortunately not all programs which look at these environment variables handle the values as POSIX expects them to do. See the section about observed usage below. So environ(7) should A) document how the values of these environment variables should be used (see above), and B) mention the problems that may arise due to the different ways the values of these environment variables are interpreted and maybe a workaround. A common workaround which works with all cases discussed below is to put the path to a shell script in the variable and let the shell script call the program with the according options. Observed Usage -- Common uses of whitespace in the values of these environment variables are: EDITOR="emacsclient -a emacs" (starts emacs if no emacs server is running, connects to an emacs server otherwise). PAGER="less -s" (see the documentation of "-s" in less(1)) PAGER="less -XF" (feels as if the pager is started only if necessary) Nevertheless not all programs handle values with whitespace (or maybe even other special characters as suggested in [5] for $BROWSER) for these variables the same way. [5] http://www.catb.org/~esr/BROWSER/ Currently there seem to be three more or less common ways to interpret the values of $PAGER and $EDITOR: The first two ways are compatible for most cases, e.g. those where whitespace is the only present special character. 1. Pass string to "sh -c" or evaluate it in a shell script. (The "right" way according to the POSIX specification as mentioned above.) This seems also to be the most common way to interpret these variables, including sensible-pager and sensible-editor on Debian as well as e.g. vipw, git or mutt. (Some other tools in Debian like e.g. crontab use sensible-editor by default and therefore work this way, too.) Even bash(*) and zsh seem to use $EDITOR for fc this way and ksh (the original one aka ksh93) uses $FCEDIT that way. (*) Whitespace handling not explicitly documented in bash(1), but setting EDITOR="emacsclient -a emacs" and pressing C-x C-e works) If the program name includes whitespace or other shell meta characters, shell escaping inside the value is needed, e.g. with a backslash: PAGER='/usr/local/bin/my\ favourite\ pager.sh' 2. Split at whitespace and pass the result as an array to exec or friends. This is how sensible-browser seems to work and fail[2]. bash and mksh seem to use $FCEDIT (but not $EDITOR in case of bash) that way. With this kind of implementation it is impossible to use programs which have whitespace in their name (or path if the path is needed). On the other hand it securely prevents security implications if file names contain shell meta characters. See also the discussion in the "Secure BROWSER Specification"[6]. [6] http://www.dwheeler.com/browse/secure_browser.html 3. Pass the whole string as first argument to exec and friends like ldapvi currently does[1]. This does not allow any options to the preferred program, but does allow unescaped whitespace in the program or path name -- which both are very uncommon on POSIX systems compared to the need to have options passed to the preferred pager. In this case the only way to call programs with options is to write a shell script and set the path of the shell script in these variables. This is also suggested several times in the EmacsWiki for emacsclient usage,
