From: David Kastrup <dak@gnu.org>
Date: Tue, 25 Sep 2007 16:04:54 GMT
Subject: Re: [PATCH] rebase -i: commit when continuing after "edit"
Message-ID: <86ir5y689l.fsf@lola.quinscape.zz>
In-Reply-To: <46F92F26.6050204@viscovery.net>

Johannes Sixt <j.sixt@viscovery.net> writes:

> David Kastrup schrieb:
>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>> I poked around a bit, but one major obstacle is that the assignments
>>> in $author_script are on separate lines, which you would have to
>>> splice into a single line before you can insert them in the eval.
>>
>> Hm?  Why?  Newlines separate assignments just as reliable as spaces
>> do.  They are primarily special to the tty as line separators, not the
>> shell as such.
>
> The task here is to have the assignments on the same line as the
> command at the end so that they are locally exported. Here we are
> inside an 'eval', and the new-lines *do* what their name suggest: make
> new lines.

The documentation to eval clearly states:

`eval'
          eval [ARGUMENTS]
     The arguments are concatenated together into a single command,
     which is then read and executed, and its exit status returned as
     the exit status of `eval'.  If there are no arguments or only
     empty arguments, the return status is zero.

So we are talking about a single command here.  However, we indeed get

$ eval "echo x
> y
> z"
x
bash: y: command not found
bash: z: command not found
$

Um, so I have been talking nonsense.  Does "the docs made me do it"
count as excuse?

-- 
David Kastrup