23.0.60; TRAMP does not pass regime

23.0.60; TRAMP does not pass regime

[Peter Dyballa]

Hello!

When I'm in a dired buffer fed via TRAMP from a remote server and I  
type: 'C-x d /pat TAB' (leading to a path name construct in mini- 
buffer of ``/ssh:root@tisnam.tisdom.de:/var/log//pat´´ with the part  
until // in invalidating grey instead of usual black as soon as GNU  
Emacs sees the two slashes) TRAMP does not understand that the  
leading slash introduces a new (and particularly local) absolute path  
(adding as another try /ssh:root@tisnam.tisdom.de:/var/log/apache2 to  
the previous remote path pattern, makes TRAMP look for something  
like /ssh:root@tisnam.tisdom.de:/ssh:root@tisnam.tisdom.de:/var/log/ 
apache2, it does an ls of /ssh:root@tisnam.tisdom.de:/var/log/apache2  
on the remote server). It tries to expand the path name with // on  
the remote server and does not seem to be able to finish/time-out  
this nonsense – or I was not patient enough.


In GNU Emacs 23.0.60.2 (powerpc-apple-darwin8.11.0, X toolkit, Xaw3d  
scroll bars)
  of 2008-03-13 on Latsche.local
Windowing system distributor `The XFree86 Project, Inc', version  
11.0.40400000
configured using `configure  '--without-pop' '--without-sound' '-- 
with-xft' '--with-libotf' '--with-dbus' '--with-x-toolkit=athena' '-- 
enable-font-backend' '--enable-locallisppath=/Library/Application  
Support/Emacs/calendar23:/Library/Application Support/Emacs/caml:/ 
Library/Application Support/Emacs:/sw/share/emacs21/site-lisp/elib'  
'PKG_CONFIG_PATH=/sw/lib/freetype219/lib/pkgconfig:/sw/lib/ 
fontconfig2/lib/pkgconfig:/sw/lib/pkgconfig:/sw/lib/system-openssl/ 
lib/pkgconfig:/sw/share/pkgconfig:/usr/lib/pkgconfig:/usr/local/lib/ 
pkgconfig:/usr/local/clamXav/lib/pkgconfig:/usr/X11R6/lib/pkgconfig'  
'CPPFLAGS=-no-cpp-precomp -D__BIND_NOSTATIC -I/sw/lib/fontconfig2/ 
include -I/sw/lib/freetype219/include -I/sw/lib/freetype219/include/ 
freetype2 -idirafter /usr/X11R6/include' 'CFLAGS=-ggdb -gfull - 
bind_at_load -Wno-pointer-sign -pipe -fPIC -mcpu=7450 -mtune=7450 - 
mno-powerpc64 -fast -mpim-altivec -ftree-vectorize -freorder-blocks- 
and-partition -fno-crossjumping' 'LDFLAGS=-bind_at_load -dead_strip - 
multiply_defined suppress -L/sw/lib/fontconfig2/lib -L/sw/lib/ 
freetype219/lib''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: de_DE.UTF-8
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: de_DE.UTF-8
   value of $XMODIFIERS: nil
   locale-coding-system: utf-8-unix
   default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   global-auto-composition-mode: t
   auto-composition-mode: t
   auto-compression-mode: t
   line-number-mode: t

--
Mit friedvollen Grüßen

   Pete

Alles Vernünftige ist einfach; alles Komplizierte ist überflüssig.	 
(M. Kalaschnikow)

Re: 23.0.60; TRAMP does not pass regime

[Michael Albinus]

Peter Dyballa <Peter_Dyballa@freenet.de> writes:

> Hello!

Hi,

> When I'm in a dired buffer fed via TRAMP from a remote server and I
> type: 'C-x d /pat TAB' (leading to a path name construct in mini- 
> buffer of ``/ssh:root@tisnam.tisdom.de:/var/log//patŽŽ with the part
> until // in invalidating grey instead of usual black as soon as GNU
> Emacs sees the two slashes) TRAMP does not understand that the
> leading slash introduces a new (and particularly local) absolute path
> (adding as another try /ssh:root@tisnam.tisdom.de:/var/log/apache2 to
> the previous remote path pattern, makes TRAMP look for something  like
> /ssh:root@tisnam.tisdom.de:/ssh:root@tisnam.tisdom.de:/var/log/
> apache2, it does an ls of /ssh:root@tisnam.tisdom.de:/var/log/apache2
> on the remote server). It tries to expand the path name with // on
> the remote server and does not seem to be able to finish/time-out
> this nonsense – or I was not patient enough.

That is a feature. See (info "(tramp)Filename completion")

"This works pretty much like for files on the local host, with the
 exception that minibuffer killing via a double-slash works only on the
 filename part, except that filename part starts with `//'.  A
 triple-slash stands for the default behaviour."

The idea behind is, that it is more likely to open another file on the
remote host, than to open a file from somwhere else.

The greyed part of the filename tries to show this visually.

Best regards, Michael.

Re: 23.0.60; TRAMP does not pass regime

[Peter Dyballa]

Am 15.03.2008 um 10:59 schrieb Michael Albinus:

> That is a feature. See (info "(tramp)Filename completion")
>
> "This works pretty much like for files on the local host, with the
>  exception that minibuffer killing via a double-slash works only on  
> the
>  filename part, except that filename part starts with `//'.  A
>  triple-slash stands for the default behaviour."


I don't understand: what is the "default behaviour?" That // starts a  
new path name? Does this paragraph tell me to use /// to start a new  
path?

> The idea behind is, that it is more likely to open another file on the
> remote host, than to open a file from somwhere else.


In which case is // part of remote path name? And on what system? DOS  
with its C://...?

--
Mit friedvollen Grüßen

   Pete

»¿ʇı̣ əsnqɐ ʇ,uɐɔ noʎ ɟı̣
ɓuı̣ɥʇʎuɐ sı̣ pooɓ ʇɐɥʍ«

Re: 23.0.60; TRAMP does not pass regime

[Michael Albinus]

Peter Dyballa <Peter_Dyballa@freenet.de> writes:

> I don't understand: what is the "default behaviour?" That // starts a
> new path name? Does this paragraph tell me to use /// to start a new
> path?

Could you, please, check the examples in the manual at
(info "(tramp)Filename completion") ? They try to explain what happens.

(And I'm always happy, if somebody could provide documentation with
better English than mine)

Best regards, Michael.