Re: substitute-in-file-name is not distributive

[Stefan Monnier]

> Relative file names come up during builds. Say I'm editing foo.c and
> the build system outputs "objchk\x86\foo.o" in some message: I want to
> be able to append this relative path and get back a full Cygwin path.

What do you append it to?  If the mapping is arbitrary, you first need
to convert the Cywin name to Windows, the concat, then convert
back, right?

>> So Cygin itself treats "\\bin" and "/bin" as equivalent
> No --- Cygwin treats "\\bin" just as Windows would: it's
> a drive-letter-relative Windows path. "/bin" is a perfectly normal
> POSIX path.

Now I'm lost.  So you're saying that Cygwin accepts backslash delimited
file names and assumes they're Window file names?  IOW Cygwin already
accepts just as happily Windows file names?  In this case, I'm wondering
why you need s-i-f-n.

Is it because Cygwin needs backslashes to recognize Windows file names
whereas Emacs wants to turn all backslashes into slashes?

Side related question: this seems to be related to your cygw32, yet at
the same tine it seems to be more GUI-independent.  How much of this
affects Cygwin-X11 builds?  Why has it not been a problem until now?

>> If you limit yourself to:
>> - rewrite "\\`[a-zA-Z]:" to "/cygdrive/c" (regardless if it is followed
> Not all Cygwin installations use "cygdrive".

I kind of know.

> Every instance of the word "cygdrive" in Emacs is a bug.

Feel free to fix them.

> "/cygdrive/c/bin/ls.exe" and "/bin/ls.exe" refer to the same file, but
> because the paths differ, Emacs will consider these as two distinct
> files.  Also, access semantics differ between drive-prefix-prefixed
> paths and native Cygwin paths.

That doesn't sound too terrible as a stop-gap until we can fix the
underlying problem.


        Stefan