All of lore.kernel.org
 help / color / mirror / Atom feed
* default editor
@ 2021-02-07 13:24 M Douglas McIlroy
  2021-02-07 17:35 ` brian m. carlson
  0 siblings, 1 reply; 9+ messages in thread
From: M Douglas McIlroy @ 2021-02-07 13:24 UTC (permalink / raw)
  To: git

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?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: default editor
  2021-02-07 13:24 default editor M Douglas McIlroy
@ 2021-02-07 17:35 ` brian m. carlson
  2021-02-07 18:12   ` Junio C Hamano
  0 siblings, 1 reply; 9+ messages in thread
From: brian m. carlson @ 2021-02-07 17:35 UTC (permalink / raw)
  To: M Douglas McIlroy; +Cc: git

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

On 2021-02-07 at 13:24:07, M Douglas McIlroy wrote:
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: default editor
  2021-02-07 17:35 ` brian m. carlson
@ 2021-02-07 18:12   ` Junio C Hamano
  2021-02-07 18:37     ` Jeff King
  0 siblings, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2021-02-07 18:12 UTC (permalink / raw)
  To: brian m. carlson; +Cc: M Douglas McIlroy, git

"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.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: default editor
  2021-02-07 18:12   ` Junio C Hamano
@ 2021-02-07 18:37     ` Jeff King
  2021-02-07 19:09       ` brian m. carlson
  2021-02-07 21:57       ` Eric Sunshine
  0 siblings, 2 replies; 9+ messages in thread
From: Jeff King @ 2021-02-07 18:37 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: brian m. carlson, M Douglas McIlroy, git

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: default editor
  2021-02-07 18:37     ` Jeff King
@ 2021-02-07 19:09       ` brian m. carlson
  2021-02-07 21:57       ` Eric Sunshine
  1 sibling, 0 replies; 9+ messages in thread
From: brian m. carlson @ 2021-02-07 19:09 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, M Douglas McIlroy, git

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: default editor
  2021-02-07 18:37     ` Jeff King
  2021-02-07 19:09       ` brian m. carlson
@ 2021-02-07 21:57       ` Eric Sunshine
  2021-02-08 10:03         ` Adam Dinwoodie
  1 sibling, 1 reply; 9+ messages in thread
From: Eric Sunshine @ 2021-02-07 21:57 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, brian m. carlson, M Douglas McIlroy, Git List

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.)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: default editor
  2021-02-07 21:57       ` Eric Sunshine
@ 2021-02-08 10:03         ` Adam Dinwoodie
  2021-02-11 15:15           ` M Douglas McIlroy
  0 siblings, 1 reply; 9+ messages in thread
From: Adam Dinwoodie @ 2021-02-08 10:03 UTC (permalink / raw)
  To: Eric Sunshine
  Cc: Jeff King, Junio C Hamano, brian m. carlson, M Douglas McIlroy, Git List

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: default editor
  2021-02-08 10:03         ` Adam Dinwoodie
@ 2021-02-11 15:15           ` M Douglas McIlroy
  2021-02-12  6:03             ` Eric Sunshine
  0 siblings, 1 reply; 9+ messages in thread
From: M Douglas McIlroy @ 2021-02-11 15:15 UTC (permalink / raw)
  To: Adam Dinwoodie
  Cc: Eric Sunshine, Jeff King, Junio C Hamano, brian m. carlson, Git List

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:
>
> 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: default editor
  2021-02-11 15:15           ` M Douglas McIlroy
@ 2021-02-12  6:03             ` Eric Sunshine
  0 siblings, 0 replies; 9+ messages in thread
From: Eric Sunshine @ 2021-02-12  6:03 UTC (permalink / raw)
  To: M Douglas McIlroy
  Cc: Adam Dinwoodie, Jeff King, Junio C Hamano, brian m. carlson, Git List

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.

> 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`)?

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-02-12  6:04 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-07 13:24 default editor M Douglas McIlroy
2021-02-07 17:35 ` brian m. carlson
2021-02-07 18:12   ` Junio C Hamano
2021-02-07 18:37     ` Jeff King
2021-02-07 19:09       ` brian m. carlson
2021-02-07 21:57       ` Eric Sunshine
2021-02-08 10:03         ` Adam Dinwoodie
2021-02-11 15:15           ` M Douglas McIlroy
2021-02-12  6:03             ` Eric Sunshine

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.