Re: current directory

[Sam Peterson]

>>>>> "help-gnu-emacs" == help-gnu-emacs  <help-gnu-emacs@vsbe.com> writes:

    > This is about unix-like environment.

    > Say I start emacs with a file in a certain directory, say
    > /a/b/c:

    > cd ~ emacs /a/b/c/file

    > then, while in emacs, I open another file, say /g/d/f/file1.

    > It looks like after this emacs moves its "current directory" to
    > /g/d/f. Now, if I start a shell script through call-process, the
    > shell script's current directory is also /g/d/f, but it depends
    > on being run somewhere in /a/b/c tree.  In fact, it looks like
    > emacs changes its internal 'current directory' each time I
    > switch to a file in a different directory, even a previously
    > opened file.

    > Is there a way to prevent emacs from changing its current
    > directory when opening a new file or changing between files
    > being visited?

    > TIA, /vb

To my knowledge, the working directory of the process is not changed
per se, rather, rather the value of the lisp variable
default-directory is different in each buffer.

There may be a way to set this variable in find-file-hooks, although
there's a chance there could be an awful lot of plumbing in Emacs that
assumes default-directory contains the name of the directory that the
current buffer's file refers to.  Worth a shot anyway.

(add-hook 'find-file-hooks
  (lambda () (setq default-directory "dir-name"))

This of course statically sets it.  I'm sure there's a way through the
magic of elisp to set the hook so it uses the dir of the requested
file.  Any suggestions elisp gurus?

The preferred way in the GNU Emacs world is to just deal with shell
commands via a shell buffer.  If you absolutely need to to use M-! for
whatever reason, whether that be to just run something quickly or
insert the output in the current buffer, shell-mode plus
killing/yanking text via a macro is one way I often go about it.

There is almost always a back-door in Emacs.  It can require writing
an awful lot of elisp sometimes though ;).

-- 
Sam Peterson
skpeterson At nospam ucdavis.edu
"if programmers were paid to remove code instead of adding it,
software would be much better" -- unknown