all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: kai.grossjohann@uni-duisburg.de (Kai Großjohann)
Subject: Make call-process (and start-process?) filename handlers?
Date: Sat, 28 Dec 2002 23:31:54 +0100	[thread overview]
Message-ID: <84isxdpyg5.fsf@lucy.cs.uni-dortmund.de> (raw)

I think it would be good to change call-process to check for a
filename handler, based on the value of default-directory.

VC uses call-process (or start-process) for the external programs;
with this change it would automagically work for remote files.  (If
the corresponding filename handler implements call-process, of
course.)

Currently, shell-command chooses a filename handler based on
default-directory.  call-process is not currently a file operation.

Previously, Richard suggested to implement an operation
process-file.  One of the arguments would be the filename to use for
finding the right filename handler.

I think that process-file leads to unnecessary complications.  For
example, what happens if the file to process is /user@host:/file1 and
one of the other args is /user@host:/file2?  Should that be
interpreted as a filename and passed to the remote program as "/file2"
or "file2"?  Or should it be interpreted as a string and passed as
"/user@host:/file2"?  Clearly, it can be both, so the interface for
process-file needs to provide a way to specify which interpretation
to use.  Another complication is that the filename that determines
the handler can be at various positions in the arg list, which makes
the interface to process-file complicated.

With call-process, one can just make all filenames relative to
default-directory before invoking call-process.  Then it will just
work.

In the unlikely event that somebody successfully invoked call-process
where default-directory was pointing to a remote directory, this
invocation can easily be rectified by let-binding default-directory
to "/" (on Windows, maybe "c:/"?) arount that problematic
invocation.  I have not done investigations on how unlikely that
event is, though.

What do people think?
-- 
Ambibibentists unite!

             reply	other threads:[~2002-12-28 22:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-28 22:31 Kai Großjohann [this message]
2002-12-31  5:47 ` Make call-process (and start-process?) filename handlers? Richard Stallman
2002-12-31 18:54   ` Kevin Rodgers
2003-01-02 18:38     ` Richard Stallman
2003-01-10 23:52   ` Stefan Monnier
2003-01-11 21:33     ` Kai Großjohann
2003-01-13 10:42       ` Richard Stallman
2003-01-12 11:55     ` Richard Stallman
2003-01-12 14:54       ` Kai Großjohann
2003-01-13 10:21         ` Andreas Schwab
2003-01-13 11:41           ` Ehud Karni
2003-01-14 18:54             ` Richard Stallman
2003-01-14 22:42               ` Luc Teirlinck
2003-01-15 23:28                 ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84isxdpyg5.fsf@lucy.cs.uni-dortmund.de \
    --to=kai.grossjohann@uni-duisburg.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.