bug#35639: 27.0.50; tramp fails to use ssh on LibreCMC (no base64 encoder available, and not mentioned in tramp manual)

[Michael Albinus]

Jeronimo Pellegrini <j_p@aleph0.info> writes:

> Hi Michael,

Hi Jeronimo,

> Yes. Instead of  od:
>  od -v -t x1 -A n
>
> it would be possible to use hexdump:
>  hexdump -v -e '16/1 " %02x" "\n"'

Yes, looks good.

> However... hexdump may not be present in all Linux/*BSD/*ix systems.
> At least in Debian, it is in package bsdmainutils, which is
> not required. (od, on the other hand, is in package coreutils, which
> is required)

See, how we do it with the other programs: we test one after the other,
until it succeeds. So it is perfect to have a second entry for awk in
tramp-remote-coding-commands.

> Would it be OK to have two different variables, and two tests for
> od+awk and hexdump+awk?
>
> tramp-od-awk-coding-test
> tramp-od-awk-{encode,decode}
>
> tramp-hexdump-awk-coding-test
> tramp-hexdump-awk-{encode-decode}

Well, decoding does not use od. So it might be sufficient to have

tramp-od-awk-coding-test
tramp-od-awk-encode
tramp-hexdump-awk-coding-test
tramp-hexdump-awk-encode
tramp-awk-decode}


>> > What happened is that (rem-enc ...) failed (because tramp could not use
>> > any encoding command), and fell through into the default action, which
>> > is this error.
>>
>> Maybe we should enhance the error message.
>
> Perhaps
>
> (tramp-error v 'file-error "Cannot find any way to encode data using
> `%s'" method)
>
> would be more precise?
>
> Or, if (tramp-local-host-p v) (tramp-method-out-of-band-p v size) are
> false, explicitly write that "encoding binaries were not found on the
> remote end"?

Yes, something like this. Do you want to prepare such a patch (which
should also include the tramp.texi changes)?

Hmm, looks like this could extend the 15 lines limit, which is the upper
limit for contributions to Emacs/Tramp, w/o having signed the FSF legal
papers (where you declare the copyright of your work be given to the
FSF). Would you like to sign such a paper? It would help also for future
contributions to Emacs or one of its packages.

> J.

Best regards, Michael.