Re: [PATCH] fix crash in path.c on Windows

[Johannes Sixt <j.sixt@viscovery.net>]

René Scharfe schrieb:
> Johannes Sixt schrieb:
>> Bash translates leading single-letter path components to drive prefix
>> notation if it invokes a non-MSYS program; and it also translates ':' to
>> ';' if the value looks like a path list. Sometimes there is an ambiguity
>> and bash guesses wrong.
> 
> Sure, but what rules or heuristics does it follow?  Do we need to
> post-process the results or can we simply change the test case in t1504?

Mingw git assumes that it operates in a typical Windows environment -
drive-letter notation for absolute paths, and ';' separates paths in
PATH-like environment variables. If a test case breaks because bash
guesses wrongly, and does not transform the environment or command line
argument correctly, change the test case. (For example if /c:c was meant
as a two paths, then change it to /foo:bar, perhaps bash gets this right.)

Everything else, I don't know. Audit how sensible the test case is, and
whether it addresses a likely real-world case. If we don't care, skip it.

We try hard not to place Windows specific code outside of compat/.

> Is is_absolute_path() too forgiving on Windows, i.e. should it stop
> classifying paths starting with a slash as absolute on that platform?

No. /foo/bar is a valid "absolute" path Windows - even though it is
relative to the current drive. The point is that it is not relative to the
current directory.

-- Hannes