[goMac]

Originally posted by mAxximo:
W-w-w-what??
We must be living in different worlds then.

Dunno about you, but most my games run faster in X since 10.3. Boot up is also faster.

10.4 resolves the interface drawing speeds, and application launch times in 10.4 are way up.

I really don't get people who complain the OS X is slow on : blank : . Every G4 I've used OS X on is snappy. I have a G4/450 at work running as a rebuild server and quite frankly, its very snappy. The only time OS X has been slow is when its run on early G3 macs. If you're going to complain about the speed of OS X on an older machine thats just stupid. I don't complain that my Pentium 3/450 runs Windows XP slow. Yes, it could run Windows 98 completely snappy. But XP runs slow on it, and Linux is a little less than amazing.

Yes, old operating systems run faster. But they're still OLD OPERATING SYSTEMS. There is no magic that lets a new operating system with new capabilities run as fast as old ones. I'm sure System 1.0 would run blazing fast on my Powerbook. Does that mean everyone should go back to System 1.0?

And as far as I'm concerned, OS 9 was insanely slow because it couldn't multitask. It's far better for me to actually be able to check my email and internet at the same time under OS X. Mac OS 9 could never do more than one thing at once, making it very slow to work with. Not to mention, because of this, the interface was very laggy under OS 9.

[goMac]

Originally posted by mAxximo:
I agree.
To me is either it works for real this time or I go PC for good. Those Alienware boxes look better every day...





(Please refrain from the usual fanboi remarks)

Thats great. You can go tell all the Windows users they are doomed when Longhorn comes then.

Seriously, what is it you are looking for? Mac OS X isn't Mac OS 9. GET OVER IT. It's a brand spanking new system, thats only 4 years old. Guess what. Operating systems change. Windows NT already replaced Windows on the PC side. Apple is doing the same thing. If it wasn't for Microsoft changing there kernel, Windows XP on that Alienware wouldn't exist. When Microsoft decides to uproot whole OS's, take 7 years to work out the kinks, and kill backwards compatibility pretty well, its fine for them, but when Apple decides to modernize their OS, its a huge problem. Instead of looking at OS X and trying to do things the same way you did in OS 9, actually learn OS X. Mac OS as we used to know it is dead. Move on. Guess what? Even if you do move to Windows you're going to have to relearn everything.

Mac OS 9 was a huge crashy mess. By the end, I was about ready to by a PC and move to Win2k. It was that bad.

All the stuff you are complaining about is just crazy. What is so bad about extensions? Why are they such a backwards idea? The user can't even see them under OS X. And at least it makes OS X compatible with every other OS on earth. It's one thing to be different because its better. Not supporting extensions is just being different for the sake of being different. Thats stupidity.

I have had no problem with OS X just working for 4 years now.

[Richard Edgar]

I'm saying that letting the user decide what app to open a file with is better than arbitrarily deciding to open the file with the app that created it

You really like ignoring what I've been saying, don't you? As I've pointed out several times, the user could decide. Very easily - drag and drop. Now, Apple didn't shove that onto a contextual menu in OS9, but that doesn't mean they couldn't have done so.

Ooh, so you don't need ResEdit! You can use another app that does the same damn thing as ResEdit! Wow, that makes it all different now!

Do I detect a slight willful overlooking of the fact that ResEdit was a slightly dangerous application to use? I accept of course that that fact was the reason your selected it for your initial example.

1. Get Info on a file, go to Open With, choose application.

2. Alternatively, you can right-click on the file, hold down the Option key, and get an "Always Open With" menu.

Now tell me.... how does it remember that change.... in the file name extension?

Uh, if someone is savvy enough to know how to write a shell script, I should hope that person would be intelligent enough to grasp the concept of putting quote marks around file paths. There's nothing so hard about that...

You mean like Apple did in the iTunes installer? If you think writing shell scripts is easy, you don't know anything about them. In any case, there's no reason that type/creator should be incompatible with a CLI.... if the CLI supports it.

[analogika]

Originally posted by Richard Edgar:
Do I detect a slight willful overlooking of the fact that ResEdit was a slightly dangerous application to use? I accept of course that that fact was the reason your selected it for your initial example.

Do I detect a slight willful overlooking of the fact that, ResEdit or otherwise, requiring a user to install and use a separate application simply to make a file open via double-click is NOT good UI?

It's like mAxx continually spouting about how horrifyingly bad the user interface in OS X is and then pouting about how much more flexible OS 9 was - PROVIDED you had years of expertdom behind you and a whole bunch of third-party tools readily at your disposal.

Only to then completely ignore points about how the WHOLE POINT OF MACINTOSH was explicitly to empower users who DON'T have years of expert experience and a whole bunch of third-party tools, be they ResEdit or whatever else, readily at their disposal.

People so stuck in their idiosyncratic workflows built around the bloat, clutter, and shortcomings of OS 9 that they've completely missed that OS X is far truer to the original Macintosh ethic than any Classic Mac OS has been since around System 7.5.

-s*

[CharlesS]

Originally posted by Richard Edgar:
You really like ignoring what I've been saying, don't you? As I've pointed out several times, the user could decide. Very easily - drag and drop. Now, Apple didn't shove that onto a contextual menu in OS9, but that doesn't mean they couldn't have done so.

1. Dragging and dropping onto an app is not the same thing as being able to set the file to launch with whatever app you want when you double-click it (yes, you can actually do that with Open With in the Get Info window in OS X! Have you never tried this or something?).

2. It was [i]not[i] very easy to drag and drop onto apps in OS 9, because there was no Dock. You had to drill down the file hierarchy to get to the app.

3. If the type/creator were wrong, most of the time you wouldn't be able to drag-and-drop onto the app anyway, because there was no command-option to force it in OS 9.

4. Again, this is not the same thing I'm talking about! The only equivalent to Open With in the Get Info window (or Always Open With in the context menu) is changing the creator code manually. Which, as I've already stated numerous times, is a pain in the ass in OS 9.

Do I detect a slight willful overlooking of the fact that ResEdit was a slightly dangerous application to use? I accept of course that that fact was the reason your selected it for your initial example.

No, the reasons I selected it were:

1. It was the standard way to change a file's type/creator codes

2. It was hard to use, nonintuitive, and a pain in the ass

Any other app for changing the type/creator codes is not going to change the fact that doing so is nonintuitive and a pain in the ass.

Now tell me.... how does it remember that change.... in the file name extension?

It uses an internal method specific to OS X. It stores information about the app it should use in a 'usro' resource in the resource fork.

Do you not have a copy of OS X or something? Why can't you just try this yourself? You sound as if you don't believe me or something.

You mean like Apple did in the iTunes installer? If you think writing shell scripts is easy, you don't know anything about them. In any case, there's no reason that type/creator should be incompatible with a CLI.... if the CLI supports it.

This coming from someone who likes to accuse people of putting words in his mouth. It's not hard to put quotes around path names. That doesn't mean it's easy to write shell scripts. God.

The iTunes issue was a major f*ck-up, simple as that.

[CharlesS]

Originally posted by analogika:
Only to then completely ignore points about how the WHOLE POINT OF MACINTOSH was explicitly to empower users who DON'T have years of expert experience and a whole bunch of third-party tools, be they ResEdit or whatever else, readily at their disposal.

People so stuck in their idiosyncratic workflows built around the bloat, clutter, and shortcomings of OS 9 that they've completely missed that OS X is far truer to the original Macintosh ethic than any Classic Mac OS has been since around System 7.5.

-s*

Exactly! I was a little apprehensive of OS X's interface when it came out, too, until I had used it for a while, and I started to get that feeling of My God, I'm home again!

[leperkuhn]

Originally posted by Richard Edgar:
You really like ignoring what I've been saying, don't you? As I've pointed out several times, the user could decide. Very easily - drag and drop. Now, Apple didn't shove that onto a contextual menu in OS9, but that doesn't mean they couldn't have done so.
Do I detect a slight willful overlooking of the fact that ResEdit was a slightly dangerous application to use? I accept of course that that fact was the reason your selected it for your initial example.
Now tell me.... how does it remember that change.... in the file name extension?
You mean like Apple did in the iTunes installer? If you think writing shell scripts is easy, you don't know anything about them. In any case, there's no reason that type/creator should be incompatible with a CLI.... if the CLI supports it.

I don't really see what your problem is. If you do a Get Info, then down to "open with" you can change what opens that file. And there's an option to "change all with this extension". It can be set to different apps for different files.

[Richard Edgar]

It was not very easy to drag and drop onto apps in OS 9, because there was no Dock. You had to drill down the file hierarchy to get to the app

Or drag to an alias on the desktop.

It was the standard way to change a file's type/creator codes

Not really. It was simply one of the ways of doing it.

because there was no command-option to force it in OS 9

And in OSX, any application can magically open any type of file can it? Or does that support have to be written into each application.... like it was for some in OS9?

It uses an internal method specific to OS X. It stores information about the app it should use in a 'usro' resource in the resource fork.

Which sounds rather suspiciously similar to a type/creator code! Or at least the 'creator' part of it. Not quite the same name, but equivalent functionality - and implemented in a very similar way. That is my point. I have said that the sytem needed thinking about - but filename extensions are a step backwards.

It's not hard to put quotes around path names

But putting quotes around the filename doesn't fix the problem, does it? You must (at the very least) know that. In a GUI, it is quite natural to give files names which are highly dangerous in a CLI (or, at least, in the UNIX one). Which rather goes against your claim of direct interoperability.

Do I detect a slight willful overlooking of the fact that, ResEdit or otherwise, requiring a user to install and use a separate application simply to make a file open via double-click is NOT good UI?

Do I detect a very deliberate ignoring of the fact that I've stated that I wished to see the type/creator system improved, and not the return to filename extensions?

[CharlesS]

Originally posted by Richard Edgar:
Or drag to an alias on the desktop.

Which usually gets covered up by some window.

edit: and also won't automatically update to always reflect what apps you have open.

Not really. It was simply one of the ways of doing it.

Then what do you say the standard way to do it was? The only other way I can think of would be to use third-party software.

And in OSX, any application can magically open any type of file can it? Or does that support have to be written into each application.... like it was for some in OS9?

Of course not every app can open every kind of file, but you can at least make it try.

I've used this successfully to deal with a few stupid apps which didn't support filename extensions properly and had to deal with files whose type codes had been lost due to being sent over e-mail. Bottom line is you have a hell of a better chance of getting the file open than you did in OS 9.

Which sounds rather suspiciously similar to a type/creator code! Or at least the 'creator' part of it. Not quite the same name, but equivalent functionality - and implemented in a very similar way. That is my point.

That's my point, too! We have all the good bits of the type/creator system right now in OS X. The only part we're missing is the "not working right with files that came from other platforms, were sent over e-mail, were put on a non-Mac disk, or were put in a .zip or .tgz archive" part.

But putting quotes around the filename doesn't fix the problem, does it? You must (at the very least) know that. In a GUI, it is quite natural to give files names which are highly dangerous in a CLI (or, at least, in the UNIX one). Which rather goes against your claim of direct interoperability.

Um, putting quotes around the path kind of does solve the problem of a space being in the path. That is, in fact, kind of how Apple fixed the iTunes bug.

And, I'm not sure why running shell scripts is a big requirement for interoperability here. You could complain about the Mac not being able to run Windows binaries too, but I don't really see the point. An OS could not have any idea what a shell script is, and it would still be able to communicate with other OSs, transfer files back and forth, and such, as long as it followed the standard formats, such as Unicode and/or ASCII, SMTP/POP/IMAP, and filename extensions. People using CLI and GUI-based systems can work together, and it in fact happens every day.

Do I detect a very deliberate ignoring of the fact that I've stated that I wished to see the type/creator system improved, and not the return to filename extensions?

[Chuckit]

Originally posted by Richard Edgar:
But putting quotes around the filename doesn't fix the problem, does it? You must (at the very least) know that. In a GUI, it is quite natural to give files names which are highly dangerous in a CLI (or, at least, in the UNIX one). Which rather goes against your claim of direct interoperability.

This is news to me. What characters (other than quotation marks themselves) commonly occur in GUI-given file names that are "highly dangerous" to use within quotes in Bash? Shell globbing characters are taken literally inside quotes, and slashes look like colons from the shell.

Originally posted by Richard Edgar:
Do I detect a very deliberate ignoring of the fact that I've stated that I wished to see the type/creator system improved, and not the return to filename extensions?

Calling it a "return to filename extensions" seems a little deceptive to me. Type codes did not disappear into the ether when Apple introduced support for extensions. Extensions are simply one more way of identifying file type information, and one that would greatly break interoperability if not supported. No features have been removed, so I don't think we're moving backwards.

[Richard Edgar]

Then what do you say the standard way to do it was? The only other way I can think of would be to use third-party software

Correct - it was (and since ResEdit didn't come as a standard install item - since it was a dangerous piece of software due to its other, indeed primary, capabilities - it effective counts as that too). The system certainly needed improvement.... perhaps by revamping what the codes were (32-bit integers making less sense these days), and adding the option to reassign to the Get Info box. Still no need for the filename extensions, except at the borders - which addresses your interoperability point.

Um, putting quotes around the path kind of does solve the problem of a space being in the pat

No it doesn't. What happens if the path also contains quotation marks (perfectly legal in the filename, and not unnatural to a GUI user)? Anything other than alphanumeric characters in filenames are a real pain for UNIX CLIs, yet a GUI users wouldn't think twice about them, if appropriate.

What characters (other than quotation marks themselves) commonly occur in GUI-given file names that are "highly dangerous" to use within quotes in Bash? Shell globbing characters are taken literally inside quotes, and slashes look like colons from the shell

Firstly: "commonly occur" is utterly irrelevant. May occur is what matters. And once a quote has appeared, things like *, !, ? and $ can wreak havoc - either by accident or intent. CLIs (or at least the UNIX CLI) do not play well with non-alphanumeric characters.

[leperkuhn]

Richard Edgar:

do you really think that mac users, as a whole, would be better off throwing away compatibility with the rest of the world in favor of exclusively using creator codes, or are you just being stubborn.

Now that we've established you can open different files with different programs, one of your original points is void. So is this your argument:

"File extensions, despite giving us better compatibility with 96% of the computers in the world, suck. I don't think that the mac should have them, even though they can be hidden and viewing them is totally optional. I ignore the practical uses for extensions as well."

Is this your opinion?

[mAxximo]

Originally posted by leperkuhn:
do you really think that mac users, as a whole, would be better off throwing away compatibility with the rest of the world in favor of exclusively using creator codes

The fact is you don't have to throw away any compatibility by not adopting filename extensions. The Mac got rid of extensions more than 20 years ago and I have never had a compatibility issue with the PC world. OS X should have dealt with extensions with a global system preference to activate them if needed as a secondary option for file identification, never as the principal mandatory method. John Gruber nails it down in “The Good, the Bad, and the Avie”:

“Tevanian’s legacy is marred, however, by Mac OS X’s usability flaws, most of which are attributable to Tevanian’s nearly unyielding obsession with promoting old Next technology over old Apple technology. His technical acumen may be undisputed, but neither is his tin ear for usability.

[...]

Technote #2034, ostensibly a series of guidelines on how to write better Mac OS X software, in fact amounted to little more than dogma against Mac technologies. E.g.: Mandating filename extensions in lieu of genuine type and creator metadata for “compatibility”; recommending against using HFS metadata at all, because doing so causes performance issues for UFS disks (no matter that UFS is a vastly inferior disk format); promoting Objective-C as a more portable cross-platform language than C++; and, most laughably, recommending the use of hard-coded pathname APIs for accessing files, rather than more flexible, friendly, and traditional Mac APIs which access files by file ID.

[JLL]

Originally posted by mAxximo:
The fact is you don't have to throw away any compatibility by not adopting filename extensions. The Mac got rid of extensions more than 20 years ago and I have never had a compatibility issue with the PC world.

Yes, you've stated a couple of times that YOU haven't had any problems, but try and ask the common Mac OS 9 user if he/she knows that you have to add extensions to be able to communicate with the real world.

[lookmark]

This thread really is blast from the past.

Wasn't Technote #2034 promptly pulled and revised? As I recall the furor was as much over lack of civility (in a tech note, no less!) as content. The most outrageously partisan parts of that document (pro Ob-C, pro-hard-coded pathnames, etc) were all taken out.

I find OS X's "What You Type is What You Get" UI solution for filename extensions a pretty smart compromise to a incredibly thorny issue. If you've been in a Mac bubble for so long you've never encountered Mac-PC compatibility problems due to a lack of file extensions -- or worse, the widespread belief that these problems exist -- count yourself lucky, but not experienced. This was a *widespread* issue before OS X, and IMO contributed strongly to perceived differences between the Macs and PCs. Having the user have to edit type + creator data with a 3rd party app was and is completely unacceptable, and the sometimes-floated idea for OS X of some API that catches files as they're sent from a Mac to another computer that adds or removes an extension never felt quite right -- or realistic.

You have to pick your battles. I'm sorry to see file extensions be accepted as a standard -- it's a crude way to do it -- but compatibility with PCs is far more important to the Mac's long-term health than the ability to have some "pure" OS free of file extensions.

Bottom line: if you don't want to see them, hide them, and enjoy the much enhanced, user-friendly abilities to control what type of data is opened by which app.

[leperkuhn]

Originally posted by mAxximo:
The fact is you don't have to throw away any compatibility by not adopting filename extensions. The Mac got rid of extensions more than 20 years ago and I have never had a compatibility issue with the PC world.

OK great. However, going back to my original "is this your opinion" statement, I say "better compatibility". I did not say "you cannot give a PC user a file". why would i state it this way?

Suppose you are a windows user. If you get an e-mail from a friend, and double click the file, you expect it to open. You do not expect a weird error, then have to drag, rename, etc.

also, they have to know what file type it is.. and are you going to put "oh yeah, it's a photoshop file"? rename it in every e-mail you sent with an attachment?

[goMac]

Originally posted by mAxximo:
The fact is you don't have to throw away any compatibility by not adopting filename extensions. The Mac got rid of extensions more than 20 years ago and I have never had a compatibility issue with the PC world. OS X should have dealt with extensions with a global system preference to activate them if needed as a secondary option for file identification, never as the principal mandatory method. John Gruber nails it down in “The Good, the Bad, and the Avie”:

“Tevanian’s legacy is marred, however, by Mac OS X’s usability flaws, most of which are attributable to Tevanian’s nearly unyielding obsession with promoting old Next technology over old Apple technology. His technical acumen may be undisputed, but neither is his tin ear for usability.

[...]

Technote #2034, ostensibly a series of guidelines on how to write better Mac OS X software, in fact amounted to little more than dogma against Mac technologies. E.g.: Mandating filename extensions in lieu of genuine type and creator metadata for “compatibility”; recommending against using HFS metadata at all, because doing so causes performance issues for UFS disks (no matter that UFS is a vastly inferior disk format); promoting Objective-C as a more portable cross-platform language than C++; and, most laughably, recommending the use of hard-coded pathname APIs for accessing files, rather than more flexible, friendly, and traditional Mac APIs which access files by file ID.

a) Not using HFS metadata is a darn good idea. It doesn't work on file systems using UFS, FAT, or NTFS iirc. UFS can be faster than HFS in some cases, and some OS X Servers use it. I know MS Office wouldn't work on a UFS OS X server I once worked with.
b) I'm not sure on this on, but Objective C is supported on all other platforms. It was added into GCC for all platforms a while ago. It's a bit odd they'd suggest its more cross platform than C++, but syntax wise its supported everywhere.
c) I'd like to see the hard coded paths thing. You might be confused. Accessing files by id is old and stupid. However, Cocoa and Core Foundation provide numerous ways of grabbing locations without the stupid file id thing.
d) Once again, HFS metadata is bad. There is really no difference between metadata and extensions on OS X. The user cannot see either, and doesn't have to bother with either. However, extensions are more compatible. A Mac OS 9 type code is essentially the extension wrapped in the resource fork. Both systems use extensions, however they put them different places. In the end it doesn't matter because the user cannot see the extension in either case. Not to mention HFS metadata gets nuked as soon as the file is moved off a Mac.

[goMac]

Originally posted by Richard Edgar:
That is my point. I have said that the sytem needed thinking about - but filename extensions are a step backwards.

Filename extensions and file type codes are the same thing, just stored in two different places. The user cannot see either, and filename extensions are more compatible.

Filename extensions have existed long before the Macintosh. They were first used on UNIX because UNIX has no built in system to distinguish file types, so people started putting ends on the file names. Mac OS X handles this system very cleanly by not bothering the user with file names, making it just as effective as file type codes. Not to mention, file type codes were limited to 4 letters and not compatible with every other OS on the planet.

[CharlesS]

Originally posted by Richard Edgar:
Correct - it was (and since ResEdit didn't come as a standard install item - since it was a dangerous piece of software due to its other, indeed primary, capabilities - it effective counts as that too). The system certainly needed improvement.... perhaps by revamping what the codes were (32-bit integers making less sense these days), and adding the option to reassign to the Get Info box. Still no need for the filename extensions, except at the borders - which addresses your interoperability point.

As I said before, converting between type codes and extensions at the "borders" equals this:



There's just no way around this if you want to do things this way.

No it doesn't. What happens if the path also contains quotation marks (perfectly legal in the filename, and not unnatural to a GUI user)? Anything other than alphanumeric characters in filenames are a real pain for UNIX CLIs, yet a GUI users wouldn't think twice about them, if appropriate.

If you have a quote mark, you escape it. If you're dealing with anything else, just use quotes.

Code:
#!/bin/sh

ls -l "$1"

exit 0

Code:
136:~/Desktop baleeted$ ./test.sh 'lots of crap$@#%$&*('
total 0
drwxr-xr-x  2 baleeted  baleeted  68 14 Mar 15:19 Hey, it worked!
drwxr-xr-x  2 baleeted  baleeted  68 14 Mar 15:20 OMG
drwxr-xr-x  2 baleeted  baleeted  68 14 Mar 15:20 WTF

Code:
136:~/Desktop baleeted$ ./test.sh "some of my \"stuff\""
total 0
drwxr-xr-x  2 baleeted  baleeted  68 14 Mar 15:19 Hey, it worked!
drwxr-xr-x  2 baleeted  baleeted  68 14 Mar 15:20 OMG
drwxr-xr-x  2 baleeted  baleeted  68 14 Mar 15:20 WTF

And anyway, you kind of ignored my question:

And, I'm not sure why running shell scripts is a big requirement for interoperability here. You could complain about the Mac not being able to run Windows binaries too, but I don't really see the point. An OS could not have any idea what a shell script is, and it would still be able to communicate with other OSs, transfer files back and forth, and such, as long as it followed the standard formats, such as Unicode and/or ASCII, SMTP/POP/IMAP, and filename extensions. People using CLI and GUI-based systems can work together, and it in fact happens every day.

Even if you take as a given that a GUI absolutely, positively cannot run any kind of shell script (which is kind of proven incorrect by OS X anyway, since the installer does just that, but just for the sake of argument), how is that any more of a problem with interoperability than not being able to run x86 binaries? You can still send stuff to each other. You can still collaborate on projects. You still don't have to do nasty conversions just to get stuff from one machine to the other, and then get it to work.

Originally posted by goMac:
c) I'd like to see the hard coded paths thing. You might be confused. Accessing files by id is old and stupid. However, Cocoa and Core Foundation provide numerous ways of grabbing locations without the stupid file id thing.

This one I disagree with. The way files can be independent of their particular location in the file system is one of the great things about the Mac. That's why Cocoa's NSDocument class automatically takes care of keeping track of the file's location if it moves, given that the app was compiled under Mac OS X 10.2 or later.

[goMac]

Originally posted by CharlesS:
This one I disagree with. The way files can be independent of their particular location in the file system is one of the great things about the Mac. That's why Cocoa's NSDocument class automatically takes care of keeping track of the file's location if it moves, given that the app was compiled under Mac OS X 10.2 or later.

Sure, but I think Apple was saying "Don't touch it yourself". They're giving you plenty of abstraction through Core Foundation. Coding with HFS in mind could especially be a problem in 10.4, with the new file system plugin architecture. I haven't looked at it much, because its not much of an area I'm interested in, but I'm guess those file systems don't support files-by-id. By using Core Foundation and Cocoa classes like NSDocument you can make it abstract enough that you aren't reliant on file ids. Of course on your end you will be seeing paths and not file id's. However, these obviously aren't "hard coded" paths like maxximo said (not sure what that was about).

[CharlesS]

Originally posted by goMac:
Sure, but I think Apple was saying "Don't touch it yourself". They're giving you plenty of abstraction through Core Foundation. Coding with HFS in mind could especially be a problem in 10.4, with the new file system plugin architecture. I haven't looked at it much, because its not much of an area I'm interested in, but I'm guess those file systems don't support files-by-id. By using Core Foundation and Cocoa classes like NSDocument you can make it abstract enough that you aren't reliant on file ids. Of course on your end you will be seeing paths and not file id's. However, these obviously aren't "hard coded" paths like maxximo said (not sure what that was about).

Yeah, but internally I imagine that NSDocument will be using a file id on an HFS+ system.

And using the Carbon APIs and the Classic APIs, you're typically not referring to files directly by ID anyway. You're referring to the files through either an FSSpec (Classic) or an FSRef (Carbon). These are not the same as direct file IDs - FSRef and FSSpec are opaque formats that give you a level of abstraction. On HFS+ systems, they store a file ID (and maybe a path to fall back on if the file ID fails; I'm not sure since it's an opaque format). On non-HFS+ file systems, I imagine that FSRef probably stores a path to the file. All I know is that using FSRef definitely works on MS-DOS formatted disks (I just tried it, just to make sure I wasn't remembering incorrectly).

[goMac]

Originally posted by CharlesS:
Yeah, but internally I imagine that NSDocument will be using a file id on an HFS+ system.

And using the Carbon APIs and the Classic APIs, you're typically not referring to files directly by ID anyway. You're referring to the files through either an FSSpec (Classic) or an FSRef (Carbon). These are not the same as direct file IDs - FSRef and FSSpec are opaque formats that give you a level of abstraction. On HFS+ systems, they store a file ID (and maybe a path to fall back on if the file ID fails; I'm not sure since it's an opaque format). On non-HFS+ file systems, I imagine that FSRef probably stores a path to the file. All I know is that using FSRef definitely works on MS-DOS formatted disks (I just tried it, just to make sure I wasn't remembering incorrectly).

Yeah, I think the way it went was that FSSpec stored the file id and FSRef stored the path. There is some way to bridge, but its not toll free. It's been a while since I've worked with either, so you probably know better than me.

[CharlesS]

Originally posted by goMac:
Yeah, I think the way it went was that FSSpec stored the file id and FSRef stored the path. There is some way to bridge, but its not toll free. It's been a while since I've worked with either, so you probably know better than me.

Hmm, you seem to be right about FSSpec. However, FSRef is opaque. This is what the documentation says for FSRef:

This data type’s purpose is similar to an FSSpec except that an FSRef is completely opaque. An FSRef contains whatever information is needed to find the given object; the internal structure of an FSRef is likely to vary based on the volume format, and may vary based on the particular object being identified.

So, the internal structure of FSRef is unknown to us mere mortals. However, it definitely uses a file ID somewhere, because I am easily able to move files referenced by an FSRef and have them continue to work. Also, FSRef is able to deal with things that choke FSSpec, like filenames longer than 32 characters and other OS X goodies.

With that said, FSSpec seems to work on MS-DOS disks too (just tried it to be sure!). I'm not sure exactly why, but presumably Apple did some kind of voodoo under the hood to avoid breaking old Classic apps (and bad Carbon ports).

[analogika]

Originally posted by Richard Edgar:
No it doesn't. What happens if the path also contains quotation marks (perfectly legal in the filename, and not unnatural to a GUI user)? Anything other than alphanumeric characters in filenames are a real pain for UNIX CLIs, yet a GUI users wouldn't think twice about them, if appropriate.

What exactly is such a "real pain" for CLI users about preceding special characters with a \?

Especially since the CLI includes autocomplete, meaning that unless you're creating a new file, in the vast majority of cases, you can just type the first few characters of the filename and hit TAB.

This is the second time in this thread you've created the impression that you have absolutely no idea what you speak of.

Do you even use OS X? Beyond briefly dabbling with it at an Apple Store, I mean.

-s*

[leperkuhn]

Originally posted by analogika:
What exactly is such a "real pain" for CLI users about preceding special characters with a \?

Especially since the CLI includes autocomplete, meaning that unless you're creating a new file, in the vast majority of cases, you can just type the first few characters of the filename and hit TAB.

This is the second time in this thread you've created the impression that you have absolutely no idea what you speak of.

Do you even use OS X? Beyond briefly dabbling with it at an Apple Store, I mean.

-s*

Him and maxximo are still rocking os 9.

[Richard Edgar]

As I said before, converting between type codes and extensions at the "borders" equals this

Tell me... how does OSX cope with file name extensions it hasn't seen before? Internet Config was certainly not particularly friendly to set up - it could have used substantial improvement. But once set up, it just sat there happily getting things right.

If you have a quote mark, you escape it. If you're dealing with anything else, just use quotes.

And how do you get the script to do that automatically, if you wish to use the results of it elsewhere? In your own example, ls failed to escape the characters in the filenames it produced. Anything attempting to use that as an input is going to break.

Even if you take as a given that a GUI absolutely, positively cannot run any kind of shell script (which is kind of proven incorrect by OS X anyway, since the installer does just that, but just for the sake of argument)

It can do it... it's just the results might not be quite what were intended.

What exactly is such a "real pain" for CLI users about preceding special characters with a \?

Done it much, have you? Even with autocomplete, it can become a pain (especially when the first different character is a 'special' one). And they break simple scripts completely - Apple was right with AppleScript.... although since that's not compatible with anything else in the world....

Do you even use OS X?

Day-to-day? No. It only runs on little machines.

You have to pick your battles. I'm sorry to see file extensions be accepted as a standard -- it's a crude way to do it -- but compatibility with PCs is far more important to the Mac's long-term health than the ability to have some "pure" OS free of file extensions

Essentially correct - I just wish people would stick to that, rather than arguing "superiority" when it is nothing of the sort. It is the triumph of the mediocre.

[Randman]

Originally posted by Richard Edgar:
Day-to-day? No. It only runs on little machines.

If you don't use OSX and aren't very familar with it, why in the hell are you posting about its weaknesses?

[JLL]

Originally posted by Richard Edgar:
But putting quotes around the filename doesn't fix the problem, does it? You must (at the very least) know that.

Wow! You have to know the environment you're working in? Shocking!!

I don't know why you're bashing (no pun intended) the shell, but perhaps you should stay away from it.

[goMac]

Originally posted by Richard Edgar:
Tell me... how does OSX cope with file name extensions it hasn't seen before? Internet Config was certainly not particularly friendly to set up - it could have used substantial improvement. But once set up, it just sat there happily getting things right.

Uhhhh... OS X automatically tracks which extensions go with which app, just like with creator codes. If it hasn't seen the extension before, it means you probably don't have an application which can read that file, and OS X will promptly tell you.

Set up OS X to know file extensions? Have you used OS X for like 2 minutes or something?

[analogika]

Originally posted by Richard Edgar:
Day-to-day? No. It only runs on little machines.

That explains why you're not making sense.

Thank you for invalidating your presence in this thread.

[analogika]

Originally posted by goMac:
Uhhhh... OS X automatically tracks which extensions go with which app, just like with creator codes. If it hasn't seen the extension before, it means you probably don't have an application which can read that file, and OS X will promptly tell you.

Set up OS X to know file extensions? Have you used OS X for like 2 minutes or something?

Exactly.

See the last three posts above yours.

[Richard Edgar]

If you don't use OSX and aren't very familar with it, why in the hell are you posting about its weaknesses?

Because I do use it from time to time, and it is a pity to see it repeating mistakes of the past.

If it hasn't seen the extension before, it means you probably don't have an application which can read that file, and OS X will promptly tell you

Just like could have happened with the creator codes, but unfortunately didn't. However, that prompting is not due to the extensions.

And I would add: if the extensions are significant, then hiding them is a very bad idea. There have been trojans on the Windows side of the fence based on that hiding.

I don't know why you're bashing (no pun intended) the shell, but perhaps you should stay away from it.

By choice, I would. Unfortunately, I have little choice, since it is 'good enough' (just about). However, this doesn't mean I stop thinking about ways that it could be better. As I have said before, "good enough" is a malaise affecting the entire computer industry.

[mAxximo]

Originally posted by analogika:
That explains why you're not making sense.

Thank you for invalidating your presence in this thread.

He's making perfect sense. As unbelievable as you think it is, one can openly criticise Apple/Jobs/OS X and still make a lot of sense.
File extensions are the triumph of mediocrity, well said. Had OS X came up with a well designed solution to avoid them, you'd be bashing Windows to no end because it's still using that lame method from 40 years ago. Right? Heh.

[lookmark]

Do you even use OS X?

Originally posted by Richard Edgar:
Day-to-day? No. It only runs on little machines.

Seriously, spend just a little time getting to know the OS -- then report back. There's something of a paradigm shift from OS 9, and it takes a while (for some, anyway) to get comfortable with it. If you use it on a daily basis *and* you don't like it, you've got a leg to stand on.

Originally posted by lookmark:
You have to pick your battles. I'm sorry to see file extensions be accepted as a standard -- it's a crude way to do it -- but compatibility with PCs is far more important to the Mac's long-term health than the ability to have some "pure" OS free of file extensions.

Originally posted by Richard Edgar:
Essentially correct - I just wish people would stick to that, rather than arguing "superiority" when it is nothing of the sort. It is the triumph of the mediocre.

I think you'll find most people here think the type + creator system, whatever its flaws, was an interesting (if quirky) system that served the Mac well for a long time. (John Siracusa's essays at Ars why metadata should not invade the filename are probably the best well-reasoned and passionate arguments against file extensions.)

2005 =/ 1984, though, and I'm confident Apple made the difficult but correct choice, and put the most flexible and user-friendly UI on filenames + extensions that I've seen. Because:

Originally posted by Richard Edgar:
I do use it from time to time, and it is a pity to see it repeating mistakes of the past.

The looming lesson from Apple's past is that it cannot exist in a vacuum.

[Richard Edgar]

If you use it on a daily basis *and* you don't like it, you've got a leg to stand on.

I do use filename extensions on a daily basis, and I don't like them - both in practice (they give me trouble which requires makefile magic to fix up on a per machine basis) and principle.

The looming lesson from Apple's past is that it cannot exist in a vacuum

But that doesn't make the triumph of the mediocre anything less of a malaise.

[lookmark]

Originally posted by Richard Edgar:
I do use filename extensions on a daily basis, and I don't like them - both in practice (they give me trouble which requires makefile magic to fix up on a per machine basis) and principle.

I mean use the OS on a daily basis.

What kind of trouble do files that use filename extensions give you? More details please.

Originally posted by Richard Edgar:
But that doesn't make the triumph of the mediocre anything less of a malaise.

I agree, the triumph of Windows is a malaise, but that's the world we live in. Apple is not in a leadership position in the consumer or business desktop, and can't lead by example in how files should be identified. Could it propose a new open standard for filename ID? Sure. Would anyone -- i.e. Microsoft, and countless *nix distro programmers -- pay attention, or care? I strongly, strongly doubt it.

Should this strike as you as defeatist, it's not. There are plenty of areas where Apple *can* lead by example -- and do. This is not one of them.

[Richard Edgar]

What kind of trouble do files that use filename extensions give you? More details please.

Compilers requiring different extensions before they compile things. Despite the fact that the contents of the files is identical. Combine that with maintaining the same codebase on multiple platforms, and you have a problem. A fixable problem, but one which shouldn't have needed fixing in the first place.

Or to put it another way: not quite broken enough to be worth fixing. Which means that more things get layered on the (slightly) broken original.... which makes it harder to fix. Wash, rinse, repeat.

I agree, the triumph of Windows is a malaise

It is one example of it.

Should this strike as you as defeatist, it's not

If not doing something better because other people aren't interested isn't defeatist, might I enquire what is?

[CharlesS]

This is a late post - I originally wrote it at 3:30 AM last night, but MacNN was apparently down for maintenance.

Originally posted by Richard Edgar:
Tell me... how does OSX cope with file name extensions it hasn't seen before? Internet Config was certainly not particularly friendly to set up - it could have used substantial improvement. But once set up, it just sat there happily getting things right.

With OS X, each app registers with the OS what extensions it's able to open. Just like each app registers what type codes it's able to open under OS 9. Simple as that. No setup necessary on the part of the user whatsoever.

And once set up, Internet Config did not just sit there happily getting things right. Every time a new file type showed up that you hadn't previously encountered, you had to tweak it. And every time some poorly written program decided to screw with the settings, you had to go figure out what the hell happened and fix it.

And how do you get the script to do that automatically, if you wish to use the results of it elsewhere? In your own example, ls failed to escape the characters in the filenames it produced. Anything attempting to use that as an input is going to break.

Um, okay. It's too late in the night for me to expend time on this one right now. But, one thing for you to think about for a while... did OS 9 have shell scripts at [all? If not, what exactly are you bitching about?

Day-to-day? No. It only runs on little machines.

This says volumes.

Essentially correct - I just wish people would stick to that, rather than arguing "superiority" when it is nothing of the sort. It is the triumph of the mediocre.

Try actually using OS X as your main system for a while and see if you still think this way. Better yet, try working in a position where you have to help lots of newbies, and have to explain why their file won't open because the type code got mangled, and notice how you don't have to do that as much with OS X.

[lookmark]

Originally posted by Richard Edgar:
Compilers requiring different extensions before they compile things. Despite the fact that the contents of the files is identical. Combine that with maintaining the same codebase on multiple platforms, and you have a problem. A fixable problem, but one which shouldn't have needed fixing in the first place.

Or to put it another way: not quite broken enough to be worth fixing. Which means that more things get layered on the (slightly) broken original.... which makes it harder to fix. Wash, rinse, repeat.

It is one example of it.

Er, I'm not understanding. Compilers requiring different extensions before they compile things? I'm not a programmer -- explain this as you would to a layperson.

Originally posted by Richard Edgar:
If not doing something better because other people aren't interested isn't defeatist, might I enquire what is?

Oh, I don't know, to continue an incompatible, platform-centric method for handling files instead of accepting a crude but pervasive common standard? It's absolutist (and way overblown, IMO) to see Apple signing on for file extensions as this huge defeat, some enormous victory of mediocrity. It's practical; it's a compromise for compatibility over some ideal but impossible system; and most importantly, most users will not even notice, as extensions are widely seen and accepted as normal, and can be easily hidden, on a system-wide or individual basis.

[CharlesS]

Originally posted by Richard Edgar:
Because I do use it from time to time, and it is a pity to see it repeating mistakes of the past.

As others have pointed out, not supporting filename extensions would be one of those mistakes just like the ones Apple made in the past.

Just like could have happened with the creator codes, but unfortunately didn't. However, that prompting is not due to the extensions.

What does this mean?

And I would add: if the extensions are significant, then hiding them is a very bad idea. There have been trojans on the Windows side of the fence based on that hiding.

This is true, and I have never been a fan of hiding extensions. At least with OS X all files' extensions are not hidden by default, and the setting to turn hiding on is stored in the HFS metadata which won't survive e-mail. Fortunately, Apple seems to have introduced some algorithm in Panther to disallow hiding the extension if some other fake extension is present. For example, try to rename Safari to Safari.jpg and it will all of a sudden display "Safari.jpg.app".

Something to note about the type/creator system, though - this kind of precaution is not going to help you at all, because in the type/creator system, you don't have to have any extension at all for a file to be executable. You could have a file called "evilvirus.jpg" that had an 'APPL' type code, and it could have an icon that looked like a JPEG file and you wouldn't notice that it was really an app and not a JPEG unless you bothered to go look at the type code for the file.

Originally posted by Richard Edgar:
Compilers requiring different extensions before they compile things. Despite the fact that the contents of the files is identical. Combine that with maintaining the same codebase on multiple platforms, and you have a problem. A fixable problem, but one which shouldn't have needed fixing in the first place.

So you think that C files and header files shouldn't have to have .c and .h extensions? How would you name them? Do you name the header file .c and the C file .h, just for the hell of it? Why? You need to have some sort of file extension anyway, because you're often going to end up with two files of the same name but with one of them being a header file. Sheesh, what a thing to complain about...

[CharlesS]

Originally posted by lookmark:
Er, I'm not understanding. Compilers requiring different extensions before they compile things? I'm not a programmer -- explain this as you would to a layperson.

You use an extension to determine what type of code file you have - .h for a header, .c for C, .cpp for C++, .m for Objective-C, or .mm for Objective C++. The compiler uses the extension to determine what language to use. Often, especially in an object-oriented language like Objective-C, you'll get two files with the same name. Say I have an Obj-C class called MyClass, I'd have two files for it:

MyClass.h
MyClass.m

MyClass.h would have descriptions of all the object's methods, and declarations of the object's instance variables. If I were writing some other class that wanted to be able to use MyClass and call its methods, I would include MyClass.h so the compiler would know about MyClass's existence and what methods MyClass has and could correct me if I made a typo in a method name, passed the wrong data type to it, etc. MyClass.m would have the actual Objective-C code which determined what all those methods actually do.

Apparently, Richard doesn't like this. He'd rather the compiler just guess the language from analyzing the contents of the files (hmm, that one looks like Objective-C. guess i'll call it that) regardless of the disaster that would occur if it made a mistake. It's really silly since you'd have to **** the filenames somehow anyway, since you can't have two files called "MyClass" in the same folder anyway.

[Chuckit]

Originally posted by Richard Edgar:
Just like could have happened with the creator codes, but unfortunately didn't. However, that prompting is not due to the extensions.

For the last time, Richard: OS X HAS TYPE AND CREATOR CODES AND DOES TREAT THEM THIS WAY.

Did you see it that time? Because you keep suggesting that Apple replaced the type/creator system with extensions, which is absolute nonsense. Look in the Info.plist file of any decent application and you'll see type and creator codes listed right alongside the known extensions.

Originally posted by Richard Edgar:
And I would add: if the extensions are significant, then hiding them is a very bad idea. There have been trojans on the Windows side of the fence based on that hiding.

This from the advocate of type codes?

[lookmark]

Originally posted by CharlesS:
You use an extension to determine what type of code file you have - .h for a header, .c for C, .cpp for C++, .m for Objective-C, or .mm for Objective C++. The compiler uses the extension to determine what language to use. Often, especially in an object-oriented language like Objective-C, you'll get two files with the same name....

Ah -- thanks for the clear explanation. That gels with what little I do know about programming; I still don't understand how file extensions are a problem for this. But obviously I'm not alone here.

[leperkuhn]

Originally posted by lookmark:

Oh, I don't know, to continue an incompatible, platform-centric method for handling files instead of accepting a crude but pervasive common standard? It's absolutist (and way overblown, IMO) to see Apple signing on for file extensions as this huge defeat, some enormous victory of mediocrity. It's practical; it's a compromise for compatibility over some ideal but impossible system; and most importantly, most users will not even notice, as extensions are widely seen and accepted as normal, and can be easily hidden, on a system-wide or individual basis.

*roaring applause*

well said.

[wadesworld]

Compilers requiring different extensions before they compile things. Despite the fact that the contents of the files is identical. Combine that with maintaining the same codebase on multiple platforms, and you have a problem. A fixable problem, but one which shouldn't have needed fixing in the first place.

Um, compilers neededing different filename extensions is not a problem that Apple created.

And having files named with a certain convention is a VERY useful thing for a programmer.

Please explain why you can't use the same filename on all platforms.

Wade

[Deimos]

I like extensions, I've always liked them. I hated the pre-OS X Mac way of dealing with files when it came to interoperability with other platforms.

One beauty of them is being able to distinguish what a file is, and what might open it. For example, I have 3 Safari icons in a folder, no extensions. What are they? How the hell do I know. I need to open them up, or get info on them to find out. Turns out that the 1st one was a .htm file, another was a jpeg, and the 3rd was a png.

Thank Christ for extensions.

[goMac]

Originally posted by Richard Edgar:
Compilers requiring different extensions before they compile things. Despite the fact that the contents of the files is identical. Combine that with maintaining the same codebase on multiple platforms, and you have a problem. A fixable problem, but one which shouldn't have needed fixing in the first place.

Ummmm... I've been programming for 10 years and I have no idea what you're talking about. Every single C compiler since the dawn of time has made use of extensions, EVEN THE C COMPILERS ON CLASSIC MAC OS.

And if you don't use extensions, how can MyClass headers and methods both exist in the same place? You couldn't have a MyClass.h and MyClass.c file both in the same place, you couldn't tell what language they were, and it would make maintaining code on multiple platforms hell, because again, all other platforms use extensions.

[CharlesS]

Originally posted by Richard Edgar:
And how do you get the script to do that automatically, if you wish to use the results of it elsewhere? In your own example, ls failed to escape the characters in the filenames it produced. Anything attempting to use that as an input is going to break.
It can do it... it's just the results might not be quite what were intended.

Code:
#!/bin/sh

cd ~/Desktop/stuff
IFS="
"
FOLDERS=`ls -1` #this is a numeral '1', not a letter 'l'

for FOLDER in ${FOLDERS[@]}
do
	echo "listing $FOLDER:"
	ls -l "$FOLDER"
done

Code:
baleeted$ find ~/Desktop/stuff -print 
/Users/baleeted/Desktop/stuff
/Users/baleeted/Desktop/stuff/.DS_Store
/Users/baleeted/Desktop/stuff/Charles's stuff
/Users/baleeted/Desktop/stuff/Charles's stuff/.DS_Store
/Users/baleeted/Desktop/stuff/Charles's stuff/hmm, should that be Charles' or Charles's?
/Users/baleeted/Desktop/stuff/some "stuff"
/Users/baleeted/Desktop/stuff/some "stuff"/.DS_Store
/Users/baleeted/Desktop/stuff/some "stuff"/empty folder!
/Users/baleeted/Desktop/stuff/some "stuff"/how exciting
/Users/baleeted/Desktop/stuff/weird-a$$ *&^!?
/Users/baleeted/Desktop/stuff/weird-a$$ *&^!?/OMG
/Users/baleeted/Desktop/stuff/weird-a$$ *&^!?/WTF

Code:
baleeted$ ./test.sh
listing Charles's stuff:
total 0
drwxr-xr-x  2 baleeted  baleeted  68 15 Mar 14:28 hmm, should that be Charles' or Charles's?
listing some "stuff":
total 0
drwxr-xr-x  2 baleeted  baleeted  68 15 Mar 14:29 empty folder!
drwxr-xr-x  2 baleeted  baleeted  68 15 Mar 14:29 how exciting
listing weird-a$$ *&^!?:
total 0
drwxr-xr-x  2 baleeted  baleeted  68 15 Mar 14:29 OMG
drwxr-xr-x  2 baleeted  baleeted  68 15 Mar 14:29 WTF

Thank you sir. How else may I destroy your argument today?

[analogika]

Originally posted by mAxximo:
He's making perfect sense. As unbelievable as you think it is, one can openly criticise Apple/Jobs/OS X and still make a lot of sense.

Unless of course one uses examples to validate one's points that are, quite simply, made up.

Mr. Edgar made a huge amount of noise about how OS X relies upon extensions exclusively to decide which applicaton to use to open a document.

Having even *casually* used the operating system he chooses to thus criticise makes it perfectly obvious that he is, bluntly put, talking out of his ass. This has been pointed out (re: Get Info --> Open with).


Mr. Edgar also, in the course of his arguments, made points about certain characters in filenames being a "real pain" in the command-line interface.

Having even minimal experience actually using the command-line interface makes it perfectly obvious that he has none whatsoever, and that his points are completely baseless and wholly inaccurate. (re: when writing shell scripts, putting filenames in quotes or escaping special characters is really the easiest aspect, especially since in 99% of cases, you actually need to do neither, since simply hitting TAB will complete the filename for you, replete with escaped special characters and what-have-you.)


I agree: One can openly criticize OS X/Jobs/Apple/whatever and make a lot of sense in doing so - witness the "Stupid Mac OS X Mistakes" thread for some of that.

But so obviously making up evidence to support one's arguments isn't sense, it's ignorance.

[analogika]

Originally posted by leperkuhn:
Him and maxximo are still rocking os 9.

No, mAxximo has actually been forced to use OS X regularly for work, AFAIK.

He's got a helluva lot quieter since then. His broken record is now a mere single, with the occasional B-Side.