how paths work in cygwin?

how paths work in cygwin?

[Leo Liu]

I am getting a bug report https://github.com/leoliu/ggtags/issues/121
because emacs and global represent paths in cygwin differently?

global: "/e/gtk-3-compilation/build/gtk+-3.19.4/gtk/"
emacs:  "e:/gtk-3-compilation/build/gtk+-3.19.4/gtk/"

Which path representation is more correct? Do we have something to
convert one to the other?

Thanks,
Leo

Re: how paths work in cygwin?

[Filipp Gunbin]

On 18/01/2016 16:24 +0800, Leo Liu wrote:

> I am getting a bug report https://github.com/leoliu/ggtags/issues/121
> because emacs and global represent paths in cygwin differently?
>
> global: "/e/gtk-3-compilation/build/gtk+-3.19.4/gtk/"
> emacs:  "e:/gtk-3-compilation/build/gtk+-3.19.4/gtk/"
>
> Which path representation is more correct? Do we have something to
> convert one to the other?

The answer is "use Cygwin port of emacs under Cygwin".

You could try to support Cygwin paths in Windows Emacs, but I don't know
if that's worth the value.

There are some path conversion functions in Cygwin Emacs (probably not
in Window Emacs), but they weren't available in the last release I used
on Cygwin.

Filipp

Re: how paths work in cygwin?

[Eli Zaretskii]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Mon, 18 Jan 2016 16:24:37 +0800
> 
> I am getting a bug report https://github.com/leoliu/ggtags/issues/121
> because emacs and global represent paths in cygwin differently?
> 
> global: "/e/gtk-3-compilation/build/gtk+-3.19.4/gtk/"
> emacs:  "e:/gtk-3-compilation/build/gtk+-3.19.4/gtk/"
> 
> Which path representation is more correct?

Neither, AFAIK.  Cygwin file names look like /cygdrive/e/gtk-3-...

What you show looks like MSYS format, not Cygwin format.  This is
consistent with what the OP says about invoking 'global' in
"mingw32.exe window".

In sum, I think the OP should use a consistent set of tools, instead
of mixing subtly incompatible sets.  My guess is that his 'global' is
an MSYS application or script, not a native Windows port, whereas his
Emacs is a native build.  These don't mix too well.

We have the unmsys--file-name function which might help, but I see no
reason why you as a maintainer will need to get into that.

Re: how paths work in cygwin?

[Achim Gratz]

Eli Zaretskii writes:
> Neither, AFAIK.  Cygwin file names look like /cygdrive/e/gtk-3-...

…although it's possible to rid yourself of the /cygdrive prefix and set
it to just / instead.  This comes with a few caveats, but in general
you'd need to ask the Cygwin installation what the prefix is set to via
"mount -p" or you skip the vagaries of the differing prefixes and use
"/proc/cygdrive" instead for scripts that should work either way.
Cygwin can and does process DOS-style paths, but if scripts are involved
that are not prepared to deal with them all bets are off, so they should
be avoided wherever possible.

> What you show looks like MSYS format, not Cygwin format.  This is
> consistent with what the OP says about invoking 'global' in
> "mingw32.exe window".

Yes, that seems likely.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: how paths work in cygwin?

[Leo Liu]

On 2016-01-18 18:10 +0300, Filipp Gunbin wrote:
[snipped 11 lines]
> The answer is "use Cygwin port of emacs under Cygwin".
>
> You could try to support Cygwin paths in Windows Emacs, but I don't know
> if that's worth the value.
>
> There are some path conversion functions in Cygwin Emacs (probably not
> in Window Emacs), but they weren't available in the last release I used
> on Cygwin.
>
> Filipp

On 2016-01-18 17:52 +0200, Eli Zaretskii wrote:
[snipped 12 lines]
> Neither, AFAIK.  Cygwin file names look like /cygdrive/e/gtk-3-...
>
> What you show looks like MSYS format, not Cygwin format.  This is
> consistent with what the OP says about invoking 'global' in
> "mingw32.exe window".
>
> In sum, I think the OP should use a consistent set of tools, instead
> of mixing subtly incompatible sets.  My guess is that his 'global' is
> an MSYS application or script, not a native Windows port, whereas his
> Emacs is a native build.  These don't mix too well.
>
> We have the unmsys--file-name function which might help, but I see no
> reason why you as a maintainer will need to get into that.

Thank you, Filipp and Eli, for the expertise on this.

Leo