Ways and means - tool existence question.
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. If there is any platform that does not have a user readable /etc/password file containing uid and username mappings, it would also be useful to know. A quick check at work seemed promising but that does not cover every platform out there... Daniel -- There are no dangerous thoughts; thinking itself is dangerous. -- Hannah Arendt
Re: [PATCH] Performance fix for XEmacs
On 28 Oct 1999, Daniel Pittman [EMAIL PROTECTED] wrote: [...] The attached patch tells XEmacs to use a pipe connection to the ssh subprocess. Damn. Not enough testing. Further playing indicates that this fails on the latest rcp from Kai for ssh(1) but not for the telnet connection I was trying. The problem is that ssh spits out: 'Pseudo-terminal will not be allocated because stdin is not a terminal.' It also seems to invoke a non-login shell if stdin in not a tty. Damn. That is painful. I must see if I can work around that somehow. :( Daniel -- Liberté! Fraternité! Sexualité! -- Graffiti in Paris Métro, 1980s
Re: rcp now as tarball
On 14 Oct 1999, Kai Großjohann [EMAIL PROTECTED] wrote: Daniel Pittman [EMAIL PROTECTED] writes: [... my suggestion ...] Yeah, I also thought about that. Hitting RET every couple of seconds is what I do, after all. But Stefan had an even better suggestion: just start up the shell with its normal shell prompt, then wait for the shell prompt to appear. I think that's the route I'm going to go through. Hmmm. I suppose that a regex matcher for shell prompts would do a reasonable job in most cases and be customizable if someone were odd enough prompt to make it vanish... Currently, you have to use two different methods for ssh, depending on whether ssh requires you to enter a password or not. But I think using the new method, it would be fairly easy to just look whether there is a passwd prompt and then act accordingly. This also seems a rather sensible plan. I don't think I'm going to support the asking-for-a-passwd feature of scp, though. I confess that the EFS passwd cache bothers me somewhat even though they xor the information. It's just not something that I want cached myself... Besides, if someone actually wants it that much, they can solve the problem ;) Daniel -- Where love rules, there is no will to power, and where power predominates,love is lacking. The one is the shadow of the other. -- Carl Jung
Re: Is this a job for rcp.el?
On 02 Nov 1999, Kai Großjohann [EMAIL PROTECTED] wrote: 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, though. How could I do that? Invoke GC? twitch Nope. Worse still, you cannot be sure that the password does not land in swap and all. Getting into these issues is a real PITA, let me tell you. It's probably not worth the effort. EFS (and probably ange-ftp) FWIW xor the password with a regular pattern. It's worth a little but I wouldn't trust it in a real security situation. Daniel -- Life is not all lovely thorns and singing vultures, you know... -- Morticia Addams, _The Addams Family_
Re: EFS and XEmacs
On Tue, 7 Sep 1999, Christopher A. Stewart [EMAIL PROTECTED] wrote: I'm very interested in getting this package working for me.. I'm running Xemacs 21.x. Of course the problem is EFS. Are you running 21.1 or 21.2? I recently sent Kai a set of three patches that let me run, almost perfectly, RCP and EFS together under 21.2. The changes should work for 21.1 as well, but I would like to see them tested a little to be sure. I always get nervous at 'obviously correct' fixes. :) I followed the directions in rcp.el to disable it. It didn't completely do it. I observed that after loading a file with efs-cu is loaded. The file loads fine but trying to save gets an error `last-coding-system-used' value as a variable is void. Someone else who is running a non-MULE XEmacs, I suspect. I don't have MULE and hit that problem. One of the patches fixed it. Also VC is not working. I can still load files using rcp.el. VC does not work here either. I know *why* but the correct fix will take a little effort to make. I will try and get it done soon and submitted to Kai. Dired is trickier and my solution is a little ugly. If you would like to try my hack, I can send it to you. Daniel -- "Do you kids think you're going to live forever?" I shouted at the innocents. "Do you think life is some kind of holiday? You think that one day you'll stop being depressed! You won't ever stop being depressed! No matter how much sex you have!" -- Donald Antri, _New Yorker Magazine_, 21/6/1999
Re: rcp.el 1.80....
On 26 Oct 1999, Kai Großjohann [EMAIL PROTECTED] wrote: Matt Swift [EMAIL PROTECTED] writes: I suggest defining it in a human-readable way and then using `regex-opt' on it to obtain an internal version used by the LISP. Somehow, I doubt that this will lead to any observable win in efficiency... Do you think a user-customizable variable is needed for this prompt? Yes. Despite the profusion of free and common software to be used in this sort of setup, someone will undoubtedly have their own preferred variant with it's own password prompt. :) Daniel -- Let the credulous and the vulgar continue to believe that all mental woes can be cured by a daily application of old Greek myths to their private parts. -- Vladimir Nabokov
Re: Missing with-timeout
On 30 Oct 1999, Kai Großjohann [EMAIL PROTECTED] wrote: 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 somewhere? Lessee... I'm now waiting for XEmacs 20.4 to come up... Right. No `with-timeout' in XEmacs 20. That's unfortunate. Hm. `with-timeout' is a compiled Lisp macro -- loaded from "/usr/local/lib/xemacs/xemacs-packages/lisp/fsf-compat/timer.elc" There *is* a 'with-timeout' in XEmacs 20 (.2 at least), it just requires that the 'fsf-compat' package be installed... Daniel -- The proper function of a critic is to save the tale from the artist who created it. -- D. H. Lawrence
Re: [PATCH] Performance fix for XEmacs
On 28 Oct 1999, Kai Großjohann [EMAIL PROTECTED] wrote: The problem is that ssh spits out: 'Pseudo-terminal will not be allocated because stdin is not a terminal.' It also seems to invoke a non-login shell if stdin in not a tty. Damn. That is painful. I must see if I can work around that somehow. :( Hm. If the shell is interactive, that should be sufficient. But you can say `ssh -t' to work around this. I think this is not going to work for rsh, though. Hm. Actually, 'ssh -t' does not work, nor does '-q' quiet it down. What I get is the equivalent of 'ssh host /bin/sh'. This is annoying. As for rsh, well, I can't test it but suspect that it will actually work right; ssh seems to be being clever here and that causes troubles. If anyone can try rsh with the patch, please do. I would be interested in knowing. Otherwise I will continue to live with scp and two seconds of delay on each file open or save... Daniel -- If you cannot get rid of the family skeleton, you may as well make it dance. -- George Bernard Shaw
Re: [PATCH] Performance fix for XEmacs
On 27 Feb 2000, Kai Großjohann [EMAIL PROTECTED] wrote: 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? Should the pty communication be fixed in XEmacs, or should rcp.el be changed to use pipes? I don't know, because I don't use them at all. I use external scp(1) method, and that's fine. Maybe the time has come to invest some work into making inline methods faster on XEmacs... When I investigated, the issue was not in RCP, it was in XEmacs. Writing a chunk of data to the shell command `cat file' on the local disk was enough to choke it down to ~25K/second after the first ~250K of data. I didn't bug-report this or anything because I was too busy at the time. Daniel -- You call this paradise |Just take my hand girl You call these mountains|Just take my hand girl We call this poverty|I'll take your tears girl We call these hills |Step aside -- Jams Ray and The Performance, _Mountain Voices_
Re: uuencode/uudecode
On 29 Feb 2000, Kai Großjohann [EMAIL PROTECTED] wrote: Pete Forman [EMAIL PROTECTED] writes: FWIW here is a command that will "uudecode" to stdout on AIX. sed '/^begin/d;/^[` ]$/d;/^end/d' | iconv -f uucode -t ISO8859-1 Very good! I have now added this to the documentation for the rcp-methods variable. Thanks Pete! Hm. I think I should be adding this to the Info file, too. Hm. Right now, the info file does not contain stuff like this. Hm. Maybe it would be useful to include a section on adding own methods to the info file. That would seem like a sensible thing to add. Daniel, would you like to write that (with your better English and all) or do you want me to write a draft and then you pound on it until it looks like real English rather than some sort of mock-up? I am happy if you want to draft up something, otherwise I will have a run at it, probably by the end of the weekend. My life is, almost regrettably, rather busy at present.[1] Daniel Footnotes: [1] Almost, because it's all fun that I am having. ;) -- When you stop learning, stop listening, stop looking and asking questions, always new questions, then it is time to die. -- Lillian Smith
Re: Ways and means - tool existence question.
On 10 Oct 1999, Kai Großjohann [EMAIL PROTECTED] wrote: 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 (I think) for the mapping, I will am writing an advice for this function to make it behave sensibly and not try to map uid = name for rcp files. Let 'ls' do all the hard work for us. :) I think this function already uses the uid if it can't find a name. Dang. I shouldn't write mail so early on a Sunday. I expressed myself badly. What I intended to say was that I can (er, have) written a function that makes vc-file-owner parse the output of 'ls -Ldl' to get the login name of the user that owns the file. With this in place there are no calls in VC (or anywhere else for that matter) to 'user-login-name' with a parameter. The only question left is what should 'vc-user-login-name' (with no parameter) return when the current file is accessed by rcp? I think that this should be the login name from the rcp path - that is the same value as a 'co' will set on the working file. I have not yet implemented that path and so will not attach a patch yet. It is still a little while of work to make that finished and I should like to test it somewhat tomorrow. Daniel -- The future is always a fairy land to the young. -- George Augustus Sala
Re: Errors using slm connection
On 19 Oct 1999, Mark A. Hershberger [EMAIL PROTECTED] wrote: Here is what I get from an manually slogging in and executing the commands: --- cut --- [other_machine:/]# exec /bin/sh [h:w]$ PS1=''; PS2=''; PS3='' stty -onlcr -echo hello // --- cut --- Seems to me that it does what is expected (at least manually). Yeah, it is. The '-onclr' stops cr/lf translations from occurring on output, confusing your terminal emulator somewhat. 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 it helps, other_machine is an SGI box running IRIX 6.4; login shell is Bash 1.14.4. Bleh. That *should* work. If you have not, can you '(setq rcp-debug-buffer t)' and then reproduce the problem. That should give a debug buffer for the connection with all the output logged. Does the content of that sync up with what you would expect? Thanks for the speedy help thus far. Sadly, this is about to stop -- I am almost out of ideas (except to walk through the code by hand). No SGI around here to test on either. It's one of the few platforms we don't work on. Daniel -- If the archangel, the dangerous one behind the stars, took just one step down toward us today: the quicker pounding of our hearts would kill us. -- Rilke
[BUG] File name completion in v1.178
I am using (stock): ;; Version: $Id: rcp.el,v 1.178 1999/10/24 17:06:42 kai Exp $ File name completion no longer seems to work. This seems to be caused by ls(1) at the far end (GNU ls from fileutils 3.16) returning several columns of names while 'rcp-handle-file-name-all-completions' expects to see only one. I suspect this is to do with the changes to using an interactive shell for the remote connections -- IIRC GNU ls(1) uses multiple vertical columns if the connection is through a pty but not if it talks to a pipe. 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. Daniel -- They always say time changes things, but you actually have to change them yourself. -- Andy Warhol
Re: Problem with rcp on NT
On Fri, 15 Oct 1999, Jeffrey Juliano [EMAIL PROTECTED] wrote: ... thanks ... this email is kind of long. It's also informative which is useful. :) 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. I think I've uncovered either a bug in NTemacs, or a bug in rcp.el's assumptions. I prefer to believe it's a bug in NTemacs. I suspect that some of the built in handling is, well, wrong. In fact, I think that it's partly the problem of rcp, or rather, that efs and ange-ftp have support in the C while RCP does not. :/ Daniel Pittman wrote: Well, I can't speak for GNU Emacs, but on XEmacs 21.2, the following snippet from 'src/fileio.c' might have the answer to why RCP paths don't work quite right... [...] It looks like the /r: syntax is interpreted as a drive letter rather than as a path by 'expand-file-name' - something that is called by most of the file handling code... well, if I change rcp.el to instead expect /rf: as the prefix, it still fails in the same way. so does /rf@scp: prefix. Darn. That's my quota of clever ideas, mostly. Well, almost. for those that don't know, NT allows paths like the following c:\foo; standared for NT, emacs accepts c:/foo; emacs also accepts this //machine_name/foo; standard for NT, emacs accepts \\machine_name\foo; emacs also accepts this and, it appears, some other form I'm not familiar with. As Kai points out, NTFS file systems also allow streams with the syntax 'file:stream' where '$DATA' is the default stream (which gets written when you open 'file' and anything else you choose to write is legal... The way the strings are parsed in fileio.c doesn't look very robust to extra colons in the string. They are parsed from right-to-left, looking for colon or slash characters. I don't know the utility functions well enough to figure out what happens with rcp-type filenames, but there is a potential for the string to get broken up incorrectly. Mmmm. It seems that even of my XEmacs on Linux there is a bit of lossage with regards to rcp filenames. Results below. so, I did a little test. (setq f "/r@scp:juliano@capefear:.emacs") "/r@scp:juliano@capefear:.emacs" (file-name-directory f) ; why is "scp:" both here "/r@scp:" I get "/", which is just plain *wrong* (file-name-nondirectory f) ; and here? "r@scp:juliano@capefear:.emacs" I get the same, again just wrong. (expand-file-name f) ;; when rcp.el not loaded, ange-ftp asks for password ;; when rcp.el loaded, ssh seg faults This is expected, except the segfault part. That one, I don't know about. Can you run an inferior SSH normally? [... expected NT behavior ...] Not sure exactly why "r@scp:" is in both directory and non-directory, but I believe it after looking at fileio.c. Is this a bug in NT emacs, or incorrect use of file-name-(non)directory? what do you get with xemacs? It gets it wrong. I think, sadly, that the C code for 'file-name-directory' and 'file-name-nondirectory' tries to kludge in support for efs or ange-ftp, which is not the right thing(tm) to do. Even on XEmacs, it gets it wrong for rcp paths. Time to handle those two in Lisp, I fear. :/ The attached patch does so, workably according to my (crude) testing. Please try it and see if it helps you at all. The patch includes updates to the texi documentation which may not apply cleanly. That does not matter, honest. :) diff -ubNr --exclude=*~ --exclude=*.info --exclude=dir /home/daniel/.xemacs/rcp.kai/lisp/rcp.el /home/daniel/.xemacs/rcp/lisp/rcp.el --- /home/daniel/.xemacs/rcp.kai/lisp/rcp.el Wed Oct 13 21:28:30 1999 +++ /home/daniel/.xemacs/rcp/lisp/rcp.el Sat Oct 16 10:27:21 1999 @@ -710,7 +710,9 @@ ;; file-name-directory, file-name-nondirectory, ;; file-name-sans-versions, get-file-buffer. (defconst rcp-file-name-handler-alist - '((file-exists-p . rcp-handle-file-exists-p) + '((file-name-directory . rcp-handle-file-name-directory) +(file-name-nondirectory . rcp-handle-file-name-nondirectory) +(file-exists-p . rcp-handle-file-exists-p) (file-directory-p . rcp-handle-file-directory-p) (file-executable-p . rcp-handle-file-executable-p) (file-accessible-directory-p . rcp-handle-file-accessible-directory-p) @@ -764,6 +766,28 @@ ;;; File Name Handler Functions: +;; Path manipulation functions that grok RCP paths... +(defun rcp-handle-file-name-directory (file) + "Like 'file-name-directory' but aware of RCP files." + ;; everything except the last filename thing is the directory + (let* ((v (rcp-dissect-file-name file)) + (method (rcp-file-name-method v)) + (user (rcp-file-name-user v)) + (host (rcp-file-name-host v)) + (
Re: bug that has annoyed me for a while
On 29 Jan 2000, Gregory Stark [EMAIL PROTECTED] wrote: This happens whenever I try to find-file an rcp file from a buffer where default-directory doesn't exist. I have tried to reproduce this problem and cannot using "$Id: rcp.el,v 1.228 2000/01/26 12:41:51 grossjoh Exp $" under XEmacs 21.2. Daniel -- The proper function of a critic is to save the tale from the artist who created it. -- D. H. Lawrence
Re: rcp.el 1.147: little bug fixes
On 21 Sep 1999, Kai Großjohann [EMAIL PROTECTED] wrote: I tried to do a few bug fixes since 1.143. RCS log enclosed. This version seems to have introduced a pair of bugs for me, possibly related. I now get: Opening connection for danielp@gandalf using scp... Waiting for remote /bin/sh to come up... Waiting for remote /bin/sh to come up...done Remote /bin/sh groks tilde expansion. Good. Wrong type argument: numberp, /root The first time I make a connection here (using scp with SSH 1), but functions correctly the second time. This seems to be related to a problem with the detection of the remote 'ls' command; debugging briefly earlier gave me 'nil -d' commands happening. I will look into this further this evening, I hope. This is Linux (Debian) local and remote. [...] Christopher: what happens when you try VC? As a side note, I believe that I have a fix for VC via RCP, using XEmacs. I need to put some more work into it but should hopefully have a patch real soon now. Francisco: I didn't do anything with regard to dired, but you never know... I presume dired-copy is still broken? As a note, XEmacs 21.2 dired works for copying files, but not for moving them. The trivial fix is to define 'rename-file' for RCP. The implementation is not so easy. I might get a chance to look at this one as well - I would think to base it on the EFS implementation. Finally, thanks again for doing this Kai - it's really made my life much nicer :) Daniel -- The Scots long ago came up with an ancient word for a magic spell that creates an illusion of beauty where no beauty exists. The word is 'glamour'. -- L.M. Boyd
Re: Problem with rcp on NT
On 10 Oct 1999, Kai Großjohann [EMAIL PROTECTED] wrote: Jeffrey uses NT and has a couple of problems with rcp. I wonder why. Apparently, everything after the first colon is chopped off before rcp ever sees the filename. Hm. But this doesn't happen with ange-ftp, so what's wrong? Well, I can't speak for GNU Emacs, but on XEmacs 21.2, the following snippet from 'src/fileio.c' might have the answer to why RCP paths don't work quite right... /* Only recognize colon as part of drive specifier if there is a single alphabetic character preceding the colon (and if the character before the drive letter, if present, is a directory separator); this is to support the remote system syntax used by ange-ftp, and the "po:username" syntax for POP mailboxes. */ It looks like the /r: syntax is interpreted as a drive letter rather than as a path by 'expand-file-name' - something that is called by most of the file handling code... Daniel -- [It's said that hallucinogenic drugs give insight] But just what kind of insight are we talking about here? Are we talking about the Second Law of Thermodynamics? Or are we talking about "Oh wow, like, I finally realized that, deep down inside, I'm me."? -- P.J. O'Rourke
Re: Problem with rcp on NT
On 17 Oct 1999, Kai Großjohann [EMAIL PROTECTED] wrote: I have now applied this patch. This patch will break things unless you also apply my patch from message [EMAIL PROTECTED] - I screwed up in the function 'rcp-handle-file-name-directory' and call 'rcp-make-rcp-file-name' with the user and host parameters swapped. :( Daniel -- Fetters of gold are still fetters, and the softest lining can never make them so easy as liberty. -- Mary Astell, _An Essay in Defence of the Female Sex_ (1696)
Re: Problem with vc-user-login-name
On Fri, 19 Nov 1999, DE WEERD [EMAIL PROTECTED] wrote: In my vc installation the vc-user-login-name advice does not work properly and I use: [... variant hack ...] The above is not very clean but it works since it looks at the file name. I do not remember where filename was defined. In any case, 'file' is not defined in my implementation and the advice returns the local user name. That's odd. You have the same version of the VC package as I do and I could not find a path where 'file was unbound. Can you generate a backtrace of the code when file is not bound and send it to me? Then I can try and fix the advice. Daniel -- Corollary of Finagle's Law (a.k.a. Hanlon's Razor): Never attribute to malice that which can be adequately explained by stupidity.
Re: Can't seem to defeat EFS
On Fri, 29 Oct 1999, Pete Forman [EMAIL PROTECTED] wrote: Daniel Pittman writes: Okay, I've got 1.180 now. The problem remains. Here is another backtrace. I am unable to spot the linkage from expand-file-name to efs-host-type. That's very odd. Can you try, painful as it is, putting a breakpoint in 'rcp-file-name-handler' and step through the code to see where it goes wrong? I'd done that. It is fine. It is not called by the following though. (expand-file-name "/r:morse:.vm") Hmmm. That *should* be called. 'find-file-name-handler' should match the path and return a result. With XEmacs 20.4 I get: (expand-file-name "/r:melancholia:.vm") "/r@scp:daniel@melancholia:/home/daniel/.vm" Something is not right in there at a higher level than RCP then. All I can think of is that for some strange reason the variable 'rcp-file-name-handler-alist' has the wrong value on your system or something. [...] RCP *should* handle both 'find-file' and 'expand-file-name' internally, not calling the file handler stuff at all, I think. expand-file-name is a built-in function. 'find-file-name-handler' should match the rcp handler and pass the request to 'rcp-file-name-handler' which should in turn call 'rcp-handle-expand-file-name'. Daniel -- Every artist knows that he is engaged in an encounter with infinity, and that work done with heart and hand is ultimately worship of life itself. -- Bernard Leach
Re: Problem with filelist generated by vc-directory.
On Mon, 24 Jan 2000, DE WEERD [EMAIL PROTECTED] wrote: After a "list files locked by any user" (C-x v d or vc-directory) I get, when selecting a file: "The directory containing /r@ru:user@host:/foo1/foo2//foo1/foo2/file.foo does not exist." It has the same structure for the files that I tested. Sorry to have taken so long to get back to you on this one. I tried to reproduce this now and cannot duplicate the failure. I am using "$Id: rcp.el,v 1.228 2000/01/26 12:41:51 grossjoh Exp $" in XEmacs 21.2. What Emacs and RCP are you using? Daniel
Re: beginner stumblings
On 08 Jan 2000, Harry Putnam [EMAIL PROTECTED] wrote: Daniel Pittman [EMAIL PROTECTED] writes: On 08 Jan 2000, Harry Putnam [EMAIL PROTECTED] wrote: [...] I want to use ssh scp rsync. Do you want to use scp(1) or rsync(1) to transfer the files? They both do the same thing in the end (rsync is actually no faster, as I understand it) I would like to be able to use either one. Is it really true that rync is no faster? Sorry, I was unclear there. rsync is identical to scp in performance _under rcp only_ because rcp does not cache local copies of files yet (to the best of my knowledge). My experience outside of rcp.el and emacs is that rsync is many times faster, depending on how many files are actually moved etc. Yes. Sorry. I should have been more clear about the context I was talking in. [...] What you want to set is `rcp-default-method', indicating the preferred method from that alist to use. Yes, I understood the list was not to be edited but was talking about choosing methods from it. In your case that would be `scp' to use scp(1) for transfers or `rsync' if you prefer to use rsync to transfer files. So, choosing one or the other would make it the default, but the other would be available if I specify it in the command syntax? Yes. That's correct. [...] Personally, the `scp' method suits me. I run the ssh-agent and that has my identity available to it, allowing me to authenticate to remote machines without a password. So, your choices (presuming that you want ssh security) are: * Use an `inline' transfer method * Use an `out-of-band' transfer method and ssh-agent(1) But according to the comment I can only use `out of band' if I don't have to log in. Something is screwy there. Yeah, the comment is. :) The way that rcp works is that it uses rsh or anything that works in a similar way to log in to the remote machine as a user. It then does a whole bunch of stuff through that directly (file existence, information, that sort of thing). When you want to visit a file in Emacs, rcp copies the file from the remote machine to a local file and inserts the content in a buffer. The reverse is done to save the file. The actual transfer of the files can be done in two ways: * `inline' to the initial login shell (using base64 or uuencode) * `out-of-band' with rcp or a similar program. It's only the rcp (or, in your case, scp) program that needs to be able to connect to the remote machine without a password. Using an inline method only requires the one login and will work with or without a password prompt. I don't want to use any agents at all. I understood rcp.el would allow me to use ssh in emacs including scp. That comment says only if I don't have to log in with a password, but I do, so is rcp.el useless for me then? No. Try the various inline methods for your work. They will operate correctly even when a password is required to log in to the remote machine. The out-of-band methods will /not/ work unless the scp or rsync command can transfer the files without being interactive at all. I never have used ange-ftp like that but like below: /reader@HOST:/path/file or /ftp@HOST:/path/file So what role does the lowercase "r" play ... What goes in METHOD? That might actually be shown better as: /r[@method]:[user@]host:filename What role does the lower case "r" play. Is it another indication of a METHOD? No. The `r' indicates that the file is an rcp file. It has *nothing* to do with the particular method that rcp uses. [...] Started an emacs that has *NO* require ange-ftp or require rcp code Evaled (require 'ange-ftp) then (require 'rcp) [...] Still not clear what the actual syntax is supposed to look like... so trying: /s@scp:reader@HOST:/home/reader/.emacs gives: /r@scp:reader@host:/home/reader/.emacs The `r' is not optional. The `s' in your example above is erroneous. The variable `rcp-file-name-regexp' is a regular expression that *must* match the filename in order for rcp to act on it. [...] If I just want to read the remote .emacs with local emacs using ssh, can I do that with rcp.el? Yes. [...] Having to do some guessing game with the syntax should be made unnecessary by having clear and real examples available somewhere in documentation or comments. Seems that would be a bare minimum. The examples all show the syntax with the `r' in place. If there is one that has `s' anywhere, please post the file and line number (or info section) so that it can be corrected. As to examples, these are filenames that work for me using rcp locally: /r:melancholia:~/.bashrc /r@scp:melancholia:~/.bashrc /r:daniel@melancholia:~/.bashrc /r@sm:melancholia:~/.bashrc /r@sm:melancholia.danann.net:/etc/squid.conf My default method, incidentally, is scp. As I noted, I use the ssh-agent to allow me to log in without a password. Without that I wouldn't be
[PATCH] Performance fix for XEmacs
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. The problem seems to be that when using a pty connection to an asynchronous subprocess, XEmacs 21.2 will write between 250K and 1.2M before performance *dies*. After that length I got about 2K per second. The attached patch tells XEmacs to use a pipe connection to the ssh subprocess. The lispref indicates that pipes are preferred when talking to processes that are not user visible; more efficient and not consuming a potentially limited resource at the cost of preventing job control to child processes. I couldn't find anything in the Emacs-20 texi, but the docstring for 'process-connection-type' was identical. If anyone else out there has had performance problems or would like to test this out, please do so and post some results back. It has had minimal testing here and worked well, but I would hesitate to ask that it join the main sources without better testing on a wide scale. Daniel --- rcp.el~ Tue Oct 26 22:03:36 1999 +++ rcp.el Thu Oct 28 20:12:18 1999 @@ -2171,9 +2171,10 @@ method parameters." (rcp-pre-connection method user host) (rcp-message 7 "Opening connection for %s@%s using %s..." user host method) - (let ((p (start-process (rcp-buffer-name method user host) - (rcp-get-buffer method user host) - (rcp-get-telnet-program method) host)) + (let* ((process-connection-type nil) ; use a pipe [EMAIL PROTECTED] + (p (start-process (rcp-buffer-name method user host) + (rcp-get-buffer method user host) + (rcp-get-telnet-program method) host)) (found nil) (pw nil)) (process-kill-without-query p) @@ -2219,10 +2220,11 @@ method parameters." (rcp-pre-connection method user host) (rcp-message 7 "Opening connection for %s@%s using %s..." user host method) - (let ((p (start-process (rcp-buffer-name method user host) - (rcp-get-buffer method user host) - (rcp-get-rsh-program method) "-l" user host)) -(found nil)) + (let* ((process-connection-type nil) ; use a pipe [EMAIL PROTECTED] + (p (start-process (rcp-buffer-name method user host) + (rcp-get-buffer method user host) + (rcp-get-rsh-program method) "-l" user host)) + (found nil)) (process-kill-without-query p) (setq found (rcp-wait-for-regexp p 10 -- If I knew for a certainty that some man was coming to my house with the conscious intention of doing me good, I would run for my life. -- Henry David Thoreau
[PATCH] Daily changes :) (was Re: rcp.el 1.164: bug fixes)
On 13 Oct 1999, Kai Großjohann [EMAIL PROTECTED]
wrote:
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
installing)
Yes, Dave submitted some patches so that CL isn't required at run
time, but apparently, FIND is not a macro...
Dave? Do you know what to do?
The attached patch replaces the find with a hand-coded bit of Lisp that
returns the first entry in the list that fails '(null (car list))'. That
should remove the dependency on 'find' in 'rcp-check-ls-command'.
It also corrects the error in the texi file that I missed last time. :/
Daniel
diff -ubNr --exclude=*~ --exclude=*.info --exclude=dir /home/daniel/.xemacs/rcp.kai/lisp/rcp.el /home/daniel/.xemacs/rcp/lisp/rcp.el
--- /home/daniel/.xemacs/rcp.kai/lisp/rcp.el Wed Oct 13 21:28:30 1999
+++ /home/daniel/.xemacs/rcp/lisp/rcp.el Thu Oct 14 11:27:35 1999
@@ -2188,14 +2188,15 @@
(defun rcp-check-ls-commands (method user host cmd dirlist)
"Checks whether the given `ls' executable in one of the dirs groks `-n'.
Returns nil if none was found, else the command is returned."
- (find nil
-(mapcar (lambda (x)
+ (let ((cmds (mapcar (lambda (x)
(when (rcp-check-ls-command
method user host
(concat (file-name-as-directory x) cmd))
(concat (file-name-as-directory x) cmd)))
-dirlist)
-:test-not #'equal))
+ dirlist)))
+(while (null (car cmds))
+ (setq cmds (cdr cmds)))
+(car cmds)))
(defun rcp-find-ls-command (method user host)
"Finds an `ls' command which groks the `-n' option, returning nil if failed.
diff -ubNr --exclude=*~ --exclude=*.info --exclude=dir /home/daniel/.xemacs/rcp.kai/texi/rcp.texi /home/daniel/.xemacs/rcp/texi/rcp.texi
--- /home/daniel/.xemacs/rcp.kai/texi/rcp.texi Mon Oct 11 06:06:32 1999
+++ /home/daniel/.xemacs/rcp/texi/rcp.texi Thu Oct 14 11:16:29 1999
@@ -9,7 +9,7 @@
@c NOTE: The 'UPDATED' value is updated by the 'time-stamp' function.
@c If you change it by hand, the modifications will not stay.
@set VERSION 1.155
-@set UPDATED Sunday, 10 October, 1999
+@set UPDATED Thursday, 14 October, 1999
@c Entries for @command{install-info} to use
@direntry
@@ -180,7 +180,7 @@
Usage is also simple: it's just like ange-ftp, but uses a different
syntax for the remote file names. The syntax used is as follows:
-@code{/@@METHOD:USER@@HOST:FILENAME}
+@code{/r@@METHOD:USER@@HOST:FILENAME}
This logs you in as USER to the remote HOST using METHOD, retrieving
FILENAME. The "USER@@" part can be omitted, in this case the current
--
You must be the change you wish to see in the world.
-- Gandhi
[PATCH] Fix rcp-handle-write-region arguments for XEmacs/MULE
When using XEmacs/MULE, the seventh argument to write-region is a coding system to use when writing, not the test `confim-p'. This would cause XEmacs/MULE to prompt every time you wrote a file for confirmation. The attached patch makes this work by ignoring the final argument. Soon I will have a think about how this coding system interacts with the writing of regions; until then I suspect that rcp will break files in any sort of complex encoding. Daniel --- rcp.el~ Mon Jan 10 20:46:20 2000 +++ rcp.el Fri Jan 21 12:43:54 2000 @@ -1518,7 +1518,9 @@ (unless (or (eq lockname nil) (string= lockname filename)) (error "rcp-handle-write-region: LOCKNAME must be nil or equal FILENAME")) - (when (and confirm (file-exists-p filename)) + ;; XEmacs takes a coding system as the sevent argument, not `confirm' + (when (and (not (featurep 'xemacs)) + confirm (file-exists-p filename)) (unless (y-or-n-p (format "File %s exists; overwrite anyway? " filename)) (error "File not overwritten"))) -- The average man doesn't want to be free. He wants to be safe. -- H.L. Mencken
Re: beginner stumblings
On 08 Jan 2000, Harry Putnam [EMAIL PROTECTED] wrote: [...] I want to use ssh scp rsync. Do you want to use scp(1) or rsync(1) to transfer the files? They both do the same thing in the end (rsync is actually no faster, as I understand it) I don't see any "ssh" on the alist and scp appears as scp scp1 scp2. I'm running ssh-1.2.26 so apparently scp2 is not for me, however do I need both scp scp1 I've chosen scp rsync == is this correct? That sounds like the list of supported methods that you have been editing. That one you don't actually need to touch unless you want to add a new method... What you want to set is `rcp-default-method', indicating the preferred method from that alist to use. In your case that would be `scp' to use scp(1) for transfers or `rsync' if you prefer to use rsync to transfer files. Reading the comments: ;; The out-of-band methods require that you can log in to the remote ;; system without having to enter a password. This is because the ;; standard program "rcp" does not query for a password but just fails ;; if entering a password is necessary. This sounds as if I have wasted my time with rcp.el since every machine I want to connect to asks for a password, and apparently scp is an out-of-band method. Yes, it is. When rcp.el connects to a remote machine, it uses ssh(1), rsh(1) or something like that. You can use uuencode or base64 encoding and transfer files directly through that connection (`inline' methods) or you can copy them separately (`out-of-band' methods). Using scp(1) or rsync(1) to transfer the files is out of band (and often faster :) So assuming I've misread something or else the package would be fairly useless to most people. Nope. If you used the rsh(1)/rcp(1) combination, no password, very useful. If you want to use ssh(1) only, you should get passworded at connect time and be able to use the `inline' methods to transfer files. Personally, the `scp' method suits me. I run the ssh-agent and that has my identity available to it, allowing me to authenticate to remote machines without a password. So, your choices (presuming that you want ssh security) are: * Use an `inline' transfer method * Use an `out-of-band' transfer method and ssh-agent(1) Taking these steps to get started: Reading comments: ;; ;; Usage is also simple: it's just like ange-ftp, but uses a different ;; syntax for the remote file names. The syntax used is as follows: ;; ;; /r@METHOD:USER@HOST:FILENAME This claims to be "just" like ange-ftp but looks considerably different to me. That comment is a tad out of date now. It is similar, sort of, to the syntax used for efs.el and ange-ftp.el. I am going to use efs.el from now on (for brevity) but all the comments about it apply equally to ange-ftp.el. I never have used ange-ftp like that but like below: /reader@HOST:/path/file or /ftp@HOST:/path/file So what role does the lowercase "r" play ... What goes in METHOD? That might actually be shown better as: /r[@method]:[user@]host:filename The method and user arguments are optional. If you don't specify a method then the value specified in `rcp-default-method' is used. If you don't specify a user value then your current login name is specified. Explicitly, by the way, so if your .ssh/config specifies the names to use when logging in remotely, they will be ignored.[1] Trying the above syntax like: /s@scp:reader@HOST:/home/reader/.emacs Give me no usefull behaviour at all. Instead I get a silly prompt that askes for a password for "s@scp" Indeed. You have not get the package installed correctly, I fear. This is the most stunningly nonintuitive feature of the package. You must make *certain* that you have done `(require 'ange-ftp)' *before* you load `rcp.el'. Without that the two packages will fight over who controls the paths and you will get the behavior that you see. So, in your .emacs, make sure that you have `(require 'rcp)' /after/ `(require 'ange-ftp)'. Make sure that you *do* have the require for ange-ftp as well... Message buffer shows ange-ftp being loaded instead of rcp: Loading ange-ftp... Loading ange-ftp...done Password for s@scp: Since this is billed as being "simple" apparently I am a dunce. Well, no. The comment is wrong. Well, not strictly wrong, simply using a definition of simple that might be used in the context of `Yeah, climbing that mountain was simple compared to Everest' ;) Further first use notes: The info file looks as if it is designed to become part of info-dir by being catenated into it when the path to rcp texi is given to emacs. Yup. [... info path ...] That is the correct path, but no info page is available at C-h i m rcp RET. Is one expected to hand edit "dir" to get this to display? Or is it supposed to just happen? I guess that emacs does not rebuild out-of-date `dir' files by default. Have a look at the variable `Info-auto-generate-directory' and see what it
Re: Copying or renaming files across machines?
On 21 Nov 1999, Kai Großjohann [EMAIL PROTECTED] wrote: Maybe I should try to make copying and renaming files work across machine boundaries. Do you also think so? Er, yes? 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 general. If I try to implement the operations across machine boundaries, how should I go about it? Probably the easiest and most general solution would be to make a local copy of the original file and to then save the local copy remotely using the new name. Another idea would be to only have the temporary copy in a buffer, rather than on disk. Since the routine will presumably be a low level one (in something like 'rcp-handle-copy-file), it would make sense to me that you only had an on-disk copy. 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 :) All other ideas aren't as general, so I'm not sure whether it is worth to even try. I suspect that it breaks down into two cases, one remote file and two remote files. I would vote for the simple 'through this machine' implementation and letting others solve the complex cases if they need it. :) Daniel -- A wonderful discovery, psychoanalysis. Makes quite simple people feel they're complex. -- S. N. Behrman
Re: [Fwd: Some stuff to improve life while using rcp]
On Fri, 29 Oct 1999, DE WEERD [EMAIL PROTECTED] wrote: Kai Großjohann wrote: DE WEERD, Mario [EMAIL PROTECTED] writes: [...] - When I do a check in, my frame layout is messed up color coding is lost. I just tested this, and 1.182 seems to do this fine. I vaguely recall that a couple of dozen versions ago there was a change to restore the window configuration after a VC checkin. [Checking...] Ah, the fix was from Daniel Pittman, in version 1.148. This is a VC problem I think. I use split windows and stuff. For a check-in, a new window is created to type the message. After finalizing the message (C-c C-c), I used to get one window less. Bother. I just did a quick test here and reproduced the problem. Darn. A quick recipe to validate it: C-x 2 C-x C-f /r:host:file/in/rcs check out edit check in There is only one window :( Darn. OK. It's not the fault of RCP. It's actually a feature(tm) of VC. Try the same thing on a local file and you will see it act the same way. Daniel -- A man can no more diminish God's glory by refusing to worship Him than a lunatic can put out the sun by scribbling the word 'darkness' on the walls of his cell. -- C. S. Lewis, _The problem of pain_
Re: Can I use rcp.el to copy a local file to several hosts ?
On Thu, 3 Feb 2000, Gerd Bavendiek [EMAIL PROTECTED] wrote: I'm working as system admin. Very often I have to change config files on a couple of unix boxes. So I edit a local copy of e.g. /etc/hosts, copy the file to the targets and still have the master on my laptops disk. [...] So it ends up in calling scp. This is by no means really flexible. Sometimes I could use rcp instead of scp, which I couldn't manage to put in this schema. I'm wondering whether rcp.el can be used in this scenario ... Sure could. If you have rcp.el running, you can just call `copy-file' for each place you want it to go, such as: (copy-file "local.file" "/r@scp:host:/remote.file") (copy-file "local.file" "/r@rcp:another.host:/remote.file") That way you take advantage of the rcp support for many protocols when transferring. Adapting this to your lisp is left as an exercise for the reader ;) Daniel -- It may sound strange coming from a research man, but an attempt to get too many facts will often leave you without any real knowledge at all. -- Ernest Dichter
Re: Can't seem to defeat EFS
On Thu, 28 Oct 1999, Jesse Marlin [EMAIL PROTECTED] wrote: I am having trouble preventing EFS from grabbing this: C-x C-f /r:me@host:/home/me/.emacs I have set rcp-default-method to: (setq rcp-default-method '"rcp") I do not specifically load EFS, it just seems to autoload it. Any hints on this. Thanks. jlm Strange, it works just fine here. What version of rcp and XEmacs are you using? Also, if you have the Lisp knowledge, breakpointing in 'efs-ftp-path' should show up where the EFS handlers are getting called from and all. That backtrace might be useful. Daniel -- Every artist knows that he is engaged in an encounter with infinity, and that work done with heart and hand is ultimately worship of life itself. -- Bernard Leach
Re: Remote directory tracking
On 17 Oct 1999, Kai Großjohann [EMAIL PROTECTED] wrote: 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 had a glance at 'rlogin' and found the following: It already does EFS (or ange-ftp) file name tracking by setting 'comint-file-name-prefix' to the right user/machine syntax. Sadly, this is done *after* any user-definable hooks are run. If he wants, Francesco could 'M-x eval-expression (setq comint-file-name-prefix "/r:user@machine:")' in the buffer each time. Fixing this will require a patch to the maintainer, I suspect. :/ Daniel -- Laughter, of course, can be strained, cruel, artificial and merely habitual... But where it is real, laughter is the voice of faith. -- Harvey Cox
Re: beginner stumblings
On 09 Jan 2000, Kai Großjohann [EMAIL PROTECTED] wrote: Daniel Pittman [EMAIL PROTECTED] writes: It's well worth noting, I think, that this software is not ready for the prime time yet. It's still mostly suitable for lisp hackers and all, the rough edges still being, well, rough. Right. I wish it weren't so, but somehow I never know what to do to polish the rough edges :-/ Can you tell me more about what problems you observe, Harry? That might help to improve the documentation, at least. It's probably worth noting that after a long time of being busy (and a little lazy) I am going to get an update to the documentation done soonish. I hope to post an updated texi file with much better `getting started' material real soon now. Daniel -- Love is like Hearts. You want to follow suit, but you don't want to have the lead. -- Dustin Fisher
[BUG] Something isn't right under XEmacs...
My guess is that the coding system isn't right in the buffer. Daniel unset MAIL MAILCHECK MAILPATH 1/dev/null 2/dev/null set +o history 1/dev/null 2/dev/null PS1=' / '; PS2=''; PS3='' $ stty -echo $ $ $ / # Opening connection for danielp@bradbury using scp... # Waiting 60s for shell or passwd prompt from bradbury Last login: Fri May 12 11:49:11 2000 from sockshost.osa.com.au Linux bradbury 2.3.42 #1 SMP Wed Mar 1 16:49:07 EST 2000 i686 unknown Copyright (C) 1993-1999 Software in the Public Interest, and others Most of the programs included with the Debian GNU/Linux system are freely redistributable; the exact distribution terms for each program are described in the individual files in /usr/doc/*/copyright Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. # Initializing remote shell $ exec /bin/sh # Waiting 30s for remote `/bin/sh' to come up... No mail. exec /bin/sh $ exec /bin/sh # Setting up remote shell environment No mail. exec /bin/sh $ exec /bin/sh stty -echo $ PS1=' / '; PS2=''; PS3='' # Waiting for remote `/bin/sh' to come up... unset MAIL MAILCHECK MAILPATH 1/dev/null 2/dev/null set +o history 1/dev/null 2/dev/null PS1=' / '; PS2=''; PS3='' $ stty -echo $ $ $ / [[INCOMPLETE!]]unset MAIL MAILCHECK MAILPATH 1/dev/null 2/dev/null set +o history 1/dev/null 2/dev/null PS1=' / '; PS2=''; PS3='' $ stty -echo $ $ $ / [[INCOMPLETE!]]# Opening connection for danielp@bradbury using scp... # Waiting 60s for shell or passwd prompt from bradbury Last login: Fri May 12 11:49:37 2000 from sockshost.osa.com.au Linux bradbury 2.3.42 #1 SMP Wed Mar 1 16:49:07 EST 2000 i686 unknown Copyright (C) 1993-1999 Software in the Public Interest, and others Most of the programs included with the Debian GNU/Linux system are freely redistributable; the exact distribution terms for each program are described in the individual files in /usr/doc/*/copyright Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. # Initializing remote shell $ exec /bin/sh # Waiting 30s for remote `/bin/sh' to come up... No mail. exec /bin/sh $ exec /bin/sh # Setting up remote shell environment No mail. exec /bin/sh $ exec /bin/sh stty -echo $ PS1=' / '; PS2=''; PS3='' # Waiting for remote `/bin/sh' to come up... unset MAIL MAILCHECK MAILPATH 1/dev/null 2/dev/null set +o history 1/dev/null 2/dev/null PS1=' / '; PS2=''; PS3='' $ stty -echo $ $ $ / [[INCOMPLETE!]]unset MAIL MAILCHECK MAILPATH 1/dev/null 2/dev/null set +o history 1/dev/null 2/dev/null PS1=' / '; PS2=''; PS3='' $ stty -echo $ $ $ / [[INCOMPLETE!]] -- 20+ years as a vegetarian and the guy who steals my credit card orders $6,000 worth of chicken parts: proof that the most powerful force in the universe is Irony. -- David Weinberger, _JOHO_ (2000-03-20)
Re: [BUG] Something isn't right under XEmacs...
On Mon, 15 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: DI Maximilian Renkin [EMAIL PROTECTED] writes: mxrenkin@kastanie:~ # Initializing remote shell $ exec /bin/sh # Waiting 30s for remote `/bin/sh' to come up... exec /bin/sh^M mxrenkin@kastanie:~ # Setting up remote shell environment exec /bin/sh^M mxrenkin@kastanie:~ stty -echo^M # Frobbing coding system Here, it says that it is frobbing the coding system. Could you go to the *rcp/foo* buffer and say M-x describe-coding-system RET RET. Note in particular the `subprocess I/O' section. Apparently, your remote shell sends ^M characters, so after frobbing the coding system, the coding system for decoding subprocess output should be *-dos. Hrm. Kai, it looks like I am seeing some lossage in the detection code for the coding system frobbing here in XEmacs 21.2. I had not a chance to finish chasing it up here, and have no access to test machines right now. :/ Er, the issue looked like a failure to detect the correct line transformation, etc, though. I will investigate further 'til I get rid of the guesswork I have though. Daniel -- I have always detested the belief that sex is the chief bond between man and woman. Friendship is far more human. -- Agnes Smedley
Re: rcp.el, XEmacs and colons
On Mon, 15 May 2000, Pete Forman [EMAIL PROTECTED] wrote: Daniel Pittman writes: Hrm and double hrm. Can you give a simple recipe for reproducing the issue? I had a quick glance in my archives of the list but didn't find anything. (expand-file-name "/r:morse:.vm") A stack trace for the ftp error induced is in a message dated Fri, 29 Oct 1999 11:57:29 +0100. The thread had a subject of "Can't seem to defeat EFS". It worked for you then. Did you (require 'efs) at any stage? Yup. I have used it right up until recently when the coding system stuff started playing up on me. My startup reads like (pretty much at the start of the file): ,[ .emacs ] | ;; Version Control stuff. Bury the hooks deep. | (require 'vc) | | [... various VC mode setup ...] | | ;; EFS gets pulled in *real* early... | (require 'efs) | (setq efs-gateway-type (list 'local "pftp" efs-ftp-program-args)) | | ;; RCP gets pulled in real early too. After EFS though, to make the path matcher |work :) | (require 'rcp) | (setq rcp-default-method "scp" | rcp-verbose 10 | rcp-auto-save-directory (expand-file-name "~/.rcp-save/")) ` This just works(tm) for me, modulo bugs in RCP. It does remote access, VC, the works. Daniel -- The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts. -- Bertrand Russell
Re: rcp.el, XEmacs and colons
On Mon, 15 May 2000, Pete Forman [EMAIL PROTECTED] wrote: Daniel Pittman writes: On Fri, 12 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: Pete says that colons in rcp-file-format don't work for him, whereas Francisco and Daniel say they work fine. What can we do to find out why the colons don't work for Pete? [...] Pete, are you running the Windows version of XEmacs? No. XEmacs 21.1.7 on AIX 4.3.2 and IRIX 6.5.5m, and 20.4 on Solaris 2.6. I have yet to upgrade to XEmacs 21.1.10 but I've just pulled efs.el from cvs.xemacs.org. The overloading code that is giving me grief is still the same. Hrm and double hrm. Can you give a simple recipe for reproducing the issue? I had a quick glance in my archives of the list but didn't find anything. If I can reproduce it, I can probably work out where it is going wrong. I hope. :) Daniel -- Quid sit futurem cras fuge quaerere -- Horace
Re: rcp.el, XEmacs and colons
On Fri, 12 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: Pete says that colons in rcp-file-format don't work for him, whereas Francisco and Daniel say they work fine. What can we do to find out why the colons don't work for Pete? The XEmacs versions used: PeteXEmacs 21.1.7 Fransisco 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Daniel 21.2 (beta32) "Kastor Polydeukes" XEmacs Lucid So maybe this is a problem in 21.1.7 which has been fixed in later releases? Maybe. I know that there is some dangerous code to manage drive letters[1] in some of the C sources. It does all the DWIM things that MS-DOS has one forever, such as 'd:file' = 'd:/current/path/file' and things like that. Er, it /tries/ not to fsck with EFS paths and that sort of thing, but reading the code I think that rcp paths may well trip some of the cases, possibly including the one above... Pete, are you running the Windows version of XEmacs? I am on Linux myself... Daniel Footnotes: [1] In my opinion. OTOH, it's probably vital to have if you actually /want/ to support the stupid things. -- The process we're witnessing now is in fact the capitalist society trying to squeeze out of each person, like blood from a stone, whatever commercial value that person may have. --Marc Rotenberg
[PATCH] Fix connection problems for XEmacs/MULE.
The attached patch makes the connection setup work for me under XEmacs/MULE. Simply put, I presume that the system I am talking to is going to have dos-style line enders, and set the coding system for reading to match that. This shouldn't hurt anything under non-MULE code, being as it binds a variable for the duration of the 'start-process' call. Still, I don't want to commit this without knowing that it at least works for a few people, and I really /don't/ understand how the MULE integration has been done in rcp. Given a little time I will probably get off my backside and try to understand it, then make sure that it gets to be working quite right under XEmacs. Er, hang on... I will have to get /on/ my backside and... ;) Anyway, comments? Daniel Index: rcp.el === RCS file: /services/emacs-rcp/cvsroot/rcp/lisp/rcp.el,v retrieving revision 1.342 diff -u -u -p -r1.342 rcp.el --- rcp.el 2000/05/21 00:03:25 1.342 +++ rcp.el 2000/05/21 10:59:41 @@ -2992,6 +2992,7 @@ must specify the right method in the fil (rcp-pre-connection multi-method method user host) (rcp-message 7 "Opening connection for %s@%s using %s..." user host method) (let* ((default-directory (rcp-temporary-file-directory)) + (coding-system-for-read 'undecided-dos) (p (apply #'start-process (rcp-buffer-name multi-method method user host) (rcp-get-buffer multi-method method user host) -- The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary. -- James D. Nicoll
Re: [PATCH] Fix connection problems for XEmacs/MULE.
On Sun, 21 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: Daniel Pittman [EMAIL PROTECTED] writes: Still, I don't want to commit this without knowing that it at least works for a few people, and I really /don't/ understand how the MULE integration has been done in rcp. Well, that makes two of us... Hrm. In that case, since it seems to be biting me, I might put in some effort to learning how MULE works and implementing it properly for RCP. Assuming you don't object, of course. MULE comes into play in different places, but for the shell buffer, I'm basically hoping that the MULE machinery does everything right automatically. Seems not to, at least for me. It keeps deciding on 'undecided-mac' as the coding system, which is just wrong. [...] [looks into the code] Oops! Where did that `echo foo ; echo bar' go? Surely searching for ^M characters won't work unless there's at least one line ending in the buffer. Will try to change this now -- can you test it to see if it works, Daniel? Er, no. Still fails, in the same way as previously. Darn. Daniel -- He who cannot change the very fabric of his thought will never be able to change reality, and will never, therefore, make any progress. -- Anwaar Sadat
Re: caching of file information?
On Sun, 21 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: "Daniel Pittman" [EMAIL PROTECTED] writes: [[ complicated caching mechanism ]] Is the complicated mechanism really necessary, or can we make do with a fairly simple mechanism which caches information for a short time only? That's an open question. Caching information over a single operation would give a big improvement to the performance of the code. The real question is if EFS[1] is right, and that remote file system performance[2] is sufficient without long-term caching of the information. EFS does keep information a long time - forever, so far as I can see. This makes the access to the remote filesystem high performance, but their implementation can be a *real* pain sometimes, if the cache is out of date. The model I outlined would help with that cache validity problem, at the cost of some local processing. For me, personally, I so very rarely edit files over slow links that the problem is moot; I can wait the two seconds when opening a new file. I guess that the best plan is to implement the simple cache and, if that isn't good enough, implement the more complex one. Daniel Footnotes: [1] I havn't used Ange-FTP, but presume that it has the same core model... [2] with these tools... -- What is a poet? A poet is an unhappy being whose heart is torn by secret sufferings, but whose lips are so strangely formed that when the sighs and cries escape them, they sound like beautiful music. -- Søren Kierkegaard, _Either/Or_ (1843)
Re: Emacs 19
On Wed, 24 May 2000, Yuji Yamano [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Kai Großjohann) writes: Hm. I don't know if rcp.el works with Emacs 19. Hm. I did stuff so that it works without MULE, but that's for XEmacs. rcp.el doesn't work with Emacs 19/MULE 2.3. I stole some lisp function from Emacs 20.x for making it work, but I couldn't take built-in function (the function name escapes from me). What are the missing/non-working functions? If you could send the list of issues, etc, to the list, that would possibly help in getting the support rolled into the distribution. Sending patches is, of course, more than welcome. :) Daniel -- Paperwork is the embalming fluid of bureaucracy, maintaining an appearance of life where none exists. -- Robert J. Meltzer
Re: configuration problem
On Wed, 24 May 2000, Tom Roche [EMAIL PROTECTED] wrote: Kai Großjohann [EMAIL PROTECTED] 5/24/00 7:28:28 AM But why doesn't it see the shell prompt? Hm. The shell prompt seems to be correct: newline followed by the slashes, followed by another newline. Kai Großjohann [EMAIL PROTECTED] 5/24/00 9:27:18 AM Did the last fix to rcp.el fix your problem, Tom? Joe Stoy [EMAIL PROTECTED] 5/24/00 4:44:19 PM You'll have to penetrate the ysteries of cvs (the details adequately described in the initial comments of rcp.el). After self-applying a dope slap for expecting to find such information in the .info (and making mental note to rectify), rcp-version now says It's on my list of things to do this evening. It should be there, er, soon. Daniel -- Reality is a collective hunch. -- Jane Wagner
Re: $Id: rcp.el,v 1.325 2000/05/15 19:49:53 grossjoh Exp $
On Wed, 24 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: Pete Forman [EMAIL PROTECTED] writes: rcp.el works now if I change "exec " to "PS1='$ '; exec " in rcp-find-shell. I guess that rcp-open-connection-setup-interactive-shell will need the same change. I have now changed rcp-find-shell. I think rcp-open-connection-setup-interactive-shell does not need to be changed. So, does it work? I think that Daniel and Tom had the same problem... Daniel? Tom? Nope. My only problem, to date, is that with my XEmacs, the EOL-conversion for the process is guessed wrong. FWIW, I have fixed this by setting the right EOL conversion by brute force, and am thinking about what the right fix is. Probably, I think, to set the eol type as an attribute of the connection type. NB: Kai, the Emacs LISP reference specifically states that automatic coding system detection for asynchronous subprocesses is, er, unreliable. It claims that the detection is done on each chunk of the input, which may not be reliable... Daniel -- They [men] work those suits, don't they? It's not about the suit making the man, it's about how the man is filling out the suit. -- Lisa Jones, _Bulletproof Diva_
Re: rcp.el name change?
On Wed, 24 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: Every now and then, the subject of name change comes up. Possibilities that I can think of: [...] * tramp: Transparent RAMP. Kudos to Pete Forman again. Pro: even better description of abilities. Con: potentially bad connotations of `tramp'? This works for me. Er, and it's a name for a software product. I really don't think that people[1] are really going to see it as more than a clever joke. After all, several more questionable names[2] are in common use. [...] Daniel Footnotes: [1] For 'people,' read 'EMACS users' througout. [2] LaTeX, for example, is most often pronounced in, er, questionable tones.[3] [3] Well, maybe it's just the people I know... ;) -- Reality is a collective hunch. -- Jane Wagner
Re: barebones webpage?
On Wed, 24 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Kai Großjohann) writes: Instead, I am pointing to an HTML version of the RCP manual. Do you feel that this is sufficient (if the RCP manual is changed to include the interesting information near the top), or do we need an extra Web page? That looks good to me. The introductory section should be, well, introductory - and that's all the web page really needs to do. Well, at least, that's all the first few inches need to do. ;) Daniel -- A tranquil city of good laws, fine architecture, and clean streets is like a classroom of obedient dullards, or a field of gelded bulls -- whereas a city of anarchy is a city of promise. -- Mark Helprin
Re: barebones webpage?
On Thu, 25 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: "Daniel Pittman" [EMAIL PROTECTED] writes: On Wed, 24 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: What should rcp-handle-file-newer-than-file-p do if it is not possible to return the right information? Fall back politely to the current implementation, I think. The current implementation calls `error', which is less than polite... Oh. Um, wasn't this the function that was subject to discussion of is 'test -nt' suitable? I didn't check that the code was written and all, just assumed. Um, it could hardly do worse than 'error,' I guess. :) But I can't think of a good solution to the issue of what happens when we cannot actually do the test, except to throw an error. :/ Daniel -- A society is in dire straits when it puts its Bohemia in power. -- Bruce Sterling
[RFC] Splitting VC interface for RCP to a distinct file.
It seems to me, on consideration, that the VC integration of RCP could very well be split out into a separate file from the main body of the code, and automatically loaded if/when VC is. This makes sense to me because, aside from anything else, it seems awfully rude to (require 'vc) at the top of the file. So, are there any objections[1] to my doing this? If not, I intend to do it tomorrow evening at about this time... Daniel Footnotes: [1] I have a patch that will be irritated by it counts... -- Every man who knows how to read has it in his power to magnify himself, to multiply the ways in which he exists, to make his life full, significant and interesting. -- Aldous Huxley
Re: $Id: rcp.el,v 1.325 2000/05/15 19:49:53 grossjoh Exp $
On Thu, 25 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: "Daniel Pittman" [EMAIL PROTECTED] writes: NB: Kai, the Emacs LISP reference specifically states that automatic coding system detection for asynchronous subprocesses is, er, unreliable. It claims that the detection is done on each chunk of the input, which may not be reliable... Whee. Hm. Maybe the following will work: as soon as possible, I send a couple of commands to the remote end which produce output. Then I tell Emacs to guess the coding system from the output thus produced, and then that coding system will be used. Only, what kind of command should be used for the output? `ls -l' comes to mind, but we're setting LANG to C, so we don't get local dates... I think that what we really need is to get the coding system used for filenames. I don't really know the LANG stuff thought. 'ls' should produce, like, a list in the local coding system for filenames, yes? Daniel -- A silly remark can be made in Latin as well as in Spanish. -- Cervantes, _The Dialogue of the Dogs_, 1613
Re: barebones webpage?
On Fri, 26 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: "Daniel Pittman" [EMAIL PROTECTED] writes: On Fri, 26 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: I think that if you signal a continuable error, that would be best. At least it's semi-obvious that something went wrong and all. Well, I've got to read up on continuable errors, then. Is `file-error' a continuable error? Hmmm. Yes, in a quick browse through my XEmacs elisp. Raised by using 'signal.' (The code for using Perl to get the mtime of the file is not written yet.) Er... It weighs in at around 380 bytes though, which is kind of heavyweight to ship every time we want to stat a file. That's a full implementation of 'file-attributes' though, 'cept for processing the mode into a string. I wonder if it might be useful to do this at shell-setup time? When the remote shell starts up, rcp.el finds out if there's a Perl. If there is, it could create a function on the remote end which runs Perl with the right arguments. Ah, now *there* is a good idea. I must remember that. I can assume Bourne shell characteristics, can't I? Hrm... does it ever select csh(1) or it's descendants? In any case, I think that using CPIO is a better plan than using Perl, and I will have a look at using that some time this weekend, I hope. Unless you are? Daniel -- I believe it is a form of decadence merely to be shocking. Shock works on the nerves and not on the intellect and any idea which has to rely on pulling at the nervous system is decadent. -- Peter Ustinov
Re: detect process coding system
On Fri, 26 May 2000, Pete Forman [EMAIL PROTECTED] wrote: Kai Großjohann writes: Pete Forman [EMAIL PROTECTED] writes: I thought we were trying to cut down on traffic. Wouldn't something like "echo foo; echo bar" be adequate. The idea is that `ls -l /' will produce date values in the local format of the remote host. `echo foo; echo bar' just produces ascii characters. [...] Again I'm unsure as to whether you're looking for date or EOL conventions. I don't use MULE. Right. This is a niceness for those who do: what we want is to guess (or, rather, intuit) the correct coding system for remote file names. That way when a user enters a file name into Emacs (where it is iso-2022 encoded), it gets translated to the right encoding on the remote machine (which may be shift-jis, koi8-r, utf-8 or some other strange and wonderful encoding). Without doing this, you will get very odd results when you try to open files and the like. Er, have I made it clearer what is being tried here? Daniel -- It's disconcerting to realize how little you have to say to someone who once occupied such a prominent place in your bed. -- Sue Grafton
Re: barebones webpage?
On Fri, 26 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: "Daniel Pittman" [EMAIL PROTECTED] writes: On Fri, 26 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: Well, I've got to read up on continuable errors, then. Is `file-error' a continuable error? Hmmm. Yes, in a quick browse through my XEmacs elisp. Raised by using 'signal.' Good. Let's change that call from error to signal, then. That will make us work like the internal bits. Do you want to do this? [...] Things will break in horrible ways if rcp.el ever starts a csh-like shell. Nonono. Down that path lies madness. You may assume Bourne-ish shells. Oh, good. Because I don't intend to learn csh syntax if I can avoid it. In any case, I think that using CPIO is a better plan than using Perl, and I will have a look at using that some time this weekend, I hope. Unless you are? My weekend is rather full already, so don't hesitate to do stuff. Cool. I now get to hack all weekend because I am a boring sod with no life. ;) Daniel -- To limit the press is to insult the nation; to prohibit reading of certain books is to declare the inhabitants to be either fools or slaves. -- Claud Adrian Helvetius, _De l'Esprit_ (1758)
Re: detect process coding system
On Fri, 26 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: Pete Forman [EMAIL PROTECTED] writes: Again I'm unsure as to whether you're looking for date or EOL conventions. I don't use MULE. I wish I was sure. I think I'm confused by the whole thing. I know that we need to grok EOL conventions, but do we need to know about the rest of the stuff? After all, I have tried to make it so that most output from the remote end will be ascii. Except for the file names. Hm. Yup. Those are the bit that count. We don't want to create iso-2022 files on a utf-8 system, or whatever. Nor do we want to present the shift-jis encoded data to the user for filename completion. OTOH, I fear that this will remain an incomplete solution until someone from a non iso-8859-1 world hacks on the codebase. I intend to sit down this weekend and have a bit of a study of the EFS codebase and see how that works with MULE though. That may shed some light on it. Daniel -- The good thing about standards is that there are so many to choose from. -- Andrew S. Tanenbaum
Re: detect process coding system
On Fri, 26 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: Do you think it would make sense to have a look at /etc/motd? That could shed some light on the coding used. Though I'm not sure if there are places where the coding for file _names_ is normally different from the coding for file _contents_. WinNT, where I work during the day, is such a place. Filenames are natively UTF-16 encoded Unicode data, while the files are a mixture of cp-1252, iso-8859-1 and utf-8. Maybe Yuji has some information on this? I think so. Either that or I learn a lot from the EFS source, or someone advises us. Otherwise I think that it will end up being a waste of time to try anything unless we really understand it. If no one can say that they actually *do* grok the MULE magic, I will put a note in the texi and all, and we can just hope it works outside of 8859-1... Daniel -- I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use. -- Galileo Galilei
Re: barebones webpage?
On Sat, 27 May 2000, Yuji Yamano [EMAIL PROTECTED] wrote: [...] Thanks. Could you add rcsid ($Id$) to rcp.texi? I believe it is useful to sync the Japanese version with the English one. It's done already. :) Daniel -- Bad science and bad religion simply swap roles, the former proclaiming Truth, the latter worshiping Doubt. -- Jeffrey Satinover
[RFC] [PATCH] Implement `file-attributes' with perl(1)
Attached is a patch that implements the `file-attributes' command on a
remote machine using the perl(1) executable, if it was found.
It should fall back to the ls(1) implementation if there is not a useful
perl on the remote machine, although that part is not really tested.
I don't want to drop this into the main source tree without some comment
though. There are several good points to it:
* Get group and user name on any machine with perl.
* Get the [cma]time of the file.
* Very simple lisp for `file-attributes'.
The down sides:
* The perl script is transfered when the connection is established -
~800 bytes of data.
Daniel
Index: rcp.el
===
RCS file: /services/emacs-rcp/cvsroot/rcp/lisp/rcp.el,v
retrieving revision 1.355
diff -u -u -p -r1.355 rcp.el
--- rcp.el 2000/05/27 05:17:03 1.355
+++ rcp.el 2000/05/27 08:16:01
@@ -924,6 +924,34 @@ upon opening the connection.")
This variable is automatically made buffer-local to each rsh process buffer
upon opening the connection.")
+;; Perl script to implement `file-attributes' in a Lisp `read'able output.
+;; If you are hacking on this, note that you get *no* output unless this
+;; spits out a complete line, including the '\n' at the end.
+;; [EMAIL PROTECTED]
+(defconst rcp-perl-stat (concat
+ "$f = $ARGV[0];"
+ "@s = lstat($f);"
+ "if (($s[2] 012) == 012) { $l = readlink($f); $l = \"\\\"$l\\\"\"; }"
+ "elsif (($s[2] 04) == 04) { $l = \"t\"; }"
+ "else { $l = \"nil\" };"
+ "$u = $ARGV[1] ? getpwuid($s[4]) : $s[4];"
+ "$g = $ARGV[1] ? getgrgid($s[5]) : $s[5];"
+ "$m = (\"\", qw(p c ? d ? b ? - ? l ? s ? ? ?)) [ ($s[2] 12) 017 ];"
+ "@p = qw(--- --x -w- -wx r-- r-x rw- rwx);"
+ "@q = (@p, qw(--- --s -wS -ws r-S r-s rwS rws));"
+ "@r = (@p, qw(--- --t -wT -wt r-T r-t rwT rwt));"
+ "$m .= $q[ (($s[2] 6) 07) | (($s[2] 8) 010) ];"
+ "$m .= $q[ (($s[2] 3) 07) | (($s[2] 7) 010) ];"
+ "$m .= $r[ ($s[2] 07) | (($s[2] 6) 010) ];"
+ "printf(\"(%s %u %s %s (%u %u) (%u %u) (%u %u) %u \\\"%s\\\" t %u %u)\\n\","
+ "$l, $s[3], $u, $g, $s[8] 0x, $s[8] 16, $s[9] 0x,"
+ "$s[9] 16, $s[10] 0x, $s[10] 16, $s[7], $m, $s[1], $s[0]);"
+ )
+ "Perl script to produce output suitable for use with `file-attributes'
+on the remote file system.")
+
+
+
;; New handlers should be added here. The following operations can be
;; handled using the normal primitives: file-name-as-directory,
;; file-name-directory, file-name-nondirectory,
@@ -1085,96 +1113,121 @@ Invokes `line-end-position' if that is d
"Like `file-attributes' for rcp files.
Optional argument NONNUMERIC means return user and group name
rather than as numbers."
- (let ((v (rcp-dissect-file-name (rcp-handle-expand-file-name filename)))
-multi-method method user host path
-symlinkp dirp
-res-inode res-filemodes res-numlinks
-res-uid res-gid res-size res-symlink-target)
-(if (not (rcp-handle-file-exists-p filename))
-nil ; file cannot be opened
+ (if (rcp-handle-file-exists-p filename)
;; file exists, find out stuff
(save-match-data
(save-excursion
- (setq multi-method (rcp-file-name-multi-method v))
- (setq method (rcp-file-name-method v))
- (setq user (rcp-file-name-user v))
- (setq host (rcp-file-name-host v))
- (setq path (rcp-file-name-path v))
- (rcp-send-command
- multi-method method user host
- (format "%s %s %s"
- (rcp-get-ls-command multi-method method user host)
- (if nonnumeric "-ild" "-ildn")
- (rcp-shell-quote-argument path)))
- (rcp-wait-for-output)
- ;; parse `ls -l' output ...
- ;; ... inode
- (setq res-inode
-(condition-case err
-(read (current-buffer))
- (invalid-read-syntax
- (when (and (equal (cadr err)
- "Integer constant overflow in reader")
- (string-match
- "^[0-9]+\\([0-9][0-9][0-9][0-9][0-9]\\)\\'"
- (caddr err)))
- (let* ((big (read (substring (caddr err) 0
- (match-beginning 1
-(small (read (match-string 1 (caddr err
-(twiddle (/ small 65536)))
- (cons (+ big twiddle)
- (- small (* twiddle 65536
- ;; ... file mode flags
- (setq res-filemodes (symbol-name (read (current-buffer
- ;; ... number links
- (setq res-numlinks (read (current-buffer)))
- ;; ... uid and gid
- (setq res-uid (read (current-buffer)))
- (setq res-gid (read (current-buffer)))
-
Re: [RFC] [PATCH] Implement `file-attributes' with perl(1)
On 27 May 2000, Stefan Monnier [EMAIL PROTECTED] wrote: "Daniel" == Daniel Pittman [EMAIL PROTECTED] writes: * Get group and user name on any machine with perl. Last I checked, this is never used. The standard `file-attributes' does not have this `nonnumeric' argument and the rcp.el code never uses it either. Hrm. Why would that be there? Ah! It will be to support some VC integration stuff. Right. That bit can be dropped[1]. [...] The Perl code could be made simpler by moving some of the processing to the Elisp side, if those 800 bytes are a problem. Yes. I think that it could go to 200 or 300 bytes if I dropped non-numeric and the permissions stuff. For me, 800 bytes per connection is "lost in the noise". Is it significant for people who suffer through a phone connection ? It was tolerable, though noticeable, on a modem-net-modem connection for me. I don't think that it's a killer issue though, especially if I break out parts of it that are not often used and send them on demand - the non-numeric stuff, for example. Daniel Footnotes: [1] Well, moved to where it should be, anyway. -- The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. - J.K. Galbraith
Re: [RFC] [PATCH] Implement `file-attributes' with perl(1)
On Sun, 28 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: Daniel Pittman [EMAIL PROTECTED] writes: I don't want to drop this into the main source tree without some comment though. There are several good points to it: [...] I had a look at your patch and I like it, though I didn't actually try it. But if it works for you, install it on the CVS server and wait if somebody starts whining... Heh. I get to break the source tree at work too often, these days, to do something like that without warning people. I think I would have done it differently, but your way is probably better. (I would have tried to only get the missing information using Perl, such as the [cma]time.) I think my way would cost too much run time because of the multiple Perl invocations. I thought 'bout it, but it seemed a heck of a lot more work than was needed, especially when I could make the Perl code spit out something nicely formatted and robust. If you would like to do more work in Lisp, a function rcp-int-to-mode-string which is the inverse of rcp-mode-string-to-int could be implemented and used. It is. The Perl is now ~430 bytes, and I may be able to squeeze it further than that. I think that this is tolerable even on a 14.4k modem, being as that is around a third of a second to send, at that speed. That did move the mode mangling into Lisp and dropped the 'non-numeric' support though. If mapping uid and gid names is needed, I can write one line perl things to do that easily enough.[1] [...] I wonder which way is more robust -- having rcp-remote-perl contain the complete path, or relying on the remote $PATH setting to find the right program? Full path. Especially as it gets sent only once. ... Unless, of course, we take the first Perl in the path. Which we do. *shrug* Daniel Footnotes: [1] Better yet, these one line things could be sent on demand, not at startup. I think. If I can make it robust enough. That would be nice. -- I have no life, and I must scream. And in response, thus spake the Oracle: } And there we have it, modern music summed up in one tidy sentence.
Re: rsync method: little problem
On Sun, 28 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: At my site, I need to invoke rsync like this when saving the buffer: rsync -e ssh --rsync-path /path/to/nonstd/bin/rsync localfile remotefile The problem is, /path/to/nonstd/bin/rsync might differ depending on the target host. The solution is to find the remote rsync executable using rcp-remote-path. Ugh. That's a PITA, isn't it? What's still missing is some infrastructure for this. If at all possible, I don't want to make a special case for rsync, so a general solution is needed. A general solution probably means that the rsync arguments should be specified in rcp-methods, in some way. I think that, by this point, the process of building a command line for the transfer methods is getting, well, arcane. I also bet that this isn't going to be the only *odd* transfer method that needs this sort of support. So, why not let `rcp-rcp-args' (or something more useful) have several types. Then, if it's a string, use `format' to put parameters in to it. If it's a function, call it with the arguments and let it do the remote path stuff and so on. [...] This sounds like work. And I don't want to search for the executable multiple times, so when setting up the connection, I need to go through rcp-rcp-args to find all the executables which I need to search for, and then this list needs to be stored in the connection buffer, somehow. Now, this is something that needs a little looking at. I think that a method like this might be useful: (defun rcp-get-connection-property (name method optional default) "Get a named value associated with a connection." (symbol-value-in-buffer (intern (concat "rcp-connection-property-" name)) (rcp-buffer-name method) default)) That way it is not needed to write special custom code for each and every connection property. How does that work for you? I will even implement it if you want to spec out the format of the connection description objects. Daniel -- 99 dreams I have had / In every one a red balloon It's all over and I'm standing pretty / In this dust that was a city If I could find a souvenir / Just to prove the world was here -- Nina, _99 Red Balloons_
Re: emacs compatibility
On Sun, 28 May 2000, Joe Stoy [EMAIL PROTECTED] wrote: When trying to check out the latest rcp.el on a Solaris client with GNU Emacs 20.3.2 (sparc-sun-solaris2.5.1, X toolkit), I have the following difficulties. [...] (2) nor is eval-when-feature. Oh, bugger. Hrm. I wonder what the FSF equivalent of that one is? Is either of these because my emacs is out of date? I can find a base64.el in the Xemacs tree, and copy it onto my own load-path somewhere; but I'm not sure how to deal with the other problem (which again seems to be about something that's in xemacs), other than simply commenting out the call of it. The intent is to have the VC integration file (rcp-vc) loaded when the vc feature is. I presume we are still trying to be compatible with all emacs 20 (and xemacs 21) versions. Er, yes. My bad. I will commit a fix soonest. Daniel -- Love like you'll never get hurt. You've got to dance like no one is watching, It's gotta come from the heart, if you want it to work. -- Susannah Clark
Re: Questions about rcp.texi
On Mon, 29 May 2000, Yuji Yamano [EMAIL PROTECTED] wrote:
I have some questions about rcp.texi.
Within these limitations, @rcp{} is quite powerful. It is worth
noting that, as of the time of writing, it is far from a polished
end-user product. For a while yet you should expect to run into rough
edges and problems with the code now and then.
What is `rough edges'?
Things that are not easy or nice to do yet, but are not more than
inconvenient. The need to load EFS or Ange-FTP before RCP is an example
of this: it's not very obvious or convenient, but it does not really
cause much hardship.
My understanding is:
rcp is a useful software, but not finished for end user now.
You may be in big trouble (rough edges) with rcp, or rcp may not work
(problems with the code).
Is it right?
Little trouble is closer to what I intended.
It is finished enough that the developers use it for day to day work
but the installation and setup can be a little difficult to master,
as can the terminology.
Does it means that installation and configuration are little difficult
because of the technical terminology?
Yes, and because it requires that the user know a little bit about load
ordering and so forth.
@rcp{} discovers that it needs a connection to the host. So it
invokes @command{telnet HOST} or @command{rsh HOST -l USER} or
whatever the file name says to use to connect to the remote host.
I can't understand the part `whatever the file name says to use to
connect to the remote host'.
It is poorly worded and should be rewritten. Try:
'it invokes ... or similar tools to connect to the remote host.'
These versions are not, of course, guaranteed to do anything more
friendly for you than eat your dog, walk your breakfast and giggle
when you complain---use at your own risk. :)
I think it's a joke, because I've never seen such crazy things.
But I can't understand what it means.
Japanese sense of humor is much differnt from English people's one.
:-)
That's it. It's a humorous way of saying that the CVS version may be
completely broken, so watch out. Feel free to translate to something
more sensible and all. :)
When submitting a bug report, please describe in excruciating detail
the steps required to reproduce the problem and, if possible, a
simple recipe that does so.
What does `recipe' means in this context?
Short summary or patch or analysis about this problem or...?
A step-by-step set of instructions for reproducing the problem. This,
also, should be reworded in the English.
If you feel particularly adventurous and would like a gold
star@footnote{Of course, you have to come down and visit me in
Australia to collect this, but who is counting?} and all, you might
consider
What is `gold star' and why go to Australia?
I think it's a joke too, but I can't understand why funny because lack
of basic culture.
Yes. When children are in school and do something good, they get given a
gold star (a little sticker) on their work if it is especially good. So,
yes, this is again a joke - and they do tend to depend on the culture.
:)
In plain English, it means 'if you submit a patch, that is a very good
thing.'
Thanks for doing the translation, and I will act on some of the points
you had trouble with and make them clearer, to try and avoid confusing
more people. :)
Daniel
--
Onanism produces seminal weaknesses, impotence, dysury, tabes dorsalis,
pulmomary consumption, dyspepsia, dimness of sight, vertigo, epilepsy,
hypochondriasis, loss of memory, manalgia, fatuity, and death.
-- Dr. Benjamin Rush, _Medical Inquiries_, 1812
Re: locale, was: Questions about rcp.texi
On Sun, 28 May 2000, Tom Roche [EMAIL PROTECTED] wrote: "Daniel Pittman" [EMAIL PROTECTED] 5/28/00 8:29:23 PM Thanks for doing the translation, and I will act on some of the points you had trouble with and make them clearer, to try and avoid confusing more people. :) Hmm ... actually, I believe this thread illustrates the value of Yamano's offer to translate, and points a different "way ahead." Having translations frees the writers of each to employ, in their own language, witticisms, figures of speech, allusions, etc that need not be transparent to readers in another language. So perhaps it is enough that Yamano (and Grossjohann?) know what you mean, and can convey the meaning as they choose (presumably not literally) in their own translations? Oh, they are free to employ the language of their choice. I don't intend to drop /all/ the humor, etc, from the documentation. The more obtuse bits, however, are going to get changed as needs be. After all, it should be fun to read - but not to the point that it can't be used. :) Daniel -- "Tut, tut, child!" said the Duchess. "Everything's got a moral, if only you can find it." -- Lewis Carroll, _Alice in Wonderland_
Re: file name coding system - and associated topics (including perl)
On Mon, 29 May 2000, Joe Stoy [EMAIL PROTECTED] wrote: I should have known better than to upgrade to the newest rcp.el before getting on with my "real" work ... *grin* After I went to all that effort to put big threatening warnings into the documentation 'bout precisely this as well. ;) Here are two debug buffers (with irrelevant lines removed), both from an NT client, both to Solaris servers. The first one is a transatlantic connection. [...] The second server was in England. Today is a public holiday, so the network is lightly loaded, and the timing is defferent. [...] So the coding decision is wrong, and ^M's are splattered all over the place. I've cured that problem for the time being by putting Bleh. I think that detecting the end of line convention is seriously broken. The coding system, yes, but the line endings should be fixed. I think. [...] PERL The US system didn't have perl in any place rcp.el was clever enough to find (in fact they were in /map/sys/bin/perl and /map/compat/bin/perl5, but I don't think I'm going to tell you that), That's non-standard enough that you would need to add it to the remote path yourself, I think. :) so that was OK. But the British system did; and my rcp.el jammed up trying to send rcp_file_attributes (no shell prompt ever received). Oh. :/ One possibility is that there's a shorter buffer involved, and the transmission got truncated; if so, it'll have to be sent as several chunks, with continuation lines, I suppose. I don't think that it can have been truncated by ssh(1) and all. Do you think that the remote shell couldn't cope with a command line longer than 255 characters or something? That would be... painful. I will try splitting the command up though, and see what happens. Let me know, if you can, how it goes? Daniel -- Reality is a collective hunch. -- Jane Wagner
Re: file name coding system
On Mon, 29 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: I think that's a really thorny issue. I with there was a way to at least guess the right coding system in some cases, but that does not appear to be possible. Hrm. Yes. It certainly seems to have, er, issues with automatic detection. I think that, maybe, line endings are the big problem though, and not the actual coding system for files themselves. [...] The out of band methods are thornier, because the coding system that's used by the `ls' output might differ from the coding system that we have to use when calling `rcp' (or `scp' or `rsync' or whatever). So we need two file name coding systems for this case. Hrm. I think that this needs to work as follows: * The local filename is in a safe local encoding. The code takes care of that - `make-temp-file' or whatever should be safe. * The remote filename needs to be in the remote encoding, otherwise it will not match correctly on the remote machine. That's not quite as difficult as I feared, I think. Um, and it needs to have the right encoding when writing, but that's already solved, I think, by the internal MULE stuff. I hope. [...] So, we have to let the user specify these coding systems. How should this be done? For the `ls' output, there is process-coding-system-alist, but I think that is not sufficient. This variable only matches on the program name, and users might wish to use ssh to connect to hosts with different coding systems. I can think of two ways to do it: (1) Yet another method parameter. Which would specify the default coding system to use. (2) An alist or two which lets the user specify the coding systems per host name (or user name / host name combination?). I think that setting parameters for connections by machine (and user) is already a requested feature, yes? In that case it seems sensible to offer support for it. [...] The disadvantage of (1) is that rcp-methods is too large already. I was thinking of having a look at the members of the object and seeing which, if any, could be merged together to make it less verbose. In any case, I don't think the size is a real concern if they /are/ different parameters. Daniel -- An idea that is not dangerous is unworthy to be called an idea at all. -- Elbert Hubbard
Re: file name coding system - and associated topics (including perl)
On Tue, 30 May 2000, Kai Großjohann [EMAIL PROTECTED] wrote: "Daniel Pittman" [EMAIL PROTECTED] writes: Bleh. I think that detecting the end of line convention is seriously broken. The coding system, yes, but the line endings should be fixed. I think. I think that the idea is sound, but there must be a bug in the code, regarding the timing. Hm. Well, the `ls -l' output is not a good idea to use, because of the `-' string that's used for symlinks. I'll change it back to `echo foo ; echo bar' -- this will at least work for ascii file names and ought to find out the right EOL convention. It would be good for the EOL convention, wouldn't it? Hrm. Of course, rcp does not support non-ASCII things until *after* the connection is initially set up, does it? I think that maybe 'echo foo; echo bar' could be used to detect the end of line convention, and then, *after* the connection is running[1] using 'ls -l' and detecting the coding system for filenames would be sensible. Well, it seems sane even after I wrote it down. ;) Daniel Footnotes: [1] and we have (rcp-wait-for-output) available... -- Reality is a collective hunch. -- Jane Wagner
Re: emacs compatibility
On Wed, 31 May 2000, Pete Forman [EMAIL PROTECTED] wrote: Kai Großjohann writes: Joe Stoy [EMAIL PROTECTED] writes: (1) base64.el[c] is not known to emacs; (2) nor is eval-when-feature. I have changed from eval-when-feature to eval-after-load. And base64 support is native in Emacs 20.4 or 20.5 or something, if I'm not mistaken. (By `native', I meant coded in C.) base64.el comes with Gnus. Hm. Maybe I should extract base64.el from Gnus 5.8, like I did with format-spec.el. Yes, I'll do that. It also comes with W3. It looks like the original was in VM, with vm-mime- prefixes. XEmacs 21.2 also has native base64 support. Any load or require of base64 should be wrapped in a test. The functions may be builtin or already loaded from Gnus or W3. FWIW, XEmacs 21.2 and Emacs 20.6 have the builtin function - and they have '(featurep 'base64) = t'. No issues with a require there. :) It will also fail to load the base64 library if it is already loaded. I think it's only an issue if you can find a broken base64 function that does not '(provide 'base64)' or something. Daniel -- Change is disruptive -- that's the point! -- Karen Bredfeldt
Re: Unidentified subject!
On Wed, 31 May 2000, Joe Stoy [EMAIL PROTECTED] wrote: Apologies for what may be another half-baked late-evening report. But I'm having repeatable trouble with filename completion in a long directory. Hrm. I couldn't get this to break on my Linux machine with around 6K files. Darn. Can you step through the code with the debugger and see where it is losing? Daniel -- It is disconcerting to reflect on the number of students we have flunked in chemistry for not knowing what we later found to be untrue. -- quoted by Robert L. Weber's, _Science With a Smile_ (1992)
Re: filename completion
On Thu, 1 Jun 2000, Joe Stoy [EMAIL PROTECTED] wrote: On 1 Jun 2000 11:37:33 +1000 Daniel Pittman [EMAIL PROTECTED] wrote: On Wed, 31 May 2000, Joe Stoy [EMAIL PROTECTED] wrote: Apologies for what may be another half-baked late-evening report. But I'm having repeatable trouble with filename completion in a long directory. Hrm. I couldn't get this to break on my Linux machine with around 6K OK -- I can reproduce the problem without involving tramp at all. It turns out that for this particular directory (at least) the command /bin/ls -d .*/ */ 2/dev/null | cat causes the /bin/ksh on the server (Solaris) to hang with no output. I've asked the server's sysadmins to tell my why. Right. The output from strace(1)[1] would be most useful. But I suspect that you will find that either ls, ksh or cat has a deadlock in it. Which sucks. More than normal, because I can't think of a *good* way to fix this problem. Daniel Footnotes: [1] I think that Solaris calls this, um, 'truss'? -- No matter how widely you have traveled, you haven't seen the world if you have failed to look into the human hearts that inhabit it. -- Donald Culross Peattie
Re: Emacs 19
On Thu, 01 Jun 2000, Yuji Yamano [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: Hm. I just grepped all the *.el files and couldn't find save-current-buffer. I could find save-excursion, save-window-excursion, and save-match-data, though. A typo? Sorry for unsufficient information. I drunk beers heavily when I wrote this e-mail. :-p save-current-buffer is used in with-current-buffer, and I took it from Emacs 20.4. You should be able to work around it like this then:[1] (defmacro with-current-buffer (buffer rest body) `(let ((the-current-buffer (current-buffer)) result) (set-buffer ,buffer) (setq result (eval ,body)) (set-buffer the-current-buffer) result)) Well, that or Lisp to that effect. Daniel Footnotes: [1] Not that I can actually test it, but it should work. ;) -- Keep a diary and one day it'll keep you. -- Mae West
Re: tramp ($Id: tramp.el,v 1.372 2000/06/01 22:41:21 grossjoh Exp $); `EOF during parsing' error on first use of any connection
On Fri, 2 Jun 2000, Joe Stoy [EMAIL PROTECTED] wrote: Message-ID: [EMAIL PROTECTED] Priority: NORMAL X-Mailer: Execmail for Win32 5.1 Build (9) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" I got that (`End of file during parsing'), too, and it happened at the same spot. But debug-on-error didn't catch it. Does anybody know what's going on? What about trying a (tramp-wait-for-output) after the (tramp-send-command ...) which immediately precedes the ";; find a `perl'" comment? It may be that the definition of tramp_test_nt() is somehow never getting the closing brace because too much is getting sent too quickly, and its syntax analyser is therefore running off the end. Just a thought. It's not a remote shell issue, it's an Emacs Lisp reader error. Tramp asks Emacs to read a Lisp expression from the connection buffer (at point) and that fails. Oh, and it does the same thing here on localhost against the latest bash which is, um, fairly solid against generic lossage. Daniel -- I am he, As you are he, As you are me, And we are all together. -- John Lennon, "I Am The Walrus"
Re: filename completion
On Sat, 3 Jun 2000, Joe Stoy [EMAIL PROTECTED] wrote:
Just as a little sanity check: if you try `find /fs ...' and that
hangs, what happens when you do `cd /fs; find . ...'?
It hangs too (in fact that's what I've been doing all the time).
Right. This is starting to make sense, I think.
You said that the /fs directory is managed by an automounter, didn't
you? This would be mounting either local removable media or network
filesystems when you did 'cd /fs/somewhere/', yes?
In which case I would run 'truss find . 21 | grep stat('[1], watch to
see what the last directory that it tried to stat[2] was, then submit a
report to my sysadmin 'bout it.
I suspect that you will find it to be the following case:
1) Find does l?stat("dead-host")
2) Kernel blocks find.
3) Kernel asks automount to mount "dead-host"
4) Automount spends some time trying to mount "dead-host" but gets
nowhere
Normally, (4) would complete (relatively) quickly, notify the kernel and
find would be unblocked again. Since "dead-host" cannot be reached, the
automounter is blocked waiting for it until it gives up trying - and I
have seen instances where mounting NFS, etc, will happily try for ten
minutes to half an hour before it gives up...
Daniel
Footnotes:
[1] Modulo local output of the program. I have only used strace myself...
[2] If this does not give answers, don't filter it 'til after the run,
then work out by hand what the bad operation was. :)
--
Most conventional soldiers think of the jungle as being full of lurking
enemies. Under our system, we will do the lurking.
-- Motto of the Australian SAS in Vietnam
Re: help with rcp problem?
On Wed, 31 May 2000, Tom Roche [EMAIL PROTECTED] wrote: Kai Großjohann [EMAIL PROTECTED] 5/31/00 3:26:03 PM Can you please (setq rcp-debug-buffer t), then try again and send the contents of the *debug rcp/foo* buffer? FWIW: to improve/ease support, perhaps it would be wise to implement something like ramp-submit-problem-report, and then upgrade the docs. M-x rcp-bug is your friend. Your documented friend, at that. OTOH, it just sets up the mail. What we often need is the output of the debug run added to the mail. Hrm. I might try extending the documentation to cover that as well. Daniel -- Cease to be a drudge; seek to be an artist. -- Mary McLeod Bethune
Re: tramp ($Id: tramp.el,v 1.372 2000/06/01 22:41:21 grossjoh Exp $); `EOF during parsing' error on first use of any connection
On Fri, 2 Jun 2000, Kai Großjohann [EMAIL PROTECTED]
wrote:
"Mark A. Hershberger" [EMAIL PROTECTED] writes:
$ tramp_test_nt () {
test -n "`find $1 -prune -newer $2 -print`"
}
# Looking for remote executable `/bin/perl5'
$ test -x /bin/perl5 ; echo $?
I got that (`End of file during parsing'), too, and it happened at the
same spot. But debug-on-error didn't catch it.
Does anybody know what's going on?
I think that it is a bug in `tramp-run-test', or maybe
`tramp-wait-for-output'.
Simply put, it looks like wait for output fails (for some reason) to
strip away the '/' bit of the text, and point is left in the wrong
place.
Point then moves to '(point-max) (forward-line -1)' which leaves it on a
blank line.
Then the reader is invoked and fails to read anything.
I didn't get any further in working through it, but I think that it's
the wait for output stuff. OTOH, maybe the 'run-test' could act like:
(goto-char (point-max))
(search-backward-regexp "^[01]$")
This would make the location of the status report more robust, against
errors in the output.
Daniel
--
The desire to belong is partly the desire to lose oneself.
-- Eric Hoffer
Re: Filename completion
On 3 Jun 2000, Stefan Monnier [EMAIL PROTECTED] wrote: "Joe" == Joe Stoy [EMAIL PROTECTED] writes: [...] 2. Is there another problem with filename completion too? If I do it completely locally, for example with "tramp.", I can if I press TAB often enough, get it to offer me "tramp.el", "tramp.el~" and "tramp.elc". Doing it remotely, it tries to tell me that "tramp.el" is the "[sole completion]" (even though the other ones are there). It seems that the "hidden extensions" keep themselves too hidden. I think filtering completion-ignored-extensions is a mistake indeed. It should be (and most likely is) done in the function that call file-name-all-completions. [...] Using shell-globbing is a problem since it can fail in really long directories. I know that recent Unixen have a max-arg-length much higher than what it used to be, but I'd rather not rely on it. Also passing filename unquoted will not do the right thing. How about (format "%s -a 2/dev/null | fgrep %s" (tramp-get-ls-command multi-method method user host) (tramp-shell-quote-argument filename)) It will match more than what we need (since fgrep does a `substring match' rather than a `prefix match'), but the subsequent all-completions call will filter out the few false-positives. Sadly, the fgrep will fail if `filename' starts with a dash :-( Hrm. Questions to those who do have access to non-Linux machines (and, specifically, non-GNU f?grep), how do these two options work for you: a) ls -a 2/dev/null | f?grep ^%s b) ls -a 2/dev/null | f?grep -- %s I think that option (a) should address both the 'substring' match issue and the leading '-' issue. I think, also, that it should work right with the 'grep' available anywhere, but maybe not with the 'fgrep' anywhere. Unfortunately, I have only experience of the GNU .?grep utilities, so I don't know for sure. If others could test and let me know, please? Option (b) is less desirable - but if '--' serves as 'end of options' on other greps, it would serve to address the leading '-' issue. ;; Now get a list of directories in a similar way. The rest of it looks relatively sane, I think. If I can get comments on the syntax acceptable for the grep, I can probably have a look at changing this today... Daniel -- Make me walk / Make me talk / Do whatever you please I can act like a star / I can beg on my knees -- Aqua, _Barbie Girl_
Re: tramp ($Id: tramp.el,v 1.368 2000/05/31 22:24:21 grossjoh Exp $); tramp-check-ls-command error
On 03 Jun 2000, Hal Snyder [EMAIL PROTECTED] wrote: [...] 2. Now I can load a file from a remote host into a buffer, but when I try to save it after editing, I get: tramp-handle-write-region: LOCKNAME must be nil or equal FILENAME This is with tramp updated from CVS a few minutes before sending this email: Version: $Id: tramp.el,v 1.375 2000/06/03 11:07:23 Does the filename that you are writing contain a `~` character? I think that the lockname needs to be `~`-expanded before the comparison. This is on my todo list. FWIW, I can reproduce the issue using tramp to save an attachment from gnus to a remote machine... Daniel -- Glass is, we now know, a 'slow liquid;' and we're slow dust. -- Albert Goldbarth
Re: check in by daniel: 'tramp/lisp tramp.el,1.376'
On Sun, 4 Jun 2000, Kai Großjohann [EMAIL PROTECTED] wrote: Daniel Pittman [EMAIL PROTECTED] writes: Also, if you have trouble with filenames with grep(1) meta-characters in them, please let me know the filename. I *hope* that I quote the argument to it right, but it's always hard to be certain that I didn't miss some corner case.[1] Do you think that using fgrep might be safer? One could do something like this: Well, it /would/ be safer, but would cost us in performance. Unless someone actually finds a broken grep somewhere, I think that the current solution is acceptable. Or maybe we could use `find' to get a list of files, that would then automatically contain `./' for each file, for easy searching using fgrep. Of course, that would work as well. Then we can search for './pattern' which is less ugly and error prone. Sounds good, I will change it. Daniel -- Americans used to roar for Liberty, now they bleat for security. -- Dr. Norman Vincent Peale.
Re: check in by daniel: 'tramp/lisp tramp.el,1.379'
On 4 Jun 2000, Stefan Monnier [EMAIL PROTECTED] wrote: "Owns" == Owns all emacs-rcp files in CVS [EMAIL PROTECTED] writes: It also refuses, point blank, to create a symbolic link across hosts. Please don't ! Symbolic links can contain *any* data. [...] Stefan On Sun, 04 Jun 2000, Francesco Potorti` [EMAIL PROTECTED] wrote: [...] What a pity :-) All right, I hear the request. Do you think that the function should prompt for confirmation when making a symbolic link across hosts? Daniel -- The essence of true friendship is to make allowances for another's little lapses. -- David Storey
Re: check in by daniel: 'tramp/lisp tramp.el,1.378'
On Sun, 4 Jun 2000, Kai Großjohann [EMAIL PROTECTED] wrote: [...] Yes. It seems that AIX and IRIX are the problematic systems, and I even found both grep and fgrep on AIX. FWIW, the type of remote systems that I was thinking of when I wrote this were WinNT machines with a small set of the Cygnus (or MKS) tools available, and my router at home. Now, WinNT is probably not going to work as a target machine for a while, but I *do* want access to my router where, incidentally, grep(1) is implemented as a sed(1) script and fgrep is non-existent. Daniel -- Life is not all lovely thorns and singing vultures, you know... -- Morticia Addams, _The Addams Family_
Re: backtrace of possible tramp bug
On 04 Jun 2000, Mark A. Hershberger [EMAIL PROTECTED] wrote: "KG" == Kai Großjohann [EMAIL PROTECTED] writes: Also, please consider adding /usr/freeware/bin to the list of directories searched on remote machines. That is where mimencode is located on the IRIX machine I am connecting to. KG Is this a fairly standard directory on IRIX? [...] I believe this is the case. There was such a CD at the last job I worked (where they used IRIX) and the directory was the same. I have now added this directory to the search path, on this basis. I think this is a good thing(tm), because it makes IRIX more plug-and-play for end users. :) Daniel -- If you cannot get rid of the family skeleton, you may as well make it dance. -- George Bernard Shaw
Re: tramp ($Id: tramp.el,v 1.368 2000/05/31 22:24:21 grossjoh Exp $); tramp-check-ls-command error
On 04 Jun 2000, Hal Snyder [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Kai Großjohann) writes: Hal Snyder [EMAIL PROTECTED] writes: [...] Still getting the LOCKNAME error on save, but I haven't read thru emails yet to see if there's a suggested fix. Kai checked a change into CVS not that long ago to try and fix this. Is it still broken for you? Daniel -- Two hundred francs for sanctuary and she led me by the hand To a room of dancing shadows where all the heartache disappears And from the glowing tongues of candles I heard her whisper in my ear. «J'éntend ton coeur» -- Marillion, _Bitter Suite (III)_ (Misplaced Childhood)
Re: tramp ($Id: tramp.el,v 1.368 2000/05/31 22:24:21 grossjoh Exp $); tramp-check-ls-command error
On 04 Jun 2000, Hal Snyder [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Kai Großjohann) writes: Daniel Pittman [EMAIL PROTECTED] writes: Does the filename that you are writing contain a `~` character? I think that the lockname needs to be `~`-expanded before the comparison. This is on my todo list. I have now tried to do this. Hal, does the new version work better? I just updated my CVS image, running tramp.el v.383 and all other tramp files updated. Same LOCKNAME problem - whether I use explicit ~ in remote file path or not. Darn it. That's /such/ a pain. I cannot reproduce this locally, against a remote FreeBSD machine. Hrm. Could you apply this patch, reproduce the issue, then send the debug output to me? You will need to have at least 'tramp-verbose' level of 6 to make this work, so please check that is set correctly. Thanks, Daniel -- Common sense imagines that when it sees a table it sees a table. This is a gross delusion. -- Bertrand Russell
Re: check in by daniel: 'tramp/lisp tramp.el,1.383'
On Mon, 5 Jun 2000, Joe Stoy [EMAIL PROTECTED] wrote: Log Message: Use 'find' internal filtering when listing files for completion on the remote machine, rather than piping through fgrep. This should, hopefully, tickle automount bugs less often (as well as not depending on fgrep on the remote machine. :) But it does depend on find on the remote machine: on Solaris (SunOS 5.7) find does not support the -maxdepth option... Gah. Does it support any option to allow limiting the recursion it does? If there is not, I don't think that there is any portable way of getting filename completion to avoid stating all the files that exist. Hrm. At least, none that does not involve *significant* quantities of network traffic, through calling 'file-attributes' on every file returned in the first list.[1] Daniel Footnotes: [1] This would be slow because it needs to resync with the server after *every* file. :/ -- We propose to burn the academic libraries, because Theology is only fanaticism, History is lies, Philosophy is dreams, and Science is unnecessary. -- The Commune of Marseilles
Re: check in by daniel: 'tramp/lisp tramp.el,1.383'
On Mon, 5 Jun 2000, Pete Forman [EMAIL PROTECTED] wrote: Daniel Pittman writes: On Mon, 5 Jun 2000, Joe Stoy [EMAIL PROTECTED] wrote: Log Message: Use 'find' internal filtering when listing files for completion on the remote machine, rather than piping through fgrep. This should, hopefully, tickle automount bugs less often (as well as not depending on fgrep on the remote machine. :) But it does depend on find on the remote machine: on Solaris (SunOS 5.7) find does not support the -maxdepth option... Gah. Does it support any option to allow limiting the recursion it does? Er, -prune. ] cd / find . -name b\* -type d \! -name . -prune -print This gives me a recursive search. I think that I don't grok find(1) yet. Worse still, I have been unable to find a variant on the command that will spit out only the directories that match a filename prefix. Anyone? Daniel -- Never raise your hand to children; it leaves your midsection unprotected. -- Robert Orben
Re: check in by daniel: 'tramp/lisp tramp.el,1.383'
On Mon, 5 Jun 2000, Joe Stoy [EMAIL PROTECTED] wrote:
Gah. Does it support any option to allow limiting the recursion it
does?
I can't see any indication of such on the man page.
*nod* I just went and hunted it out from Sun. :)
Daniel, can you put me out of my misery and tell me why the ls-based
solutions are unacceptable ("ls -ad foo*" and "ls -ad foo*/")?
Completion without any initial characters, vis:
,
| ] ls -ad
| .
`
We can get around this by globing, of course, but that has the issue of
command line argument count limits. Oh, and I have directories on my
machine that would exceed them, I think, being over 30,000 files and
all.
I /could/ use find for the no-filename case and ls for the case where I
have one, but that seems... flakey.
Daniel
--
When a person with experience meets a person with money, the person with
experience will get the money. And the person with the money will get
some experience.
-- Leonard Lauder
File name completion, done to death.
People, a new check-in with the bestest little find(1) tricks I could work out. It does the same thing as '-maxdepth' without it. If people could beat on this one and let me know if it works. Also, a small advertisement: If anyone can give me shell access to any of the various Unix machines out there in the world, with the exception of Linux, I would be very grateful. As it stands, I can only test locally and don't know what will break for others. Daniel -- Yet, I am the necessary angel of earth, Since, in my sight, you see the earth again... -- Wallace Stevens
Re: File name completion, done to death.
On Mon, 5 Jun 2000, Joe Stoy [EMAIL PROTECTED] wrote: People, a new check-in with the bestest little find(1) tricks I could work out. It does the same thing as '-maxdepth' without it. If people could beat on this one and let me know if it works. Oh dear, not quite, I'm afraid. Automounts again. Even if I give enough initial characters to rule out all problem directories, the first clause in find's conjunction stats all the top-level files, I think, causing great delays. Reversing the order of the clauses makes matters worse, as it recursively searches the whole tree (including the parts that aren't there ...). Indeed. If you can provide a recipe for find(1) that does work better than this one... :) I /could/ use find for the no-filename case and ls for the case where I have one, but that seems... flakey. I see what you mean, but at least they would both work, if you see what I mean -- that is, they would behave as expected (with no initial filename I expect not to avoid the automount failures). Well, I am not ideologically opposed to doing this, but I think that I have not the energy to attack it any more this evening. I think. Unless, of course, this cleaning that I should be doing gets to be too boring. :) Daniel -- Sometimes a scream is better than a thesis. -- Ralph Waldo Emerson
[PATCH] File name completion with ls(1) and sh(1).
Well, it turns out that cleaning really *is* that boring. I got to
thinking about what could be done to fix the find(1) problems and ended
up with the attached patch.
This threw away two thirds of the code in
`...-file-name-all-completions', so I am actually quite happy 'bout it.
Could you give this a try (along with anyone else who feels enthused)
and see if it does what you want?
FWIW, it passed the test of running under bash, pdksh and ash[1]
locally, so I feel pretty confident that the remote sh would have to be
pretty stupid to fall over on this one.
Um, if it *does* fail, could you work out the command by hand and run it
in the shell? Then I can know exactly what is broken.
Hrm. The only other issue is that this patch /does/ introduce a limit to
the number of files offered for completion, because it uses shell
globing into ls. Of course, this is only when the list is filtered
somewhat so, I hope, it should be fine. If anyone actually hits the
limit, we can rewrite it. :)
Daniel
Index: tramp.el
===
RCS file: /services/emacs-rcp/cvsroot/tramp/lisp/tramp.el,v
retrieving revision 1.385
diff -u -u -p -r1.385 tramp.el
--- tramp.el 2000/06/05 10:54:06 1.385
+++ tramp.el 2000/06/05 13:00:18
@@ -1489,52 +1489,28 @@ is initially created and is kept cached
(tramp-barf-unless-okay
"tramp-handle-file-name-all-completions: Couldn't `cd %s'"
(tramp-shell-quote-argument path))
- ;; Get list of file names by calling ls.
+
+ ;; Get a list of directories and files, including reliably tagging
+ ;; the directories with a trailing '/'. Because I rock. [EMAIL PROTECTED]
(tramp-send-command
multi-method method user host
- (format "find . \\( \\! -name . -prune \\) %s -print"
+ (format (concat "%s -a %s | while read f; do if test -d $f; "
+ "then echo \"$f/\"; else echo \"$f\"; fi; done")
+ (tramp-get-ls-command multi-method method user host)
(if (zerop (length filename)) ""
- (format "-a \\( -name %s\\* -prune \\)"
- (tramp-shell-quote-argument filename)
+ (format "-d %s*" (tramp-shell-quote-argument filename)
+
+ ;; Now grab the output.
(tramp-wait-for-output)
(goto-char (point-max))
(while (zerop (forward-line -1))
-(push (buffer-substring (+ 2 (point))
+(push (buffer-substring (point)
(tramp-line-end-position))
result))
- ;; Now get a list of directories in a similar way.
- ;; I think this should not by using find(1) [EMAIL PROTECTED]
- (tramp-send-command
- multi-method method user host
- (format "find . \\( \\! -name . -prune \\) -a \\( %s -type d -prune \\) -print"
- (if (zerop (length filename)) ""
- (format "-name %s\\*" (tramp-shell-quote-argument filename)
- (tramp-wait-for-output)
- (goto-char (point-max))
- (while (zerop (forward-line -1))
-(push (buffer-substring (+ 2 (point))
-(tramp-line-end-position))
- dirs)))
-;; Now annotate all dirs in list of file names with a slash,
-;; at the same time checking for
-(mapcar
- (function (lambda (x)
- (if (member x dirs)
- (file-name-as-directory x)
- x)))
- (save-match-data
- (all-completions
-filename (mapcar 'list result)
-(lambda (x)
- (and (not (string= (car x) "."))
- (not (string= (car x) ".."))
- (not (string-match
- (concat "\\("
- (mapconcat 'regexp-quote
-completion-ignored-extensions
-"\\|")
- "\\)\\'")
- (car x))
+
+ ;; Return the list.
+ result)))
+
;; The following isn't needed for Emacs 20 but for 19.34?
(defun tramp-handle-file-name-completion (filename directory)
Footnotes:
[1] The single most brain-dead shell that I have ever had the
misfortune to deal with, but at least it doesn't have any of those
nasty 'features' to get in the way of the frustration. :)
--
They always say time changes things, but
you actually have to change them yourself.
-- Andy Warhol
Re: [PATCH] File name completion with ls(1) and sh(1).
On 05 Jun 2000, Daniel Pittman [EMAIL PROTECTED] wrote: Well, it turns out that cleaning really *is* that boring. I got to thinking about what could be done to fix the find(1) problems and ended up with the attached patch. [...] Which, of course, has a bug in it. If you happen to have a filename with spaces, the sh(1) code isn't quoted enough. Just go in to the function definition and change: test -d $f; to test -d \"$f\"; and it will all work. Which is actually pretty cool, because I expected it to die miserably on them, not almost work. :) Daniel -- An idea that is not dangerous is unworthy to be called an idea at all. -- Elbert Hubbard
Re: LOCKNAME workaround
On 06 Jun 2000, Hal Snyder [EMAIL PROTECTED] wrote: FWIW, I'm still getting the LOCKNAME error reported recently, with tramp.el 1.388. Sorry to have been quiet, I am hoping to soon have access to a machine where I can debug this issue directly. Do you have enough knowledge of Lisp to debug it? If so, you may be able to help thinks by breaking at the start of `save-buffer' and seeing where it is that LOCKNAME gets broken. I have a nasty suspicion that it may be a bug in TRAMP somewhere, but I can't be sure without the debug run to find out where it goes west... [...] Well, it is now possible to save files edited remotely. Is this asking for trouble? :-0 You should be just fine. I think that you will no longer get clash detection, but I doubt you use it anyway.[1] Daniel Footnotes: [1] I don't even think it was enabled in that version of XEmacs... -- Youth is happy because it has the capacity to see beauty. Anyone who keeps the ability to see beauty never grows old. -- Franz Kafka
Re: feature freeze?
On Tue, 6 Jun 2000, Kai Großjohann [EMAIL PROTECTED] wrote: I think it would be a good idea to try for a feature freeze and just fix bugs, right now. I'd like to get Tramp into Emacs 21, if possible, and it better be stable when we do that. I think somebody was aiming at getting it into XEmacs, as well? Could be a good time for that, as well. *nod* My aim is to push the first release up as an XEmacs package. I plan on waiting 'til a package shows though. Some people (Daniel, especially) have good ideas about new features, and I don't want to spoil your fun, though. We could fork a branch for the new features, but there is a tradeoff between forking and the amount of testing that could go into the to-be-stable version. FWIW, I don't feel a pressing need to implement new features; I do want (and plan) to work through more of the bugs before doing any major development.[1] What do you think? I would be happy to see a feature freeze leading up to a stable release, and will happily hold off new development for it. Daniel Footnotes: [1] Well, I did plan on introducing some degree of caching but, well, that's not something that I /need/ to do. It can wait.[2] [2] Unless it annoys me enough, in which case it can live in my repository locally for a while. :) -- Mother is the name for God in the lips and hearts of little children. -- William Makepeace Thackeray, _Vanity Fair_
Re: check in by daniel: 'tramp/lisp tramp.el,1.383'
On Tue, 6 Jun 2000, Kai Großjohann [EMAIL PROTECTED] wrote: "Stefan Monnier" [EMAIL PROTECTED] writes: [ GNU find has been fairly buggy in my experience ] Goodness. Well, it's good that Daniel has implemented something which works without find and does not suffer from command length limits. Actually, anything I implemented would have worked with GNU find, but might have been losing[1] against other versions. I work with GNU tools daily so, oddly enough, I have a lot of motivation to fix bugs with them.[2] Oh, and it's only *fairly* good against command line limits. You could still hit them by, say, having more files starting with 'a' than work on a command line and doing completion with them. I don't think anyone actually hit that as a limit though, so I suggest not fixing it until it actually breaks. But we must keep this in mind; I was about to suggest using `find' for other things, as well. Hm. Oh, please do. If they break against the GNU find, I will suggest fixes and stuff. Besides, it seems *mostly* reliable. :/ Daniel Footnotes: [1] Performance-wise and stuff. [2] Well, with TRAMP and them. Actually, with them as well, except that I didn't know if this silly behavior was the way find(1) worked or not. -- There is something more horrible than hoodlums, churls and vipers, and that is knaves with moral justification for their cause. -- P.J. O'Rourke
Re: suggestion for making cvs updates one step easier
On 08 Jun 2000, Matt Swift [EMAIL PROTECTED] wrote: Actually adding it to .cvsignore does not change the behavior of 'cvs update', it will still download MANIFEST after 'make clean' has deleted it. It needs to be removed from CVS as well. Consider that done. :) Daniel -- The youth gets together his materials to build a bridge to the moon, or, perchance, a palace or temple on the earth, and, at length, the middle-aged man concludes to build a woodshed with them. -- Henry David Thoreau
Re: Problem with tramp/scp on NT Emacs
On 14 Jun 2000, Glenn Proctor [EMAIL PROTECTED] wrote: Daniel Pittman [EMAIL PROTECTED] writes: On 14 Jun 2000, Glenn Proctor [EMAIL PROTECTED] wrote: Daniel Pittman [EMAIL PROTECTED] writes: [...] That is not a good thing, I believe. Try giving the '-t' argument to ssh, which may help. If not, there was a hack floating around on the list that would let you get a terminal on the remote system, you could check the archives. I had already tried the -t argument with no success. I have discovered that I *can* use scp (but not ssh) from within an emacs shell buffer. Joe Stoy has a version that does work, and has agreed to work with you privately on this one. Unfortunately, you *do* need to be able to log in to an interactive shell on the remote system for TRAMP to work - a working scp on it's own is not enough Hrm. It looks like Emacs tries to run the child ssh process, which fails. Can you try running '(start-process "ssh-test" (current-buffer) "/ssh/ssh" "bacon" "-l" "glennp")' This gives me a similar backtrace to before. Gah. That's not very good. This looks like a bug with 'start-process.' Can you send me the output of 'M-x describe-function' for 'start-process'. I want to know if there are different arguments needed for that version of Emacs. Is there anything in that needs to be set up at the remote end? The backtrack is not while talking to the remote side, it's in the local Emacs, which fails to create the child ssh process. :/ Daniel -- Machina Improba! Vel Mihi Ede Potum Vel Mihi Redde Nummos Meos!
Re: Modifying buffer name to contain name of host etc?
On 15 Jun 2000, Glenn Proctor [EMAIL PROTECTED] wrote: Now that I've got TRAMP working from an NT client (see previous post), Glad to hear it. I'd like to be able to have "remote" buffers marked in some way; at the moment the buffer name is simply the file name. Er... That isn't TRAMP specific behavior, it's Emacs behavior. You might try this snippet (untested) though: application/emacs-lisp Ideally I'd like the buffer to be called something like user@host:file or some such. I'm likely to be editing files of the same name on different hosts and I'm easily confused :-). Feel free to modify the function if you prefer a different format. Personally, 'file @ host' makes more sense to me, but it's your call. :) Daniel -- May the Forces of Evil become confused on the way to your house. -- George Carlin
Re: Japanese copyright
On Sun, 18 Jun 2000, Yuji Yamano [EMAIL PROTECTED] wrote: Yuji Yamano [EMAIL PROTECTED] writes: [...] I just did it, and added the following statement for English people. But I don't have any confident in my English writing. Does anyone make sure it is right? It is correct, yes. Daniel -- It may sound strange coming from a research man, but an attempt to get too many facts will often leave you without any real knowledge at all. -- Ernest Dichter
Re: Problem with tramp/scp on NT Emacs
On 14 Jun 2000, Glenn Proctor [EMAIL PROTECTED] wrote: Daniel Pittman [EMAIL PROTECTED] writes: Can you run ssh as an Emacs subprocess and get an interactive shell on the remote system? If not, TRAMP will not work quite right, I fear. Hmm - when I try this I get "Pseudo-terminal will not be allocated because stdin is not a terminal." and it never returns to the shell prompt. :-( That is not a good thing, I believe. Try giving the '-t' argument to ssh, which may help. If not, there was a hack floating around on the list that would let you get a terminal on the remote system, you could check the archives. [...] I set tramp-debug-buffer to t, but no *debug tramp...* buffer was generated. So it's not even getting as far as a remote call. Gah. Not good. :/ 2. I get a "Spawning child process: invalid argument" error If you can reproduce this with the debug value set, then send both the '*debug tramp/...*' and '*tramp/...*' buffers to the list, that would be helpful. This occurs when trying /r@scp:user@host:file. There is no debug buffer (even with the tramp-debug-buffer variable set) but I've attached the backtrace below. [...] To clarify: if I use /r@scp:hostname:filename I get the "hang" described above. If I use /r:hostname:filename I get the "instant return" instead. If I use /r@scp:user@host:filename I get the error shown below. Hrm. It looks like Emacs tries to run the child ssh process, which fails. Can you try running '(start-process "ssh-test" (current-buffer) "/ssh/ssh" "bacon" "-l" "glennp")' Do that in the *scratch* buffer, and use 'C-j' to run it. See what that says Daniel -- A good poet is someone who manages, in a lifetime of standing out in thunderstorms, to be struck by lightning five or six times; a dozen or two dozen times and he is great. -- Randall Jarrell
Re: RCS checkin over tramp
On 28 Jun 2000, [EMAIL PROTECTED] wrote: Problems running vc/rcs over tramp. When I try to check in changes I sometimes get this error in the echo area: Command rcsdiff returned status 2. Running `rcsdiff'...FAILED (status 2) And then a buffer pops up displaying these error messages: rcsdiff: `RCS/' is not a regular file rcsdiff: RCS/: Invalid argument Do these show up on the command line when you log in and do them by hand? Daniel -- Remember that under the skin you fondle lie the bones, waiting to reveal themselves. -- Ikkyu
Re: tramp ($Id: tramp.el,v 1.393 2000/06/06 12:58:27 grossjoh Exp $); tramp doesn't seem to work with ediff
On Wed, 26 Jul 2000, Skip Montanaro [EMAIL PROTECTED] wrote: I just installed tramp with the intent of using it to edit and compare remote (via ssh/scp) and local copies of files that have gotten out of sync with one another. Ediff is my preferred method for this. [...] Once upon a time when I had efs working, I was able to use the ediff package to compare remote and local files. It appears that ediff thinks the tramp-fetched file is actually local and just spits out a diff command instead of grabbing a local copy of the file from wherever tramp cached it. Is it possible to get a tramp+ediff combination working? Short answer: If EFS did it, so can we. :) Long answer: I don't have time to work on this right now, and Kai isn't back for a while. If you know elisp at all, or are willing to learn it, you could have a bit of a dig around the internals of EFS and ediff to find out where they hook together... If you can find that, post the results - or, better yet, write some support code like that in 'tramp-vc.el' to make ediff work and stuff. Daniel -- Recursion is the root of computation since it trades description for time. -- Alan Perlis
Re: telnet method to NeXT
On Sat, 29 Jul 2000, Yuji Yamano [EMAIL PROTECTED] wrote: Yuji Yamano [EMAIL PROTECTED] writes: $ /bin/ls -lnd /; echo $? drwxrwxrwt 13 root1024 Apr 2 12:19 / 0 $ It is okay. -n option works fine. Sorry for my misunderstanding. ls with -n option doesn't work on your NeXT box, but I think it's not so important problem if you don't use VC. Er. Not quite. If you don't have an ls that supports '-n' for numeric UID/GID values, and you don't have a usable perl5 on the remote machine, things may go very wrong with 'file-attributes'. Of course, things /might/ work, but... Daniel -- Youth is happy because it has the capacity to see beauty. Anyone who keeps the ability to see beauty never grows old. -- Franz Kafka
Re: tramp ($Id: tramp.el,v 1.393 2000/06/06 12:58:27 grossjoh Exp $); Error message: Signaling: (wrong-type-argument listp perl:)
On Wed, 2 Aug 2000, Alexander Schindler [EMAIL PROTECTED] wrote: Hi, unfortunately I think this is probably not a bug, but a configuration problem. Anyway, What version of perl have you on the remote machine, and can you put the content of the tramp buffer in mail? Daniel -- Copyright law is totally out of date. It is a Gutenburg artifact. Since it is a reactive process, it will probably have to break down completely before it is corrected. -- Nicholas Negroponte, _Being Digital_, 1995
Re: telnet method to NeXT
On Wed, 2 Aug 2000, Kai Großjohann [EMAIL PROTECTED] wrote: On 31 Jul 2000, Daniel Pittman wrote: Er. Not quite. If you don't have an ls that supports '-n' for numeric UID/GID values, and you don't have a usable perl5 on the remote machine, things may go very wrong with 'file-attributes'. I think Tramp just uses -1 as uid and gid. Since ange-ftp also does this, we should be fairly safe. (The uid and gid become important only for VC, like Yuji says.) Well, reading 'tramp-handle-file-attributes-with-ls', it looks like we try to read out the uid and gid and stuff, which the caller expects to be a number. If they got a string or symbol... Or did I goof, yet again? kai PS: `Goof'? `Goof up'? My English... ... is really good. 'Goof' can be a noun or a verb. 'Goop up' is a verb. Daniel -- If the doors of perception were cleansed every thing would appear to man as it is, Infinite. -- William Blake, _The Marriage of Heaven and Hell_
