master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Yuri D'Elia]

% which emacs
/usr/local/bin/emacs
% ls -l =emacs
/usr/local/bin/emacs -> ../stow/emacs-20190624/bin/emacs
% emacs
emacs: could not resolve realpath of "(null)": No such file or directory

reverting commit b9ac4f815ebaa1acb0d045fe9583f665efa6f628 fixes the
issue.

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Ergus]

Hi:

I am getting the new warning after commit b9ac4f815ebaa1a. It is just a
warning but it is right.

../../emacs_git/src/emacs.c:752:5: warning: ???%s??? directive argument is
null [-Wformat-overflow=]

This is the code.

750|  char* argv0 = realpath (argv[0], NULL);
751|  if (!argv0)
752|    fatal ("could not resolve realpath of \"%s\": %s",
752|           argv0, strerror (errno));

The format %s expects a char[] but in this case argv0 is NULL, thats
where the warning is coming from.

On the other hand I see that realpath() was called with NULL as a second
parameter, in that case it internally invokes a malloc, so there should
be a free for it somewhere.


On Mon, Jun 24, 2019 at 12:26:00PM +0200, Yuri D'Elia wrote:
>% which emacs
>/usr/local/bin/emacs
>% ls -l =emacs
>/usr/local/bin/emacs -> ../stow/emacs-20190624/bin/emacs
>% emacs
>emacs: could not resolve realpath of "(null)": No such file or directory
>
>reverting commit b9ac4f815ebaa1acb0d045fe9583f665efa6f628 fixes the
>issue.
>
>

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Yuri Khan]

On Mon, Jun 24, 2019 at 6:12 PM Ergus <spacibba@aol.com> wrote:

> 750|  char* argv0 = realpath (argv[0], NULL);
> 751|  if (!argv0)
> 752|    fatal ("could not resolve realpath of \"%s\": %s",
> 752|           argv0, strerror (errno));

This looks wrong. If we called realpath and it returned null, we’d
probably want the original argv[0] in the error message, not the null
result.

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Ergus]

On Mon, Jun 24, 2019 at 06:57:32PM +0700, Yuri Khan wrote:
>On Mon, Jun 24, 2019 at 6:12 PM Ergus <spacibba@aol.com> wrote:
>
>> 750|  char* argv0 = realpath (argv[0], NULL);
>> 751|  if (!argv0)
>> 752|    fatal ("could not resolve realpath of \"%s\": %s",
>> 752|           argv0, strerror (errno));
>
>This looks wrong. If we called realpath and it returned null, we???d
>probably want the original argv[0] in the error message, not the null
>result.
>

This also produces problems when using emacs from an alias like em o emc 
which is a very common practice.

So there should be actually other conditions to try if the first 
realpath call fails and not abort (call fatal) in the first try.

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Daniel Colascione]

> On Mon, Jun 24, 2019 at 06:57:32PM +0700, Yuri Khan wrote:
>>On Mon, Jun 24, 2019 at 6:12 PM Ergus <spacibba@aol.com> wrote:
>>
>>> 750|  char* argv0 = realpath (argv[0], NULL);
>>> 751|  if (!argv0)
>>> 752|    fatal ("could not resolve realpath of \"%s\": %s",
>>> 752|           argv0, strerror (errno));
>>
>>This looks wrong. If we called realpath and it returned null, we???d
>>probably want the original argv[0] in the error message, not the null
>>result.
>>
>
> This also produces problems when using emacs from an alias like em o emc
> which is a very common practice.
>
> So there should be actually other conditions to try if the first
> realpath call fails and not abort (call fatal) in the first try.

Try it now. Sorry about the botched change.

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Ergus]

On Mon, Jun 24, 2019 at 06:21:12AM -0700, Daniel Colascione wrote:
>> On Mon, Jun 24, 2019 at 06:57:32PM +0700, Yuri Khan wrote:
>>>On Mon, Jun 24, 2019 at 6:12 PM Ergus <spacibba@aol.com> wrote:
>>>
>>>> 750|  char* argv0 = realpath (argv[0], NULL);
>>>> 751|  if (!argv0)
>>>> 752|    fatal ("could not resolve realpath of \"%s\": %s",
>>>> 752|           argv0, strerror (errno));
>>>
>>>This looks wrong. If we called realpath and it returned null, we???d
>>>probably want the original argv[0] in the error message, not the null
>>>result.
>>>
>>
>> This also produces problems when using emacs from an alias like em o emc
>> which is a very common practice.
>>
>> So there should be actually other conditions to try if the first
>> realpath call fails and not abort (call fatal) in the first try.
>
>Try it now. Sorry about the botched change.
>
>
Hi Daniel:

Did you pushed any change too savannah/master?

Best Ergus

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Daniel Colascione]

> On Mon, Jun 24, 2019 at 06:21:12AM -0700, Daniel Colascione wrote:
>>> On Mon, Jun 24, 2019 at 06:57:32PM +0700, Yuri Khan wrote:
>>>>On Mon, Jun 24, 2019 at 6:12 PM Ergus <spacibba@aol.com> wrote:
>>>>
>>>>> 750|  char* argv0 = realpath (argv[0], NULL);
>>>>> 751|  if (!argv0)
>>>>> 752|    fatal ("could not resolve realpath of \"%s\": %s",
>>>>> 752|           argv0, strerror (errno));
>>>>
>>>>This looks wrong. If we called realpath and it returned null, we???d
>>>>probably want the original argv[0] in the error message, not the null
>>>>result.
>>>>
>>>
>>> This also produces problems when using emacs from an alias like em o
>>> emc
>>> which is a very common practice.
>>>
>>> So there should be actually other conditions to try if the first
>>> realpath call fails and not abort (call fatal) in the first try.
>>
>>Try it now. Sorry about the botched change.
>>
>>
> Hi Daniel:
>
> Did you pushed any change too savannah/master?

Graph. Of course the push failed. *Now* try it.  :-)

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Ergus]

On Mon, Jun 24, 2019 at 06:54:10AM -0700, Daniel Colascione wrote:
>> On Mon, Jun 24, 2019 at 06:21:12AM -0700, Daniel Colascione wrote:
>>>> On Mon, Jun 24, 2019 at 06:57:32PM +0700, Yuri Khan wrote:
>>>>>On Mon, Jun 24, 2019 at 6:12 PM Ergus <spacibba@aol.com> wrote:
>>>>>
>>>>>> 750|  char* argv0 = realpath (argv[0], NULL);
>>>>>> 751|  if (!argv0)
>>>>>> 752|    fatal ("could not resolve realpath of \"%s\": %s",
>>>>>> 752|           argv0, strerror (errno));
>>>>>
>>>>>This looks wrong. If we called realpath and it returned null, we???d
>>>>>probably want the original argv[0] in the error message, not the null
>>>>>result.
>>>>>
>>>>
>>>> This also produces problems when using emacs from an alias like em o
>>>> emc
>>>> which is a very common practice.
>>>>
>>>> So there should be actually other conditions to try if the first
>>>> realpath call fails and not abort (call fatal) in the first try.
>>>
>>>Try it now. Sorry about the botched change.
>>>
>>>
>> Hi Daniel:
>>
>> Did you pushed any change too savannah/master?
>
>Graph. Of course the push failed. *Now* try it.  :-)
>
Yes, it works for me. Very thanks :)

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Andy Moreton]

On Mon 24 Jun 2019, Daniel Colascione wrote:

>> On Mon, Jun 24, 2019 at 06:57:32PM +0700, Yuri Khan wrote:
>>>On Mon, Jun 24, 2019 at 6:12 PM Ergus <spacibba@aol.com> wrote:
>>>
>>>> 750|  char* argv0 = realpath (argv[0], NULL);
>>>> 751|  if (!argv0)
>>>> 752|    fatal ("could not resolve realpath of \"%s\": %s",
>>>> 752|           argv0, strerror (errno));
>>>
>>>This looks wrong. If we called realpath and it returned null, we???d
>>>probably want the original argv[0] in the error message, not the null
>>>result.
>>>
>>
>> This also produces problems when using emacs from an alias like em o emc
>> which is a very common practice.
>>
>> So there should be actually other conditions to try if the first
>> realpath call fails and not abort (call fatal) in the first try.
>
> Try it now. Sorry about the botched change.

Building commit 65d45def8d71e50d111adf1141011a5d30a27447 still fails on
MSYS2 (Windows), and adds warnings:

C:/emacs/git/emacs/master/lib/canonicalize-lgpl.c:51:21: warning: no previous prototype for 'realpath' [-Wmissing-prototypes]
   51 | # define __realpath realpath
      |                     ^~~~~~~~
C:/emacs/git/emacs/master/lib/canonicalize-lgpl.c:117:1: note: in expansion of macro '__realpath'
  117 | __realpath (const char *name, char *resolved)
      | ^~~~~~~~~~
C:/emacs/git/emacs/master/lib/canonicalize-lgpl.c:50:35: warning: no previous prototype for 'canonicalize_file_name' [-Wmissing-prototypes]
   50 | # define __canonicalize_file_name canonicalize_file_name
      |                                   ^~~~~~~~~~~~~~~~~~~~~~
C:/emacs/git/emacs/master/lib/canonicalize-lgpl.c:416:1: note: in expansion of macro '__canonicalize_file_name'
  416 | __canonicalize_file_name (const char *name)
      | ^~~~~~~~~~~~~~~~~~~~~~~~

[...]

C:/emacs/git/emacs/master/src/emacs.c: In function 'load_pdump':
C:/emacs/git/emacs/master/src/emacs.c:851:22: warning: implicit declaration of function 'realpath' [-Wimplicit-function-declaration]
  851 |       real_exename = realpath (exename, NULL);
      |                      ^~~~~~~~
C:/emacs/git/emacs/master/src/emacs.c:851:22: warning: nested extern declaration of 'realpath' [-Wnested-externs]
C:/emacs/git/emacs/master/src/emacs.c:851:20: warning: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
  851 |       real_exename = realpath (exename, NULL);
      |                    ^
C:/emacs/git/emacs/master/src/emacs.c:923:7: error: 'argv0_len' undeclared (first use in this function)
  923 |       argv0_len = strlen (argv0_base);
      |       ^~~~~~~~~
C:/emacs/git/emacs/master/src/emacs.c:923:7: note: each undeclared identifier is reported only once for each function it appears in
make[1]: *** [Makefile:402: emacs.o] Error 1

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Ergus]

On Mon, Jun 24, 2019 at 06:54:10AM -0700, Daniel Colascione wrote:
>> On Mon, Jun 24, 2019 at 06:21:12AM -0700, Daniel Colascione wrote:
>>>> On Mon, Jun 24, 2019 at 06:57:32PM +0700, Yuri Khan wrote:
>>>>>On Mon, Jun 24, 2019 at 6:12 PM Ergus <spacibba@aol.com> wrote:
>>>>>
>>>>>> 750|  char* argv0 = realpath (argv[0], NULL);
>>>>>> 751|  if (!argv0)
>>>>>> 752|    fatal ("could not resolve realpath of \"%s\": %s",
>>>>>> 752|           argv0, strerror (errno));
>>>>>
>>>>>This looks wrong. If we called realpath and it returned null, we???d
>>>>>probably want the original argv[0] in the error message, not the null
>>>>>result.
>>>>>
>>>>
>>>> This also produces problems when using emacs from an alias like em o
>>>> emc
>>>> which is a very common practice.
>>>>
>>>> So there should be actually other conditions to try if the first
>>>> realpath call fails and not abort (call fatal) in the first try.
>>>
>>>Try it now. Sorry about the botched change.
>>>
>>>
>> Hi Daniel:
>>
>> Did you pushed any change too savannah/master?
>
>Graph. Of course the push failed. *Now* try it.  :-)
>
>
Hi again:

I think this is related with bug#35503 and could be used to fix it too
(if not done already with your latest change)

Very thanks,
Ergus

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Mon, 24 Jun 2019 15:14:47 +0100
> 
> Building commit 65d45def8d71e50d111adf1141011a5d30a27447 still fails on
> MSYS2 (Windows), and adds warnings:

I'm working on this.

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Basil L. Contovounesios]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> Building commit 65d45def8d71e50d111adf1141011a5d30a27447 still fails on
> MSYS2 (Windows), and adds warnings:
>
> C:/emacs/git/emacs/master/lib/canonicalize-lgpl.c:51:21: warning: no previous
> prototype for 'realpath' [-Wmissing-prototypes]
>    51 | # define __realpath realpath
>       |                     ^~~~~~~~
> C:/emacs/git/emacs/master/lib/canonicalize-lgpl.c:117:1: note: in expansion of macro '__realpath'
>   117 | __realpath (const char *name, char *resolved)
>       | ^~~~~~~~~~
> C:/emacs/git/emacs/master/lib/canonicalize-lgpl.c:50:35: warning: no previous
> prototype for 'canonicalize_file_name' [-Wmissing-prototypes]
>    50 | # define __canonicalize_file_name canonicalize_file_name
>       |                                   ^~~~~~~~~~~~~~~~~~~~~~
> C:/emacs/git/emacs/master/lib/canonicalize-lgpl.c:416:1: note: in expansion of
> macro '__canonicalize_file_name'
>   416 | __canonicalize_file_name (const char *name)
>       | ^~~~~~~~~~~~~~~~~~~~~~~~
>
> [...]
>
> C:/emacs/git/emacs/master/src/emacs.c: In function 'load_pdump':
> C:/emacs/git/emacs/master/src/emacs.c:851:22: warning: implicit declaration of
> function 'realpath' [-Wimplicit-function-declaration]
>   851 |       real_exename = realpath (exename, NULL);
>       |                      ^~~~~~~~
> C:/emacs/git/emacs/master/src/emacs.c:851:22: warning: nested extern declaration
> of 'realpath' [-Wnested-externs]
> C:/emacs/git/emacs/master/src/emacs.c:851:20: warning: assignment to 'char *'
> from 'int' makes pointer from integer without a cast [-Wint-conversion]
>   851 |       real_exename = realpath (exename, NULL);
>       |                    ^
> C:/emacs/git/emacs/master/src/emacs.c:923:7: error: 'argv0_len' undeclared
> (first use in this function)
>   923 |       argv0_len = strlen (argv0_base);
>       |       ^~~~~~~~~
> C:/emacs/git/emacs/master/src/emacs.c:923:7: note: each undeclared identifier is
> reported only once for each function it appears in
> make[1]: *** [Makefile:402: emacs.o] Error 1

See also:
https://lists.gnu.org/archive/html/emacs-devel/2019-06/msg00898.html

-- 
Basil

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[dancol]

[-- Attachment #1: Type: text/html, Size: 753 bytes --]

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Eli Zaretskii]

> Date: Mon, 24 Jun 2019 17:52:59 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Andy Moreton <andrewjmoreton@gmail.com>
> > Date: Mon, 24 Jun 2019 15:14:47 +0100
> > 
> > Building commit 65d45def8d71e50d111adf1141011a5d30a27447 still fails on
> > MSYS2 (Windows), and adds warnings:
> 
> I'm working on this.

Should be fixed now, please test.

The use case with emacs.exe being a symlink to another directory is
not yet supported on Windows, I will add that later.  (It's a bit
tricky, as at this early stage of startup the file names are still
unibyte strings in the current system codepage, so many file-name
related functions will not work as expected.  But using symlinks to
executables is relatively rare on Windows, so I thin we can wait for
this for a few more days.)

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Eli Zaretskii]

> Date: Mon, 24 Jun 2019 09:06:37 -0700
> From: dancol@dancol.org
> Cc: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org
> 
>  > Building commit 65d45def8d71e50d111adf1141011a5d30a27447 still fails on 
>  > MSYS2 (Windows), and adds warnings: 
> 
>  I'm working on this. 
> 
> Thanks. I thought gnulib was supposed to "just work" here.

It mostly does, but not in this case, evidently.  And even if it did,
we cannot use in Emacs Gnulib modules that manipulate file names,
because Gnulib on Windows supports only file names encodable in the
current ANSI codepage, whereas Emacs supports the full Unicode.  Also,
in this case there are two more problems: (1) canonicalize-lgpl.c
doesn't support symlinks on Windows, and (2) it uses 'stat', which we
replaced in Emacs by our own enhanced implementation.  So there are
more than enough reasons for this changeset to require additional work
on Windows ;-)

Thanks for fixing this issue on Posix platforms.  Did you close the
bug which Richard opened about this?

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Daniel Colascione]

>> Date: Mon, 24 Jun 2019 09:06:37 -0700
>> From: dancol@dancol.org
>> Cc: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org
>>
>>  > Building commit 65d45def8d71e50d111adf1141011a5d30a27447 still fails
>> on
>>  > MSYS2 (Windows), and adds warnings:
>>
>>  I'm working on this.
>>
>> Thanks. I thought gnulib was supposed to "just work" here.
>
> It mostly does, but not in this case, evidently.  And even if it did,
> we cannot use in Emacs Gnulib modules that manipulate file names,
> because Gnulib on Windows supports only file names encodable in the
> current ANSI codepage, whereas Emacs supports the full Unicode.  Also,
> in this case there are two more problems: (1) canonicalize-lgpl.c
> doesn't support symlinks on Windows, and (2) it uses 'stat', which we
> replaced in Emacs by our own enhanced implementation.  So there are
> more than enough reasons for this changeset to require additional work
> on Windows ;-)

Ah, I didn't look all that closely at the Gnulib implementation: I was
under the impression that it was supposed to be more generally portable.
It has other questionable behavior: for example, the findprog Gnulib
module is a no-op on Cygwin even though the search path logic there is the
same as it is on other platforms.

> Thanks for fixing this issue on Posix platforms.  Did you close the
> bug which Richard opened about this?

I will.

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Eli Zaretskii]

> Date: Mon, 24 Jun 2019 20:23:22 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: andrewjmoreton@gmail.com, emacs-devel@gnu.org
> 
> we cannot use in Emacs Gnulib modules that manipulate file names

To prevent  interpretation I didn't intend, let me clarify: I meant we
cannot use _on_Windows_ such Gnulib modules.  On Posix platforms we
can, and we do.

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Andy Moreton]

On Mon 24 Jun 2019, Eli Zaretskii wrote:

>> Date: Mon, 24 Jun 2019 17:52:59 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>> 
>> > From: Andy Moreton <andrewjmoreton@gmail.com>
>> > Date: Mon, 24 Jun 2019 15:14:47 +0100
>> > 
>> > Building commit 65d45def8d71e50d111adf1141011a5d30a27447 still fails on
>> > MSYS2 (Windows), and adds warnings:
>> 
>> I'm working on this.
>
> Should be fixed now, please test.

Thanks Eli, master builds and runs again.

> The use case with emacs.exe being a symlink to another directory is
> not yet supported on Windows, I will add that later.  (It's a bit
> tricky, as at this early stage of startup the file names are still
> unibyte strings in the current system codepage, so many file-name
> related functions will not work as expected.  But using symlinks to
> executables is relatively rare on Windows, so I thin we can wait for
> this for a few more days.)

Tricky indeed. Perhaps using a unicode command line would help, but I
assume that would require pervasive changes.

    AndyM

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Mon, 24 Jun 2019 19:26:06 +0100
> 
> Perhaps using a unicode command line would help, but I assume that
> would require pervasive changes.

Starting with the fact that 'main' can only receive argv[] encoded in
system codepage.

In any case, the tricky part in this case is not that we receive the
leading directories ANSI-encoded -- this is a known limitation of
Emacs on Windows, regardless of symlinks and pdumper look up -- the
tricky part is the resolution of symlinks in argv[0].  We have already
code for that, see chase_symlinks, but it wants to receive file names
in UTF-8.  So some recoding of file names is in order, and then
testing.

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Eli Zaretskii]

> Date: Mon, 24 Jun 2019 20:12:54 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> The use case with emacs.exe being a symlink to another directory is
> not yet supported on Windows, I will add that later.

Now done.

I invite people to try this and report any problems, especially when
the directory from which Emacs is started includes non-ASCII
characters.  Note that only non-ASCII characters encodable in the
system codepage are supported in the name of the directory from which
Emacs is started on MS-Windows.

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Eli Zaretskii]

> Date: Wed, 26 Jun 2019 19:26:56 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > Date: Mon, 24 Jun 2019 20:12:54 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: emacs-devel@gnu.org
> > 
> > The use case with emacs.exe being a symlink to another directory is
> > not yet supported on Windows, I will add that later.
> 
> Now done.
> 
> I invite people to try this and report any problems, especially when
> the directory from which Emacs is started includes non-ASCII
> characters.

Btw, Ken: did you try this new functionality on Cygwin?  Does it work
as expected?

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Ken Brown]

On 6/26/2019 12:58 PM, Eli Zaretskii wrote:
>> Date: Wed, 26 Jun 2019 19:26:56 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>>
>>> Date: Mon, 24 Jun 2019 20:12:54 +0300
>>> From: Eli Zaretskii <eliz@gnu.org>
>>> Cc: emacs-devel@gnu.org
>>>
>>> The use case with emacs.exe being a symlink to another directory is
>>> not yet supported on Windows, I will add that later.
>>
>> Now done.
>>
>> I invite people to try this and report any problems, especially when
>> the directory from which Emacs is started includes non-ASCII
>> characters.
> 
> Btw, Ken: did you try this new functionality on Cygwin?  Does it work
> as expected?

It didn't, but I just fixed it.

Ken

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Eli Zaretskii]

> From: Ken Brown <kbrown@cornell.edu>
> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Thu, 27 Jun 2019 17:45:45 +0000
> 
> > Btw, Ken: did you try this new functionality on Cygwin?  Does it work
> > as expected?
> 
> It didn't, but I just fixed it.

Thanks.  Does the PATH search in load_pdump_find_executable also work
on Cygwin, when argv[0] doesn't include the .exe suffix?  Or does it
always include the .exe?

Re: master b9ac4f8.. (Fix locating pdump by symlink) breaks with stow

[Ken Brown]

On 6/27/2019 2:36 PM, Eli Zaretskii wrote:
>> From: Ken Brown <kbrown@cornell.edu>
>> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>> Date: Thu, 27 Jun 2019 17:45:45 +0000
>>
>>> Btw, Ken: did you try this new functionality on Cygwin?  Does it work
>>> as expected?
>>
>> It didn't, but I just fixed it.
> 
> Thanks.  Does the PATH search in load_pdump_find_executable also work
> on Cygwin, when argv[0] doesn't include the .exe suffix?  Or does it
> always include the .exe?

Yes, it works without the .exe, and it doesn't always include the .exe.  For 
example, if I have the symlink

   emacs -> ../src/emacs/x86_64/src/emacs.exe

in ~/bin, which is in my PATH, and if I invoke EMACS simply as "emacs", then 
argv[0] is "emacs", and everything works.

Ken