Hi Steve,
When you launch an application from the Finder there is no "reasonable" place for the cwd to be set, so it is set at the file system root. Note that it is actually the invoking code (Finder) that has (or hasn't ;) set the working directory in this case. The concept of a working directory makes sense from the shell environment, and the shell leaves it set to wherever you have it set. But note that even from a shell, the working directory does not get set to the exe location: it stays at wherever you last set it within the shell. Xcode will offer to set the working directory for you for purposes of debugging, but that information doesn't get bundled into the executable anywhere, and so won't have any effect outside of Xcode.
So: getcwd is working fine, but it's just that the cwd is not what you're expecting it to be. The issue with HGetVol is not relevent to this situation. It's still true, but it's orthogonal information.
If you want the cwd to be something particular from within your gui app, you should set it explicitly. If you really want to set it to where your executable is, I believe you can get that information from LaunchServices.
Note that I believe your earlier assertion that files you created were relative to some other cwd was false: any files created with relative paths will be relative to the cwd, which will be root if you're launched by Finder.
I hope that helps.
-jdb
On Mar 18, 2005, at 3:11 PM, Steve Smith wrote:
That works fine from the command line. It works fine if I do the equivalent in a C++ code from the command line.
Except, when I compile the same program in xcode, which creates an application package. Then it works ok under the following circumstances:
1) I run the application from within xcode AND I've set xcode to set the working directory of the executable to somewhere outside the application package.
This does not work if:
a) I have xcode set the working directory of the executable to inside the application package (which I was lead to understand is what happens at runtime) and I run the application from within xcode, or
b) I run the application from outside xcode by double clicking on the application package (regardless of what settings I've made in xcode).
I poking around in the documentation I found the following:
Carbon applications should use HGetVol and HSetVol to get and set the default directory. the functions GetVol and SetVol, as well as working directories, are no longer supported.
Is that relevant to this behavior?
Thanks,
Steve
At 9:19 PM -0800 3/17/05, James Berry wrote: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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
