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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
