Re: [PATCH] rebase -i: commit when continuing after "edit"

From: David Kastrup <dak@gnu.org>
Date: Sep 25, 2007, 16:04 UTC
Message-ID: <86ir5y689l.fsf@lola.quinscape.zz>
In-Reply-To: <46F92F26.6050204@viscovery.net>

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

Show 14 quoted lines

> 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