10:52 p.m.
Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
[...] and have Emacs figure out the best way of accessing based on
user and site configuration. [...]
I'm not sure that a table that maps host names (and/or user names) to
access methods is the right thing.
How about file names for FTP, file names for rsh/rcp, and general
remote file names, and the latter means that all available methods are
tried until one succeeds?
Dunno what one would choose for the file name patterns, though. Right
now, we have "/user＠host:/path/to/file" for ange-ftp. Maybe this
should become the general syntax and we should use
"/ftp:user＠host:/path/to/file" and "/rcp:user＠host:/path/to/file" for
the more specific syntaxes? ("/:" could then become an abbreviation
for "/verbatim:".)
kai
--
Just because I'm paranoid doesn't mean they're not out there to get me!
8:35 p.m.
New subject: rssh.el interactions with ange-ftp/efs
Why propose so much effort just to use an alternative to ftp?
ftp seems to work; what benefit would we have from the option
to use another alternative?
8:40 p.m.
New subject: rssh.el interactions with ange-ftp/efs
Why propose so much effort just to use an alternative to ftp?
ftp seems to work; what benefit would we have from the option
to use another alternative?
ftp isn't the only file transfer protocol out there. scp (part of ssh,
the de-facto standard for a secure alternative to rlogin/rsh/rcp) is
particularly nice because it offers encryption and simple RSA based
authentication.
I really think it'd be good if emacs standardized on using URLs to
specify things to load that are outside the filesystem. URLs are a
nice, standard syntax for specifying a method and a location: it
solves exactly the problem we are discussing here.
It's a problem that // means something special in emacs: could you
maybe special case "://" to mean something different to handle URLs?
(// isn't common to all URLs, btw, although it's typical for many of
the ones that name things that look like files).
How did emacs work under Apollo, where // in a filename meant
something special to the OS?
nelson(a)media.mit.edu
. . . . . . . . http://www.media.mit.edu/~nelson/
8:52 p.m.
New subject: rssh.el interactions with ange-ftp/efs
Nelson Minar writes:
I really think it'd be good if emacs standardized on using URLs
to
specify things to load that are outside the filesystem. URLs are a
nice, standard syntax for specifying a method and a location: it
solves exactly the problem we are discussing here.
It's a problem that // means something special in emacs: could
you
maybe special case "://" to mean something different to handle URLs?
(// isn't common to all URLs, btw, although it's typical for many of
the ones that name things that look like files).
Actually, given WHAT // means, I'd just as soon pull it out -- it's
not much faster to type // as ^a^k (which does the same thing,
mostly), and normal // parsing can be done on the protocol side,
rather than the editing side; long filenames that are really much
shorter filenames shouldn't be a problem, yes?
Not to mention that I've been bit by // more often than I've
benifited from it -- as presently implemented, it's a single-keystroke
operation that can, in an instant, wipe out the last minute of hunting
around on the filesystem (even if it IS undoable). There's little
reason to have it resolve electrically, and several reasons not to.
--
Joshua Kronengold (mneme(a)mcny.com) |\ _,,,--,,_ ,)
---^---- Application Developer, Winstar Media Connection /,`.-'`' -,
;-;;'
/\\ "What part of 'Pthhhrrrrrrrrrrrrrrrrrr' |,4- ) )-,_ ) /\
-/-\\\-- didn't you understand?" '---''(_/--' (_/-'
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1.2
GCS d- a- C+++$ U+++$(++++) P+++$ L++$ E+ W++$ N++ K++ w-- !O
!M V-- PS+++ PE Y+ PGP !t 5++ !X R++＠ !tv b++++ DI++++ D- G
e+＠ h! r++ y+* s:
------END GEEK CODE BLOCK------
9:05 p.m.
New subject: rssh.el interactions with ange-ftp/efs
On Fri, 15 Jan 1999, Joshua Kronengold wrote:
Actually, given WHAT // means, I'd just as soon pull it out --
it's
not much faster to type // as ^a^k (which does the same thing,
I disagree. I use it all the time, although I normally just hit one /, or
more often a ~ after an existing slash. I would be very upset if the
feature went away.
Not to mention that I've been bit by // more often than
I've
benifited from it -- as presently implemented, it's a single-keystroke
operation that can, in an instant, wipe out the last minute of hunting
around on the filesystem (even if it IS undoable).
You must be using XEmacs. Emacs won't erase the previous contents of the
minibuffer until you hit tab or return, which means you can just hit DEL
to get rid of an extra slash.
9:06 p.m.
New subject: rssh.el interactions with ange-ftp/efs
Alan Shutko writes:
On Fri, 15 Jan 1999, Joshua Kronengold wrote:
> Actually, given WHAT // means, I'd just as soon pull it out -- it's
> not much faster to type // as ^a^k (which does the same thing,
I disagree. I use it all the time, although I normally just hit one /, or
more often a ~ after an existing slash. I would be very upset if the
feature went away.
The point is that you don't need this to be electric for it to work --
any given protocol has to and can implement it's own meaning for //;
if it makes sense for // to be "back to root", this will be understood
when doing completion.
You must be using XEmacs. Emacs won't erase the previous contents
of the
minibuffer until you hit tab or return, which means you can just hit DEL
to get rid of an extra slash.
So what's the problem?
--
Joshua Kronengold (mneme(a)mcny.com) |\ _,,,--,,_ ,)
---^---- Application Developer, Winstar Media Connection /,`.-'`' -,
;-;;'
/\\ "What part of 'Pthhhrrrrrrrrrrrrrrrrrr' |,4- ) )-,_ ) /\
-/-\\\-- didn't you understand?" '---''(_/--' (_/-'
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1.2
GCS d- a- C+++$ U+++$(++++) P+++$ L++$ E+ W++$ N++ K++ w-- !O
!M V-- PS+++ PE Y+ PGP !t 5++ !X R++＠ !tv b++++ DI++++ D- G
e+＠ h! r++ y+* s:
------END GEEK CODE BLOCK------
9:27 p.m.
New subject: rssh.el interactions with ange-ftp/efs
Dear Nelson,
On Fri, 15 Jan 1999 you wrote:
I really think it'd be good if emacs standardized on using URLs
to
specify things to load that are outside the filesystem. URLs are a
nice, standard syntax for specifying a method and a location: it
solves exactly the problem we are discussing here.
There was a great deal of discussion of using the URL syntax for
remote filenames accessed by EfS back when EFS was developed. The
issue was whether we should stick to the ange-ftp syntax or move EFS
to the URL syntax, which had just been introduced. After much debate,
it was decided to stick to the the ange-ftp syntax because the URL
syntax is not well suited to editing remote files. If memory serves
me right, at the time, the Internet Engineering Draft that defined the
URL syntax allowed for no way to specify the username that you wished
to use to access the remote file. As well, it had no concept of
remote relative paths. i.e. no analogue of /sandy＠foobar:xxx.tex
meaning the file xxx.tex in my FTP home on foobar. This makes it very
clumsy for the purpose of doing actual work on a remote machine. The
URL syntax was really designed for the purpose of read access to
remote resources, via the web, etc. EFS was designed for the purpose
of doing editing on remote machines. Although, many people use it as
an anonymous FTP interface (and it does do the job), that is not what
it is optimized for.
While I'm spouting history, this is also why EFS has never supported
local caching of files like netscape. Code to do caching is easy to
write for read access only. For write access, it's more complicated.
This coupled with the fact that still many many FTP servers out there
cannot be counted on the follow RFC 959 (making it hard to get
reliable information about the remote file system) meant that I never
really got caching code to work reliably in real world use.
How did emacs work under Apollo, where // in a filename meant
something special to the OS?
BTW, if you use EFS to access a remote apollo, it has code to make
sure that the // will not be short circuited. This is part of the
reason why EFS overloads expand-file-name.
...Sandy
10:19 p.m.
New subject: rssh.el interactions with ange-ftp/efs
>>>> "SR" == Sandy Rutherford <of Fri, 15 Jan
1999 13:27:17 PST> writes:
SR> If memory serves
SR> me right, at the time, the Internet Engineering Draft that defined the
SR> URL syntax allowed for no way to specify the username that you wished
SR> to use to access the remote file.
I dunno about the IED, but Netscape has been supporting
the ftp://user＠machine/path syntax
for many years now. There is no reason to not revisit the old decision
about not supporting URLs in EFS or ange-ftp.
10:49 p.m.
New subject: rssh.el interactions with ange-ftp/efs
Michael,
On Fri, 15 Jan 1999 you wrote:
>>>> "SR" == Sandy Rutherford <of Fri, 15 Jan
1999 13:27:17 PST> writes:
SR> If memory serves
SR> me right, at the time, the Internet Engineering Draft that defined the
SR> URL syntax allowed for no way to specify the username that you wished
SR> to use to access the remote file.
I dunno about the IED, but Netscape has been supporting
the ftp://user＠machine/path syntax
for many years now. There is no reason to not revisit the old decision
about not supporting URLs in EFS or ange-ftp.
OK, it's been some years since I have had the time to stay up to date
with these things. How does it handle relative remote paths? Is
there a special syntax for filenames in my remote home directory?
Without this, editing remote files would still be a pain.
...Sandy
11:06 p.m.
New subject: rssh.el interactions with ange-ftp/efs
OK, it's been some years since I have had the time to stay up to
date
with these things. How does it handle relative remote paths? Is
there a special syntax for filenames in my remote home directory?
Without this, editing remote files would still be a pain.
Unfortuantely, no, but the answer is fairly obvious:
ftp://user:password＠host/~/filename
(should hit the location where ftp starts, which will be your home directory).
(nyetscape just hacks it by making ftp://user:password＠host (no
trailing slash) get renamed to the user's home directory)
--
Joshua Kronengold (mneme(a)mcny.com) |\ _,,,--,,_ ,)
---^---- Application Developer, Winstar Media Connection /,`.-'`' -,
;-;;'
/\\ "What part of 'Pthhhrrrrrrrrrrrrrrrrrr' |,4- ) )-,_ ) /\
-/-\\\-- didn't you understand?" '---''(_/--' (_/-'
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1.2
GCS d- a- C+++$ U+++$(++++) P+++$ L++$ E+ W++$ N++ K++ w-- !O
!M V-- PS+++ PE Y+ PGP !t 5++ !X R++＠ !tv b++++ DI++++ D- G
e+＠ h! r++ y+* s:
------END GEEK CODE BLOCK------
11:15 p.m.
New subject: rssh.el interactions with ange-ftp/efs
Joshua,
On Fri, 15 Jan 1999 you wrote:
> OK, it's been some years since I have had the time to stay up
to date
> with these things. How does it handle relative remote paths? Is
> there a special syntax for filenames in my remote home directory?
> Without this, editing remote files would still be a pain.
Unfortuantely, no, but the answer is fairly obvious:
ftp://user:password＠host/~/filename
(should hit the location where ftp starts, which will be your home directory).
This syntax is still not as compact as the ange-ftp syntax. If people
really wanted the URL syntax, it would be quite easy to make it an
option in EFS. This is because the first thing that EFS does is parse
the remote file name into a list. However, I would be opposed to
dropping the ange-ftp syntax, because personally I find it more
logical and convenient. Besides, it is an older standard than URL
anyway ;-)
...Sandy
11:27 p.m.
New subject: rssh.el interactions with ange-ftp/efs
SR> If people
SR> really wanted the URL syntax, it would be quite easy to make it an
SR> option in EFS. This is because the first thing that EFS does is parse
SR> the remote file name into a list. However, I would be opposed to
SR> dropping the ange-ftp syntax, because personally I find it more
SR> logical and convenient. Besides, it is an older standard than URL
SR> anyway ;-)
Yes, people want URLs! Please Make it optional (and I don't oppose to
keeping the old syntax as another option---fewer things to change in my
.emacs :-)
m.
12:51 a.m.
New subject: rssh.el interactions with ange-ftp/efs
Michael,
On Fri, 15 Jan 1999 you wrote:
SR> If people
SR> really wanted the URL syntax, it would be quite easy to make it an
SR> option in EFS. This is because the first thing that EFS does is parse
SR> the remote file name into a list. However, I would be opposed to
SR> dropping the ange-ftp syntax, because personally I find it more
SR> logical and convenient. Besides, it is an older standard than URL
SR> anyway ;-)
Yes, people want URLs! Please Make it optional (and I don't
oppose to
keeping the old syntax as another option---fewer things to change in my
.emacs :-)
m.
OK, OK. I'll put it on my todo list. I can hear Andy & Mike Sperber
laughing themselves off their chairs. My record with to do lists has
been rather dismal since my postdoc days. It's hard to hack code at
3am when you need to prepare a lecture for the next morning...
Perhaps it's time to prepare another EFS release. I'm not teaching
this term, so it may even be in the realm of the possible that I could
work on this.
...Sandy
11:09 p.m.
New subject: rssh.el interactions with ange-ftp/efs
Michael,
On Fri, 15 Jan 1999 you wrote:
>>>>> "SR" == Sandy Rutherford <of Fri, 15 Jan 1999 13:27:17
PST> writes:
SR> If memory serves
SR> me right, at the time, the Internet Engineering Draft that defined the
SR> URL syntax allowed for no way to specify the username that you wished
SR> to use to access the remote file.
> I dunno about the IED, but Netscape has been supporting
> the ftp://user＠machine/path syntax
> for many years now. There is no reason to not revisit the old decision
> about not supporting URLs in EFS or ange-ftp.
OK, it's been some years since I have had the time to stay up to date
with these things. How does it handle relative remote paths? Is
there a special syntax for filenames in my remote home directory?
Without this, editing remote files would still be a pain.
...Sandy
Well, it still requires the absolute path name (this is why I still use EFS!)
However, nothing precludes you from extending the syntax by allowing ~ and
by assuming that if the file name doesn't start with / then it is a
relative file name.
I hope that now that Navigator is in the hands of mozilla.org, they will
also start using relative path names.
m.
8:13 p.m.
New subject: rssh.el interactions with ange-ftp/efs
>>>> nelson(a)media.mit.edu (Nelson Minar) (NM) writes:
NM> It's a problem that // means something special in emacs: could you
NM> maybe special case "://" to mean something different to handle URLs?
NM> (// isn't common to all URLs, btw, although it's typical for many of
NM> the ones that name things that look like files).
NM> How did emacs work under Apollo, where // in a filename meant
NM> something special to the OS?
In emacs 20.3 on Window NT/95, // also is used for network addresses,
like
//machine/dir/file/
--
Piet van Oostrum <piet(a)cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: Piet.van.Oostrum(a)gironet.nl
8:04 p.m.
New subject: rssh.el interactions with ange-ftp/efs
ssh is particularly nasty, because it is not free software, but people
are being lured into using it anyway.
12:47 a.m.
New subject: rssh.el interactions with ange-ftp/efs
>>>> "rms" == Richard Stallman
>>>> "Re: rssh.el interactions with ange-ftp/efs"
>>>> Sun, 17 Jan 1999 13:04:39 -0700 (MST)
rms> ssh is particularly nasty, because it is not free software,
rms> but people are being lured into using it anyway.
ssh-1.2.x is freely distributable and the author has repeatedly
clarified a broad interpretation of "non-commercial" use that IIRC
extends to practically anything short of selling the code outright,
but IANAL. Anyway, ssh-1.2.x is widely deployed. ssh-2.x has a
restrictive license, is viewed by many as being problematical in other
ways, and probably will not soon have anything like the following that
ssh-1.2.x has had.
The GPLed LSH implementation of the ssh protocols does not look like
it will be ready for non-combatant use for some time.
In the interim having efs use the GPLed ftpsshd or a work-alike (or
_be_ a work-alike) would let folks use strong encryption _now_ and, it
would seem, should be easy to make work with a rudimentary LSH until
such time as LSH has its own secure ftp. Having this established and
working would also seem to help encourage future secure ftp
implementations to remain compatible with classic ftp rather than
follow only the approach taken by the ssh-2.x sftp.
Is it better to cut off the nose to spite the face of ssh-1.x being
freely distributed and used without the GPL or to go ahead with a
capability that is wanted by many and that will help to establish the
routine use strong cryptography by everyone? Would it be better to
continue to force those with hard security requirements to find
solutions outside their Emacsen and without Open Source? Who will
that benefit?
FWIW IMHO the worsening developments with ssh-2.x make a strong case
for the GPL over and above quasi open/free licenses. Providing an
alternative to the sftp of the commercial ssh-2.x can not be all bad.
jam
1:50 a.m.
New subject: Gnus in the Waldman Install
Dear Y'all -
Is anyone else having trouble uudecoding news atricles.
Xemacs crashes when I try to.
Yours - Billy
**------------------------------------------------------------------**
** William Goedicke, Billy | goedicke(a)acs.neu.edu **
** Associate Director, Client/Server | billy＠staff＠acs (NUnet) **
** Administrative Computer Services | 360 Huntington Ave. **
** (617) 373-3392 | Northeastern University **
** (617) 373-4354 FAX (Use e-mail!) | Boston, MA USA 02115 **
** http://acs.neu.edu/~goedicke | PGP Key on Request **
**------------------------------------------------------------------**
12:13 a.m.
New subject: rssh.el interactions with ange-ftp/efs
Yes, that's true--but that's not enough to be free software. So we
don't use ssh in the GNU Project, and I would not want to encourage
others to use it.
The GPLed LSH implementation of the ssh protocols does not look like
it will be ready for non-combatant use for some time.
It may take time, but we have to wait. The purpose of GNU Emacs, and
the GNU system as a whole, is to give users freedom; it would not do
to get caught up in the details and forget the ultimate purpose.
If you wish LSH would get done sooner, how about volunteering to help
(those of you not in the US)?
In the interim having efs use the GPLed ftpsshd
I don't think I have heard of ftpsshd before. Can you tell me what it
does? Can it be used on its own, or does it depend on ssh?
Is it better to cut off the nose to spite the face of ssh-1.x being
freely distributed and used without the GPL
I would not reject a program merely because its license is not the
GPL. If it is free software using some other license, we can still
recommend it. However, ssh is not free software at all.
1:05 a.m.
New subject: rssh.el interactions with ange-ftp/efs
>>>> On Mon, 18 Jan 1999 17:13:03 -0700 (MST),
>>>> Richard Stallman <rms(a)gnu.org> said:
ssh-1.2.x is freely distributable and the author has repeatedly
clarified a broad interpretation of "non-commercial" use
Yes, that's true--but that's not enough to be free software.
So we
don't use ssh in the GNU Project, and I would not want to encourage
others to use it.
The GPLed LSH implementation of the ssh protocols does not look
like
it will be ready for non-combatant use for some time.
It may take time, but we have to wait. The purpose of GNU Emacs,
and
the GNU system as a whole, is to give users freedom; it would not do
to get caught up in the details and forget the ultimate purpose.
If you wish LSH would get done sooner, how about volunteering to
help
(those of you not in the US)?
In the interim having efs use the GPLed ftpsshd
I don't think I have heard of ftpsshd before. Can you tell me
what it
does? Can it be used on its own, or does it depend on ssh?
Is it better to cut off the nose to spite the face of ssh-1.x
being
freely distributed and used without the GPL
I would not reject a program merely because its license is not the
GPL. If it is free software using some other license, we can still
recommend it. However, ssh is not free software at all.
Also, as I mentioned in an earlier message of mine (that went to a
smaller recipient list than this one), scp (part of ssh-1) and sftp
(part of ssh-2) don't follow a well-defined protocol, such as defined
in RFC 959. EFS relies almost exclusively on the 3-digit FTP return
codes to determine the state of the server and the success or failure
of commands. Here is an example of what I mean:
sftp> pwd
/home/sandy
as opposed to
ftp> pwd
257 "/home/sandy" is current directory.
Therefore, any EFS-like program that used scp or sftp underneath would
likely be quite unreliable. IMHO, writing scp support into EFS would
be a waste of time. In addition, because scp isn't following any
published protocol, chances are more than likely that you would no
sooner finish your code, than some bright light at SSH would decide to
change the output from scp commands for the sake of aesthetics.
I agree with Richard that a free secure file transfer program is
needed. However, I would add that it should also be based on a
well-defined and established protocol. The FT Protocol defined in RFC
959 is a good starting point; although, a case can be made for expanding
this protocol in some areas.
...Sandy
3:37 p.m.
New subject: rssh.el interactions with ange-ftp/efs
>>>> "Sandy" == Sandy Rutherford
>>>> "Re: rssh.el interactions with ange-ftp/efs"
>>>> Mon, 18 Jan 1999 17:05:03 -0800 (PST)
Sandy> Also, as I mentioned in an earlier message of mine (that
Sandy> went to a smaller recipient list than this one), scp (part
Sandy> of ssh-1) and sftp (part of ssh-2) don't follow a
Sandy> well-defined protocol, such as defined in RFC 959. EFS
Sandy> relies almost exclusively on the 3-digit FTP return codes
Sandy> to determine the state of the server and the success or
Sandy> failure of commands. Here is an example of what I mean:
sftp> pwd
Sandy> /home/sandy
Sandy> as opposed to
ftp> pwd
Sandy> 257 "/home/sandy" is current directory.
Using ftp through the ssh tunnels set up by ftpsshd does not change
the behavior of either the ftp client nor of the ftp server. You see
exactly the same result.
Sandy> Therefore, any EFS-like program that used scp or sftp
Sandy> underneath would likely be quite unreliable. IMHO, writing
Sandy> scp support into EFS would be a waste of time. In
Sandy> addition, because scp isn't following any published
Sandy> protocol, chances are more than likely that you would no
Sandy> sooner finish your code, than some bright light at SSH
Sandy> would decide to change the output from scp commands for the
Sandy> sake of aesthetics.
That is why I suggested ftpsshd. You still run plain old ftp but
through channels secured by ssh. Also it would seem that since this
approach uses only a straight forward application of the port
forwarding mechanism of ssh-1.x it should work with little change with
successor implementations of the ssh protocol(s) that do port
forwarding whether or not they have their own ftp-like facilities.
Sandy> I agree with Richard that a free secure file transfer
Sandy> program is needed. However, I would add that it should
Sandy> also be based on a well-defined and established protocol.
Sandy> The FT Protocol defined in RFC 959 is a good starting
Sandy> point; although, a case can be made for expanding this
Sandy> protocol in some areas.
That seems to argue for ftpsshd.
jam
3:35 p.m.
New subject: rssh.el interactions with ange-ftp/efs
>>>> "rms" == Richard Stallman
>>>> "Re: rssh.el interactions with ange-ftp/efs"
>>>> Mon, 18 Jan 1999 17:13:03 -0700 (MST)
rms> In the interim having efs use the GPLed ftpsshd
rms> I don't think I have heard of ftpsshd before. Can you tell
rms> me what it does? Can it be used on its own, or does it
rms> depend on ssh?
http://www.docs.uu.se/~pem/hacks/ftpsshd-1.1.tar.gz
ftpsshd starts a ssh (ssh-1.2.26) session with a remote host and uses
the ssh port forwarding to establish encrypted channels for the ftp
command and data channels then listens for connections on another
local port. That is the effect, I haven't looked "under the hood".
Then a normal ftp client pointed at the afore mentioned port, as in
'ftp localhost 2121' can login to the ftp server on the above
mentioned remote host and proceed as usual. There is no crypto in
ftpsshd. The encrypted channels are provided by ssh.
jam
7:55 a.m.
New subject: rssh.el interactions with ange-ftp/efs
It sounds like ftpsshd is not useful in the absence of ssh. Too bad.
Perhaps once LSH is working, ftpsshd will be useful with that too.
8:41 p.m.
New subject: rssh.el interactions with ange-ftp/efs
On Fri, 15 Jan 1999, Richard Stallman wrote:
Why propose so much effort just to use an alternative to ftp?
ftp seems to work; what benefit would we have from the option
to use another alternative?
It would be useful to support other protocols in the general case, because
we could have support for DAV for editing things through HTTP servers, and
any other free secure protocols which appear.
8:45 p.m.
New subject: rssh.el interactions with ange-ftp/efs
Richard Stallman writes:
Why propose so much effort just to use an alternative to ftp?
ftp seems to work; what benefit would we have from the option
to use another alternative?
Flexablily.
The ability to get around nasty firewalls.
The ability to transparently include html files, and edit them using
http fetch and related protocols.
Anythng else that comes along.
--
Joshua Kronengold (mneme(a)mcny.com) |\ _,,,--,,_ ,)
---^---- Application Developer, Winstar Media Connection /,`.-'`' -,
;-;;'
/\\ "What part of 'Pthhhrrrrrrrrrrrrrrrrrr' |,4- ) )-,_ ) /\
-/-\\\-- didn't you understand?" '---''(_/--' (_/-'
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1.2
GCS d- a- C+++$ U+++$(++++) P+++$ L++$ E+ W++$ N++ K++ w-- !O
!M V-- PS+++ PE Y+ PGP !t 5++ !X R++＠ !tv b++++ DI++++ D- G
e+＠ h! r++ y+* s:
------END GEEK CODE BLOCK------
8:53 p.m.
New subject: rssh.el interactions with ange-ftp/efs
>>>> "RS" == Richard Stallman <of Fri, 15 Jan
1999 15:35:00 EST> writes:
RS> Why propose so much effort just to use an alternative to ftp?
RS> ftp seems to work; what benefit would we have from the option
RS> to use another alternative?
1. Ftp *doesn't* work for many people, especially those concerned with
security. I, for one, don't want my password to be sniffed (as it
happened once when I was using ftp to maintain packages at gnu.org
2. There is a need to support other protocols.
3. The fact that // means something else in emacs is not a good argument.
First, there are ways around it (perhaps, :// should be a special case).
Second, the effects of bad decisions made in the past should not be
perpetuated.
8:04 p.m.
New subject: rssh.el interactions with ange-ftp/efs
I think it's a good reason to keep the // feature unchanged.
It is very important.
9253
days inactive
9260
days old
26 comments
10 participants
participants (10)
-
Alan Shutko -
John A. Martin -
Joshua Kronengold -
Kai Großjohann -
Michael Kifer -
Nelson Minar -
Piet van Oostrum -
Richard Stallman -
Sandy Rutherford -
William Goedicke