Re: [MIT-Scheme-devel] working directory

[Taylor R Campbell]

   Date: Sun, 13 Feb 2011 10:33:48 -0700
   From: address@hidden (Matt Birkholz)

   I rely on the default pathname defaults to do everything, i.e. produce
   absolute pathnames (URIs?).  Thus I do not have to think about the OS
   process's working directory.  I do not often think of the OS process
   at all.  I like that.  I like not dropping into C to frob things I
   don't use.

I don't propose to change the default pathname defaults.  All I
propose to change is the working directory pathname.

   How did you notice a klunkiness?  How do I produce a klunk?  I tried

       (with-working-directory-pathname "~/Scheme/MIT/src/"
         (lambda () (run-shell-command "cat makefiles_created")))

   and it works correctly regardless of the OS process's mumblefrotz.

At the end of this message are some ways to produce klunks.  Part of
the reason for the klunkiness is that WITH-WORKING-DIRECTORY-PATHNAME
doesn't really match SET-WORKING-DIRECTORY-PATHNAME!: only the latter
ever actually chdirs.  It doesn't always chdir, though.  But both
maintain *WORKING-DIRECTORY-PATHNAME*, and mirror it in the default
pathname defaults so that OPEN-INPUT-FILE &c. respect the setting.

   Are there procedures like run-shell-command that do not already
   "fchdir, if necessary"?

There are only two primitives in the microcode that use chdir:
SET-WORKING-DIRECTORY-PATHNAME! and UX-MAKE-SUBPROCESS.  Nothing uses
fchdir -- not even UX-MAKE-SUBPROCESS, as a consequence of which
Scheme can't report a sensible error message if you try to run a
subprocess in a bogus working directory.

   If I spawn a hundred threads, do they open a hundred file descriptors?

Only if you change the working directory in all of them.

   If I pass "/absolute/filename" to a primitive that theoretically
   depends on the cwd (as I am wont to do), will it now have to frob some
   OS randomness before doing as I ask?

It could avoid that.  I wasn't planning to make it avoid that.  There
would be an observable difference on operating systems such as Linux,
if you look at /proc/N/cwd.  I don't think this matters much, though.
The difference would arise anyway if we used openat &c. where
available, and fchdir/open &c. otherwise, which I think is the right
thing to do.

;;; Instructions for producing klunks.  (Here ~/scheme/mit/git/work is
;;; like your ~/Scheme/MIT.)

;;; First, observe that a file exists:

(fluid-let ((*default-pathname-defaults*
             (->pathname "~/scheme/mit/git/work/src")))
  (call-with-input-file "makefiles_created" read-line))
;Value: "i386"

;;; 1. Get threads involved.

(let ((x #f) (t (current-thread)))
  (with-working-directory-pathname "~/scheme/mit/git/work/src/"
    (lambda ()
      (fluid-let ((*default-pathname-defaults*
                   (make-pathname #f #f #f #f #f #f)))
        (create-thread #f
          (lambda ()
            (set-working-directory-pathname! "/tmp/")
            (set! x #t)
            (signal-thread-event t #t)))
        (do () (x) (suspend-current-thread))
        (call-with-input-file "makefiles_created" read-line)))))
;Unable to open file "makefiles_created" because: No such file or directory.

;;; 2. Assume WITH-WORKING-DIRECTORY-PATHNAME preserves the outer and
;;; inner working directories with SET-WORKING-DIRECTORY-PATHNAME!
;;; just like FLUID-LET preserves the outer and inner values of
;;; variables with SET!.

(with-working-directory-pathname "~/scheme/mit/git/work/src/"
  (lambda ()
    (fluid-let ((*default-pathname-defaults*
                 (make-pathname #f #f #f #f #f #f)))
      (with-working-directory-pathname "../"
        (lambda ()
          (set-working-directory-pathname! "/tmp/")))
      (call-with-input-file "makefiles_created" read-line))))
;Unable to open file "makefiles_created" because: No such file or directory.