• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Unix v. Mac [was: Setting up searches in Xcode [was: Xcode + Leopard at WWDCthis year]]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Unix v. Mac [was: Setting up searches in Xcode [was: Xcode + Leopard at WWDCthis year]]


  • Subject: Unix v. Mac [was: Setting up searches in Xcode [was: Xcode + Leopard at WWDCthis year]]
  • From: Chris Espinosa <email@hidden>
  • Date: Fri, 21 Jul 2006 11:27:20 -0700

This thread, too, has veered wildly from being helpful to people using Xcode, and ought to be taken off-list.

Or to save you time, you can read longer, older, better rehashes of this debate in the archives.

Chris


On Jul 21, 2006, at 11:12 AM, Laurence Harris wrote:

Responding to David and Steve:

On Jul 20, 2006, at 10:58 PM, Steve Checkoway wrote:

On Jul 20, 2006, at 7:31 PM, David Masover wrote:

Laurence Harris wrote:
That's bad app design -- use relative, configurable paths, not absolute paths. Besides, one of the major points of Unix is that paths don't necessarily correspond to real, physical locations.


and for problems to occur if a path is too long.

Hmm. You're right:
[...]
It would appear that this is the limit, either in number of directories or sheer filename length. Still, I can't see hitting that limit anytime soon. Also, it would appear to be a limitation of the software, not the system or the concept:

A quick grep of the system headers returns this:

$ egrep 'PATH_?MAX|MAX_?PATH' /usr/include/sys/{syslimits,param}.h
/usr/include/sys/syslimits.h:#define PATH_MAX 1024 /* max bytes in pathname */
/usr/include/sys/param.h: * MAXPATHLEN defines the longest permissable path length after expanding
/usr/include/sys/param.h:#define MAXPATHLEN PATH_MAX

Path-based APIs fail when paths get too long. Given that names in Mac OS X can be up 255 characters long, that some people like to use a deeper directory structure than others, and that as I understand it, Unicode characters can expand to at least three UTF-8 characters (can't remember the max off the top of my head), this limitation can cause problems in the real world. I realize they aren't common, but it's my position that they simply should never occur. 25 years ago this limitation might have made sense. Today it's just another outdated aspect of Unix. If I have a multi-thousand dollar computer with Gigs of RAM and a 100GB hard drive, I never *ever* want the system to tell me I can't create a folder because there would be too many characters in the path. Ever. It's long past time for the Unix community to move into the present in this regard (and others IMO), at least on the Mac.


So, lots of poor application design, but there's no really good reason not to use or support names that insanely long.

In any case, it's far longer than anyone will ever have to use,

I don't think you can guarantee that. One thing I've learned in the more than 10 years I've been doing a file utility is that Mac users can be doing virtually anything you can imagine. Long names, Unicode characters, deeply nested folders, hundreds of thousands of files such as images, and so on. It's virtually impossible to predict what users will want to do, and it's usually a mistake to assume they won't need or want to do this or that thing.


I organize my Applications folder into subfolders. I remember the first time I played with iDVD and tried to run its tutorial. Because I'd moved iDVD into Applications/Media, iDVD couldn't find its tutorial which was in its own bundle.

Another example of absolute vs. relative, and poor app design. An Application bundle is designed specifically to let programs depend on relative paths.

The two apis I mentioned both give absolute paths though since the notion of the current working directory is fuzzier and I know of no guarantee that it won't change due to Carbon or Cocoa calls, especially anything working with the file system. I find that it's nearly always best to just do that stuff using the system calls directly.

And you can't use working directory tricks when storing persistent references on disk.


I've also seen Software Updater crash because an application wasn't in the Applications folder. I think they've fixed it now, but I remember when I used to drag certain applications out of their subfolders back up into Applications before running Software Updater just so it wouldn't crash.

This is actually pretty fair. How would you propose that Software Updater find the applications it's trying to update? Maybe it could have links to them somewhere... like some, I don't know, PATH inside its configuration directory?

Actually, you can ask for the location of an application. I'm not entirely sure how it works and it might require that the app be launched from the new location first. Most of the code I write is portable so I've never depended on that.

You can use Launch Services to locate an application by its bundle ID or search for it using FSCatalogSearch, or less robustly, you could iterate over the contents of the Applications folder, but in practice using Launch Services with the application's bundle ID is what I'd use now. In the past, before bundle IDs, the usual practice was to search the disk.


They're an improvement the Unix and Cocoa folks dumped upon us because they rely on paths.

Allow me to quote an old Usenet signature:

"Those who do not understand Unix are condemned to reinvent it, poorly."

Feel free to quote this as well: "Those who do not understand the Mac OS are condemned to reinvent it, poorly."


You're very much a Unix guy. Allow me to point out that no one stuck the Mac OS on top of your previous flavor of Unix and forced you to deal with it. If you love Unix you can still use it without the Mac OS. In fact, if you just woke up from a coma after 15 years you could probably use it exactly the same as you did before. ;-)

OTOH, Apple built Mac OS X on top of Unix, so there's no way to avoid Unix completely if you use a halfway recent version of the Mac OS. And let's be perfectly clear on the fact that the bulk of the people buying Macs are not Unix gurus, they're ordinary folk who can't even spell eunuchs and think terminal is a disease you don't want. Those are the people most of us want to keep happy because they buy the vast majority of the software sold and the hardware as well. From that standpoint it doesn't matter what Unix users like or even programmers, because we aren't a very big share of the market. That's why -- sadly -- there's no money to be made in Mac developer tools. ;-)

I'm happy we're not using UNIX as originally described in "The UNIX Time-Sharing System" [1] but after being exposed to UNIX with OS X, I've found that the ideas that came from UNIX have improved my productivity immensely.

It's not my intention to say that Unix brought nothing of value to the Mac OS, only to point out that some aspects of it can negatively impact the user experience for mainstream Mac users and, more importantly, that thinking like a Unix programmer is probably not going to lead to the best result when designing Mac software.


Larry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year) (From: "Chris Espinosa" <email@hidden>)
 >Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year) (From: Laurence Harris <email@hidden>)
 >Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year) (From: Steve Checkoway <email@hidden>)
 >Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year) (From: Laurence Harris <email@hidden>)
 >Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year) (From: David Masover <email@hidden>)
 >Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year) (From: Steve Checkoway <email@hidden>)
 >Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year) (From: Laurence Harris <email@hidden>)

  • Prev by Date: Re: [ANN] Xcode + Leopard at WWDC this year
  • Next by Date: Intel and gcc compilers in same Xcode project?
  • Previous by thread: Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year)
  • Next by thread: Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year)
  • Index(es):
    • Date
    • Thread