[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [BUG] TRAMP 2.1.20: "uudecode -o /dev/stdout" check

From: Michael Albinus
Subject: Re: [BUG] TRAMP 2.1.20: "uudecode -o /dev/stdout" check
Date: Thu, 15 Dec 2011 19:32:59 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Dmitry Kurochkin <address@hidden> writes:

> Hi Michael.

Hi Dmitry,

>> Thanks for confirmation, I've committed the patch to the Tramp
>> repository. Will appear with Tramp 2.2.4.
> Cool.  So it will be part of Emacs 24, right?

Nope. Emacs 24.1 is sync'ed with Tramp 2.2.3, due to the pretest of
Emacs I'll commit only additional fixes for serious bugs. This one
you've reported does not seem to touch the majority of users.

>> I beg you pardon, but it does check it. Could you, please, detail what
>> you are missing?
> Here is the code that checks if a remote encoder and decoder work:
>                  "Checking remote decoding command `%s' for sanity" rem-dec)
>                 (unless (tramp-send-command-and-check
>                          vec
>                          (format "echo %s | %s | %s" magic rem-enc rem-dec)
>                          t)
>                   (throw 'wont-work-remote nil))
> (this is from Emacs trunk, but the code in the patch you sent is
> essentially the same)
> It checks that the command exits with zero status code, but does not
> check that it's output is the same as input, i.e. `magic'.  If it did,
> then I would not found the original issue, because "uudecode -o
> /dev/stdout" does not output anything on the affected system and the
> check would fail (it would still create /dev/stdout file, but I would
> not notice that).

And the next lines read

                  (with-current-buffer (tramp-get-buffer vec)
                    (goto-char (point-min))
                    (unless (looking-at (regexp-quote magic))
                      (throw 'wont-work-remote nil)))

This code checks the returned string, as contained in the connection

I don't know, why this check hasn't raised an alarm on your remote system.

> Regards,
>   Dmitry

Best regards, Michael.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]