"Phil Burfitt" <phil.burf...@talktalk.net> writes: > The directory "trial" is lowercase. > > However I've tried with... > > c:\trial > c:/trial > C:\trial > C:/trial > C:\TRIAL > C:/TRIAL > > all treated the same and same output. Under Windows/DOS you can use > "\" or "/" for paths and changing directories etc.
Ok ok, this is pretty thorough. It was just a case of "Once you ruled out all the probable cases, it must be one of the improbable ones." Something like the file name containing a BOM mark (non-printing character). But that's not terribly likely. We have Source_file * Sources::get_file (string file_string, string const ¤t_dir) { if (file_string != "-") { // First, check for a path relative to the directory of the // file currently being parsed. if (current_dir.length () && file_string.length () && !File_name (file_string).is_absolute () && is_file (current_dir + DIRSEP + file_string)) file_string = current_dir + DIRSEP + file_string; // Otherwise, check the rest of the path. else if (path_) { string file_string_o = path_->find (file_string); if ((file_string_o == "") && (file_string != "")) return 0; file_string = file_string_o; } } Source_file *f = new Source_file (file_string); add (f); return f; } Which is called in lily/includable-lexer.cc with /** Set the new input file to NAME, remember old file. */ void Includable_lexer::new_input (const string &name, Sources *sources) { string current_dir = dir_name (main_input_name_); if (relative_includes) current_dir = include_stack_.size () ? dir_name (include_stack_.back ()->name_string ()) : ""; Source_file *file = sources->get_file (name, current_dir); if (!file) { string msg = _f ("cannot find file: `%s'", name); msg += "\n"; msg += _f ("(search path: `%s')", (current_dir.length () ? (current_dir + PATHSEP) : "") + sources->path_->to_string ().c_str ()); LexerError (msg.c_str ()); return; } Now relative_includes is _off_ by default, so current_dir should be dir_name (main_input_name_). And that appears to be just the normal file name., so as far as I can tell from string dir_name (const string &file_name) { string s = file_name; s = slashify (s); ssize n = s.length (); if (n && s[n - 1] == '/') s[n - 1] = 0; if (s.rfind ('/') != NPOS) s = s.substr (0, s.rfind ('/')); else s = ""; return s; } We should get an empty string. The s[n - 1] = 0; line is obviously utterly broken, but it should not get executed in your case. Which should let us fall through "check the rest of the path". path_->find leads us to File_path::find (const string &name) const { if (!name.length () || (name == "-")) return name; #ifdef __MINGW32__ if (name.find ('\\') != NPOS) programming_error ("file name not normalized: " + name); #endif /* __MINGW32__ */ /* Handle absolute file name. */ File_name file_name (name); if (file_name.dir_[0] == DIRSEP && is_file (file_name.to_string ())) return file_name.to_string (); for (vsize i = 0; i < dirs_.size (); i++) { File_name file_name (name); File_name dir = (string) dirs_[i]; file_name.root_ = dir.root_; dir.root_ = ""; if (file_name.dir_.empty ()) file_name.dir_ = dir.to_string (); else if (!dir.to_string ().empty ()) file_name.dir_ = dir.to_string () + ::to_string (DIRSEP) + file_name.dir_; if (is_file (file_name.to_string ())) return file_name.to_string (); } return ""; } Now the criterion for "absolute file names" is obviously wrong for Windows, but I don't see this causing a problem. One worthwhile observation is that when the path is printed, this gets done using string File_path::to_string () const { string s; for (vsize i = 0; i < dirs_.size (); i++) { s = s + dirs_[i]; if (i < dirs_.size () - 1) s += ::to_string (PATHSEP); } return s; } rather than just printing a string. So if one entry looks like C:/something;C:/somethingelse rather than being two separate entries in the File_path array, we don't get to see the difference. Do we have any other Windows users who could try reproducing this rather strange behavior? -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user