RE: NSFileManager
RE: NSFileManager
- Subject: RE: NSFileManager
- From: Fritz Anderson <email@hidden>
- Date: Fri, 29 Jun 2001 13:15:10 -0500
At 4:28 AM -0700 6/29/2001, jgo wrote:
> Fritz Anderson <email@hidden> Sun, 2001-06-24 14:51:06 -0500
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.
For context: The discussion was about -[NSFileManager
currentDirectoryPath], and why an application launched from the
Finder will find the return value, upon application start, always to
be @"/", regardless of the location of the application or any
document.
You offer good, plausible predictions of how an application that
wants to preserve the working-directory idea would behave under
particular scenarios.
But everything a computer does is predictable (or at least
explainable after the fact). Predictions and explanations can be
produced for good HI designs and bad ones alike. The mere existence
of an explanation for an HI behavior therefore does nothing to assure
us that the design is good.
I offered my scenarios as a challenge. Predictions answer the
challenge halfway. The other half is to explain how the predicted
behavior benefits a user who is trying to do his work without paying
attention to (for instance) modeling how a Finder gesture might be
decomposed into tcsh command lines, and how tcsh would set up the
application's environment in response to a particular sequence of
command lines.
For instance, I offered: Launch an application in directory A by
double-clicking on a document in directory B. Later (presumably
after you've long forgotten how the application, which is still
running, was launched), double-click a document in directory C,
causing the application to open it.
> or if you launch the application in the network-mounted
directory A by double-clicking in a document in directory B
At that time, the PWD is B; it has to reach out to the
application's directory to launch it, just as you can
run a shell script by typing, e.g. ../fredscript
or ./george/henry/ianscript without changing your PWD.
and then return to the Finder, days later, to double-click a
document in directory C.
At that time, the PWD is C.
Now, I'm thinking about "the working directory" in the sense of the
application's shell environment, as reflected by -[NSFileManager
currentDirectoryPath]. Assuming I'm on the same page as you, you
suggest that the Finder in my scenario should change the
application's working directory. Fine.
First, how does the application deal with that? The working
directory is a convenience, shifting information out to the
environment so the programmer doesn't have to present it to the file
system every time. Presumably, while the Finder changed the result
of -[NSFileManager currentDirectoryPath], the application itself had
important state that depended on the working directory pointing to
the directory the programmer last set it to (or last found it at).
Most people who rely on working directories rely on their not raising
concurrency issues.
How is the application to respond to this change? How will this
change be of benefit to the user? Why would this be better (for the
programmer, but especially for the user) than the current situation,
in which the working directory of a program that runs concurrently
(and in frequent communication) with a shell that has no use for the
concept, is initially @"/", and is always under program control
thereafter?
Finally, explain the resulting behavior to your grandmother. (It is
a bad habit in these discussions to assume one's grandmother is a
ditz who can happily go to her grave not using computers at all.
Assume instead that your grandmother is a neurosurgeon, and that
wasting her attention either on explanations or on error-avoidance
rituals has a cost in lives and dementia.)
-- F
--
Fritz Anderson <email@hidden>
Parallel Software, Inc <
http://www.parallel.com/>
Naperville, Illinois