perl local decoding leads to empty buffers

[David Smith]

Hi!

I'm trying to use tramp to edit files via ssh from an openwrt box.
When I attempt find-file on a tramp filename for that box, tramp
appears to work, no errors are reported, but the resulting buffer
contains no contents for files that have contents. I'm using tramp
2.2.3-24.1 bundled with emacs 24.1 on ubuntu 12.10.

I debugged the problem a bit and have a workaround but I doubt it is
the best solution. Can you please help me understand what the right
fix should be? I'm happy to test.

What I noticed is that from tramp-sh-handle-file-local-copy, the
remote-encoding and local-decoding commands are gotten from
tramp-get-inline-coding, then passed to
tramp-call-local-coding-command. The decoding command looks like this
initially:

  perl -e 'binmode STDIN; binmode STDOUT; print unpack(q{u*}, join q{}, <>)'

And when returned from tramp-get-inline-coding, a >%s is appended, producing

  perl -e 'binmode STDIN; binmode STDOUT; print unpack(q{u*}, join q{}, <>)' >%s

tramp-call-local-coding-command take three args: cmd, input, and
output. tramp-sh-handle-file-local-copy invokes
tramp-call-local-coding-command with the perl command with >%s
appended for cmd, the temporary file containing the output of the
remote-encoding perl command as input, and a second temporary file as
output. tramp-call-local-coding-command also interprets any %s in cmd
as a place to put the input filename. The bug manifests when
tramp-call-local-coding-command interpolates the %s in the cmd to the
first temporary file containing the input, making perl overwrite the
encoded contents, and giving me my empty result buffer for output.

My workaround is to modify tramp-get-inline-coding such that it does
not add >%s to the local decoding command. I've attached a patch. It
seems deceptively easy and I am probably not realizing some case where
this is wrong. Please take a look.

Cheers,
David

tramp-sh.el.patch
Description: Binary data