threads / discuss / 55114

default editor

Subject: default editor

## tl;dr

9 messages between Feb 7, 2021 and Feb 12, 2021.

replies: 8people: 6as markdown or json

M Douglas McIlroy· Feb 7, 2021, 13:24 UTC · lore

While downloading git, I was asked to name a default editor, which I did: ed. from cygwin. It worked in the enuing test, but was rejected because it returned an error. I suppose this is because cygwin return conventions are those of Unix, not Windows. That raises the question: does it matter? Does any other part of git depend on the editor's return value?

brian m. carlson· Feb 7, 2021, 17:35 UTC · re: M Douglas McIlroy · lore

Re: default editor

On 2021-02-07 at 13:24:07, M Douglas McIlroy wrote:
Show 6 quoted lines
> While downloading git, I was asked to name a default editor, which I
> did: ed. from cygwin. It worked in the enuing test, but was rejected
> because it returned an error. I suppose this is because
> cygwin return  conventions are those of Unix, not Windows. That raises
> the question: does it matter? Does any other part of git depend on the
> editor's return value?

First of all, I don't use Windows and this sounds like a Windows-specific problem, so you may have more help at the Git for Windows issue tracker. But I'll try to help anyway.

At the command line, what does "git var GIT_EDITOR" print? Is it "/usr/bin/ed" or the like? Or is it something like "/c/..."? Also, what is the exact error message you receive from trying to run your command (copy and paste)?

The reason I ask is that Git for Windows ships with a POSIX-like environment called MSYS, and as such, Unix-style paths are interpreted according to that. So to specify a path for Cygwin, you'd need to specify it as a Unix-style path under /c (or /d, or whatever drive) so that it could be invoked as a normal Windows program and not something relative to the MSYS environment. However, the path is handed off to the shell, so it needs to be in a form that uses slashes.

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.

-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US
Junio C Hamano· Feb 7, 2021, 18:12 UTC · re: brian m. carlson · lore

Re: default editor

"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> First of all, I don't use Windows and this sounds like a
> Windows-specific problem, so you may have more help at the Git for
> Windows issue tracker.  But I'll try to help anyway.
I don't do Windows, either ;-)
> 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.

Jeff King· Feb 7, 2021, 18:37 UTC · re: Junio C Hamano · lore

Re: default editor

On Sun, Feb 07, 2021 at 10:12:33AM -0800, Junio C Hamano wrote:
Show 19 quoted lines
> > 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
brian m. carlson· Feb 7, 2021, 19:09 UTC · re: Jeff King · lore

Re: default editor

On 2021-02-07 at 18:37:38, Jeff King wrote:
Show 17 quoted lines
> 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.

I wasn't previously aware of this behavior, and it's not very helpful unless you're scripting, since humans inevitably make mistakes. ex seems to have a more forgiving behavior; maybe it's similar enough that it'd be a better choice?

-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US
Eric Sunshine· Feb 7, 2021, 21:57 UTC · re: Jeff King · lore

Re: default editor

On Sun, Feb 7, 2021 at 1:38 PM Jeff King <peff@peff.net> wrote:
> 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.

Cygwin `ed` does support `-l`, so that's helpful, although it still fails the "test editor" button in the Git-For-Windows installer program since the installer calls `ed` with a Windows style path rather than a Unix style path which Cygwin `ed` doesn't understand. It is possible to skip "test editor" and continue Git-For-Windows installation without testing. The bigger problem after that, at least in my testing, is that when `git` from Git-For-Windows itself eventually launches Cygwin `ed` at commit time, it bombs with:

    0 [main] ed (2444) C:\cygwin64\bin\ed.exe: *** fatal error -
    cygheap base mismatch detected - 0x18034C408/0x180347408.

In fact, Cygwin `ed` crashes with that same problem even just being launched from the MSYS shell provided by Git-For-Windows due to bad interaction between the DLL's. On the other hand, Cygwin `ed` launches just fine from the Cygwin shell as one would expect.

By the way, it's also possible to install Cygwin's Git from the Cygwin installer rather than attempting to use the Git provided by the Git-For-Windows project. The combination of Cygwin `ed` and Cygwin `git` works just fine (in my tests) once you configure `ed` as the Git editor either by setting GIT_EDITOR or EDITOR environment variables to `ed -l` or by configuring git itself:

    git config --global --add core.config 'ed -l'
(You would want to uninstall Git-For-Windows, too, if you have it installed.)
Adam Dinwoodie· Feb 8, 2021, 10:03 UTC · re: Eric Sunshine · lore

Re: default editor

On Sun, 7 Feb 2021 at 21:59, Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 10 quoted lines
> By the way, it's also possible to install Cygwin's Git from the Cygwin
> installer rather than attempting to use the Git provided by the
> Git-For-Windows project. The combination of Cygwin `ed` and Cygwin
> `git` works just fine (in my tests) once you configure `ed` as the Git
> editor either by setting GIT_EDITOR or EDITOR environment variables to
> `ed -l` or by configuring git itself:
>
>     git config --global --add core.config 'ed -l'
>
> (You would want to uninstall Git-For-Windows, too, if you have it installed.)

As the Cygwin Git maintainer, I'd strongly recommend this approach: either use a Cygwin toolchain or a Git for Windows one, rather than trying to combine the two. While Cygwin and the Git for Windows environment share common ancestry, they have substantial differences arising from the fact that Cygwin generally attempts to provide an environment that's as close to Unix-like as possible, while Git for Windows is aiming for compatibility with native Windows applications. Differences in handling paths and return codes are to be expected.

I expect it is possible to use a Cygwin editor with Git for Windows, but I don't think it's an expected use case, and I'm not aware of anyone else having produced and published documentation of the configuration and wrapper scripts I imagine you would need to convert between the two interfaces.

Adam
M Douglas McIlroy· Feb 11, 2021, 15:15 UTC · re: Adam Dinwoodie · lore

Re: default editor

Eric and Adam,

Many thanks for so thoroughly exploring my query. I have long lived with the limitations of invoking Windows apps from Cygwin. Fortuitously I could work around them without resorting to "command prompt", though clearly that isn't always possible. And you have shed light on the difficulty of the opposite: invoking Cygwin apps from Windows.

Doug
On Mon, Feb 8, 2021 at 5:03 AM Adam Dinwoodie <adam@dinwoodie.org> wrote:
Show 29 quoted lines
>
> On Sun, 7 Feb 2021 at 21:59, Eric Sunshine <sunshine@sunshineco.com> wrote:
> > By the way, it's also possible to install Cygwin's Git from the Cygwin
> > installer rather than attempting to use the Git provided by the
> > Git-For-Windows project. The combination of Cygwin `ed` and Cygwin
> > `git` works just fine (in my tests) once you configure `ed` as the Git
> > editor either by setting GIT_EDITOR or EDITOR environment variables to
> > `ed -l` or by configuring git itself:
> >
> >     git config --global --add core.config 'ed -l'
> >
> > (You would want to uninstall Git-For-Windows, too, if you have it installed.)
>
> As the Cygwin Git maintainer, I'd strongly recommend this approach:
> either use a Cygwin toolchain or a Git for Windows one, rather than
> trying to combine the two. While Cygwin and the Git for Windows
> environment share common ancestry, they have substantial differences
> arising from the fact that Cygwin generally attempts to provide an
> environment that's as close to Unix-like as possible, while Git for
> Windows is aiming for compatibility with native Windows applications.
> Differences in handling paths and return codes are to be expected.
>
> I expect it is possible to use a Cygwin editor with Git for Windows,
> but I don't think it's an expected use case, and I'm not aware of
> anyone else having produced and published documentation of the
> configuration and wrapper scripts I imagine you would need to convert
> between the two interfaces.
>
> Adam
Eric Sunshine· Feb 12, 2021, 06:03 UTC · re: M Douglas McIlroy · lore

Re: default editor

On Thu, Feb 11, 2021 at 10:15 AM M Douglas McIlroy <m.douglas.mcilroy@dartmouth.edu> wrote:

> Many thanks for so thoroughly exploring my query.
You are very welcome.
Show 5 quoted lines
> I have long lived with the limitations of invoking Windows apps from
> Cygwin. Fortuitously I could work around them without resorting to
> "command prompt", though clearly that isn't always possible. And you
> have shed light on the difficulty of the opposite: invoking Cygwin
> apps from Windows.

Were you able to resolve the situation (for instance, by staying entirely within the Cygwin ecosystem for `git` and `ed`)?

← back to recent threads