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

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Feb 5, 2009, 17:13 UTC
Message-ID: <498B1E37.2020302@viscovery.net>
In-Reply-To: <498B1862.5070703@lsrfire.ath.cx>

René Scharfe schrieb:

Show 8 quoted lines

> 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