From: Jens G. <Jen...@lo...> - 2002-03-27 08:19:50
|
Hello everybody, thanks a lot for tramp, really helps me a lot in my daily work, avoiding yp, nfs and all that complicated remote security setups. I recently downloaded the latest version and I found the new filename conventions. Have to get used to it, the old syntax was hardwired in my fingers, but that's not why I am writing... What's really puzzeling me is that /[my.really.complicated.network.access] for find-file eg is not expanded to my remote home directory as it used to be but by a simple plain and anoying / (all my difficult and painfull typing simply went away!) I found the place in the sources where this is done (tramp-handle-file-name-directory) , but the reasons don't appear to me. Did you mean something like (concat file "/") which could be a usefull choice. I personally would vote for (concat file "~/") but probably this would best be handled by a customizable user variable or a hook. Best Jens |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2002-03-27 09:41:14
|
Jens Gustedt <Jen...@lo...> writes: > What's really puzzeling me is that > > /[my.really.complicated.network.access] > > for find-file eg is not expanded to my remote home directory as it used > to be but by a simple plain and anoying > > / > > (all my difficult and painfull typing simply went away!) > > I found the place in the sources where this is done > (tramp-handle-file-name-directory) , but the reasons don't appear to me. > Did you mean something like > > (concat file "/") > > which could be a usefull choice. I personally would vote for > > (concat file "~/") > > but probably this would best be handled by a customizable user variable > or a hook. Originally, I had (tramp-handle-file-name-directory "/[foo]") => "/[foo]~/" or so, but that broke file-expand-wildcards. It inflooped. So I made the change that you are seeing. (Or was it file-truename that broke? I'm not sure. I'd have to look in the mailing list archives to be 100% sure. But I do know that I made the change on purpose, to fix something. I should have made a comment.) kai -- Silence is foo! |
From: Jens G. <Jen...@lo...> - 2002-03-27 10:00:49
Attachments:
.signature-de.vcf
|
Hallo Kai, >>>>> ``Kai'' == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> schreibt: Kai> Originally, I had (tramp-handle-file-name-directory "/[foo]") Kai> => "/[foo]~/" or so, but that broke file-expand-wildcards. Kai> It inflooped. So I made the change that you are seeing. Hm, sounds like a quick fix to get things going. Kai> (Or was it file-truename that broke? I'm not sure. I'd have Kai> to look in the mailing list archives to be 100% sure. But I Kai> do know that I made the change on purpose, to fix something. Kai> I should have made a comment.) You made a comment, but as an outsider it was (is!) just incomprehensible to me... Anyhow, I patched my version locally such that it gives me "/[foo]" => "/[foo]~/" and it works quite fine for me: (21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid) Was this an FSF Emacs problem you had? What do you think of making this customizable? Grüße Jens -- :: LORIA & INRIA Lorraine :::: http://www.loria.fr/~gustedt/ :: :: campus scientifique, BP 239, F-54506 Vandoeuvre lès Nancy :: :: Tel 00 33 3 83 59 30 90 :::::::: Fax 00 33 3 83 27 83 19 ::: |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2002-03-27 10:41:54
|
Jens Gustedt <Jen...@lo...> writes: > Hallo Kai, >=20=20=20=20 > >>>>>> ``Kai'' =3D=3D Kai Gro=DFjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE>= schreibt: > > > Kai> Originally, I had (tramp-handle-file-name-directory "/[foo]") > Kai> =3D> "/[foo]~/" or so, but that broke file-expand-wildcards. > Kai> It inflooped. So I made the change that you are seeing. > > Hm, sounds like a quick fix to get things going. > > Kai> (Or was it file-truename that broke? I'm not sure. I'd have > Kai> to look in the mailing list archives to be 100% sure. But I > Kai> do know that I made the change on purpose, to fix something. > Kai> I should have made a comment.) > > You made a comment, but as an outsider it was (is!) just > incomprehensible to me... > > Anyhow, I patched my version locally such that it gives me > > "/[foo]" =3D> "/[foo]~/" > > and it works quite fine for me: > > (21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid) > > Was this an FSF Emacs problem you had?=20 > > What do you think of making this customizable? Hm. Does it still work with find-file-wildcards being true? (Not sure what's the XEmacs equivalent of this variable -- it allows you do say C-x C-f *.c RET and it will open all *.c files in the current directory.)=20 kai --=20 Silence is foo! |
From: Jens G. <Jen...@lo...> - 2002-03-28 11:56:22
Attachments:
.signature-de.vcf
|
Guten Tag, >>>>> ``Kai'' == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> schreibt: Kai> Hm. Does it still work with find-file-wildcards being true? Kai> (Not sure what's the XEmacs equivalent of this variable -- it Kai> allows you do say C-x C-f *.c RET and it will open all *.c Kai> files in the current directory.) Didn't knew of that feature, but it seems to exist in dired in xemacs, too, and actually is always switched on. I tried it a bit out, and didn't encounter too much of a problem. Whenever I give `C-x d' a wildcard pattern added to the current directory it proposes, no problem at all. (Actually quite nice) It only has problems if I am nasty: call `C-x d' on a remote tramp directory, then erasing all the path it proposes and then giving something like *.c without other prefix doesn't work. So to get wildcards in the cwd you have to leave the proposed path as it is and simply add to that path. Looks quite convenient to me. Jens -- :: LORIA & INRIA Lorraine :::: http://www.loria.fr/~gustedt/ :: :: campus scientifique, BP 239, F-54506 Vandoeuvre lès Nancy :: :: Tel 00 33 3 83 59 30 90 :::::::: Fax 00 33 3 83 27 83 19 ::: |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2002-03-29 11:27:26
|
Jens Gustedt <Jen...@lo...> writes: >>>>>> ``Kai'' =3D=3D Kai Gro=DFjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE>= schreibt: > > Kai> Hm. Does it still work with find-file-wildcards being true? > Kai> (Not sure what's the XEmacs equivalent of this variable -- it > Kai> allows you do say C-x C-f *.c RET and it will open all *.c > Kai> files in the current directory.) > > Didn't knew of that feature, but it seems to exist in dired in xemacs, > too, and actually is always switched on. I tried it a bit out, and > didn't encounter too much of a problem.=20 C-x d and C-x C-f are two different things. The wildcard support for C-x d is older than the wildcard support for C-x C-f, and it is implemented in another way. Please try C-x C-f *.c RET, as well, to be sure it doesn't break anything. kai --=20 Silence is foo! |
From: Jens G. <Jen...@lo...> - 2002-03-29 11:56:36
Attachments:
.signature-de.vcf
|
Guten Tag, >>>>> ``Kai'' == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> schreibt: Kai> C-x d and C-x C-f are two different things. The wildcard Kai> support for C-x d is older than the wildcard support for C-x Kai> C-f, and it is implemented in another way. Kai> Please try C-x C-f *.c RET, as well, to be sure it doesn't Kai> break anything. Here the emacsen seem to be quite different. Look at the two different help strings: Xemacs> C-x C-f runs `find-file' Xemacs> Xemacs> `find-file' is an interactive compiled Lisp function Xemacs> -- loaded from "/usr/src/bs/BUILD/xemacs-21.1.14/lisp/files.elc" Xemacs> (find-file FILENAME &optional CODESYS) Xemacs> Xemacs> Documentation: Xemacs> Edit file FILENAME. Xemacs> Switch to a buffer visiting file FILENAME, Xemacs> creating one if none already exists. Xemacs> Under XEmacs/Mule, optional second argument specifies the Xemacs> coding system to use when decoding the file. Interactively, Xemacs> with a prefix argument, you will be prompted for the coding system. Emacs> C-x C-f runs the command find-file Emacs> which is an interactive compiled Lisp function in `files'. Emacs> (find-file FILENAME &optional WILDCARDS) Emacs> Emacs> Edit file FILENAME. Emacs> Switch to a buffer visiting file FILENAME, Emacs> creating one if none already exists. Emacs> Interactively, or if WILDCARDS is non-nil in a call from Lisp, Emacs> expand wildcards (if any) and visit multiple files. So on Xemacs there can't be a problem with that, since this feature simply doesn't exist. And obviously I also can't test it for you ;-)) Jens -- :: LORIA & INRIA Lorraine :::: http://www.loria.fr/~gustedt/ :: :: campus scientifique, BP 239, F-54506 Vandoeuvre lès Nancy :: :: Tel 00 33 3 83 59 30 90 :::::::: Fax 00 33 3 83 27 83 19 ::: |
From: Jens G. <Jen...@lo...> - 2002-03-29 12:11:41
|
Hello, since I am on it, I stumbled into another little bug. Still for Xemacs. Look at the following dired /some-fancy-local-nfs-path: total 6 drwxr-xr-x 6 root bin 512 Feb 14 2001 . drwxr-xr-x 42 root root 1024 Feb 27 09:02 .. drwxr-xr-x 2 root bin 512 Oct 13 2000 cgi-bin drwxr-xr-x 4 root bin 512 Feb 14 2001 fcgi-bin drwxr-xr-x 3 nobody bin 512 Feb 14 2001 passe drwxr-xr-x 8 nobody 4294967294 512 Nov 29 10:11 texte This ``4294967294'' for the group is due to a miss-instalation of yp or something (isn't that the traditional -1 for nobody?). Dired itself handles this situation without problems: I can go with the cursor on ``texte'' type ``f'' and I get a listing of that directory. Tramp doesn't work here. The listing as above is still ok but when I wanna go into ``texte'' it produces a weird overflow for the integer 4294967294. Below you find the backtrace in case it helps. What is the reason that a numeric group is treated differently than others? Couldn't this just be taken as a string? Jens -- :: LORIA & INRIA Lorraine :::::::::: http://www.loria.fr/~gustedt/ :: :: campus scientifique, BP 239, 54506 Vandoeuvre lès Nancy, France :: :: phone +33 3 83 59 30 90 :::::::::::::::: fax +33 3 83 27 83 19 ::: Signaling: (invalid-read-syntax "Integer constant overflow in reader" "4294967294" 10) read(#<buffer "*tramp/smx xrousse*">) tramp-handle-file-attributes-with-perl(nil "smx" nil "xrousse" "/some-fancy-local-nfs-path/texte/" nil) tramp-handle-file-attributes("/[smx/xrousse]/some-fancy-local-nfs-path/texte/") apply(tramp-handle-file-attributes "/[smx/xrousse]/some-fancy-local-nfs-path/texte/") tramp-file-name-handler(file-attributes "/[smx/xrousse]/some-fancy-local-nfs-path/texte/") file-attributes("/[smx/xrousse]/some-fancy-local-nfs-path/texte/") apply(file-attributes "/[smx/xrousse]/some-fancy-local-nfs-path/texte/") dired-handler-fn(file-attributes "/[smx/xrousse]/some-fancy-local-nfs-path/texte/") file-attributes("/[smx/xrousse]/some-fancy-local-nfs-path/texte/") dired-set-file-modtime("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" (("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" #<marker at 1 in texte 0x9453794> nil (?l ?a) nil))) apply(dired-set-file-modtime ("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" (("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" #<marker at 1 in texte 0x9453794> nil ... nil)))) dired-handler-fn(dired-set-file-modtime "/[smx/xrousse]/some-fancy-local-nfs-path/texte/" (("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" #<marker at 1 in texte 0x9453794> nil (?l ?a) nil))) dired-set-file-modtime("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" (("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" #<marker at 1 in texte 0x9453794> nil (?l ?a) nil))) apply(dired-set-file-modtime ("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" (("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" #<marker at 1 in texte 0x9453794> nil ... nil)))) tramp-run-real-handler(dired-set-file-modtime ("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" (("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" #<marker at 1 in texte 0x9453794> nil ... nil)))) tramp-file-name-handler(dired-set-file-modtime "/[smx/xrousse]/some-fancy-local-nfs-path/texte/" (("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" #<marker at 1 in texte 0x9453794> nil (?l ?a) nil))) dired-set-file-modtime("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" (("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" #<marker at 1 in texte 0x9453794> nil (?l ?a) nil))) apply(dired-set-file-modtime ("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" (("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" #<marker at 1 in texte 0x9453794> nil ... nil)))) dired-handler-fn(dired-set-file-modtime "/[smx/xrousse]/some-fancy-local-nfs-path/texte/" (("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" #<marker at 1 in texte 0x9453794> nil (?l ?a) nil))) dired-set-file-modtime("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" (("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" #<marker at 1 in texte 0x9453794> nil (?l ?a) nil))) dired-simple-subdir-alist() dired-readin("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" #<buffer "texte"> nil) dired-internal-noselect("/[smx/xrousse]/some-fancy-local-nfs-path/texte/" nil) ad-Orig-dired-noselect("/[smx/xrousse]/some-fancy-local-nfs-path/texte" nil) (setq ad-return-value (ad-Orig-dired-noselect dir-or-list switches)) ) (if (and dir (string= "CVS" ...) (file-readable-p ...) cvs-dired-use-hook (if ... ... ...)) (save-excursion (setq ad-return-value ...)) (setq ad-return-value (ad-Orig-dired-noselect dir-or-list switches))) ) (let* ((arg dir-or-list) (dir ...)) (if (and dir ... ... cvs-dired-use-hook ...) (save-excursion ...) (setq ad-return-value ...))) ) (let (ad-return-value) (let* (... ...) (if ... ... ...)) ad-return-value) ) dired-noselect("/[smx/xrousse]/some-fancy-local-nfs-path/texte") find-file-noselect("/[smx/xrousse]/some-fancy-local-nfs-path/texte") find-file("/[smx/xrousse]/some-fancy-local-nfs-path/texte" nil) dired-advertised-find-file(nil) call-interactively(dired-advertised-find-file) |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2002-06-16 21:14:43
|
Jens Gustedt <Jen...@lo...> writes: > This ``4294967294'' for the group is due to a miss-instalation of yp > or something (isn't that the traditional -1 for nobody?). Dired itself > handles this situation without problems: I can go with the cursor on > ``texte'' type ``f'' and I get a listing of that directory. > > Tramp doesn't work here. The listing as above is still ok but when I > wanna go into ``texte'' it produces a weird overflow for the integer > 4294967294. Below you find the backtrace in case it helps. > > What is the reason that a numeric group is treated differently than > others? Couldn't this just be taken as a string? > > [...] > > Signaling: (invalid-read-syntax "Integer constant overflow in reader" "4294967294" 10) It's not clear to me what should be done in this case. Hm. Ah. The number appears to be 4G - 2. I think that's 2^32-2? In that case, an Emacs on a 32 bit architecture will fail, since it needs some of the 32 bits for tagging. Fascinating. There's nothing in Emacs that tells me what should happen in such a case: file-attributes is supposed to return a number, but the number is too big for a Lisp integer. In some cases, the documentation for file-attributes documents workarounds (cons cells for the inode number, and a floating point number for the file size), but the documentation (and the code in Emacs) do not mention anything about the uid and gid fields. kai -- People mountain, people sea, today no see, tomorrow see. (from Chinese) |
From: Jens G. <Jen...@lo...> - 2002-07-27 21:16:09
Attachments:
.signature-de.vcf
|
Guten Tag Kai, I suppose you meant ELISP> (read "(123 999999999999999999 432)") *** Eval error *** Invalid read syntax: "Integer constant overflow in reader", "999999999999999999", 10 Probably not much usefull by itself. So you might want to try-catch it (or however this construct might be called in elisp) ? Thanks a lot for trying to fix it ! Grüße Jens -- :: LORIA & INRIA Lorraine :::: http://www.loria.fr/~gustedt/ :: :: campus scientifique, BP 239, F-54506 Vandoeuvre lès Nancy :: :: Tel 00 33 3 83 59 30 90 :::::::: Fax 00 33 3 83 27 83 19 ::: |