Re: Why is NSString-FSRef so hard?
On 29.04.2009, at 15:15, Mark Douma wrote: If you are working with file paths, you shouldn't be using componentsSeparatedByString:, nor should you be defining / to be the component you should be separating by. What if someone had your app inside of a folder they named Apps/Utilities? The HFS+ filesystem actually uses a colon as the path separator, so having a / in the name of a file or folder is perfectly acceptable, but would likely cause a headache and unexpected results if your code were to encounter it. (Go to the Finder and try adding a /). Errr... No. This is very misleading. While it is true that HFS and HFS+ use a colon as the path separator on disk, all Cocoa and POSIX APIs on the Mac swap colons and slashes before you ever get to see them. The only case where you as a programmer see this difference is in Finder, in CoreServices File Manager calls (fka Carbon File Manager), and when you call displayNameAtPath:. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On 30.04.2009, at 13:12, Alastair Houghton wrote: 3. AFAIK the Carbon layer maps them back again. Carbon's filesystem functions are implemented on top of the BSD layer, not alongside it as some people assume (OK, OK, there is the .vol special folder and there are a couple of additional entry-points that Carbon uses that are really SPI rather than API, but they're still BSD-level things). In defense of those some people, it should be mentioned that this has changed over time. AFAIK, in 10.0 Carbon and POSIX (I'm lumping together anything that uses POSIX paths here) took two parallel, but mostly separate paths, leading to fun bugs like permissions being ignored in some cases. At some later MacOS revision, this was changed to have one common pipeline. Since not every description gets updated with every system revision, it's easy to see how people could get confused. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
/ has been in use since the inception of unix in 1970 that's 39 years. I seriously doubt it's going to change anytime soon. In 39 more years, i'll be dead. ERG Sent from my iPod On Apr 29, 2009, at 8:50 PM, Michael Ash michael@gmail.com wrote: On Wed, Apr 29, 2009 at 10:22 PM, Andrew Farmer andf...@gmail.com wrote: On 29 Apr 09, at 06:15, Mark Douma wrote: If you are working with file paths, you shouldn't be using componentsSeparatedByString:, nor should you be defining / to be the component you should be separating by. What if someone had your app inside of a folder they named Apps/Utilities? The HFS+ filesystem actually uses a colon as the path separator, so having a / in the name of a file or folder is perfectly acceptable, but would likely cause a headache and unexpected results if your code were to encounter it. (Go to the Finder and try adding a /). What you're saying here is incredibly misleading, and actively harmful. While I believe that HFS+ uses : as a path separator on-disk, virtually all non-Carbon userspace code makes use of UNIX paths. Either Carbon or the Finder itself is swapping colons and slashes for display purposes - running ls should reveal that filenames which appear as slashes in the Finder appear as colons. It is a baffling myth, and I can't understand how anyone with any experience with the system would actually believe it. The OS goes through a great deal of trouble to make HFS+ filesystems look and behave exactly like any other UNIX-visible filesystem. Do you not use Terminal? Do you not examine any of the hundreds or thousands of paths flying through your application? They *all* use / as the path separator. (The reason a folder named Apps/Utilities does not break things is because at the UNIX level this is represented as Apps:Utilities. / is not allowed in filenames at that level, period. Doesn't matter what filesystem you're on.) Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/erg_consultant%40yahoo.com This email sent to erg_consult...@yahoo.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Thu, Apr 30, 2009 at 4:32 AM, ERG Consultant erg_consult...@yahoo.com wrote: / has been in use since the inception of unix in 1970 that's 39 years. I seriously doubt it's going to change anytime soon. In 39 more years, i'll be dead. Cocoa is derived from Openstep (or OPENSTEP, or OpEnStEp, depending on the state of the caps lock key in the marketing department at the time). Openstep has run on a multitude of platforms, including Microsoft Windows. This is why the API exists. With the API you also get bonuses like proper concatenation of non-delimiter-terminated paths with relative paths. In other words, why not just use the damn API? It's not like you need to deposit a coin to make a function call. --Kyle Sluder P.S. Apologies for the pun. P.P.S. If you did have to pay per call, how much more expensive would a far call be? :) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On 30 Apr 2009, at 05:02, Charles Srstka wrote: Carbon and the Finder are displaying the filenames as is, as HFS allows slashes to be in a filename, and the colon is the separator. Cocoa and the BSD layer, on the other hand, do swap the slashes and colons. Presumably the idea is to display slashes in a filename as whatever the path separator is supposed to be, so that the path can be a standard UNIX path - my guess is that if you had a file on an NTFS volume with a slash in its filename, Cocoa would interpret the slash as a backslash. I don't have an NTFS disk to test that with, though. Just to clear things up: 1. Cocoa and the BSD layer are *not* swapping the slashes and colons. They use the filenames that they are given by the kernel. 2. The HFS+ filesystem implementation *inside the kernel* does map slashes in filenames to colons. It has to, because the kernel parses path strings (which it must do in order to support symlinks and mount points), and it requires that the separator is /. 3. AFAIK the Carbon layer maps them back again. Carbon's filesystem functions are implemented on top of the BSD layer, not alongside it as some people assume (OK, OK, there is the .vol special folder and there are a couple of additional entry-points that Carbon uses that are really SPI rather than API, but they're still BSD-level things). 4. NTFS does not support slashes in filenames (or at least, not on Windows, which is arguably the same thing). Furthermore, Windows (contrary to popular belief) is quite happy to use the slash as a path separator; I sometimes wish that fact was more widely known, because it would save us from reams of unnecessary code to substitute forward slashes with backslashes. (It might help people to think of the substitution of on-disk / characters with :s as being entirely an issue of character encoding.) Kind regards, Alastair. -- http://alastairs-place.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Apr 30, 2009, at 4:52 AM, Kyle Sluder wrote: In other words, why not just use the damn API? It's not like you need to deposit a coin to make a function call. If you did, we wouldn't have toll-free bridging. --Andy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On 29.Apr, 2009, at 21:02 , Charles Srstka wrote: On 29 Apr 09, at 06:15, Mark Douma wrote: Carbon and the Finder are displaying the filenames as is, as HFS allows slashes to be in a filename, and the colon is the separator. Cocoa and the BSD layer, on the other hand, do swap the slashes and colons. Since all access to the filesystem is via the kernel and the kernel uses '/', the above is not true. Carbon and the Finder also get '/' from the kernel, they then proceed to swap them for legacy- compatibility. So what you are interpreting as displaying the filename as is is actually the result of two transformations that cancel each other out in that particular case. Presumably the idea is to display slashes in a filename as whatever the path separator is supposed to be, The display transformation is done by Carbon and the Finder. All kernel processing of paths is slash-based (except obviously inside one of the filesystems that do it differently, but that difference is not visible to the rest of the kernel or userland processes). so that the path can be a standard UNIX path - my guess is that if you had a file on an NTFS volume with a slash in its filename, Cocoa would interpret the slash as a backslash. It wouldn't be Cocoa doing this, it would be the kernel. So the kernel, BSD userspace and Cocoa would all see the slash. Carbon would translate the slash to a colon. With that said, I don't really see what is harmful about recommending the use of NSString's path concatenation methods, which could save quite a few headaches in the case that this *does* somehow change for some bizarre reason, however unlikely that may be. Good advice, yes. Marcel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Apr 28, 2009, at 1:34 AM, Erg Consultant wrote:
if( glBundle ) {
// Get main bundle info dict...
d = [ glBundle infoDictionary ];
if( d ) {
// Get the GL bundle's path from the info dict...
z = [ d objectForKey:kNSBundleInitialPathInfoDictKey ];
if( z ) {
// Break the path up into a path component array...
arr = [ z
componentsSeparatedByString:kSlashStringKey ];
// Make a mutable path string to manipulate...
m = [ NSMutableString stringWithCapacity:0 ];
}
}
}
if( m arr ){
for(i=0; i[ arr count] - 1; i++ ) {
[m appendString:[arr objectAtIndex:i] ];
[m appendString:@/ ];
}
//go up one level to get at Info.plist
[m appendString:@Info.plist ];
dd = [ NSDictionary dictionaryWithContentsOfFile:m ];
zzz = [ dd valueForKey:@CFBundleExecutable ];
//reset
[ m setString:@ ];
//Loop again appening all path compoents to final file to
launch...
for(i=0; i[ arr count] - 1; i++ ) {
[m appendString:[arr objectAtIndex:i] ];
[m appendString:@/ ];
}
//now get full path to the file we want to actually run...
[ m appendString:zzz ];
[ m appendString:@.ifn ];
Wow, you are making this problem way, way harder than it needs to
be. ;-)
If you are working with file paths, you shouldn't be using
componentsSeparatedByString:, nor should you be defining / to be the
component you should be separating by. What if someone had your app
inside of a folder they named Apps/Utilities? The HFS+ filesystem
actually uses a colon as the path separator, so having a / in the name
of a file or folder is perfectly acceptable, but would likely cause a
headache and unexpected results if your code were to encounter it. (Go
to the Finder and try adding a /).
When dealing with file paths, you should be using the following methods:
+ (NSString *)pathWithComponents:(NSArray *)components;
- (NSArray *)pathComponents;
- (NSString *)lastPathComponent;
- (NSString *)stringByDeletingLastPathComponent;
- (NSString *)stringByAppendingPathComponent:(NSString *)str;
- (NSString *)pathExtension;
- (NSString *)stringByDeletingPathExtension;
- (NSString *)stringByAppendingPathExtension:(NSString *)str;
- (NSString *)stringByStandardizingPath;
Note that these aren't in the NSString.h header itself, but in a
separate NSPathUtilities.h file.
Using these higher-level commands will insulate you from even having
to worry about what the path separator even is (it will be handled for
you). The same goes for adding a filename extensions: [fileName
stringByAppendingString:@.jpg] should be [fileName
stringByAppendingPathExtension:@jpg].***
Hope this helps,
Mark
*** Adobe developers, this means you! Maybe then I wouldn't have a
folder in my user library folder whose name is Application Support/
Adobe/Acrobat.
---
Mark Douma
Grand Rapids, MI, USA
mdoum...@mac.com
http://homepage.mac.com/mdouma46/
---
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On 29 Apr 09, at 06:15, Mark Douma wrote: If you are working with file paths, you shouldn't be using componentsSeparatedByString:, nor should you be defining / to be the component you should be separating by. What if someone had your app inside of a folder they named Apps/Utilities? The HFS+ filesystem actually uses a colon as the path separator, so having a / in the name of a file or folder is perfectly acceptable, but would likely cause a headache and unexpected results if your code were to encounter it. (Go to the Finder and try adding a /). What you're saying here is incredibly misleading, and actively harmful. While I believe that HFS+ uses : as a path separator on- disk, virtually all non-Carbon userspace code makes use of UNIX paths. Either Carbon or the Finder itself is swapping colons and slashes for display purposes - running ls should reveal that filenames which appear as slashes in the Finder appear as colons. Indeed, the methods in NSPathUtilities are entirely equivalent to string manipulation methods which split and join on slashes. They handle a lot of special cases for you (absolute paths, for instance), but they are in no way doing anything specific to HFS+. Moreover, you can rely on the path separator remaining a slash for the foreseeable future. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Wed, Apr 29, 2009 at 10:22 PM, Andrew Farmer andf...@gmail.com wrote: On 29 Apr 09, at 06:15, Mark Douma wrote: If you are working with file paths, you shouldn't be using componentsSeparatedByString:, nor should you be defining / to be the component you should be separating by. What if someone had your app inside of a folder they named Apps/Utilities? The HFS+ filesystem actually uses a colon as the path separator, so having a / in the name of a file or folder is perfectly acceptable, but would likely cause a headache and unexpected results if your code were to encounter it. (Go to the Finder and try adding a /). What you're saying here is incredibly misleading, and actively harmful. While I believe that HFS+ uses : as a path separator on-disk, virtually all non-Carbon userspace code makes use of UNIX paths. Either Carbon or the Finder itself is swapping colons and slashes for display purposes - running ls should reveal that filenames which appear as slashes in the Finder appear as colons. It is a baffling myth, and I can't understand how anyone with any experience with the system would actually believe it. The OS goes through a great deal of trouble to make HFS+ filesystems look and behave exactly like any other UNIX-visible filesystem. Do you not use Terminal? Do you not examine any of the hundreds or thousands of paths flying through your application? They *all* use / as the path separator. (The reason a folder named Apps/Utilities does not break things is because at the UNIX level this is represented as Apps:Utilities. / is not allowed in filenames at that level, period. Doesn't matter what filesystem you're on.) Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Apr 29, 2009, at 9:22 PM, Andrew Farmer wrote: On 29 Apr 09, at 06:15, Mark Douma wrote: If you are working with file paths, you shouldn't be using componentsSeparatedByString:, nor should you be defining / to be the component you should be separating by. What if someone had your app inside of a folder they named Apps/Utilities? The HFS+ filesystem actually uses a colon as the path separator, so having a / in the name of a file or folder is perfectly acceptable, but would likely cause a headache and unexpected results if your code were to encounter it. (Go to the Finder and try adding a /). What you're saying here is incredibly misleading, and actively harmful. While I believe that HFS+ uses : as a path separator on- disk, virtually all non-Carbon userspace code makes use of UNIX paths. Either Carbon or the Finder itself is swapping colons and slashes for display purposes - running ls should reveal that filenames which appear as slashes in the Finder appear as colons. Indeed, the methods in NSPathUtilities are entirely equivalent to string manipulation methods which split and join on slashes. They handle a lot of special cases for you (absolute paths, for instance), but they are in no way doing anything specific to HFS+. Moreover, you can rely on the path separator remaining a slash for the foreseeable future. Carbon and the Finder are displaying the filenames as is, as HFS allows slashes to be in a filename, and the colon is the separator. Cocoa and the BSD layer, on the other hand, do swap the slashes and colons. Presumably the idea is to display slashes in a filename as whatever the path separator is supposed to be, so that the path can be a standard UNIX path - my guess is that if you had a file on an NTFS volume with a slash in its filename, Cocoa would interpret the slash as a backslash. I don't have an NTFS disk to test that with, though. With that said, I don't really see what is harmful about recommending the use of NSString's path concatenation methods, which could save quite a few headaches in the case that this *does* somehow change for some bizarre reason, however unlikely that may be. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Thu, Apr 30, 2009 at 12:02 AM, Charles Srstka cocoa...@charlessoft.com wrote: With that said, I don't really see what is harmful about recommending the use of NSString's path concatenation methods, which could save quite a few headaches in the case that this *does* somehow change for some bizarre reason, however unlikely that may be. Even if the path separator never changes, they are still beneficial to use because they automatically handle both the trailing slash present and trailing slash missing cases transparently [@/foo stringByAppendingPathComponent: @bar] - /foo/bar [@/foo/ stringByAppendingPathComponent: @bar] - /foo/bar - Jim ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Thu, Apr 30, 2009 at 12:02 AM, Charles Srstka cocoa...@charlessoft.com wrote: With that said, I don't really see what is harmful about recommending the use of NSString's path concatenation methods, which could save quite a few headaches in the case that this *does* somehow change for some bizarre reason, however unlikely that may be. Nothing wrong with recommending the NSString methods. Indeed, that's a good idea. What's harmful is spreading false information about HFS's path separators. When dealing with UNIX paths, the OS X path separator is /, end of story. (When dealing with Carbon paths, it's :, no matter what your filesystem, even on UFS, even on FAT32, but a Cocoa app rarely has any occasion to use Carbon paths.) Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Tue, Apr 28, 2009 at 12:21 AM, Erg Consultant erg_consult...@yahoo.com wrote: LSOpenCFURLRef doesn't work either - kLSApplicationNotFoundErr. The nature of the file is the app's exe which is normally inside the MacOS dir. However, all this works perfectly fine if there are no special chars in the path - the exe launches just fine. I find it hard to believe that Apple would issue an API that executes single executable binaries only in the case that they don't have special chars in the path. Because you seem to still think this is Apple's fault, I've created a simple app which demonstrates what you are telling us you are trying to do: https://netfiles.uiuc.edu:443/sbutler1/www/Open%20An%20App.tar.gz The way I tested it is I copied TextEdit to my desktop. Then I renamed it TextEdit™, and went into the app bundle and renamed the executable TextEdit™. Then I typed this into the text box and hit return: /Users/me/Desktop/TextEdit™.app/Contents/MacOS/TextEdit™ Hit launch and TextEdit launched. Ergo, OS X has no problems with special characters in the path. Your issue is in your code. QED. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
I should mention I am using XCode 2.5 under 10.5 so I cannot use the 10.5 SDK nor Obj-C 2.0. Erg From: Stephen J. Butler stephen.but...@gmail.com To: Cocoa-Dev List cocoa-dev@lists.apple.com Sent: Monday, April 27, 2009 11:14:44 PM Subject: Re: Why is NSString-FSRef so hard? On Tue, Apr 28, 2009 at 12:21 AM, Erg Consultant erg_consult...@yahoo.com wrote: LSOpenCFURLRef doesn't work either - kLSApplicationNotFoundErr. The nature of the file is the app's exe which is normally inside the MacOS dir. However, all this works perfectly fine if there are no special chars in the path - the exe launches just fine. I find it hard to believe that Apple would issue an API that executes single executable binaries only in the case that they don't have special chars in the path. Because you seem to still think this is Apple's fault, I've created a simple app which demonstrates what you are telling us you are trying to do: https://netfiles.uiuc.edu:443/sbutler1/www/Open%20An%20App.tar.gz The way I tested it is I copied TextEdit to my desktop. Then I renamed it TextEdit™, and went into the app bundle and renamed the executable TextEdit™. Then I typed this into the text box and hit return: /Users/me/Desktop/TextEdit™.app/Contents/MacOS/TextEdit™ Hit launch and TextEdit launched. Ergo, OS X has no problems with special characters in the path. Your issue is in your code. QED. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/erg_consultant%40yahoo.com This email sent to erg_consult...@yahoo.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Apr 27, 2009, at 9:14 PM, Erg Consultant wrote: I write the original STL string to a tmp file, then read it back in. The file is encoded in MacRoman. I tried UTF8 with both converting and reinterpreting but if I use UTF8 when I read it back from file, the read returns nil. If I use MacRoman, the string reads back fine, but when I go to convert it to the URL and then the FSSpec, the FSSpec is invalid and cannot be used byLSOpenApplication I think the confusion in your code about encodings is part of the problem: Why is anything MacRoman to begin with at all? Applications these days should be using Unicode throughout if at all possible. Here are the snippets: exePathString = [ NSString stringWithContentsOfFile:kTempQuagmireHackFilePathNSString encoding:NSMacOSRomanStringEncoding error:inError ];// - Works urlRef = [ NSURL fileURLWithPath:exePathString ]; // - Works converted = CFURLGetFSRef( (CFURLRef)urlRef, exeRef ); // - Works It's important to know that this really works -- that CFURLGetFSRef is returning true -- because an FSRef can't refer to a non-existent file. Does it? If you use -[NSData dataWithContentsOfURL:options:error:] to read the contents of your URL, does that succeed? Or if it fails, what does it return for its error output parameter? inAppParams.application = exeRef; // I also zero out the whole block before this. err = LSOpenApplication( inAppParams, outPSN ); // - Fails with -10810 error - Unexpected internal error What else do you have set in inAppParams? Did you specify kLSLaunchDefaults (which *is not* 0) for inAppParams.flags? Do you have appropriate permissions for the application at your ultimate FSRef? -- Chris ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
Yes, I've verified that everything is correct. I zero'ed the launch param block and set kLSLaunchDefaults. Oddly, I can now get it to work in the built release version (binary) but if I run it from the debugger, LSOpenApplication returns noErr, but if I try to get the pid of the launched, process, it says not found + the binary itself never runs (even though LSOpenApplication returns no err). I assume this has something to do with XCode launching it within its own process. What a headache! Erg From: Chris Hanson c...@me.com To: Erg Consultant erg_consult...@yahoo.com Cc: cocoa-dev@lists.apple.com Sent: Tuesday, April 28, 2009 12:22:38 AM Subject: Re: Why is NSString-FSRef so hard? On Apr 27, 2009, at 9:14 PM, Erg Consultant wrote: I write the original STL string to a tmp file, then read it back in. The file is encoded in MacRoman. I tried UTF8 with both converting and reinterpreting but if I use UTF8 when I read it back from file, the read returns nil. If I use MacRoman, the string reads back fine, but when I go to convert it to the URL and then the FSSpec, the FSSpec is invalid and cannot be used byLSOpenApplication I think the confusion in your code about encodings is part of the problem: Why is anything MacRoman to begin with at all? Applications these days should be using Unicode throughout if at all possible. Here are the snippets: exePathString = [ NSString stringWithContentsOfFile:kTempQuagmireHackFilePathNSString encoding:NSMacOSRomanStringEncoding error:inError ];// - Works urlRef = [ NSURL fileURLWithPath:exePathString ]; // - Works converted = CFURLGetFSRef( (CFURLRef)urlRef, exeRef ); // - Works It's important to know that this really works -- that CFURLGetFSRef is returning true -- because an FSRef can't refer to a non-existent file. Does it? If you use -[NSData dataWithContentsOfURL:options:error:] to read the contents of your URL, does that succeed? Or if it fails, what does it return for its error output parameter? inAppParams.application = exeRef; // I also zero out the whole block before this. err = LSOpenApplication( inAppParams, outPSN ); // - Fails with -10810 error - Unexpected internal error What else do you have set in inAppParams? Did you specify kLSLaunchDefaults (which *is not* 0) for inAppParams.flags? Do you have appropriate permissions for the application at your ultimate FSRef? -- Chris ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Tue, Apr 28, 2009 at 1:13 AM, Erg Consultant erg_consult...@yahoo.com wrote: Apple's doc's specifically say to stay away from using the CString routines which require encodings. So now the encoding issue goes away. The problem is LSOpenApplication() does not like the FSRef I pass it which gets created from the path NSString-CFURL-FSRef. They state the opposite. They say to stay away from the ones which do NOT require encodings. That's because the ones without encodings use the system encoding which is not guaranteed to be anything useful. The ones with encodings require you to specify them yourself and are therefore just fine. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Mon, Apr 27, 2009 at 10:13 PM, Erg Consultant erg_consult...@yahoo.com wrote: Apple's doc's specifically say to stay away from using the CString routines which require encodings. Where do they say that? -- Clark S. Cox III clarkc...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
Le 28 avr. 09 à 17:47, Michael Ash a écrit : On Tue, Apr 28, 2009 at 1:13 AM, Erg Consultant erg_consult...@yahoo.com wrote: Apple's doc's specifically say to stay away from using the CString routines which require encodings. So now the encoding issue goes away. The problem is LSOpenApplication() does not like the FSRef I pass it which gets created from the path NSString- CFURL-FSRef. They state the opposite. They say to stay away from the ones which do NOT require encodings. That's because the ones without encodings use the system encoding which is not guaranteed to be anything useful. The ones with encodings require you to specify them yourself and are therefore just fine. And to add a word about your LS issue, it's because to launch an app, you should create a ref on the bundle, not on the executable. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
I was reading it wrong. Page 12 Strings Programming Guide For Cocoa: Important: NSString provides a number of methods to use Cstrings directly (such as stringWithCString:,initWithCString:, initWithCString:length:, and initWithCStringNoCopy:length:freeWhenDone:). These methods use the default C string encoding and may lose information in the conversion from that encoding. You are strongly discouraged from using these methods as are deprecated in Mac OS X v10.4. From: Clark Cox clarkc...@gmail.com To: Erg Consultant erg_consult...@yahoo.com Cc: cocoa-dev cocoa-dev@lists.apple.com Sent: Tuesday, April 28, 2009 9:07:00 AM Subject: Re: Why is NSString-FSRef so hard? On Mon, Apr 27, 2009 at 10:13 PM, Erg Consultant erg_consult...@yahoo.com wrote: Apple's doc's specifically say to stay away from using the CString routines which require encodings. Where do they say that? -- Clark S. Cox III clarkc...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
Well, I finally got it to work - but it took a lot of work. How does one launch an exe inside an app bundle if LSOpenApplication isn't desgined to do that? Erg From: Jean-Daniel Dupas devli...@shadowlab.org To: cocoa-dev cocoa-...@lists.apple..com Sent: Tuesday, April 28, 2009 9:59:07 AM Subject: Re: Why is NSString-FSRef so hard? Le 28 avr. 09 à 17:47, Michael Ash a écrit : On Tue, Apr 28, 2009 at 1:13 AM, Erg Consultant erg_consult...@yahoo.com wrote: Apple's doc's specifically say to stay away from using the CString routines which require encodings. So now the encoding issue goes away. The problem is LSOpenApplication() does not like the FSRef I pass it which gets created from the path NSString-CFURL-FSRef. They state the opposite. They say to stay away from the ones which do NOT require encodings. That's because the ones without encodings use the system encoding which is not guaranteed to be anything useful. The ones with encodings require you to specify them yourself and are therefore just fine. And to add a word about your LS issue, it's because to launch an app, you should create a ref on the bundle, not on the executable.. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/erg_consultant%40yahoo.com This email sent to erg_consult...@yahoo.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Tue, Apr 28, 2009 at 5:03 PM, Erg Consultant erg_consult...@yahoo.com wrote: How does one launch an exe inside an app bundle if LSOpenApplication isn't desgined to do that? exe? You need to specify what you mean: executable binary, which is just a plain binary file, or application, which is wrapped in a .app bundle. If you just want to launch a binary as a child task, you can use NSTask and -[NSBundle pathForAuxiliaryExecutable:]. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
This is a DRM situation where there are multiple app executables inside the main .app bundle. From: Kyle Sluder kyle.slu...@gmail.com To: Erg Consultant erg_consult...@yahoo.com Cc: cocoa-dev cocoa-dev@lists.apple.com Sent: Tuesday, April 28, 2009 2:11:40 PM Subject: Re: Why is NSString-FSRef so hard? On Tue, Apr 28, 2009 at 5:03 PM, Erg Consultant erg_consult...@yahoo.com wrote: How does one launch an exe inside an app bundle if LSOpenApplication isn't desgined to do that? exe? You need to specify what you mean: executable binary, which is just a plain binary file, or application, which is wrapped in a .app bundle. If you just want to launch a binary as a child task, you can use NSTask and -[NSBundle pathForAuxiliaryExecutable:]. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Apr 28, 2009, at 4:13 PM, Erg Consultant wrote: This is a DRM situation where there are multiple app executables inside the main .app bundle. NSTask. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
I write the original STL string to a tmp file, then read it back in. The file is encoded in MacRoman. I tried UTF8 with both converting and reinterpreting but if I use UTF8 when I read it back from file, the read returns nil. If I use MacRoman, the string reads back fine, but when I go to convert it to the URL and then the FSSpec, the FSSpec is invalid and cannot be used byLSOpenApplication Here are the snippets: exePathString = [ NSString stringWithContentsOfFile:kTempQuagmireHackFilePathNSString encoding:NSMacOSRomanStringEncoding error:inError ];// - Works urlRef = [ NSURL fileURLWithPath:exePathString ]; // - Works converted = CFURLGetFSRef( (CFURLRef)urlRef, exeRef ); // - Works inAppParams.application = exeRef; // I also zero out the whole block before this. err = LSOpenApplication( inAppParams, outPSN ); // - Fails with -10810 error - Unexpected internal error From: Steve Christensen puns...@mac.com To: Erg Consultant erg_consult...@yahoo.com Cc: cocoa-dev@lists.apple.com Sent: Saturday, April 25, 2009 6:04:14 PM Subject: Re: Why is NSString-FSRef so hard? You'd said in an earlier thread that the file path characters are coming from a text file and that you're then storing those in a STL string. The STL string doesn't care what the encoding is since it's just a storage construct. When you try to create a CFString or NSString from those characters, you need to know what the character encoding is, particularly for the case where a path contains special (non-ASCII) characters, otherwise the CFStringCreate*() or [NSString stringWith*:] calls will fail. If those fail then you won't be able to successfully create a CFURL/NSURL, so CFURLGetFSRef will naturally fail. Since you haven't been able (so far) to determine what the character encoding is, have you thought about reading in the characters from the file, displaying each character in hex, and finding the value(s) that represent one of the non-ASCII characters? With those values in hand you should be able to do some online research to determine what the character encoding actually is. Once you get past that part, everything else should just work. On Saturday, April 25, 2009, at 05:28PM, Erg Consultant erg_consult...@yahoo.com wrote: I was using CFURLGetFSRef passing in the NSString which works fine as long as the path contains no special chars. If it does, CFURLGetFSRef returns nil. Erg From: Nick Zitzmann n...@chronosnet.com To: Erg Consultant erg_consult...@yahoo.com Cc: cocoa-dev@lists.apple.com Sent: Saturday, April 25, 2009 4:41:20 PM Subject: Re: Why is NSString-FSRef so hard? On Apr 25, 2009, at 5:33 PM, Erg Consultant wrote: Isn't there some easy way to get an FSRef from an NSString that is a path containing special characters? What, specifically, have you tried? I don't think I've ever had +fileURLWithPath: fail on me with a path string, even if the string contained non-ASCII characters. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
FSPathMakeRef did not work - which drove me to find some other way such an NSString-CFURL-FSRef. Reading the string in from a file as an NSString does however work for making the original path string without magling the characters - reading the same string from the same file as a CFStringRef however does not work - the special characters get mangled. Erg From: Ken Thomases k...@codeweavers.com To: Erg Consultant erg_consult...@yahoo.com Cc: cocoa-dev@lists.apple.com Sent: Saturday, April 25, 2009 6:12:33 PM Subject: Re: Why is NSString-FSRef so hard? On Apr 25, 2009, at 8:03 PM, Erg Consultant wrote: On Apr 25, 2009, at 7:48 PM, Stephen J. Butler wrote: On Sat, Apr 25, 2009 at 7:28 PM, Erg Consultant erg_consult...@yahoo.com wrote: I was using CFURLGetFSRef passing in the NSString which works fine as long as the path contains no special chars. If it does, CFURLGetFSRef returns nil. CFURLGetFSRef is great if what you have originally is a CF/NSURL. But if you just have an NSString, you might as well use FSPathMakeRef with [aString fileSystemRepresentation]. No reason to create an intermediary NSURL. When I do that, the conversion from NSString to const UInt8 * path mangles the special characters in the path. What do you mean mangles? I suspect you're misinterpreting encodes as mangles. Asking a file path string for its -fileSystemRepresentation is asking it to encode the string into the form expected by various APIs which take file paths in C strings (of 8-bit characters). Of course this won't look like the original Unicode string contents; Unicode can't fit into 8-bit characters without being encoded somehow. But the question is, why do you care? Did FSPathMakeRef work, when passed such a string? It should, which is all you're interested in. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
One other thing I should mention - the mangled char in question is the tm symbol (option-2). In its string form, the debugger shows it as the tm char. But when I convert the string to an NSURL using fileURLWithPath, and then do a CFShow, the tm is converted to *three* hex chars: %E2%84%A2 Are NSURL and CFURL not toll-free bridged? Erg From: Sean McBride cwat...@cam.org To: Erg Consultant erg_consult...@yahoo.com; cocoa-dev@lists.apple.com Sent: Sunday, April 26, 2009 2:41:20 PM Subject: Re: Why is NSString-FSRef so hard? Erg Consultant (erg_consult...@yahoo.com) on 2009-04-25 7:33 PM said: Isn't there some easy way to get an FSRef from an NSString that is a path containing special characters? You can use NDAlias: http://github.com/nathanday/ndalias/tree/master It provides an NSString category that converts to/from FSRef. Sean ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Apr 27, 2009, at 11:26 PM, Erg Consultant wrote: One other thing I should mention - the mangled char in question is the tm symbol (option-2). In its string form, the debugger shows it as the tm char. But when I convert the string to an NSURL using fileURLWithPath, and then do a CFShow, the tm is converted to *three* hex chars: %E2%84%A2 Right. This is to be expected. Not all characters are legal within URLs. So, URLs have to be escaped. The trademark character in UTF-8 encoding is the byte sequence 0xE2, 0x84, 0xA2. Yes, three bytes. Those bytes are then escaped using percent-sign-hex-value to make them safe for a URL. I strongly suspect your problems and your confusion about the results you're seeing are because you aren't understanding the subject of string encoding. You appear to be blindly stabbing in the dark, trying to guess why things work or don't. As somebody earlier in the thread pointed out, STL strings are not encoding aware. If you don't know the encoding of the bytes that you used to initialize those STL strings, then you're not going to have any luck interpreting them, writing them sanely to a file in a consistent way, nor reading them back in. Are NSURL and CFURL not toll-free bridged? They are toll-free bridged. What about the above made you think otherwise? Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Tue, Apr 28, 2009 at 12:51 AM, Erg Consultant erg_consult...@yahoo.com wrote: So why isn't it working? Why does LSOpenApplication give me an error? It is impossible to answer questions of this nature if you do not post your code. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
BOOLresult = YES;
Booleanconverted = false;
unsignedi = 0;
pid_tpid = -1;
NSBundle*glBundle = [ NSBundle mainBundle ];
NSDictionary*d = nil;
NSDictionary*dd;
NSString*z;
NSString*zzz;
NSMutableString*m;
NSArray*arr;
NSURL*urlRef = nil;
NSError*inError = nil;
FSRefexeRef;
LSApplicationParametersinAppParams;
ProcessSerialNumberoutPSN;
OSStatuserr = noErr;
memset( inAppParams, 0, sizeof( inAppParams ) );
memset( outPSN, 0, sizeof( outPSN ) );
if( glBundle )
{
// Get main bundle info dict...
d = [ glBundle infoDictionary ]
if( d )
{
// Get the GL bundle's path from the info dict...
z = [ d objectForKey:kNSBundleInitialPathInfoDictKey ];
if( z )
{
// Break the path up into a path component array...
arr = [ z componentsSeparatedByString:kSlashStringKey ];
// Make a mutable path string to manipulate...
m = [ NSMutableString stringWithCapacity:0 ];
}
}
}
if( m arr )
{
for(i=0; i[ arr count] - 1; i++ )
{
[m appendString:[arr objectAtIndex:i] ];
[m appendString:@/ ];
}
//go up one level to get at Info.plist
[m appendString:@Info.plist ];
dd = [ NSDictionary dictionaryWithContentsOfFile:m ];
zzz = [ dd valueForKey:@CFBundleExecutable ];
//reset
[ m setString:@ ];
//Loop again appening all path compoents to final file to launch...
for(i=0; i[ arr count] - 1; i++ )
{
[m appendString:[arr objectAtIndex:i] ];
[m appendString:@/ ];
}
//now get full path to the file we want to actually run...
[ m appendString:zzz ];
[ m appendString:@.ifn ];
urlRef = [ NSURL fileURLWithPath:m ];
if( urlRef )
{
CFShow( urlRef );
converted = CFURLGetFSRef( (CFURLRef)urlRef, exeRef );
if( converted )
{
// Setup launch param block...
inAppParams.application = exeRef;
// Launch!
err = LSOpenApplication( inAppParams, outPSN );
if( !err )
{
err = GetProcessPID( outPSN, pid );
if( !err )
{
lppiProcInfo-dwProcessId = (DWORD)pid;
result = true;
}
}
}
}
From: Michael Ash michael@gmail.com
To: cocoa-dev cocoa-dev@lists.apple.com
Sent: Monday, April 27, 2009 9:57:33 PM
Subject: Re: Why is NSString-FSRef so hard?
On Tue, Apr 28, 2009 at 12:51 AM, Erg Consultant
erg_consult...@yahoo.com wrote:
So why isn't it working? Why does LSOpenApplication give me an error?
It is impossible to answer questions of this nature if you do not post
your code.
Mike
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/erg_consultant%40yahoo.com
This email sent to erg_consult...@yahoo.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Apr 27, 2009, at 11:51 PM, Erg Consultant wrote: 4) I verified that the file I am trying to open using LSOpenApplication exists at the path the URL points to when it gets converted to an FSRef. So why isn't it working? Why does LSOpenApplication give me an error? What is the path/URL/FSRef pointing to? What is the nature of the file-system object at that location? LSOpenApplication is expecting it to be an application bundle, generally. (There are some corner cases that are extremely rare in practice.) Have you considered using one of the other Launch Services functions, like LSOpenCFURLRef? Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
I abandoned the idea of using the temp file and now I assemble the path to the file I want on the fly using the main bundle and an Info.plist file which contains the executable file name - I am still having the same problem - without the STL string, temp file, or reading any file at all. So the STL string is no longer an issue - but the problem is. Apple's doc's specifically say to stay away from using the CString routines which require encodings. So now the encoding issue goes away. The problem is LSOpenApplication() does not like the FSRef I pass it which gets created from the path NSString-CFURL-FSRef. Erg From: Michael Ash michael@gmail.com To: cocoa-dev cocoa-dev@lists.apple.com Sent: Monday, April 27, 2009 9:51:14 PM Subject: Re: Why is NSString-FSRef so hard? On Tue, Apr 28, 2009 at 12:26 AM, Erg Consultant erg_consult...@yahoo.com wrote: One other thing I should mention - the mangled char in question is the tm symbol (option-2). In its string form, the debugger shows it as the tm char. But when I convert the string to an NSURL using fileURLWithPath, and then do a CFShow, the tm is converted to *three* hex chars: %E2%84%A2 Are NSURL and CFURL not toll-free bridged? Read this: http://www.joelonsoftware.com/articles/Unicode.html And then this: http://en.wikipedia.org/wiki/UTF-8 And this: http://en.wikipedia.org/wiki/UTF-16 Then, suitably enlightened, come back and fix up your code to work with your new knowledge. One other piece of knowledge: if you're converting your std::string to an NSString by writing it to a file, you're doing it wrong. Very, very, very wrong. All you should have to do is [NSString stringWithCString:stl_string.c_str() encoding:...] with the appropriate encoding substituted at the end. If you do not know the appropriate encoding, then you must find out. If the encoding is not UTF-8, then I strongly encourage you to make whatever changes are necessary so that it *is* UTF-8, as UTF-8 is the only sensible 8-bit encoding to use these days unless you're communicating with legacy systems. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/erg_consultant%40yahoo.com This email sent to erg_consult...@yahoo.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
LSOpenCFURLRef doesn't work either - kLSApplicationNotFoundErr. The nature of the file is the app's exe which is normally inside the MacOS dir. However, all this works perfectly fine if there are no special chars in the path - the exe launches just fine. I find it hard to believe that Apple would issue an API that executes single executable binaries only in the case that they don't have special chars in the path. Erg From: Ken Thomases k...@codeweavers.com To: Erg Consultant erg_consult...@yahoo.com Cc: cocoa-dev@lists.apple.com Sent: Monday, April 27, 2009 10:11:43 PM Subject: Re: Why is NSString-FSRef so hard? On Apr 27, 2009, at 11:51 PM, Erg Consultant wrote: 4) I verified that the file I am trying to open using LSOpenApplication exists at the path the URL points to when it gets converted to an FSRef. So why isn't it working? Why does LSOpenApplication give me an error? What is the path/URL/FSRef pointing to? What is the nature of the file-system object at that location? LSOpenApplication is expecting it to be an application bundle, generally. (There are some corner cases that are extremely rare in practice.) Have you considered using one of the other Launch Services functions, like LSOpenCFURLRef? Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
Ok, here is the code:
BOOLresult = NO;
Booleanconverted = false;
unsignedi = 0;
pid_tpid = -1;
NSBundle*glBundle = [ NSBundle mainBundle ];
NSDictionary*d = nil;
NSDictionary*dd = nil;
NSString*z = nil;
NSString*zzz = nil;
NSMutableString*m = nil;
NSArray*arr = nil;
NSURL*urlRef = nil;
NSError*inError = nil;
FSRefexeRef;
LSApplicationParametersinAppParams;
ProcessSerialNumberoutPSN;
OSStatuserr = noErr;
memset( exeRef, 0, sizeof( exeRef ) );
memset( inAppParams, 0, sizeof( inAppParams ) );
memset( outPSN, 0, sizeof( outPSN ) );
if( glBundle )
{
// Get main bundle info dict...
d = [ glBundle infoDictionary ];
if( d )
{
// Get the GL bundle's path from the info dict...
z = [ d objectForKey:kNSBundleInitialPathInfoDictKey ];
if( z )
{
// Break the path up into a path component array...
arr = [ z componentsSeparatedByString:kSlashStringKey ];
// Make a mutable path string to manipulate...
m = [ NSMutableString stringWithCapacity:0 ];
}
}
}
if( m arr )
{
for(i=0; i[ arr count] - 1; i++ )
{
[m appendString:[arr objectAtIndex:i] ];
[m appendString:@/ ];
}
//go up one level to get at Info.plist
[m appendString:@Info.plist ];
dd = [ NSDictionary dictionaryWithContentsOfFile:m ];
zzz = [ dd valueForKey:@CFBundleExecutable ];
//reset
[ m setString:@ ];
//Loop again appening all path compoents to final file to launch...
for(i=0; i[ arr count] - 1; i++ )
{
[m appendString:[arr objectAtIndex:i] ];
[m appendString:@/ ];
}
//now get full path to the file we want to actually run...
[ m appendString:zzz ];
[ m appendString:@.ifn ];
urlRef = [ NSURL fileURLWithPath:m ];
if( urlRef )
{
converted = CFURLGetFSRef( (CFURLRef)urlRef, exeRef );
if( converted )
{
CFURLRefqaud = NULL;
err = LSOpenCFURLRef( (CFURLRef)urlRef, qaud );
// Setup launch param block...
inAppParams.application = exeRef;
// Launch!
err = LSOpenApplication( inAppParams, outPSN );
if( !err )
{
err = GetProcessPID( outPSN, pid );
if( !err )
{
lppiProcInfo-dwProcessId = (DWORD)pid;
result = YES;
}
}
}
}
From: Ken Thomases k...@codeweavers.com
To: Erg Consultant erg_consult...@yahoo.com
Cc: cocoa-dev@lists.apple.com
Sent: Saturday, April 25, 2009 6:12:33 PM
Subject: Re: Why is NSString-FSRef so hard?
On Apr 25, 2009, at 8:03 PM, Erg Consultant wrote:
On Apr 25, 2009, at 7:48 PM, Stephen J. Butler wrote:
On Sat, Apr 25, 2009 at 7:28 PM, Erg Consultant
erg_consult...@yahoo.com wrote:
I was using CFURLGetFSRef passing in the NSString which works fine as long
as the path contains no special chars. If it does, CFURLGetFSRef returns
nil.
CFURLGetFSRef is great if what you have originally is a CF/NSURL. But
if you just have an NSString, you might as well use FSPathMakeRef with
[aString fileSystemRepresentation]. No reason to create an
intermediary NSURL.
When I do that, the conversion from NSString to const UInt8 * path mangles
the special characters in the path.
What do you mean mangles? I suspect you're misinterpreting encodes as
mangles. Asking a file path string for its -fileSystemRepresentation is asking
it to encode the string into the form expected by various APIs which take file
paths in C strings (of 8-bit characters). Of course this won't look like the
original Unicode string contents; Unicode can't fit into 8-bit characters
without being encoded somehow.
But the question is, why do you care? Did FSPathMakeRef work, when passed such
a string? It should, which is all you're interested in.
Regards,
Ken
Re: Why is NSString-FSRef so hard?
Erg Consultant (erg_consult...@yahoo.com) on 2009-04-25 7:33 PM said: Isn't there some easy way to get an FSRef from an NSString that is a path containing special characters? You can use NDAlias: http://github.com/nathanday/ndalias/tree/master It provides an NSString category that converts to/from FSRef. Sean ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Why is NSString-FSRef so hard?
I am trying to convert an NSString containing a path to a file directly to an FSRef. If there are no special characters in the path, it's easy - I can go from NSString to CFURL to FSRef. But if the path contains any special characters at all, both CFURL and NSURL creation routines fail. No matter what I do, or which routines I use, it won't work. Unfortunately I am stuck with some 3rd party apps that have special characters like (tm) in their bundle names and I can't change them. Isn't there some easy way to get an FSRef from an NSString that is a path containing special characters? Thanks, Erg ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Apr 25, 2009, at 5:33 PM, Erg Consultant wrote: Isn't there some easy way to get an FSRef from an NSString that is a path containing special characters? What, specifically, have you tried? I don't think I've ever had +fileURLWithPath: fail on me with a path string, even if the string contained non-ASCII characters. Nick Zitzmann http://www.chronosnet.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Sat, Apr 25, 2009 at 7:33 PM, Erg Consultant erg_consult...@yahoo.com wrote: I am trying to convert an NSString containing a path to a file directly to an FSRef. If there are no special characters in the path, it's easy - I can go from NSString to CFURL to FSRef. But if the path contains any special characters at all, both CFURL and NSURL creation routines fail. No matter what I do, or which routines I use, it won't work. Unfortunately I am stuck with some 3rd party apps that have special characters like (tm) in their bundle names and I can't change them. Isn't there some easy way to get an FSRef from an NSString that is a path containing special characters? Yes, using the technique you described. If it's not working for you, then it's because you're doing something wrong. However, since you have not posted your code, it is impossible to say just what it is that you're doing wrong. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Sat, Apr 25, 2009 at 6:33 PM, Erg Consultant
erg_consult...@yahoo.com wrote:
I am trying to convert an NSString containing a path to a file directly to an
FSRef. If there are no special characters in the path, it's easy - I can go
from NSString to CFURL to FSRef.
But if the path contains any special characters at all, both CFURL and NSURL
creation routines fail. No matter what I do, or which routines I use, it
won't work.
Unfortunately I am stuck with some 3rd party apps that have special
characters like (tm) in their bundle names and I can't change them.
Isn't there some easy way to get an FSRef from an NSString that is a path
containing special characters?
Works for me. My suspicion is that you aren't properly creating your
NSString in the first place.
#import Foundation/Foundation.h
int main (int argc, const char * argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
if (argc != 2) {
NSLog( @usage: file/directory path );
[pool drain];
return 1;
}
NSString *filePath = [NSString stringWithCString:argv[ 1 ]
encoding:NSUTF8StringEncoding];
NSLog( @filePath = %@, filePath );
NSURL *fileURL = [NSURL fileURLWithPath:filePath];
NSLog( @fileURL = %@, [fileURL absoluteURL] );
FSRef fileFSRef;
if (CFURLGetFSRef( (CFURLRef)fileURL, fileFSRef )) {
NSLog( @Created FSRef! );
} else {
NSLog( @Failed to create FSRef. );
}
[pool drain];
return 0;
}
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
I was using CFURLGetFSRef passing in the NSString which works fine as long as the path contains no special chars. If it does, CFURLGetFSRef returns nil. Erg From: Nick Zitzmann n...@chronosnet.com To: Erg Consultant erg_consult...@yahoo.com Cc: cocoa-dev@lists.apple.com Sent: Saturday, April 25, 2009 4:41:20 PM Subject: Re: Why is NSString-FSRef so hard? On Apr 25, 2009, at 5:33 PM, Erg Consultant wrote: Isn't there some easy way to get an FSRef from an NSString that is a path containing special characters? What, specifically, have you tried? I don't think I've ever had +fileURLWithPath: fail on me with a path string, even if the string contained non-ASCII characters. Nick Zitzmann http://www.chronosnet.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Sat, Apr 25, 2009 at 7:28 PM, Erg Consultant erg_consult...@yahoo.com wrote: I was using CFURLGetFSRef passing in the NSString which works fine as long as the path contains no special chars. If it does, CFURLGetFSRef returns nil. CFURLGetFSRef is great if what you have originally is a CF/NSURL. But if you just have an NSString, you might as well use FSPathMakeRef with [aString fileSystemRepresentation]. No reason to create an intermediary NSURL. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
When I do that, the conversion from NSString to const UInt8 * path mangles the special characters in the path. From: Stephen J. Butler stephen.but...@gmail.com To: Cocoa-Dev List cocoa-dev@lists.apple.com Sent: Saturday, April 25, 2009 5:48:09 PM Subject: Re: Why is NSString-FSRef so hard? On Sat, Apr 25, 2009 at 7:28 PM, Erg Consultant erg_consult...@yahoo.com wrote: I was using CFURLGetFSRef passing in the NSString which works fine as long as the path contains no special chars. If it does, CFURLGetFSRef returns nil. CFURLGetFSRef is great if what you have originally is a CF/NSURL. But if you just have an NSString, you might as well use FSPathMakeRef with [aString fileSystemRepresentation]. No reason to create an intermediary NSURL. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/erg_consultant%40yahoo.com This email sent to erg_consult...@yahoo.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
You'd said in an earlier thread that the file path characters are coming from a text file and that you're then storing those in a STL string. The STL string doesn't care what the encoding is since it's just a storage construct. When you try to create a CFString or NSString from those characters, you need to know what the character encoding is, particularly for the case where a path contains special (non-ASCII) characters, otherwise the CFStringCreate*() or [NSString stringWith*:] calls will fail. If those fail then you won't be able to successfully create a CFURL/NSURL, so CFURLGetFSRef will naturally fail. Since you haven't been able (so far) to determine what the character encoding is, have you thought about reading in the characters from the file, displaying each character in hex, and finding the value(s) that represent one of the non-ASCII characters? With those values in hand you should be able to do some online research to determine what the character encoding actually is. Once you get past that part, everything else should just work. On Saturday, April 25, 2009, at 05:28PM, Erg Consultant erg_consult...@yahoo.com wrote: I was using CFURLGetFSRef passing in the NSString which works fine as long as the path contains no special chars. If it does, CFURLGetFSRef returns nil. Erg From: Nick Zitzmann n...@chronosnet.com To: Erg Consultant erg_consult...@yahoo.com Cc: cocoa-dev@lists.apple.com Sent: Saturday, April 25, 2009 4:41:20 PM Subject: Re: Why is NSString-FSRef so hard? On Apr 25, 2009, at 5:33 PM, Erg Consultant wrote: Isn't there some easy way to get an FSRef from an NSString that is a path containing special characters? What, specifically, have you tried? I don't think I've ever had +fileURLWithPath: fail on me with a path string, even if the string contained non-ASCII characters. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Apr 25, 2009, at 7:28 PM, Erg Consultant wrote: I was using CFURLGetFSRef passing in the NSString which works fine as long as the path contains no special chars. If it does, CFURLGetFSRef returns nil. File path strings aren't URLs. Even a string which looks a bit URL- ish (for example, if you just tack file:// on the front of a path) isn't a URL. It's not a valid URL string; it is especially not a CFURL or NSURL object! If you've got a path string and you want to make a URL referencing the same file, you have to do it the right way. As mentioned, +fileURLWithPath: is one good way. CFURLCreateWithFileSystemPath also works. Wrong ways include +URLWithString: (and the other ...WithString... methods of NSURL) and CFURLCreateWithString. Those are only appropriate if your have a proper URL string (with characters that aren't legal in a URL escaped). Passing an NSString to a function which expects a CFURLRef is asking for trouble. Having it work or return nil is luck; it was just as like to crash your program. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Sat, Apr 25, 2009 at 8:28 PM, Erg Consultant erg_consult...@yahoo.com wrote: I was using CFURLGetFSRef passing in the NSString which works fine as long as the path contains no special chars. If it does, CFURLGetFSRef returns nil. That's unlikely. CFURLGetFSRef needs a CFURLRef or NSURL, not an NSString. If you want help with your code, *post your code*. It is pointless to try to describe in English what your code does. You already have a perfectly good textual description of what your code does, written in a language that everybody on this mailing list can read: your code itself. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why is NSString-FSRef so hard?
On Apr 25, 2009, at 8:03 PM, Erg Consultant wrote: On Apr 25, 2009, at 7:48 PM, Stephen J. Butler wrote: On Sat, Apr 25, 2009 at 7:28 PM, Erg Consultant erg_consult...@yahoo.com wrote: I was using CFURLGetFSRef passing in the NSString which works fine as long as the path contains no special chars. If it does, CFURLGetFSRef returns nil. CFURLGetFSRef is great if what you have originally is a CF/NSURL. But if you just have an NSString, you might as well use FSPathMakeRef with [aString fileSystemRepresentation]. No reason to create an intermediary NSURL. When I do that, the conversion from NSString to const UInt8 * path mangles the special characters in the path. What do you mean mangles? I suspect you're misinterpreting encodes as mangles. Asking a file path string for its - fileSystemRepresentation is asking it to encode the string into the form expected by various APIs which take file paths in C strings (of 8- bit characters). Of course this won't look like the original Unicode string contents; Unicode can't fit into 8-bit characters without being encoded somehow. But the question is, why do you care? Did FSPathMakeRef work, when passed such a string? It should, which is all you're interested in. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
