Jan Minar wrote:
> >> It would really help if we had all the ``special items'' documented, > >> in one place, so people knew what to expect, how to sanitize, and what > >> can go wrong. Something akin to the bash(1) man page talking about > >> various kinds of expansion -- this is what the man page says: > >> > >> ``Expansion is performed on the command line after it has been split > >> into words. There are seven kinds of expansion performed: brace > >> expansion, tilde expansion, parameter and variable expansion, command > >> substitution, arithmetic expansion, word splitting, and pathname > >> expansion. > >> > >> ``The order of expansions is: brace expansion, tilde expansion, > >> parameter, variable and arithmetic expansion and command substitution > >> (done in a left-to-right fashion), word splitting, and pathname > >> expansion.'' > >> > >> And then it goes on, talking about the various types of expansion, in > >> the order they are performed. > >> > >> That would be helpful to have. > >> > >> Now with bash, all we have to do is enclose command arguments in > >> quotes, and interpose the double-dash ``--'' in between the command > >> line switches and the rest of the positional arguments. Simple, easy, > >> provably right. Now with Vim, it is all but easy, and so far there > >> always been a way to trick the quoting. If we had a description of > >> how the evaluation of the command line works wrt ``special items'', at > >> least we could tell whether the sanitization is done correctly. > >> > >> Is somebody up to the task? > > > > The vi POSIX documentation has a try at this, but it's a big puzzle. > > And still wrong. > > What I'd really like to see is, with every command and function, > starting with ``execute'' and system(), an exhaustive documentation of > their behaviour wrt what in their arguments may be interpreted as a > special item, instead of a literal character. This would be part of > the :help documentation for every respective function and command. > The documentation is mostly there, but it's the bits that are missing > that are a trouble. I don't like repeating the same things in several places. It makes documentation maintenance difficult. More difficult to read too. We could find commands that handle their arguments indentically and document that behavior somewhere, with a link to it. Still, that's going to be a lot of work. As mentioned before, system() starts a shell command, so this depends on the shell, not on Vim. I'm not going to document behavior of various shells in the Vim docs. > > There are too many exceptions, I'm afraid. And that the value of > > 'shell' matters doesn't make it simpler. We can't document what all the > > shells do with their arguments when explaining how system() works. > > There are 80 calls to system() throughout the runtime; the following > table details counts per script file in Vim 7.2b: > > 35 autoload/netrw.vim > 16 autoload/tar.vim > 7 autoload/gzip.vim > 5 autoload/zip.vim > 3 ftplugin/ruby.vim > 3 autoload/vimball.vim > 2 ftplugin/perl.vim > 2 ftplugin/man.vim > 2 ftplugin/gitcommit.vim > 2 ftplugin/changelog.vim > 1 ftplugin/debchangelog.vim > 1 autoload/phpcomplete.vim > > Most of those calls don't use any features such as globbing -- if > system() is inherently insecure, what would you think about replacing > it with, say, a function with execve() semantics? We still need a shell to have commands executed in a way that people are used to, such as redirection. Invoking execve() or execvp() has many complications (streams, signals, etc.) and it's not portable. This will probably introduce more bugs than would be solved. -- This sentence is not sure that it exists, but if it does, it will certainly consider the possibility that other sentences exist. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ download, build and distribute -- http://www.A-A-P.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
