I have started to implement this. It will be a few commits before it
is finished, though. Watch me code... ;-)
kai
--
The birch trees fly way too low these days.
Charles Karney [EMAIL PROTECTED] writes:
The right solution would be to move the rcp hooks up the Emacs calling
chain. This would allow the safe save to be implemented as
copy REMOTE:FILE to REMOTE:#TMP#0
rsync BUFFER REMOTE:#TMP#0# potential rsync efficiencies
David Barr [EMAIL PROTECTED] writes:
$ echo hello
hello
hello
$ echo ~root
# Remote /bin/sh groks tilde expansion. Good.
Ick! This seems to be a timing problem. Here's what's going on:
rcp.el sends "echo hello" to the remote end, but it arrives too early,
so ssh gets kind of a hickup.
Pete Forman [EMAIL PROTECTED] writes:
My mistake. I had been confusing "login" and "interactive". A login
shell will read .profile or similar prior to reading commands which is
what was worrying me. An interactive, non-login shell generally will
not read any file. It may read .bashrc,
Pete Forman [EMAIL PROTECTED] writes:
Kai Großjohann writes:
I have now applied the code given by Stefan.
But in the wrong place :-(
Argh. I hope it is better now.
Ok if I don't do anything about the large file problem until it
actually happens?
kai
--
Life is hard and then you
Francesco Potorti` [EMAIL PROTECTED] writes:
If I am not wrong, doing
M-x cd RET /r:box: RET
should be enough. Not sure, though.
Sounds about right. But WIBNI this happened automatically?
kai
--
Life is hard and then you die.
There is this todo item:
;; * Do not unconditionally use /bin/sh for local shell commands.
;; Instead, try to find out a local shell which groks tilde
;; expansion. (Mario DeWeerd)
I have now had a look at the two places where /bin/sh is executed
locally. Looks as if the tmp file names
"Spencer L. Swift" [EMAIL PROTECTED] writes:
$ stty -onlcr -echo 1/dev/null 2/dev/null ; unset MAIL ; set +o history
1/dev/null 2/dev/null ; PS1='
/
'; PS2=''; PS3=''
What happens if you manually connect to that machine, then say `exec
/bin/sh', then type the above command (embedded
Martin Pool [EMAIL PROTECTED] writes:
Opening connection for mbp@localhost using scp...
Waiting 60s for shell or passwd prompt from localhost
Initializing remote shell
Waiting 30s for remote /bin/sh to come up...
Setting up remote shell environment
Couldn't set
I got several bug reports about rcp.el failing to see that a target
file wasn't writable. What do you think is the best approach?
(1) Check whether copy/rename will succeed, first. Barf if not, else
do it.
(2) Just do stuff, but check for errors in each step.
(3) Check first, then check
Daniel Pittman [EMAIL PROTECTED] writes:
While working on the VC remote username code, I believe I have a
solution. To know how general it is, however, I would like to know if
there are any platforms out there that don't have the grep(1) and cut(1)
tools installed.
I'm not sure that the
Tim Carroll [EMAIL PROTECTED] writes:
I took the opportunity to remove the color prompt, et al from the
remote server I have been trying to link to, as well as the local
client. Alas, I get the same result with rcp as before. So, I suppose
that this is not the source of the problem.
Hm.
Matt Swift [EMAIL PROTECTED] writes:
v1.149 has the following code:
(defun rcp-set-auto-save ()
(when (and (rcp-rcp-file-p (buffer-file-name))
auto-save-default)
(auto-save-mode 1)))
(defun rcp-rcp-file-p (name)
"Return t iff this is an rcp file."
(string-match
Pete Forman [EMAIL PROTECTED] writes:
That fails on both AIX and IRIX. Neither support any uudecode option
to write to stdout.
So, what does one do for those systems?
tmpdir=/tmp/rcp.$$
( mkdir $tmpdir
cd $tmpdir
uudecode
cat * )
rm -rf $tmpdir
Whee...
Or
There has been much talk some time ago about uuencode and uudecode. A
couple of versions ago, I have implemented a partial solution which
seems to work for two common strands of uudecode. But on some
machines, uudecode does not accept any arguments at all, so to
accomodate these machines, quite
There has been talk about setting up interactive shells with more
intelligence. The discussion was specifically about tset, IIRC.
What I could do is this: I could set up an alist of regex/action pairs
and rather than expecting just a shell prompt, I expect any of the
regexes in that alist. And
"Stefan Monnier" [EMAIL PROTECTED] writes:
(unless (re-search-forward "\\(\\(foo\\)\\|bar\\)\\|baz" nil t)
That's a cool idea.
kai
--
The birch trees fly way too low these days.
I just wanted to inform you that, right now, it's code cleanup and bug
fix time. So if you were to do a sanity check every now and then to
check whether it still works normally, that would be wonderful.
I think I'll want to think about a more structured approach to
development, but I haven't
Edward J. Sabol [EMAIL PROTECTED] writes:
Excerpts from mail: (08-Oct-99) Re: uuencode syntax? by Kai
=?iso-8859-1?q?Gro=DFjohann?=
Any ideas for a uuencode replacement with awk and od?
No, but I think it's fairly simple to write one in Perl.
Yes, but perl doesn't come standard with most
Pete Forman [EMAIL PROTECTED] writes:
If /dev/stdout was available on AIX, IRIX, etc. then we would not need
to jump through some of these hoops.
Ah, yes, silly me. Hm. But one could do the decoding to a buffer and
then do (princ (buffer-string)) or something like this.
And can emacs
Daniel Pittman [EMAIL PROTECTED] writes:
For quite a while now I have had a real problem with the performance
of inline methods while using rcp.el. This finally got to me enough
to go and do some testing and all.
I wonder what has become of this? Are the inline methods still slow
in XEmacs?
[EMAIL PROTECTED] (Mark A. Hershberger) writes:
I use ffap.el with emacs and really enjoy its convenience. However,
it tends to confuse rcp.el.
Hm. I also use ffap, with the following customization:
/
| ;; -- ffap -- find-file-at-point --
| (require 'ffap)
| ;; replace mouse bindings
Mark Galassi [EMAIL PROTECTED] writes:
I would suggest trapping the incorrect syntax and making the error
message something other than:
Wrong type argument: stringp, nil
This is the equivalent of a core dump in C.
You're right. The current behavior is that unknown methods lead to
Can you set rcp-debug-buffer to t then send the contents of the debug
buffer, too?
I can't really see anything wrong with the buffer you're showing. Hm.
But a few ideas: did you update rcp.el? Did you change your shell
prompt?
kai
--
~/.signature: No such file or directory
[EMAIL PROTECTED] (Mark A. Hershberger) writes:
[...] If you are going to just do sudo -u user bash, then you
really shouldn't need to worry about the authentication
timeout.[...]
Good.
Hmm... Well, if there is that much need for `cd', then let's avoid the
second form for now.
`cd' is
Paul Stevenson [EMAIL PROTECTED] writes:
I've had this too. Presumably it's the `find' in
rcp-check-ls-commands. The `find' seems to come from cl, so perhaps there
is a missing (require 'cl) somewhere. (although it would appear to be
there right at the top of rcp.el - i did type 'make' after
Daniel Pittman [EMAIL PROTECTED] writes:
For me, adding the '-1' switch to the two ls(1) calls in the mentioned
function fixed the problem and file name completion works again. I don't
know if this is portable to any ls but the GNU one however and so have
not supplied a patch.
All the ls
David Whitfield Morriss [EMAIL PROTECTED] writes:
Not really sure. The el loads, but doesn't seem to work.
Well, what are you trying to do and what happens when you do that?
What happens when you do M-x load-library RET rcp RET? What happens
when you do C-x C-f /r@ssh:user@host:/path/to/file
Edward J. Sabol [EMAIL PROTECTED] writes:
[...] (To be honest, I feel that's too many. I'm nostalgic for the
old days when rcp.el only supported rcp and scp.) [...]
Yes, yes, you're right. I wish I had a dwim command which just worked
:-( Or else, maybe a way to try out different
"Tom Roche" [EMAIL PROTECTED] writes:
The root of this problem seems not to be '/' :-) Rather, as the former
thread title suggests, getting rcp.el to work around ange-ftp and EFS.
Would it instead be possible to work _with_ them? Given our magic
cookie
AFAIK, rcp.el works fine together
This version tries to provide better error reporting if `rcp' or `scp'
need to be called. Note that this doesn't fix any bug, it just tries
to provide better error messages.
Does this help those of you with troubles to diagnose the problem?
kai
--
This gubblick contains many nonsklarkish
Mark A. Hershberger [EMAIL PROTECTED] writes:
Using the sm method, when I type my password incorrectly, rcp.el fails
to identify this as the problem.
Instead of finding the error (as ange-ftp does) and displaying it in
the minibuffer, rcp.el times out and says "Couldn't find remote shell
Right now, I have code like this:
(setq found (re-search-forward "\\(foo\\)\\|\\(bar\\)"))
(unless found (error ...))
(when (match-string 2)
;; found bar
)
Of course, this fails badly if foo contains any \\(...\\) pairs.
So, what's the best way to do this? Count the number of \\(...\\)
Gregory Stark [EMAIL PROTECTED] writes:
rcp-handle-shell-command("date" nil nil)
Recently, shell-command seems to have aquired an optional third
argument which I hadn't known anything about. I can't see a way to
implement this, right away. But now the code at least emits a helpful
message
Paul Stevenson [EMAIL PROTECTED] writes:
unknown mode: -echo
I have now redirected stdout and stderr of the `stty -echo' command to
/dev/null. This is untested! New version in CVS.
kai
--
~/.signature: No such file or directory
Pete Forman [EMAIL PROTECTED] writes:
Kai Großjohann writes:
Pete Forman [EMAIL PROTECTED] writes:
Most versons of ls work for me, but I do have an older machine
running ISC 4.0 (Interactive Unix) which does not handle -1. How
much of a problem is it to parse the results
It seems that www.mail-archive.com was finally able to set up the
mailing list archive. I have just sent all previous messages there.
I don't know how long it will take them to archive the stuff, but when
they are finished, it will be searchable and all. Hurray!
So, implementing the Win32 and
[EMAIL PROTECTED] (Kai Großjohann) writes:
Sadly, the life of rcp.el is not so simple.
I think I might have been overly protective and defensive when
replying to your message, Dale. Now that I've thought about it, `hard
to implement' is a pretty lame excuse. Please do not refrain from
Matthew Swift [EMAIL PROTECTED] writes:
[...] the minibuffer will claim that the copy is successfully made,
but it will not be made. (Yes, I know that better error-catching is
already on the the todo list.) [...]
Thanks for your bug report. I _like_ bug reports with patch included
:-)
As
David Barr [EMAIL PROTECTED] writes:
[...] And even if I install it myself, I can't get it to work with
rcp.el because of the PATH issue which I described earlier. [...]
*blank look*
Que?
What PATH issue? Doesn't it work to add directories to
rcp-remote-path? rcp.el should add them to
Matt Swift [EMAIL PROTECTED] writes:
[...] (I'm assuming rcp caches passwords, as ange-ftp does, but I'm
not positive -- I'm sure someone will correct me if I'm wrong.)
[...]
There is no passwd caching I know of. I'm not sure if that makes the
passwd disappear from memory immediately,
Pete Forman [EMAIL PROTECTED] writes:
New in rcp.el 1.180 (since 1.130) is use of the function
with-timeout. That is not present on my XEmacs 20.3. There appears
to be an emulation of it in startup.el.
I don't have access to that XEmacs version. Hm. Or maybe I can find
that version
Matt Swift [EMAIL PROTECTED] writes:
I have redefined `make-backup-file' from the default of Emacs 20.4 so
that, when working with a remote file with rcp, the backup file is on
my local machine. This presently causes an error from rcp in the case
that you open a remote file F, alter it, and
Mark A. Hershberger [EMAIL PROTECTED] writes:
Barfs for me.
So, this is working as it should? Good.
Now, all I need to do is figure out which file to modify so that I can
get the mimencode or uuencode in my path.
There is a variable rcp-remote-path. Don't worry about putting
directories
Daniel Pittman [EMAIL PROTECTED] writes:
This would also make the transport of, say, a 2GB file far more pleasing
(if anyone really wanted to do something so silly with RCP :)
This may work in some cases but not in all cases. For one thing, the
logical place to put the local tmp copy is /tmp
In rcp.el, the following is sent to the shell:
,-
| PS1='
| /
| '
`-
Yes, the first line ends with "'" and the last line consists of only
one character. This is supposed to put two newlines into the prompt.
Does the above work for you? Which one of the following alternatives
Jeffrey Juliano [EMAIL PROTECTED] writes:
(setq f "/r@scp:juliano@capefear:.emacs")
"/r@scp:juliano@capefear:.emacs"
(file-name-directory f) ; why is "scp:" both here
"/r@scp:"
(file-name-nondirectory f) ; and here?
"r@scp:juliano@capefear:.emacs"
Daniel has some good
David Forrest [EMAIL PROTECTED] writes:
I'm tring the newer versions now, and have not been getting connections
any more. It does start up the remote shell, but fails to recognize it.
From looking at your transcript, I see two possibilities. (1) rcp.el
uses shell-prompt-pattern to
I've been thinking about default login names. Right now, deep down in
the bowels of rcp.el, every file name with a missing login name is
rewritten to put in the local user name instead.
I was thinking of allowing nil as user name everywhere, with the
semantics that the user name is then not
Mark A. Hershberger [EMAIL PROTECTED] writes:
Daniel Pittman [EMAIL PROTECTED] writes:
Do you have enough elisp to breakpoint in 'rcp-open-connection-rlogin'
and single-step the code to see where it is losing it?
If you can give me a pointer, I will.
I suggest putting point in the
"Spencer L. Swift" [EMAIL PROTECTED] writes:
Can someone please help me debug my login problem using the latest
version of rcp.el (1.254) under FSF emacs 20.6?
I'm not sure what's wrong, but I'm beginning to think that I should
have sent `stty -onlcr -echo' first, and then the other commands.
Francesco suggested WIBNI remote shells executed via M-x rlogin or M-x
telnet or M-x ssh or something would do remote directory tracking, so
that doing C-x C-f in the shell buffer automatically uses rcp.el to
load the file?
I'm afraid I almost never use any of the alternatives to start a
remote
Jeffrey Juliano [EMAIL PROTECTED] writes:
... thanks ... this email is kind of long. I did a little poking in
fileio.c and did some testes. I describe as far as I got, including an
excerpt of fileio.c that may be part of the problem, and my test showing
why I think so.
Hm. I saw a
[EMAIL PROTECTED] (Mark A. Hershberger) writes:
I just began using rcp.el a few days ago and I like where this is
headed.
A problem, though:
When I want open the following file,
/r@slm:user_other_than_me@other_machine:/file/there
I can see that rcp.el has logged me in, but it
-
Date: Sat, 09 Oct 1999 20:55:51 -0400
From: Jeffrey Juliano [EMAIL PROTECTED]
To: Kai =?iso-8859-1?Q?Gro=DFjohann?= [EMAIL PROTECTED]
Subject: Re: rcp.el questions
Message-ID: [EMAIL PROTECTED]
References: [EMAIL PROTECTED] [EMAIL PROTECTED]
Content-Type: text/plain; charset
[EMAIL PROTECTED] (Mark A. Hershberger) writes:
Are you saying that the sed will eliminate all the '/etc/' in the path?
Not so. At least when I tried it.
Right. It will only eliminate the first one. Hm. Hm
It _could_ work.
Sorry for the line-noise.
If I were to add code to
Erik Arneson [EMAIL PROTECTED] writes:
I think I see what's happening now. The PATH is being emptied, and
`test' therefore isn't found. It is located in /bin/ on that machine,
and isn't built into the shell. Could that be the problem?
Oh, my. Hm. I empty $PATH in order to get more
"Stefan Monnier" [EMAIL PROTECTED] writes:
[...] It would probably be good to detect those situations and
COMPLAIN LOUDLY,[...]
I hope that rcp.el beeps and says `couldn't find shell prompt' or
something like this, which I hope is a good error message. Does this
happen?
I'll try to put it
Here are the changes:
revision 1.208
date: 1999/11/13 12:57:58; author: grossjoh; state: Exp; lines: +4 -2
rcp-open-connection-setup-interactive-shell: Turn off bash history, if
appropriate.
revision 1.207
date: 1999/11/13 12:51:46; author: grossjoh;
I think that something needs to be done about the end-of-line
convention of the *rcp/foo* buffers. Right now, I try to just send
`stty -onlcr -echo' to the remote end and hope that this is doing the
right thing. But it isn't. So.
How about this: after I see the first shell prompt, I erase the
DE WEERD, Mario [EMAIL PROTECTED] writes:
- When I restart emacs, rcp files are not reloaded (of course, to save
startup time with slow connections);
Are you saying they are not reloaded but you expected them to be? Or
are you saying that they are reloaded but should not be?
Are you using a
Paul Stevenson [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Kai Großjohann) writes:
Kai Großjohann [EMAIL PROTECTED] writes:
I connect to the remote machine using some method. I then have to
wait for the remote shell to come up before doing anything. How do I
do
revision 1.154
date: 1999/10/06 15:21:19; author: grossjoh; state: Exp; lines: +42 -42
Dave Love [EMAIL PROTECTED]: Only require cl when compiling. Move
`provide' to end. Minor doc and message fixes.
Thanks, Dave!
ftp://ls6-ftp.cs.uni-dortmund.de/pub/src/emacs/rcp.el
kai
--
Life
"Tom Roche" [EMAIL PROTECTED] writes:
[...] It'd be nice if the user could specify (perhaps even by
server) a sequence of preferred transports. E.g. for ssh.ncsu.edu I
want only to transfer via scp; for ftp.ncs.ncsu.edu I want to
transfer via scp but will transfer via ftp if that fails; for
[EMAIL PROTECTED] (Mark A. Hershberger) writes:
It would also be very useful to have a `sudo' method availible and
would probably be very similar to the `su' methods.
I have never used sudo. I know that it can be used to restrict which
commands can be executed as root by another user, but
[EMAIL PROTECTED] (Kai Großjohann) writes:
It turns out that rcp.el was choosing the wrong process coding
system. This leads me to thinking that I should do something about
this.
I have now changed rcp-open-connection-setup-interactive-shell to
issue the `stty -nonlcr -echo' first thing
I found the bug where end-of-file was being signalled. For an
rcp-send-command, the corresponding rcp-wait-for-output was missing.
This seems to be a problem with the current implementation: if the
rcp-wait-for-output is missing, you don't (easily) see what's wrong.
It took me _quite_ some time
DI Maximilian Renkin [EMAIL PROTECTED] writes:
Who could send me working base64-encode-region, base64-decode-region
functions?
They are part of Emacs 20.4 (C implementations), but Lisp
implementations come with Pterodactyl Gnus.
kai
--
This gubblick contains many nonsklarkish English
David Barr [EMAIL PROTECTED] writes:
Although if Kai can get uuencoding working right, I could just use the
"su" method and not use scp at all.
I have been using the sm method with much success. So, if you have
mimencode installed on your remote machines... Have you?
kai
--
Life is hard
[EMAIL PROTECTED] (Mark A. Hershberger) writes:
sudo ls -lda /etc/im* | sed 's,/etc/,,'
mkdir -p '/etc/image/etc/image/ /etc/image/etc/foo'
Hm. Maybe requiring rcp.el to cope with that space is not necessary.
But I think such path names really do occur. For example, pkg_add'ing
a Solaris
Daniel Pittman [EMAIL PROTECTED] writes:
(let ((tries 5))
(while tries
(rcp-send-command "echo rcp-unique-string")
(rcp-wait-for-output 5)
(if (not (string-match (regexp-quote "rcp-unique-string")
(buffer-substring (point-min) (point-max
Maybe I should try to make copying and renaming files work across
machine boundaries. Do you also think so? It seems that people have
problems with backups and/or autosave files, so another alternative
would be to try to correct that, rather than trying to make copying
and renaming more
Hannu Koivisto has suggested that I implement an abbreviation feature
so that you can say /r:x:/path/to/file rather than
/r@scp:user@host:/path/to/file, for example.
What do you think? What's a good way to do this? Maybe Emacs already
provides a standard feature for this kind of thing? Can we
[EMAIL PROTECTED] (Kai Großjohann) writes:
Maybe I should try to make copying and renaming files work across
machine boundaries.
I have now tried to do so. If using an inline method, the file
transfer is through a buffer (without a local tmp file). Please have
a look at the code (rcp-do
Andi Hechtbauer [EMAIL PROTECTED] writes:
Not "undefined" as I worngly stated above, but rather:
(wrong-type-argument stringp nil)
It seems to happen iff the file's in Version Control (cvs here),
and not all of the time.
I have now incorporated a change which should allow you to edit a
Mark A. Hershberger [EMAIL PROTECTED] writes:
I get the following message when I do 'M-x ansi-term [RET]' in a dired
that I loaded using rcp.el:
Process *ansi-term* exited abnormally with code 2
Maybe call-process fails when run in an rcp buffer?
*looking*
Yes, it calls
The rcp-like methods didn't work, because saving didn't work. Maybe
this is now corrected. Could those of you who had problems with the
`scp' method please try again with this version? Mark, does ansi-term
work in this version?
ftp://ls6-ftp.cs.uni-dortmund.de/pub/src/emacs/rcp.tar.gz
kai
--
James H. Cloos Jr. [EMAIL PROTECTED] writes:
perl -e 'print getpwnam("username")."\n"'
Well, I'm all for doing it right. But given the fact that ange-ftp
just returns -1 as user and group id and further given that the user
and group id aren't really used (except by VC), I don't think
DI Maximilian Renkin [EMAIL PROTECTED] writes:
In no of messages/debug/... buffers appear enlightning messages
Hm. What is the content of the corresponding *rcp/foo* buffer? Also,
set rcp-debug-buffer to t, then repeat the error, then mail me the
contents of the corresponding *debug rcp/foo*
revision 1.130
date: 1999/08/04 16:28:10; author: grossjoh; state: Exp; lines: +2 -1
Matthias Koeppe [EMAIL PROTECTED]:
dired-may-insert-subdir wouldn't work because subdir wasn't
indented correctly because point and mark were exchanged
As usual, available from
Barring any bugs, this version can do remote renaming.
ftp://ls6-ftp.cs.uni-dortmund.de/pub/src/emacs/rcp.tar.gz
(Btw, the rcp-src tarball is still kept up to date.)
kai
--
Life is hard and then you die.
"Tom Roche" [EMAIL PROTECTED] writes:
Why is it that inline transfers can prompt for a password, but
out-of-band transfers can't? ange-ftp prompts for a password without
difficulty.
The FSF doesn't like ssh very much. So I concentrated on getting
rcp.el to work with rcp rather than scp.
[EMAIL PROTECTED] (Mark A. Hershberger) writes:
$ ls -l test*
-rw-r--r-- 1 mah mah0 Mar 30 17:16 test
-rw-r--r-- 1 root wheel 0 Mar 30 17:16 test~
[in emacs] C-x C-f /r@scp:everybody.org:test RET
[in emacs] test
[in emacs] C-x C-s
*** Wait ***
[in emacs] C-g
Thanks to Daniel, you can now use M-x rcp-bug RET to submit a bug
report.
ftp://ls6-ftp.cs.uni-dortmund.de/pub/src/emacs/rcp.tar.gz
kai
--
A large number of young women don't trust men with beards. (BFBS Radio)
[EMAIL PROTECTED] (Mark A. Hershberger) writes:
"KG" == Kai Großjohann [EMAIL PROTECTED] writes:
KG Can you try to eval (insert-file-contents
KG "/r:mumble@frotz:/foo") and see if that delay occurs there,
KG too? Does it occur with rcp-handle-insert-f
Pete Forman [EMAIL PROTECTED] writes:
Yup, that works. "(read buf)" becomes "(read (current-buffer))" in my
version 1.130 of rcp.el.
I have now applied the code given by Stefan.
kai
--
Life is hard and then you die.
Yuji Yamano [EMAIL PROTECTED] writes:
The line "TERM = (kterm)" is output of tset command. tset prints it
and wait for entering the terminal type.
Hm. Can you change your shell init such that it doesn't ask the user
for a term type setting when running under rcp.el?
kai
--
A large number
[EMAIL PROTECTED] (Mark A. Hershberger) writes:
I don't see a "waiting ..." msg with rcp-verbose set to 10.
I have now tried to add more (and hopefully useful) messages.
kai
--
~/.signature: No such file or directory
Jeffrey Juliano [EMAIL PROTECTED] writes:
I think the problem lies in a text/binary mode thing. ssh requires
cygwin be in the mode where it expects not to see ^M's at the end of
lines. ssh (as compiled) doesn't run if you don't put cygwin in this
mode. However, I suspect that emacs is
Daniel Pittman [EMAIL PROTECTED] writes:
In my VC, the only place that actually calls (vc-user-login-name) with a
uid is:
(defun vc-file-owner (file)
;; Return who owns FILE (user name, as a string).
So, rather than spend a lot of effort putting in a hack that will not
work so well
It seems that there are at least two versions of uuencode and uudecode
floating around, which have incompatible invocation syntax.
Encoding on Linux: uuencode foo FILE
Decoding on Linux: uudecode -o - FILE
Encoding on FreeBSD:uuencode FILE
Decoding on FreeBSD:uudecode -p
Have the byte compiler warnings disappeared now? Did I do the right
thing to make them disappear?
Does this work on XEmacs now, or does it still complain that
last-coding-system-used is undefined?
kai
--
I like BOTH kinds of music.
Dale R Worley [EMAIL PROTECTED] writes:
[...] But there is no reason to assume that the "login shell" of
the target host/account *is* a shell. What rcp needs to do is more
like "ssh hostname /bin/sh". [...]
I used to have this, but abandoned it for the following reasons:
(1) The FSF
I have now done the complete switch regarding the communication
mechanism. The function rcp-open-connection-rlogin has been removed,
as its functionality has been incorporated into
rcp-open-connection-rsh.
The function rcp-open-connection-rsh now looks for a password prompt
and asks the user if
Mark A. Hershberger [EMAIL PROTECTED] writes:
--- cut ---
[other_machine:/]# exec /bin/sh
[h:w]$ PS1=''; PS2=''; PS3=''
stty -onlcr -echo
hello
//
--- cut ---
Does it work if you modify rcp.el to say +onlcr rather than -onlcr?
kai
--
Life is hard and then you die.
Martin Pool [EMAIL PROTECTED] writes:
~$ stty -onlcr -echo 1/dev/null 2/dev/null ; unset MAIL ; set +o
history 1/de
v/null 2/dev/null ; PS1='
/
'; PS2=''; PS3=''
I think I know what is happening. Due to `stty -onlcr' not being in
effect yet, PS1 contains "\n\n/\n\n"
Dale R Worley [EMAIL PROTECTED] writes:
The documentation for the entries in rcp-methods seems to be a bit
weak. It does specify what you're specifying, but it doesn't really
tell what will be done once the programs are run.
Thanks for this report. I have written up the following section
Charlie Zender [EMAIL PROTECTED] writes:
Once I have edited the file (small or large), attempts to save
it with C-x s (save-some-buffers) always fail with an error like
Wrong type argument: arrayp, (nil 1 3002 6020 (0 0) (0 0) (0 0) 139 "-rw-r--r--" nil
... . (14926318 -1))
Does it work
Martin Pool [EMAIL PROTECTED] writes:
I would be *so* happy if there was a simpler version that worked for
me. The functionality like remote vc is great, but I haven't been able to
use it for ages.
I think that it is possible to get it to work for you, there is just
(well) some debugging
When looking at a dired buffer, you can type `+' to make a directory.
Normally, the newly-created directory is listed immediately. But in
rcp dired buffers, it shows the name `.' rather than the right
directory name.
Try it: type C-x d to open an rcp dired buffer, then type `+' to
create a new
1 - 100 of 527 matches
Mail list logo
