Tramp and BusyBox problem?

Tramp and BusyBox problem?

[Mats Löfdahl]

I'm trying to connect with tramp to my NAS (a Synology CubeStation 407), 
which is running linux and BusyBox. Regular ssh works fine and when I 
try to connect from emacs it looks like everything is going fine through 
the tramp setting up procedure, until I get to the following point:

...
tramp: Testing remote command `/bin/ls' for -n...okay
tramp: Using remote command `/bin/ls' for getting directory listings
tramp: Sending the Perl script `tramp_file_attributes'...done.
tramp-handle-file-attributes: Wrong type argument: listp, if

Of course, I don't know if BusyBox is to blame here, it's just that it's 
the thing in my NAS that I know differs from the systems I usually 
connect to.

Any ideas?

Re: Tramp and BusyBox problem?

[Mats Löfdahl]

Mats Löfdahl wrote:
> I'm trying to connect with tramp to my NAS (a Synology CubeStation 407), 
> which is running linux and BusyBox. Regular ssh works fine and when I 
> try to connect from emacs it looks like everything is going fine through 
> the tramp setting up procedure, until I get to the following point:
> 
> ...
> tramp: Testing remote command `/bin/ls' for -n...okay
> tramp: Using remote command `/bin/ls' for getting directory listings
> tramp: Sending the Perl script `tramp_file_attributes'...done.
> tramp-handle-file-attributes: Wrong type argument: listp, if
> 
> Of course, I don't know if BusyBox is to blame here, it's just that it's 
> the thing in my NAS that I know differs from the systems I usually 
> connect to.
> 
> Any ideas?

Might be easier if I remember to give some information about my environment:

emacs-version:
GNU Emacs 22.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.14.7) of 
2009-02-09 on x86-1.fedora.phx.redhat.com

tramp-version:
2.0.58-pre

Re: Tramp and BusyBox problem?

[Michael Albinus]

Mats Löfdahl <mats_lofdahl@yahoo.se> writes:

>> tramp: Testing remote command `/bin/ls' for -n...okay
>> tramp: Using remote command `/bin/ls' for getting directory listings
>> tramp: Sending the Perl script `tramp_file_attributes'...done.
>> tramp-handle-file-attributes: Wrong type argument: listp, if

Could you, please, show the backtrace?

> Might be easier if I remember to give some information about my environment:
>
> emacs-version:
> GNU Emacs 22.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.14.7) of
> 2009-02-09 on x86-1.fedora.phx.redhat.com
>
> tramp-version:
> 2.0.58-pre

Tramp 2.0 hasn't seen so many corrections last time. Would it be an
option for you to switch to Tramp 2.1?

Best regards, Michael.

Re: Tramp and BusyBox problem?

[Mats Löfdahl]

Michael Albinus wrote:
> Mats Löfdahl <mats_lofdahl@yahoo.se> writes:
> 
>>> tramp: Testing remote command `/bin/ls' for -n...okay
>>> tramp: Using remote command `/bin/ls' for getting directory listings
>>> tramp: Sending the Perl script `tramp_file_attributes'...done.
>>> tramp-handle-file-attributes: Wrong type argument: listp, if
> 
> Could you, please, show the backtrace?
> 
>> Might be easier if I remember to give some information about my environment:
>>
>> emacs-version:
>> GNU Emacs 22.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.14.7) of
>> 2009-02-09 on x86-1.fedora.phx.redhat.com
>>
>> tramp-version:
>> 2.0.58-pre
> 
> Tramp 2.0 hasn't seen so many corrections last time. Would it be an
> option for you to switch to Tramp 2.1?

OK, I installed Tramp 2.1.9. Same problem! I tried to mouse-copy a 
backtrace into this message but failed, there's some byte code in there 
that apparently wasn't liked much by the mouse...

I saved it to a file instead: 
http://www.solarphysics.kva.se/~mats/backtrace.txt

Thanks for responding!

/Mats

Re: Tramp and BusyBox problem?

[Michael Albinus]

Mats Löfdahl <mats_lofdahl@yahoo.se> writes:

> Michael Albinus wrote:
>> Mats Löfdahl <mats_lofdahl@yahoo.se> writes:
>>
>>>> tramp: Testing remote command `/bin/ls' for -n...okay
>>>> tramp: Using remote command `/bin/ls' for getting directory listings
>>>> tramp: Sending the Perl script `tramp_file_attributes'...done.
>>>> tramp-handle-file-attributes: Wrong type argument: listp, if
>>
>> Could you, please, show the backtrace?
>>
>>> Might be easier if I remember to give some information about my environment:
>>>
>>> emacs-version:
>>> GNU Emacs 22.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.14.7) of
>>> 2009-02-09 on x86-1.fedora.phx.redhat.com
>>>
>>> tramp-version:
>>> 2.0.58-pre
>>
>> Tramp 2.0 hasn't seen so many corrections last time. Would it be an
>> option for you to switch to Tramp 2.1?
>
> OK, I installed Tramp 2.1.9. Same problem! I tried to mouse-copy a
> backtrace into this message but failed, there's some byte code in
> there that apparently wasn't liked much by the mouse...
>
> I saved it to a file instead:
> http://www.solarphysics.kva.se/~mats/backtrace.txt

You have problems with an echoing shell, which is known for
Busybox. There are some Tramp patches wrt this, even after release of
2.1.9. Why did you choose this? Tramp 2.1.15 is the recent version.

> Thanks for responding!
>
> /Mats

Best regards, Michael.

Re: Tramp and BusyBox problem?

[Mats Löfdahl]

Michael Albinus wrote:
> Mats Löfdahl <mats_lofdahl@yahoo.se> writes:
> 
>> Michael Albinus wrote:
>>> Mats Löfdahl <mats_lofdahl@yahoo.se> writes:
>>>
>>>>> tramp: Testing remote command `/bin/ls' for -n...okay
>>>>> tramp: Using remote command `/bin/ls' for getting directory listings
>>>>> tramp: Sending the Perl script `tramp_file_attributes'...done.
>>>>> tramp-handle-file-attributes: Wrong type argument: listp, if
>>> Could you, please, show the backtrace?
>>>
>>>> Might be easier if I remember to give some information about my environment:
>>>>
>>>> emacs-version:
>>>> GNU Emacs 22.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.14.7) of
>>>> 2009-02-09 on x86-1.fedora.phx.redhat.com
>>>>
>>>> tramp-version:
>>>> 2.0.58-pre
>>> Tramp 2.0 hasn't seen so many corrections last time. Would it be an
>>> option for you to switch to Tramp 2.1?
>> OK, I installed Tramp 2.1.9. Same problem! I tried to mouse-copy a
>> backtrace into this message but failed, there's some byte code in
>> there that apparently wasn't liked much by the mouse...
>>
>> I saved it to a file instead:
>> http://www.solarphysics.kva.se/~mats/backtrace.txt
> 
> You have problems with an echoing shell, which is known for
> Busybox. There are some Tramp patches wrt this, even after release of
> 2.1.9. Why did you choose this? Tramp 2.1.15 is the recent version.

Why? Because I'm stupid and 2.1.9 is sorted alphabetically after 2.1.15 
on the download webpage... :o)

But installing 2.1.15 does not remove the problem. A fresh backtrace is 
available from the same URL: 
http://www.solarphysics.kva.se/~mats/backtrace.txt

The error message in the *Messages* buffer is now (with some context):

...
Tramp: Sending password
Tramp: Found remote shell prompt on `10.0.0.3'
File error: Couldn't find exit status of `echo \"`uname -sr`\"'

/Mats

Re: Tramp and BusyBox problem?

[Michael Albinus]

Mats Löfdahl <mats_lofdahl@yahoo.se> writes:

>>>>>> tramp: Testing remote command `/bin/ls' for -n...okay
>>>>>> tramp: Using remote command `/bin/ls' for getting directory listings
>>>>>> tramp: Sending the Perl script `tramp_file_attributes'...done.
>>>>>> tramp-handle-file-attributes: Wrong type argument: listp, if

> Tramp: Sending password
> Tramp: Found remote shell prompt on `10.0.0.3'
> File error: Couldn't find exit status of `echo \"`uname -sr`\"'

That's another problem. I would need Tramp traces now. Please apply

(set tramp-verbose 6)

and rerun your test. Afterwards, send the *debug tramp/scp root@10.0.0.3*
buffer.

> /Mats

Best regards, Michael.

Re: Tramp and BusyBox problem?

[Mats Löfdahl]

Michael Albinus wrote:
> Mats Löfdahl <mats_lofdahl@yahoo.se> writes:
> 
>>>>>>> tramp: Testing remote command `/bin/ls' for -n...okay
>>>>>>> tramp: Using remote command `/bin/ls' for getting directory listings
>>>>>>> tramp: Sending the Perl script `tramp_file_attributes'...done.
>>>>>>> tramp-handle-file-attributes: Wrong type argument: listp, if
> 
>> Tramp: Sending password
>> Tramp: Found remote shell prompt on `10.0.0.3'
>> File error: Couldn't find exit status of `echo \"`uname -sr`\"'
> 
> That's another problem. I would need Tramp traces now. Please apply
> 
> (set tramp-verbose 6)
> 
> and rerun your test. Afterwards, send the *debug tramp/scp root@10.0.0.3*
> buffer.

The buffer is called *tramp/scp root@10.0.0.3*, without the "debug" 
part, at least I guess this is what you need:

----begin----
set +o vi +o emacs
/bin/sh: set: Illegal option -o emacs
echo \"`uname -sr`\" 2>/dev/null; echo tram \bp_exit_status $?
"Linux 2.6.15"
tramp_exit_status 0

///690e72efcac87c597846ebc18c28f2ce
----end----


Another weird thing: The above is from connecting to root@ the NAS. I've 
now installed bash on it and use that as my shell when I log in as an 
ordinary user. This works but the dired buffer looks weird, there are 
some codes surrounding the file names that I guess should have been 
stripped at some point.

Here's an extract:

----begin----
   /scp:mats@10.0.0.3:/:
   drwxr-xr-x   21 root     root         4096 Mar  9 00:41 ^[[1;34m.^[[0m
   drwxr-xr-x   21 root     root         4096 Mar  9 00:41 ^[[1;34m..^[[0m
   -rw-r--r--    1 root     root            3 Aug 18  2004 
^[[0;0m.mkcert.serial^[[0m
   -rw-r--r--    1 root     root            0 Feb 23 21:55 
^[[0;0m.needquotacheck^[[0m
   -rw-------    1 root     root         1024 Aug 18  2004 ^[[0;0m.rnd^[[0m
   -rw-r--r--    1 root     root            2 Mar  9 23:16 
^[[0;0m.upgrade_vol^[[0m
   drwxr-xr-x    2 root     root         4096 Feb 23 21:54 ^[[1;34mbin^[[0m
   drwxr-xr-x    3 root     root        12288 Feb 23 21:55 ^[[1;34mdev^[[0m
   drwxr-xr-x   10 root     root         4096 Mar 13 23:51 ^[[1;34metc^[[0m
----end----

The non-ascii characters are represented as "^[" in the dired buffer but 
may not have survived the mouse copy to thunderbird.

/Mats

Re: Tramp and BusyBox problem?

[Michael Albinus]

Mats Löfdahl <mats_lofdahl@yahoo.se> writes:

>> That's another problem. I would need Tramp traces now. Please apply
>>
>> (set tramp-verbose 6)
>>
>> and rerun your test. Afterwards, send the *debug tramp/scp root@10.0.0.3*
>> buffer.
>
> The buffer is called *tramp/scp root@10.0.0.3*, without the "debug"
> part, at least I guess this is what you need:

Sorry, typo. I meant

(setq tramp-verbose 6)

And I still need the *debug ...* buffer.

> Another weird thing: The above is from connecting to root@ the
> NAS. I've now installed bash on it and use that as my shell when I log
> in as an ordinary user. This works but the dired buffer looks weird,
> there are some codes surrounding the file names that I guess should
> have been stripped at some point.
>
> Here's an extract:
>
> ----begin----
>   /scp:mats@10.0.0.3:/:
>   drwxr-xr-x   21 root     root         4096 Mar  9 00:41 .
>   drwxr-xr-x   21 root     root         4096 Mar  9 00:41 ..
>   -rw-r--r--    1 root     root            3 Aug 18  2004
> .mkcert.serial
>   -rw-r--r--    1 root     root            0 Feb 23 21:55
> .needquotacheck
>   -rw-------    1 root     root         1024 Aug 18  2004 .rnd
>   -rw-r--r--    1 root     root            2 Mar  9 23:16
> .upgrade_vol
>   drwxr-xr-x    2 root     root         4096 Feb 23 21:54 bin
>   drwxr-xr-x    3 root     root        12288 Feb 23 21:55 dev
>   drwxr-xr-x   10 root     root         4096 Mar 13 23:51 etc
> ----end----
>
> The non-ascii characters are represented as "^[" in the dired buffer
> but may not have survived the mouse copy to thunderbird.

Her I need the debug buffer as well. Maybe you can run both constellations?

> /Mats

Best regards, Michael.

Re: Tramp and BusyBox problem?

[Mats Löfdahl]

Michael Albinus wrote:
> Mats Löfdahl <mats_lofdahl@yahoo.se> writes:
> 
>>> That's another problem. I would need Tramp traces now. Please apply
>>>
>>> (set tramp-verbose 6)
>>>
>>> and rerun your test. Afterwards, send the *debug tramp/scp root@10.0.0.3*
>>> buffer.
>> The buffer is called *tramp/scp root@10.0.0.3*, without the "debug"
>> part, at least I guess this is what you need:
> 
> Sorry, typo. I meant
> 
> (setq tramp-verbose 6)
> 
> And I still need the *debug ...* buffer.

Right...


>> Another weird thing: The above is from connecting to root@ the
>> NAS. I've now installed bash on it and use that as my shell when I log
>> in as an ordinary user. This works but the dired buffer looks weird,
>> there are some codes surrounding the file names that I guess should
>> have been stripped at some point.
>>
>> Here's an extract:
>>
>> ----begin----
>>   /scp:mats@10.0.0.3:/:
>>   drwxr-xr-x   21 root     root         4096 Mar  9 00:41 .
>>   drwxr-xr-x   21 root     root         4096 Mar  9 00:41 ..
>>   -rw-r--r--    1 root     root            3 Aug 18  2004
>> .mkcert.serial
>>   -rw-r--r--    1 root     root            0 Feb 23 21:55
>> .needquotacheck
>>   -rw-------    1 root     root         1024 Aug 18  2004 .rnd
>>   -rw-r--r--    1 root     root            2 Mar  9 23:16
>> .upgrade_vol
>>   drwxr-xr-x    2 root     root         4096 Feb 23 21:54 bin
>>   drwxr-xr-x    3 root     root        12288 Feb 23 21:55 dev
>>   drwxr-xr-x   10 root     root         4096 Mar 13 23:51 etc
>> ----end----
>>
>> The non-ascii characters are represented as "^[" in the dired buffer
>> but may not have survived the mouse copy to thunderbird.
> 
> Her I need the debug buffer as well. Maybe you can run both constellations?

It was different this time. When I connected as mats (bash), I first got 
the same uname error message as for root (BusyBox). But I knew that it 
_had_ worked, so I tried again and got the ugly dired buffer.

So I did the same experiment with root in a fresh instance of emacs. 
This generated the uname error but did _not_ work at the second attempt.

The debug buffers from the two sessions are here:

http://www.solarphysics.kva.se/~mats/debug1.txt - root/BusyBox
http://www.solarphysics.kva.se/~mats/debug2.txt - mats/bash

Re: Tramp and BusyBox problem?

[Michael Albinus]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

Mats Löfdahl <mats_lofdahl@yahoo.se> writes:

[I fear my answer from yesterday has been lost. Reposted, therefore.]

> It was different this time. When I connected as mats (bash), I first
> got the same uname error message as for root (BusyBox). But I knew
> that it _had_ worked, so I tried again and got the ugly dired buffer.
>
> So I did the same experiment with root in a fresh instance of
> emacs. This generated the uname error but did _not_ work at the second
> attempt.
>
> The debug buffers from the two sessions are here:
>
> http://www.solarphysics.kva.se/~mats/debug1.txt - root/BusyBox
> http://www.solarphysics.kva.se/~mats/debug2.txt - mats/bash

Looks like there is a race condition. Could you, please, check the
appended patch?

Best regards, Michael.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 916 bytes --]

*** /home/albinus/src/tramp/lisp/tramp.el.2.677	2009-03-17 21:31:51.000000000 +0100
--- /home/albinus/src/tramp/lisp/tramp.el	2009-03-17 21:52:16.000000000 +0100
***************
*** 5859,5869 ****
  	  (delete-region begin (point))
  	  (goto-char (point-min)))))
  
!     (when (or
! 	   ;; No echo to be handled, now we can look for the regexp.
! 	   (not (tramp-get-connection-property proc "check-remote-echo" nil))
! 	   ;; Sometimes the echo is invisible.
! 	   (not (re-search-forward tramp-echo-mark-marker nil t)))
        (goto-char (point-min))
        (re-search-forward regexp nil t))))
  
--- 5859,5866 ----
  	  (delete-region begin (point))
  	  (goto-char (point-min)))))
  
!     (when (not (tramp-get-connection-property proc "check-remote-echo" nil))
!       ;; No echo to be handled, now we can look for the regexp.
        (goto-char (point-min))
        (re-search-forward regexp nil t))))
  

Re: Tramp and BusyBox problem?

[Mats Löfdahl]

Michael Albinus wrote:
> Mats Löfdahl <mats_lofdahl@yahoo.se> writes:
> 
> [I fear my answer from yesterday has been lost. Reposted, therefore.]
> 
>> It was different this time. When I connected as mats (bash), I first
>> got the same uname error message as for root (BusyBox). But I knew
>> that it _had_ worked, so I tried again and got the ugly dired buffer.
>>
>> So I did the same experiment with root in a fresh instance of
>> emacs. This generated the uname error but did _not_ work at the second
>> attempt.
>>
>> The debug buffers from the two sessions are here:
>>
>> http://www.solarphysics.kva.se/~mats/debug1.txt - root/BusyBox
>> http://www.solarphysics.kva.se/~mats/debug2.txt - mats/bash
> 
> Looks like there is a race condition. Could you, please, check the
> appended patch?

Sure. And thanks!

I applied the patch and byte-compiled tramp.el. Looks like I did it right:

[root@localhost site-lisp]# diff tramp.el tramp.el.orig
5855,5856c5855,5859
<     (when (not (tramp-get-connection-property proc "check-remote-echo" 
nil))
<       ;; No echo to be handled, now we can look for the regexp.
---
 >     (when (or
 > 	   ;; No echo to be handled, now we can look for the regexp.
 > 	   (not (tramp-get-connection-property proc "check-remote-echo" nil))
 > 	   ;; Sometimes the echo is invisible.
 > 	   (not (re-search-forward tramp-echo-mark-marker nil t)))
[root@localhost site-lisp]# ls -l tramp.el*
-rw-r--r-- 1 root root 303964 2009-03-17 23:19 tramp.el
-rw-r--r-- 1 root root 285934 2009-03-17 23:20 tramp.elc
-rw-r--r-- 1 root root 304070 2009-03-08 17:37 tramp.el.orig

I then started a fresh emacs and did the double attempt to connect as 
root. To me it looked just like last time but I've uploaded the debug 
buffer anyway: http://www.solarphysics.kva.se/~mats/debug3.txt

Re: Tramp and BusyBox problem?

[Michael Albinus]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

Mats Löfdahl <mats_lofdahl@yahoo.se> writes:

> I then started a fresh emacs and did the double attempt to connect as
> root. To me it looked just like last time but I've uploaded the debug
> buffer anyway: http://www.solarphysics.kva.se/~mats/debug3.txt

Things progress. Still an error, but at another place.

Tramp has two problems with your Busybox: it echoes the commands, and it
is slow. This case, when Tramp has send "PS1='$ '", only the "PS1='$"
substring was visible in the output buffer, and Tramp thought it is a
shell prompt. Then it has sent the next command, and it began to be
confused by the not read characters.

So we must convince Tramp there isn't a shell prompt, even if the
command itself is echoed, and even if only a substring of the whole
command is visible.

The appended patch tries to catch this situation. Could you, please,
test?

Thanks, and best regards, Michael.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1155 bytes --]

*** /tmp/tramp.el.~2.678.~	Thu Mar 19 17:35:00 2009
--- /tmp/tramp.el	Thu Mar 19 17:35:00 2009
***************
*** 5669,5675 ****
  	  (let ((tramp-end-of-output "$ "))
  	    (tramp-send-command
  	     vec
! 	     (format "PROMPT_COMMAND='' PS1='$ ' PS2='' PS3='' exec %s" shell)
  	     t))
  	  ;; Setting prompts.
  	  (tramp-message vec 5 "Setting remote shell prompt...")
--- 5669,5675 ----
  	  (let ((tramp-end-of-output "$ "))
  	    (tramp-send-command
  	     vec
! 	     (format "PROMPT_COMMAND='' PS1=\\$\\  PS2='' PS3='' exec %s" shell)
  	     t))
  	  ;; Setting prompts.
  	  (tramp-message vec 5 "Setting remote shell prompt...")
***************
*** 5951,5957 ****
      (tramp-send-command
       vec
       (format
!       "exec env ENV='' PROMPT_COMMAND='' PS1='$ ' PS2='' PS3='' %s"
        (tramp-get-method-parameter
         (tramp-file-name-method vec) 'tramp-remote-sh))
       t)
--- 5951,5957 ----
      (tramp-send-command
       vec
       (format
!       "exec env ENV='' PROMPT_COMMAND='' PS1=\\$\\  PS2='' PS3='' %s"
        (tramp-get-method-parameter
         (tramp-file-name-method vec) 'tramp-remote-sh))
       t)

Re: Tramp and BusyBox problem?

[Mats Löfdahl]

Michael Albinus wrote:
> Mats Löfdahl <mats_lofdahl@yahoo.se> writes:
> 
>> I then started a fresh emacs and did the double attempt to connect as
>> root. To me it looked just like last time but I've uploaded the debug
>> buffer anyway: http://www.solarphysics.kva.se/~mats/debug3.txt
> 
> Things progress. Still an error, but at another place.
> 
> Tramp has two problems with your Busybox: it echoes the commands, and it
> is slow. This case, when Tramp has send "PS1='$ '", only the "PS1='$"
> substring was visible in the output buffer, and Tramp thought it is a
> shell prompt. Then it has sent the next command, and it began to be
> confused by the not read characters.

I guess this is consistent with my varying success with the bash test. 
If it's dependent on timing, the NAS could have been doing different 
things during the two tests, one that worked and one that failed.

> So we must convince Tramp there isn't a shell prompt, even if the
> command itself is echoed, and even if only a substring of the whole
> command is visible.
> 
> The appended patch tries to catch this situation. Could you, please,
> test?

Tested as before. Yes, this improves things. I now get to the dired 
buffer! This dired buffer looks badly formatted in the way described 
before, when I managed to connect with another user running bash.

A debug buffer was still created, it is available as 
http://www.solarphysics.kva.se/~mats/debug4.txt

An error was echoed. I guess the info is in the debug buffer but here it 
is from the *Messages* buffer as well:

----begin----
...
Loading tramp...done
Loading easymenu...done
Loading tramp...done
Loading time-date...done
Tramp: Opening connection for root@10.0.0.3 using scp...
Loading outline...
Loading easy-mmode...done
Loading outline...done
Tramp: Waiting 60s for local shell to come up...
Tramp: Sending command `ssh 10.0.0.3 -l root  -q -e none && exit || exit'
Tramp: Waiting for prompts from remote shell
Tramp: Sending password
Tramp: Found remote shell prompt on `10.0.0.3'
File error: `getconf PATH' returns with error
Tramp: `getconf PATH' not successful, using default value "/bin:/usr/bin".
Making completion list...
Quit
Making completion list...
Wrote /home/mats/debug4.txt
byte-code: Beginning of buffer
----end----


Back to the badly formatted dired buffer: In addition to it looking 
funny, completion to existing file names does not work. Neither does 
clicking on the file names. It fails to open the file and an error is 
echoed: "dired-get-file-for-visit: File no longer exists; type `g' to 
update dired buffer"

Thanks for spending time on this!

/Mats

Re: Tramp and BusyBox problem?

[Michael Albinus]

Mats Löfdahl <mats_lofdahl@yahoo.se> writes:

> An error was echoed. I guess the info is in the debug buffer but here
> it is from the *Messages* buffer as well:
>
> ----begin----
> ...
> File error: `getconf PATH' returns with error
> Tramp: `getconf PATH' not successful, using default value "/bin:/usr/bin".

That's not a problem. Your Busybox does not support the "getconf"
command; Tramp detects this, and uses (correcty, as I can see) default
values.

> Back to the badly formatted dired buffer: In addition to it looking
> funny, completion to existing file names does not work. Neither does
> clicking on the file names. It fails to open the file and an error is
> echoed: "dired-get-file-for-visit: File no longer exists; type `g' to
> update dired buffer"

That's another problem. Let's look into the debug buffer:

21:03:39 tramp-send-command (6) # _echo\b\b\b\b\b/bin/ls -al /._echo\b\b\b\b\b

Tramp has detected that Busybox echoes commands, and makes a trick to
mask the echo. The sent command is "/bin/ls -al /.".

21:03:39 tramp-check-for-regexp (5) # echo-mark found
21:03:39 tramp-wait-for-regexp (6) # 

drwxr-xr-x   21 root     root         4096 Mar 15 22:03 ^[[1;34m.^[[0m
drwxr-xr-x   21 root     root         4096 Mar 15 22:03 ^[[1;34m..^[[0m
-rw-r--r--    1 root     root            3 Aug 18  2004 ^[[0;0m.mkcert.serial^[[0m

And so on. Your "ls" command returns escape sequences, in order to
colorize the output! Poor Tramp does not understand.

See the Tramp manual, section "Frequently Asked Question", where the
case of colorized "ls" output is discussed. Please suppress this in your
~/.profile on Busybox. You could use a check for $TERM in order to
suppress it only when Tramp connects, as it is discussed for the zsh in
that section.

> Thanks for spending time on this!
>
> /Mats

Best regards, Michael.