5:43 p.m.
Matt Curtin <cmcurtin(a)interhack.net> writes:
If I am understanding you properly, then, the issue is:
How do we add cryptographic functionality to Emacs without
removing the impetus to create a free SSH-like tool?
No, :-(. The issue is
How do we extend the remote file hooks/syntax in Emacs such that is
allows access mechanisms other than FTP.
Where other includes for example:
1. Http. Free tools exist. Even pure elisp implementations.
2. rsh like. Free tools exist, i.e. rsh.
Yes, there are also non-free remote file protocols, but that should be
irrelevant[1].
Jan
Footnotes:
[1] Nobody is going to seriously propose
(if (string-match "ssh" rrsh-rsh-program)
(error "Go away!))
hopefully?
6:51 p.m.
New subject: rssh.el interactions with ange-ftp/efs
The issue is
How do we extend the remote file hooks/syntax in Emacs such that is
allows access mechanisms other than FTP.
Yes, this is the issue.
1. Http. Free tools exist. Even pure elisp implementations.
2. rsh like. Free tools exist, i.e. rsh.
Right. So the simple question is, is there a uniform syntax that Emacs
can support for accessing files that includes a method to access them?
And again, I would argue that the syntax should be a URL (Or maybe,
more technically, a URI - if URNs ever get anywhere emacs should
support them too). Before we got sidetracked, we were discussing the
good and bad points of URLs.
The good points
1. URLs are a very widespread standard.
2. URLs work well for specifying resources on the net.
3. It is easy to encode an access method, username, password, and
filename in a URL.
4. URLs are extensible; you can easily add new methods, new naming
schemes, etc.
Bad points
1. Many URLs contain //, and that means something special to Emacs
2. URLs are long
3. Many URLs (ftp, http) might make it awkward to express relative
filenames in the way that EFS does.
My proposal is that in the low-level functions that emacs uses to work
with files, if the filename looks like a URI then the resolution of
that to data should be delegated to a loader function. As a special
case, the EFS syntax (/username＠host:filename) should also be
supported; it should delegate to a "default" load method, which by
default should be ftp, but could be user settable to be something else.
As for bad points of URLs.. for #1, emacs should be smarter about //.
If the string looks like a URL, don't do the special stripping that
emacs does. For #2, I think supporting the EFS syntax as a special
case would take care of it. For #3, I'm not so sure - it has to be
handled on a case by case basis for each protocol. ftp is easy,
rcp/scp/ssh is easy, I'm not so sure about http.
One last little bit - someone will need to define a URL syntax for
methods that don't currently have URLs. ssh, for instance. That should
be done in coordination with the people who develop those tools.
nelson(a)media.mit.edu
. . . . . . . . http://www.media.mit.edu/~nelson/
10:27 a.m.
New subject: rssh.el interactions with ange-ftp/efs
I won't say "no way", but I think I would have to see an
implementation which "does the right thing" in all the cases before I
could be confident that it is possible. Some people think this is an
easy problem, but I think it is hard. I am not sure that it is
possible to meet all of these requirements. An implementation which
does so would prove it is possible.
10:37 p.m.
New subject: rssh.el interactions with ange-ftp/efs
>>>> On Sat, 30 Jan 1999 05:27:28 -0500,
>>>> Richard Stallman <rms(a)gnu.org> said:
As for bad points of URLs.. for #1, emacs should be smarter about
//.
If the string looks like a URL, don't do the special stripping that
emacs does.
I won't say "no way", but I think I would have to see
an
implementation which "does the right thing" in all the cases before I
could be confident that it is possible. Some people think this is an
easy problem, but I think it is hard. I am not sure that it is
possible to meet all of these requirements. An implementation which
does so would prove it is possible.
I agree completely. If somebody wrote a version of expand-file-name
that did the "right thing" with URLs, without messing up other stuff,
then EFS would support it. In fact, if expand-file-name did do this,
then it would be possible for EFS to simultaneously support the
ange-ftp syntax and the URL syntax, according to context.
I am not sure if this can be done -- can't say either way without
trying, but I suspect that Richard is right. It would be harder than
it appears. I can't see myself writing this any time soon, but I
would certainly integrate EFS with it if somebody were to write one
that works. The trick will be that any new version of
expand-file-name must do the right thing 100% of the time, not just
most of the time. Bugs in expand-file-name cannot be tolerated. This
function is too critical.
--sandy
12:20 a.m.
New subject: A partial implementation (was Re: rssh.el interactions with ange-ftp/efs)
I've implemented some partial code that makes emacs 19 and 20 let you
load ftp://username＠host/filename by delegating to ange-ftp via
file-name-handler-alist. I've put it at the bottom. This code is
proof-of-concept only, it needs work, but I hope it demonstrates that
emacs is capable of dealing with // in filenames without great pain.
Sandy says:
The trick will be that any new version of expand-file-name must do
the right thing 100% of the time, not just most of the time. Bugs in
expand-file-name cannot be tolerated. This function is too critical.
I understand that it has to be bulletproof. Personally, I think saying
"emacs can never handle URLs in filenames" is a sure way to make a lot
of people unhappy. URLs are not some passing fad, it's worthwhile to
make emacs handle them.
Happily, I don't think you even need to hack expand-file-name. I went
wading through fileio.c... The actual // code is in
substitute-in-file-name. There's lots of special cases in there for
Apollo, NT, etc. One solution would be to put in another special case
for URLs.
But even better, I learned that substitute-in-file-name first checks
if there's an appropriate handler in file-name-handler-alist. If there
is a handler it calls that instead with the operation
"substitute-in-file-name". As near as I can tell this short-circuits
// substitution (although it might be invoked on the substituted
name). So you just put a handler in for ftp:// URLs and all is well.
The code below is a really simple proof-of-concept handler. Load it up
and try it! To make this work for real, some extra effort will be
necessary to make it bullet-proof and to figure out the semantics of
filenames in ftp URLs. This substitution isn't quite right: it's
loading relative to the home directory, not the server's root. I'm not
quite sure what is right here, but it'd be good if emacs behaved the
same as other URL using tools.
;; Quick hack by Nelson Minar <nelson(a)media.mit.edu> to demonstrate that
;; it is possible to use FTP URLs in emacs. All this does is use the
;; file-name-handler-alist to catch ftp:// URLs and call ange-ftp.
;; This is a prototype only; real code needs error detection etc.
;; This code works in emacs 19.34 and emacs 20.3. Not tested in XEmacs.
;;
;; Try to open the file "ftp://yourname＠localhost/.emacs". If all goes well,
;; ange-ftp will open ~/.emacs via ftp. Some notes:
;; you must kill the find-file minibuffer first.
;; filenames are relative to your homedir; the ftp protocol seems to be
;; relative to /. This should be resolved.
(defun ftp-url-to-ange-ftp (url)
"Map a ftp://user＠host/filename URL to /user＠host:filename ange-ftp string.
This is only a hack - it needs work to make it robust, and to make it handle
relative directory semantics right."
(string-match "ftp://[a-z]+＠[a-z]+/" url)
(let ((filename-start (match-end 0)))
(concat
(substring url 5 (- filename-start 1)) ; strip out ftp:/
":" ; give ange-ftp a colon
(substring url filename-start)))) ; append the rest of filename
(defun ftp-url-handler-hack (operation &rest args)
"A file name handler for emacs to pass FTP urls through to ange-ftp."
(if (eq 'substitute-in-file-name operation)
(message (car args))
(ange-ftp-hook-function operation (ftp-url-to-ange-ftp (car args)))))
(setq file-name-handler-alist
(append '(("^ftp://" . ftp-url-handler-hack))
file-name-handler-alist))
nelson(a)media.mit.edu
. . . . . . . . http://www.media.mit.edu/~nelson/
9:48 p.m.
New subject: A partial implementation (was Re: rssh.el interactions with ange-ftp/efs)
That is true. I did this hoping to make the // feature less deeply
embedded in Emacs.
The code below is a really simple proof-of-concept handler. Load it up
and try it! To make this work for real, some extra effort will be
necessary to make it bullet-proof and to figure out the semantics of
filenames in ftp URLs.
I encourage people to keep working on this, and get experience with it.
If the problem can be solved and gives reliable results, I would be happy
to make Emacs support URL syntax.
3:27 a.m.
New subject: rssh.el interactions with ange-ftp/efs
>>>> On Tue, 26 Jan 1999 13:51:18 -0500 (EST),
>>>> nelson(a)media.mit.edu (Nelson Minar) said:
As for bad points of URLs.. for #1, emacs should be smarter about
//.
If the string looks like a URL, don't do the special stripping that
emacs does. For #2, I think supporting the EFS syntax as a special
case would take care of it. For #3, I'm not so sure - it has to be
handled on a case by case basis for each protocol. ftp is easy,
rcp/scp/ssh is easy, I'm not so sure about http.
One last little bit - someone will need to define a URL syntax for
methods that don't currently have URLs. ssh, for instance. That should
be done in coordination with the people who develop those tools.
As I've mentioned before, there is another and much tougher issue than
simply using URLs to specify file names. EFS cannot use a file
transfer program that does not follow a protocol. EFS works with ftpd
by parsing the 3-digit return codes, which are defined in RFC 959.
Neither of rcp, scp, or ssh (or even sftp) provide status information
back, nor do they follow any defined protocol. They are designed as
user-level programs. EFS will not work with them now, nor will it
ever work with them.
To my knowledge, the only file transfer program that does give
well-defined status codes is ftp. Or more precisely, I should say
that the only programs are the various and many ftpd's which implement
the FT Protocol.
Therefore, the main reason for supporting URLs is not to allow people
to use rcp, scp, etc, but to provide the convenience of having EFS
support a widespread syntax. Support for URLs will not lead to
support for rcp, scp, etc.
A separate issue is support for secure file transfer with EFS. For
this there appear to be two options: ftpsshd and SSLftp. However,
these are both implementations of FTP and I believe that with some
minor setup of config variables, EFS will work with them now. We do
not need URLs for this.
To summarise, there are 3 issues swirling around here:
1. URL support. This is a user interface issue. Some work will need
to be done to make it compatible with Emacs, but this is a
possibility (maybe even a likelhood).
2. Support for rcp, scp and sftp. This is a non-starter.
3. Support for secure file transfers. Via ftpsshd and SSLftp we have
support for this now. However, we can probably do some things to
make it easier to set up EFS to use them.
--sandy
9211
days inactive
9219
days old
6 comments
4 participants
participants (4)
-
Jan Vroonhof -
Nelson Minar -
Richard Stallman -
Sandy Rutherford