Build commands are supposed to be either strings or lists of strings.
But the code for deciding whether to eval the :build property only
checks for a string, not a list. This commit fixes this, so that a
build property whose commands are all lists of strings should no
longer cause an error. Evaluation of the :build property now only
happens when the car is a symbol, since that is the only time that
evaluation would not result in an error.
Also in this commit:
* Ensure build commands are all strings or lists of strings and raise
an error otherwise. The check happens after flattening, so nested
lists of strings should also pass.
* A few syntax fixes
* Add a function "el-get-list-of-strings-p"
Use it like this:
(url-retrieve
"https://raw.github.com/dimitri/el-get/master/el-get-install.el"
(lambda (s)
(let ((el-get-install-branch "3.stable"))
(end-of-buffer)
(eval-print-last-sexp))))
This variable takes precedence over "el-get-master-branch", and must
be set to a string.
Documentation for this needs to be added to the readme.
El-get-build allows a command to be specified as a single string. It
will split that string on whitespace into a list of strings, and each
element of that list will eventually be shell-quoted (by
`el-get-start-process-list`). This is wrong behavior that can easily
cause an innocent command to be over-escaped or split into too many
arguments, or both. For example, consider a build process that
involves running the following command:
make SOME_OPTION="this is the option value"
Written as a string in Elisp, that would be:
"make SOME_OPTION=\"this is the option value\""
After splitting on whitespace and then shell-quoting and then passing
the result to the shell, the above command is equivalent to running
the following at the shell:
"make" "SOME_OPTION=\"this" "is" "the" "option" "value\""
See the problem? What was once a single argument is now five, and the
quotation marks have been inappropriately quoted. For this reason, I
think auto-whitespace splitting should probably be deprecated. The
command should either be a single string, which would be interpreted
as a command to be run with no arguments, or a list of strings, like
this:
'("make" "SOME_OPTION=\"this is the option value\"")
The `el-get-install-or-init-info` composed a command as a single
pre-quoted string using `concat` and `shell-quote-argument`. It is
better to make the command a list of unquoted arguments, which is what
this commit does.
I haven't tested this at all, but assuming that the :build property of
a recipe gets passed through el-get-build and subsequently
el-get-start-process-list, the recipe itself should never use
`shell-quote-argument`.
Same reason as in 11ef806a. The result of this function is passed to
`el-get-start-process-list` with a `:shell t` option, which results in
shell-quoting. So doing it here is redundant and potentially harmful.
Before, the newly-installed el-get package was loaded while
`el-get-default-process-sync` and `el-get-post-install` were
let-bound, which caused their corresponding `defvar` statements to be
ignored, which resulted in a non-functional el-get unless one manually
re-loaded el-get or restarted emacs.
