The shell hardly views the files unless you're using Terminal.app or an editor like emacs or a BBEdit worksheet. The metadata is better considered a feature of the file system. Finder is NOT a shell but we might well be better off if it were. Anyone know why not? Why isn't Terminal.app part of Finder? Why can't Finder set environment variables for everything - including applications - that it spawns
Interesting. Now I think about it, I was using 'shell' to describe "Finder" because my boyfriend (a Windows programmer) uses 'it's a shell' to describe what Windows Explorer is, and I'd picked up the habit and just assumed Finder was the Mac equivalent. It's not a command line shell like Dos/Command Prompt/tcsh/bash, but I suspect my mental model of a shell is 'thing that lets the user manipulate the operating system, closely-tied-in to the way the operating system is designed', so it seemed evident to me that Finder was that on the Mac the same way Explorer is on XP. Is there a tighter definition? Was my boyfriend wrong--does 'shell' only describe things like bash etc? Or is Explorer a shell and Finder not-a-shell, in which case I *really* don't understand what the difference is... (puzzled shake of head)
but if it's part of the file's content it should be _in_ the file. .... if it's Finder stuff to do with displaying files I don't need it at all for the small flash drive.
There are things, not associated with display, that should NOT be in the file. The choice of application that should be used depends on the user and may be different on different machines. It is NOT good enough to say that all files with an extension to the name like .txt must go to the same application when "opened." Text files should be text. Perhaps UTF08 or UTF16 but not formatted files with special characters - gremlins - that keep the file from working when sent to a compiler, a scientific instrument, or a text messaging system. The preferred monitor on which a file should be displayed is included in Microsoft Excel (.xls) files. It creates a telephone call every time I forget to move all windows to the center and re-save before sending them to someone else.
Eeek! This is definitely a good and interesting definition of _why_ keeping some things connected with a file outside the file is a good idea. I'd been thinking that this external-yet-connected thing sounds evidently broken, because it adds a layer of stuff to become confused and get lost, but that's a really clear definition of what benefits there are in keeping stuff outside a file because it's essentially non-portable.
When I change the desired application to open a single file OS neXt should NOT create or enlarge an associated resource fork to contain some 50 kB of copies of the selected application's icons. That stuff belongs in the desktop database which disappeared with OS neXt.
When you say OS neXt, do you mean OS X considered as those things that started in NeXtStep?
So I'm slightly confused.
So am I. Part of the problem is that UNIX never has supported the concept of an application "owning" a file. It can hardly understand the concept of an application and that results in crazy things like logging in to Aqua desktop without ever logging into the UNIX of old with a shell. There was a time when "dot" files .profile or .cshrc file could be depended upon. No longer. We have $HOME/.Mac_OSX/environment.plist - another "Dot" file/directory - which no one is supposed to know about but do_shell_script needs if you want to personalize your environment
That's interesting. I've sometimes looked at Unix/Linux books and wondered how much of the stuff carries through to Darwin--not necessarily that much.