Since commit a90d5e6309c0306d931d398506b242c3eb4f40d7 which fixes bug #23159 the `--eval' command line option signals (error "Trailing garbage following expression: %s") on more than one expression recevied. === $ Emacs --batch --eval "1 2" Trailing garbage following expression: 2 === However if there's trailing white space even single valid expression would be rejected after the fix. === $ Emacs --batch --eval "1 " Trailing garbage following expression: === This causes some old shell script snippets which has trailing newline for formatting no longer works, such as the follow script from https://orgmode.org/manual/Batch-Execution.html#Batch-Execution === #!/bin/sh # Tangle files with Org mode # emacs -Q --batch --eval " (progn (require 'ob-tangle) (dolist (file command-line-args-left) (with-current-buffer (find-file-noselect file) (org-babel-tangle)))) " "$@" === From the proposal in bug#23159 https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-07/msg00097.html > I¡¯d suggest (error =22Trailing garbage following expression¡±) > for consistency with the eval-expression function. > > Peace > ¡ªDevon Since `eval-expression' accepts additional white space and newlines after a single expression, this mismatch behavior of `--eval' should be considered as a bug. My proposed fix is apply `string-trim-right` to received string of expression. --- lisp/startup.el.old 2019-06-15 10:31:59.000000000 +0800 +++ lisp/startup.el 2019-06-15 10:34:51.000000000 +0800 @@ -2360,7 +2360,9 @@ ((member argi '("-eval" "-execute")) (setq inhibit-startup-screen t) - (let* ((str-expr (or argval (pop command-line-args-left))) + (let* ((str-expr + (string-trim-right + (or argval (pop command-line-args-left)))) (read-data (read-from-string str-expr)) (expr (car read-data)) (end (cdr read-data)))