RE: FW: NSFileManager
RE: FW: NSFileManager
- Subject: RE: FW: NSFileManager
- From: "Tommy Braas" <email@hidden>
- Date: Sun, 24 Jun 2001 13:10:36 -0700
Fritz,
Thank you for your help!
Although it might not be a programmatic but it is definitely a documentation bug. I think it should clearly state under which circumstances [ NSFileManager currentDirectoryPath ] returns what.
Am I the only one that thinks that?
Regards and thanks,
\tommy
>
-----Original Message-----
>
From: Fritz Anderson [mailto:email@hidden]
>
Sent: Sunday, 24 June, 2001 12:51 PM
>
To: Tommy Braas
>
Cc: Cocoa-Dev
>
Subject: RE: FW: NSFileManager
>
>
>
At 11:17 AM -0700 6/24/2001, Tommy Braas wrote:
>
On the Finder's startup environment having a working directory of "/":
>
>
> I beg to differ ( maybe ) on what is passed in from the Finder. I
>
>think this is a bug and I will report it as such.
>
>
I hope they don't accept it as a bug.
>
>
Working directories are a convenience to programmers, and are the
>
only way for a user to stay sane in the face of a command line, where
>
the context is mostly invisible, and therefore must be strictly
>
treated as a single-valued mode.
>
>
It's not clear to me what the "current working directory" in the
>
Finder is. You can answer this easily if the Finder is launching the
>
application from its home directory in an icon-only view. The answer
>
becomes less easy if the view contains more than one directory (as in
>
column or expanded-list views); or if there is more than one Finder
>
window open; or if you launch the application in the network-mounted
>
directory A by double-clicking in a document in directory B, and then
>
return to the Finder, days later, to double-click a document in
>
directory C.
>
>
You could devise a set of rules to explain to the user what a working
>
directory is, and why your program won't work if he doesn't set the
>
working directory properly, and why he won't be able to use your
>
program to control his work until he thoroughly trains himself in the
>
concept of working directories and how your program uses them. But
>
that strikes me as a crappy way to treat a customer, especially when
>
the OS provides you with tools like [NSBundle mainBundle]
>
resourcePath] to do what you want to do, more reliably and with less
>
hassle.
>
>
-- F