bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21702: shell-quote-argument semantics and safety


From: Taylan Ulrich Bayırlı/Kammer
Subject: bug#21702: shell-quote-argument semantics and safety
Date: Sun, 18 Oct 2015 17:26:19 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

On the development list it has been pointed out that the Info manual
contains more verbose documentation on this function, although it
doesn't clarify the semantics much either.

=== snip ===
Lisp programs sometimes need to run a shell and give it a command that
contains file names that were specified by the user.  These programs
ought to be able to support any valid file name.  But the shell gives
special treatment to certain characters, and if these characters occur
in the file name, they will confuse the shell.  To handle these
characters, use the function ‘shell-quote-argument’:

 -- Function: shell-quote-argument argument
     This function returns a string that represents, in shell syntax, an
     argument whose actual contents are ARGUMENT.  It should work
     reliably to concatenate the return value into a shell command and
     then pass it to a shell for execution.

     Precisely what this function does depends on your operating system.
     The function is designed to work with the syntax of your system’s
     standard shell; if you use an unusual shell, you will need to
     redefine this function.

          ;; This example shows the behavior on GNU and Unix systems.
          (shell-quote-argument "foo > bar")
               ⇒ "foo\\ \\>\\ bar"

          ;; This example shows the behavior on MS-DOS and MS-Windows.
          (shell-quote-argument "foo > bar")
               ⇒ "\"foo > bar\""

     Here’s an example of using ‘shell-quote-argument’ to construct a
     shell command:

          (concat "diff -c "
                  (shell-quote-argument oldfile)
                  " "
                  (shell-quote-argument newfile))
=== /snip ===

I'm not sure if that needs change, given the change to the docstring,
which counts as the more authoritative documentation of the precise
semantics if I'm not mistaken.

Taylan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]