Couldn't find exit status of `/bin/ls^M -lnd /'

Hi,

I use 
 * openSUSE 11.0
 * gnu-emacs 22.2.1
 * tramp 2.1.14

On most remote hosts tramp works fine (I use ssh as connect method).
However I have a problem work an a specific Linux-host (SUSE LINUX
Enterprise Server 9 (x86_64)), say blueeye.jim.de

I get the following message:

Tramp: Found remote shell prompt on `blueeye.jim.de'
File error: Couldn't find exit status of `/bin/ls
 -lnd /'
tramp-send-command-and-check: Couldn't find exit status of `/bin/ls
 -lnd /'

I can connect to this host with ssh as the same user as tramp is
connecting.
What is going on here ?

Best regards,
Thomas

--

-- 

Re: Couldn't find exit status of `/bin/ls^M -lnd /'

Thomas Porschberg <porschberg <at> osp-dd.de> writes:

> Hi,

Hi Thomas,

> I get the following message:
>
> Tramp: Found remote shell prompt on `blueeye.jim.de'
> File error: Couldn't find exit status of `/bin/ls
>  -lnd /'

The "^M" in the ls command is the problem. However, I don't know where
it comes from.

Could you, please, try it again with enabled traces (see the manual)?
I would also like to see your "~/.emacs.d/tramp" file.

> Best regards,
> Thomas

Best regards, Michael.

Re: tramp (2.0.58-pre); rsync method fails

skip <at> pobox.com writes:

Hi,

> In the output appended I successfully visited a nonexistent
> file, /tmp/trash, but after entering some text in the buffer, the save
> step failed with the message "Login failed".

Neither I can see that error message in the trace, nor I can see a
call of rsync. Could you, please, check whether this are the related
traces? You might also increase tramp-verbose.

> As further evidence that it's somehow related to my network setup at
> work, I just popped open an XEmacs session and visited
> /[rsync/www.smontanaro.net]/tmp/trash.  Both the visit and the save
> worked fine.
>
> The rsync on the machine at work is
>
>     rsync  version 2.6.2  protocol version 28
>
> On my Mac it is
>
>     rsync  version 2.6.9  protocol version 29
>
> On www.smontanaro.net it is
>
>     rsync  version 3.0.3  protocol version 30
>
> Any suggestions?

Re: Tramp and GVFS

On Friday 06 February 2009 10:44:09 Michael Albinus wrote:

> I have added a new package tramp-gvfs.el to the CVS repository. The
> major new functionality are the new connection methods "dav", "davs",
> and "obex".
>
> If would be nice, if I could get feedback about.

I'm having some problems getting started.  Whenever I try to open a connection 
to a local server on it's WebDAV port (1980), using this filename:

    /dav:web2.xrsnet.com#1980:/

I get:

Tramp: Opening connection for web2.xrsnet.com#1980 using dav...
(dbus-event :session 3 8 ":1.728" nil nil nil ignore "HTTP Error: Cannot 
connect to destination")
File error: HTTP Error: Cannot connect to destination
tramp-gvfs-dbus-event-error: HTTP Error: Cannot connect to destination

I wasn't actually aware that gvfs existed before I started trying to use 
Tramp's new dav method, so I don't know where to start troubleshooting.  Any 
suggestions?
--

-- 
Kirk Strauser
Daycos

Re: Tramp and GVFS

Kirk Strauser <kirk <at> daycos.com> writes:

> I wasn't actually aware that gvfs existed before I started trying to use 
> Tramp's new dav method, so I don't know where to start troubleshooting.  Any 
> suggestions?

You shall check the gvfs version:

arthur:~> apt-cache policy gvfs
gvfs:
  Installed: 1.1.7-0ubuntu1
  Candidate: 1.1.7-0ubuntu1
  Version table:
 *** 1.1.7-0ubuntu1 0
        500 http://de.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

This is for Ubuntu 9.04. Older versions of GVFS shall work as well (I've
tested with 1.0.2).

You could check, whether the GVFS FUSE daemon runs:

arthur:~> ps -eaf | grep gvfs
albinus   4307     1  0 19:55 ?        00:00:00 /usr/lib/gvfs/gvfsd
albinus   4313     1  0 19:55 ?        00:00:00 /usr/lib/gvfs//gvfs-fuse-daemon /home/albinus/.gvfs
albinus   4421     1  0 19:55 ?        00:00:00 /usr/lib/gvfs/gvfs-hal-volume-monitor
albinus   4426     1  0 19:55 ?        00:00:00 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
albinus   4432     1  0 19:55 ?        00:00:00 /usr/lib/gvfs/gvfsd-trash --spawner :1.5 /org/gtk/gvfs/exec_spaw/0
albinus   4434     1  0 19:55 ?        00:00:00 /usr/lib/gvfs/gvfsd-burn --spawner :1.5 /org/gtk/gvfs/exec_spaw/1
albinus   5669     1  0 20:04 ?        00:00:00 /usr/lib/gvfs/gvfsd-dav --spawner :1.5 /org/gtk/gvfs/exec_spaw/2

Problem compiling remote files

Hi,

this is tramp 2.1.15 with emacs 23.0.91.1 (CVS as of yesterday) on
linux.

I have problems compiling remote files with M-x compile. Although
compilation works, emacs does never notice that it's finished, which
results in status `run' in the modeline and a warning when compiling
again.

Browsing the devel ml archives, I found that this problem was already
raised in 2007 [1] and Michael said he'd fixed it [2]. Am I missing
something obvious as I'm not following tramp development very closely,
or is this a bug that was somehow re-introduced?

Ulf

[1] http://lists.gnu.org/archive/html/tramp-devel/2007-01/msg00015.html
[2] http://lists.gnu.org/archive/html/tramp-devel/2007-01/msg00018.html

Re: Problem compiling remote files

Ulf Stegemann <ulf-news <at> zeitform.de> writes:

> Hi,

Hi,

> this is tramp 2.1.15 with emacs 23.0.91.1 (CVS as of yesterday) on
> linux.

I run Emacs 23.0.90 and Tramp 2.1.16-pre. Closed to your versions.

> I have problems compiling remote files with M-x compile. Although
> compilation works, emacs does never notice that it's finished, which
> results in status `run' in the modeline and a warning when compiling
> again.

I have tried it; no problem. Compilation exits as expected, modeline
changes.

Could you, please, send the contents of the compilation buffer? Tramp
debug buffer might be helpful as well.

> Ulf

Best regards, Michael.

Re: Problem compiling remote files

Hi,

Michael Albinus <michael.albinus <at> gmx.de> wrote:

> Ulf Stegemann <ulf-news <at> zeitform.de> writes:
>
>> this is tramp 2.1.15 with emacs 23.0.91.1 (CVS as of yesterday) on
>> linux.
>
> I run Emacs 23.0.90 and Tramp 2.1.16-pre. Closed to your versions.
>
>> I have problems compiling remote files with M-x compile. Although
>> compilation works, emacs does never notice that it's finished, which
>> results in status `run' in the modeline and a warning when compiling
>> again.
>
> I have tried it; no problem. Compilation exits as expected, modeline
> changes.
>
> Could you, please, send the contents of the compilation buffer? Tramp
> debug buffer might be helpful as well.

I was able to narrow down this a little bit. The problem occurs only
when trying to compile a file opened by multihop, in my case su via ssh.
When accessing the file directly, compile behaves as expected (I tried
ssh and scpc methods).

Anyway, you've asked for the compilation and debug buffers. The
compilation is started with an ordinary `make' and is about to create
the binary data file for tinydns (something that should be done as

Re: Problem compiling remote files

Ulf Stegemann <ulf-news <at> zeitform.de> writes:

> Hi,

Hi,

> I was able to narrow down this a little bit. The problem occurs only
> when trying to compile a file opened by multihop, in my case su via ssh.
> When accessing the file directly, compile behaves as expected (I tried
> ssh and scpc methods).

Good observation! The appended patch should fix it. It is towards Tramp
2.1.16-pre, line numbers might differ slightly.

> Ulf

Best regards, Michael.

_______________________________________________
Tramp-devel mailing list
Tramp-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/tramp-devel

Re: Problem compiling remote files

Hi Michael,

Michael Albinus <michael.albinus <at> gmx.de> wrote:

> Ulf Stegemann <ulf-news <at> zeitform.de> writes:
>
>> I was able to narrow down this a little bit. The problem occurs only
>> when trying to compile a file opened by multihop, in my case su via ssh.
>> When accessing the file directly, compile behaves as expected (I tried
>> ssh and scpc methods).
>
> Good observation! The appended patch should fix it. It is towards Tramp
> 2.1.16-pre, line numbers might differ slightly.

works like a charm. Thank you for fixing it :)

Ulf