Xref: utzoo gnu.emacs.help:1259 comp.emacs:10177
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!zaphod.mps.ohio-state.edu!magnus.ircc.ohio-state.edu!tut.cis.ohio-state.edu!unreplyable!garbage
From: bjaspan@ATHENA.MIT.EDU ("Barr3y Jaspan")
Newsgroups: gnu.emacs.help,comp.emacs
Subject: Unwrapping lists, or nested &rest arguments
Message-ID: <9102151924.AA16963@steve-dallas.MIT.EDU>
Date: 15 Feb 91 19:24:42 GMT
Sender: daemon@tut.cis.ohio-state.edu
Followup-To: gnu.emacs.help
Organization: Gatewayed from the GNU Project mailing list help-gnu-emacs@prep.ai.mit.edu
Lines: 37

I want to write a wrapper for call-process that does some frobbing
with process-environment before starting the process.  For example:

(defun frob-call-process (program &optional infile buf-or-name dsp &rest args)
  "Exactly like call-process except that frob-environment is added to
the processes environment."
  (let ((process-environment (append frob-environment process-environment)))
    (call-process program infile buf-or-name dsp args)))

This, however, does not work.  The &rest args in frob-call-process are
collected into a single list of strings, so call-process ends up
getting a single argument in ARGS, a list, whereas it requires a
series of arguments, all of which must be strings.  I have been unable
to think of a way around the problem and hope that I am missing
something obvious.  (Perhaps I should look into macros, but I've never
used them before.)

There are a couple possible solutions.

(1) Inventing some way of "unlisting" a list so that, for example, I
could pass (unlist args) as the last argument to call-process; then,
call-process would get a list of strings (the elements of args)
instead of a list with one element, a list of strings.  This would be
pretty wild and not necessarily even a good idea.

(2) Changing call-process so that it accepts strings OR lists of
strings (or, I suppose, lists of lists of strings, or ...) and expands
all the lists itself into one big list of strings, which it then
passes to exec using whatever mechanism it currently does.  This
strikes me as The Right Thing.

(3) Exporting another interface to the call-process mechanism that
does the same as (2) without actually changing call-process.

Thanks.

Barr3y Jaspan, bjaspan@mit.edu


Brought to you by Super Global Mega Corp .com