Hey Steve,
Funny, getcwd() works just fine for me on Mac OS X. Try this:
% pwd /Volumes/Data/jberry/junk
% cat > test.c << EOT #include <unistd.h> #include <stdio.h>
int main(int argc, char* argv[]) { printf("cwd is: %s\n", getcwd(NULL, 0)); } EOT
% gcc test.c
% ./a.out
cwd is: /Volumes/Data/jberry/junk
(i.e., the current directory).
Does that work for you? Is your program by any chance linking against some other library that's supplying a bogus getcwd() routine?
James
On Mar 17, 2005, at 1:54 PM, Steve Smith wrote:
It turns out that getcwd() consistently returns "/" everywhere in the program.
However, C++ file output functions are also writing consistently using relative paths, so its using something else to get the working directory. I've used the setting in xcode to "set working directory to:" somewhere else and C++ is evidently using this information somehow.
The following: ofstream outFile; outFile.open( outFileName.c_str(), ios::out ); outFile << "whatever"
In the same program uses relative paths. (printing out getcwd right before this returns "\")
This seems to a Mac OS specific problem which does not occur when the program is complied under gcc on a PC.
This isn't really a xerces problem I suppose -- though I would appreciate any further suggestions.
Steve
At 12:27 PM -0800 3/16/05, James Berry wrote:Steve,
getcwd() works for me. You might try printing out what it returns at the very start of your program. Is it possible that something else in your code is calling chdir or fchdir?
-jdb
On Mar 16, 2005, at 11:38 AM, Steve Smith wrote:Indeed, you are correct. getcwd is returning "/".
This seems strange, given that the C++ code is writing files relative to the build directory correctly. I am using paths relative to the exe location and those are working correctly.
Why the difference? (and more importantly, what can I do about it!)
Thanks for the help!
Steve
At 10:11 AM -0800 3/16/05, James Berry wrote:Steve,
Could you do a bit of debugging on this?
One way or another, the relative path should be resolved inside XMLParsePathToFSRef_X in MacOSPlatformUtils.cpp. This would be either in response to getCurrentDirectory (which calls XMLParsePathToFSSpec with the path "."), or with the entire relative path. In this case, XMLParsePathToFSRef_X calls getcwd to retrieve the current directory, then prepends it to the path, followed by a "/".
I firmly believe (until proven otherwise) that getcwd is returning "/" in your case, perhaps because that's what the cwd is set to??? Can you set a breakpoint, or add some debug output, to verify this condition?
-jdb
On Mar 16, 2005, at 7:36 AM, Smith, Steven J (PNNL/JGCRI) wrote:I'm using xcode (1.5) with the default gcc 3.3 and OS (10.3.8) and the latest xerces (2.6 I believe, this behavior was the same for other recent releases).
We're initializing the parser with:
xercesc::XMLPlatformUtils::Initialize();
mParser.reset( new xercesc::XercesDOMParser() );
mParser->setValidationScheme( xercesc::XercesDOMParser::Val_Always );
mParser->setDoNamespaces( false );
mParser->setDoSchema( true );
mParser->setCreateCommentNodes( false ); // No comment nodes
mParser->setIncludeIgnorableWhitespace( false ); // No text nodes
mErrHandler.reset( (xercesc::ErrorHandler*)new xercesc::HandlerBase() );
mParser->setErrorHandler( mErrHandler.get() );
And passing the file string to parser->parse( xmlFile.c_str() );
where parse is a pointer to the already initialized parser.
If I pass in ../../../configuration.xml
The parser looks for the file configuration.xml in the root directory. If its not there
then I get an exception message of
The primary document entity could not be opened. Id=//../../../configuration.xml
Note the extra "/"'s in front of the string that I passed in.
Thanks for your help.
Steve
-----Original Message----- From: James Berry [mailto:[EMAIL PROTECTED] Sent: Wed 3/16/05 10:07 AM To: xerces-c-dev@xml.apache.org Cc: Smith, Steven J (PNNL/JGCRI) Subject: Re: Relative paths in C++ on Macintosh OS X
Steve,
I don't know of a problem in this area. I've used relative paths successfully. But your setup may be somewhat different.
Can you provide more information about the context in which you're
seeing this issue? Build environment? Compiler? What API you're passing
the relative path to? Can you duplicate the issue with a test program?
On Mar 15, 2005, at 9:20 AM, Steve Smith wrote:
I'm having difficulty getting the Xerces-C++ parser to use relative
paths on Mac OS X. Using absolute paths works fine.
But when I try to pass the parser a path such as ../../../configuration.xml
Note that it's puzzling why the path above gets converted into an
absolute path as below... It looks like the current directory is root.
Xerces should be calling getcwd to fetch the current directory (and
does so at XMLParsePathToFSRef_X in MacOSPlatformUtils.cpp.
-jdb
I get an error: The primary document entity could not be opened. Id=//../../../configuration.xml
Do I need to use the routines in MacOSPlatformUtils.hpp to help with
this somehow?
Any help on this would be appreciated.
Thanks,
Steve
----------------------------------------------------------------- ----
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]