bug#59743: Implement `command-line-args-left' for emacsclient --eval expressions

bug#59743: Implement `command-line-args-left' for emacsclient --eval expressions

[Max Nikulin]

I propose to expand protocol of communication between emacsclient and 
server to allow passing of arbitrary arguments for --eval expression
that are not treated as files. The goal is to pass strings to evaluated 
expressions in a safe way without necessity of escaping double quotes 
and backslashes.

I suggest to add e,g, --args option of emacsclient that transfers 
everything after it (including arguments starting with dash) to server 
and causes let-binding the list to command-line-args-left (or another 
variable) before execution of preceding --eval options.

It was briefly discussed in the following thread: Max Nikulin to 
emacs-orgmode. Re: Lazy load of org-protocol. Mon, 7 Feb 2022 21:57:09 
+0700. https://list.orgmode.org/strc07$3o0$1@ciao.gmane.io

Such feature will allow to avoid the following complications:
- A lot of backslashes are used to escape double quotes in
 
http://git.savannah.gnu.org/cgit/emacs.git/tree/etc/emacsclient-mail.desktop
        --eval \\\\(message-mailto\\\\ \\\\\\"%u\\\\\\"\\\\)
   and this file still relies on desktop environment protection
   against shell special characters in the value of %u
- org-protocol sets an advice to intercept file names containing
   components like org-protocol:/store-link?url=URL&title=TITLE
   It is a hack since current working directory is prepended
   when such URI is specified as an emacsclient argument.
   Autoloading currently is not implemented for this advice.
- There are enough unsafe suggestions on the web to directly inject
   argument into elisp expression without proper escaping.

Consider the following message: Gregory Heytings to emacs-devel. Re: How 
to get DISPLAY of emacsclient? Mon, 28 Nov 2022 17:15:28 +0000. 
https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01771.html 
mid:338f50d42149668a6b3a@heytings.org

     emacsclient --eval '(progn (setq display "'$DISPLAY'") (princ 
display))'

Despite probability of such event is rather low, accidentally DISPLAY 
value may be corrupted causing undesired effects of unsafe usage of the 
variable:
- Word splitting is performed by shell after variable substitution.
- If $DISPLAY is additionally wrapped into shell double quotes
   then something unexpected may still be executed by emacs
        DISPLAY=':0") (do-something-else) (ignore "'

More examples of unsafe substitutions into evaluated expression:
- 
https://www.reddit.com/r/emacs/comments/hhbcg7/emacsclient_eval_with_command_line_arguments/
- 
https://stackoverflow.com/questions/8848819/emacs-eval-ediff-1-2-how-to-put-this-line-in-to-shell-script
the second link contains a recipe for proper quoting, but it is not
in the accepted answer
     quoted1=${1//\\/\\\\}; quoted1=${quoted1//\"/\\\"}

As an alternative, Jim Porter suggested an emacsclient option similar to 
emacs --funcall that should apply function to the following argument. I 
believe, if --args is implemented then it will be possible to define a 
helper function that combines function name and the 
command-line-args-left list. It will not require further extension of 
client-server protocol. Since the function to be applied must take 
strings arguments only, no integers or symbols are allowed, anyway 
wrapper functions to convert argument types will be required. That is 
why I do not expect real value of such apply feature.

I hope, the

     emacsclient --eval "(message-mailto (car command-line-args-left))" \
         --args mailto:bug-gnu-emacs@gnu.org

feature will make it easier to pass arguments to the evaluated 
expressions in a safe way.

bug#59743: Implement `command-line-args-left' for emacsclient --eval expressions

[Jim Porter]

On 12/1/2022 7:06 AM, Max Nikulin wrote:
> I propose to expand protocol of communication between emacsclient and 
> server to allow passing of arbitrary arguments for --eval expression
> that are not treated as files. The goal is to pass strings to evaluated 
> expressions in a safe way without necessity of escaping double quotes 
> and backslashes.
> 
> I suggest to add e,g, --args option of emacsclient that transfers 
> everything after it (including arguments starting with dash) to server 
> and causes let-binding the list to command-line-args-left (or another 
> variable) before execution of preceding --eval options.

I believe this is a duplicate of bug#57752, where I and several others 
previously discussed a few options to solve this.