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]
