On Sun, Feb 07, 2021 at 10:12:33AM -0800, Junio C Hamano wrote:
> > I don't think the return value is the problem. Both Unix and Windows
> > return 0 on success and nonzero on error, and Git will interpret
> > editor return codes that way.
>
> When git spawns an editor, it is asking the editor to give the text
> file that has been edited by the end user into a shape that the end
> user is happy with. A non-zero exit is a way for the end user to
> tell the editor (and hence git) that, even though the user has ended
> the editor session, the resulting contents is not satisfactory and
> not to be used.
>
> If the 'ed' in question behaves the same as traditional UNIX 'ed' (I
> am guessing so, as even this is on Windows, Cygwin was mentioned),
> you can start making changes and attempt to quit without saving by
> typing 'q<RET>' twice (the first one will be greeted with '?'
> meaning "are you sure you want to quit without saving", and the
> second one lets you quit). 'ed' will signal the calling environment
> that the editor session was aborted by exiting with a non-zero
> status.
There are lots of ways to make ed exit non-zero. Any invalid command
during the session will do. E.g.:
$ echo bar >foo
$ ed foo
ed -> 4
me -> l
ed -> bar$
me -> 2l
ed -> ?
me -> q
$ echo $?
1
The "2l" was bogus (there is no line 2). It seems likely that an
interactive user might make at least one invalid command while editing.
Some versions (like GNU ed) have a "-l" option to loosen the exit code.
-Peff
