wp.jochen.hayek.name/blog-en

Tag: tramp

maybe it should be a category

  • tracing Emacs Tramp

  • tramp says: “Cannot find local copy program: pscp” – but that does not mean there is something wrong with your emacs/tramp/PuTTY set-up

    Every now and then I come across this error message:

    Cannot find local copy program: pscp

    This only occurs for “bigger” files (e.g. a 40k file), not for small files, because small files are being dealt with by plink.

    tramp-do-copy-or-rename-file-out-of-band (in lisp/net/tramp-sh.el) tries to find the copy-program on exec-path instead of PATH, so we have to add putty-directory to exec-path as well. I amended this page to deal with the situation:

    Fixed  😆

  • Emacs’ “TRAMP” (again)

  • if saving a file through emacs’s “tramp” is not successful …

    On Windows …:

    PLINK.EXE is part of the PuTTY family, and it’s the utility tramp is communicating through. (You do know that, as tramp does not set itself up to make use of PuTTY.)

    On all platforms:

    Burying the tramp buffer in question is actually my 1st approach on all platforms (Linux/Mac/Windows), whenever tramp communication seems to be stuck. Afterwards with a “clean new start” everything is fine again in like 99% of the respective cases.

    Sometimes only taking emacs down seems to solve the issue.

  • Emacs and VC AKA Version Control and an excessive list of handled backends — the 2016-01 update

    I am accessing files remotely from within Emacs through Tramp over mobile Internet.

    I just remembered, how many file checks Emacs’ VC library does, if you don’t cut down its list vc-handled-backends. For every single backend listed there “we” are doing a “repository check”. Maybe that’s fast in a LAN, it may even be rather fast on a WAN, but you don’t really want to waste the transfer volume through all these checks, do you?

    Customise vc-handled-backends the Emacs way, and you will sleep better.

  • emacs/tramp/win/putty: what versions to choose in January 2016

    As recently I successfully ssh-connected to hosts beyond the corporate firewall using OpenSSH and PuTTY through a SOCKS5 proxy, I am now also able to create tramp-connections to “out there“.

  • emacs/tramp/win/putty: what versions to choose in March/April 2014

    After completing my recent “incident article” on emacs/tramp/win/putty [link], I thought I should prepare an article with a clear subject resp. statement. This is it.

    I sort of think resp. hope, that all currently released versions work together well. But PuTTY-0.63 breaks this expectation.

    • “Windows 7 Professional” is set – because that’s the current company standard
    • http://www.gnu.org/software/emacs/windows/ – the latest released version was fine for me: 24.3.1 – I am always happy to get and try the very latest released version
    • tramp – as packaged with the emacs at the location just referred to
    • PuTTY to be found at http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
    • PuTTY-0.63 faults (for me) with accesses like this one: “/pscp:SESSIONNAME:…”
    • PuTTY’s development snapshot does not fault for me, as 0.63 does – r10156 is, what I picked up – I am happy to try newer ones, if asked to, and I would rather prefer a released version to be honest

    A released version is always easier to get installed officially, should I get the necessary privileges withdrawn to “install” resp. unpack packages myself. My privileges are good enough to put files “permanently” on the local disk, but not to “install” applications Windows-wise.

  • emacs/tramp/win/putty: one of the pieces involved kept removing Unix file permissions — solved!

    Unix: PSCP and PSFTP now preserve the Unix file permissions, on copies in both directions.

    For quite a while whenever I edited a remote executable file (using emacs/tramp/putty on Windows), the file lost its executable privilige bit. Looks like that issue got solved with 0.63. What a relief! The very arrogant meritocrat at work kept criticizing me for using “such poor software“, and he referred to emacs(/tramp).

  • emacs/tramp/win/putty: “Fatal: Received unexpected end-of-file from server”

    Short story – what (released) versions to choose:

    The combination emacs/tramp/putty on Windows does not work with the released PuTTY-0.63. Use either PuTTY-0.62 or a PuTTY development snapshot, r10016 works for me.

    • http://www.gnu.org/software/emacs/windows/ – the latest released version was fine for me: 24.3.1 – I am always happy to get the very latest released version
    • tramp – as packaged with the emacs at the location just referred to
    • PuTTY to be found at http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
    • PuTTY-0.63 faults with accesses as shown below
    • PuTTY’s development snapshot does not fault for me, as 0.63 does – r10156 is, what I picked up – I am happy to try newer ones, if asked to
    • Windows 7 Professional – because that’s the current company standard

    Long story:

    After the Windows upgrade at work (WinXP->Win7) I certainly installed the newest available emacs (i.e. emacs package) and PuTTY (0.63) as well.

    Current issue: On opening a file accessed through “/pscp:SESSIONNAME:”, I keep getting this message:

    Fatal: Received unexpected end-of-file from server

    I tried the “/plink:SESSIONNAME:” tramp access instead, and it worked (I mean: it didn’t yield this message), but the combination tramp/plink keeps leading to corrupted (remote) files, as I described before [link], so that’s not really an option.

    S.K.R. de Jong wrote [link], that the quoted message stems from an improper reaction of PuTTY, and Simon Tatham conceded the bug [link], writing the bug would be fixed with r10016.

    Because I  found Simon’s statement and announcement only during my later investigations, I decided to give the older PuTTY-0.62 a try, and this problem actually disappeared. Of course I love leading / bleeding edge, but right now this seems to stand in my way. So I will have to post the scenario on some PuTTY forum / mailing list, but until that will lead to an improvement here, I shall stick to PuTTY-0.62.

    When I had found Simon Tatham statement on this issue [link], I drew new hope, that a more modern version of PuTTY addressing the latest security issues  would also solve my problem – so I am giving the current development snapshot (to be found here) a chance, i.e. “r10156”. Actually I have never been eager to employ a development snapshot of PuTTY, so that is my “first“. I subscribed for the PuTTY-announce mailing list, so I shall be able to replace the development snapshot by a properly released one.

    If that will not successful:

  • emacs/tramp/win/putty: “byte-code: couldn’t find a proper ‘ls’ command”

    The PC at “my” desk at my customer’s site just got migrated from WinXP to win7, and I have to re-install and re-configure a couple of packages, and now I have trouble re-adopting tramp.

    Having to deal with tramp always brings Michael Albinus to my mind. I only met him during one week in 1988 (1989?), when I had only lived for a couple of months in Berlin. It was quite an enthusiastic time then, and we were so much younger then. Would he let me invite him on a couple of glasses of rather drinkable red wine in the future back home in Berlin?

    Alright, back to the issue itself! Yes, after the Windows upgrade I certainly installed the newest available emacs (i.e. emacs package) and PuTTY (0.63) as well.

    • byte-compile …/emacs/lisp/net/tramp-sh.el
    • exit emacs
    • remove ~/.emacs.d/tramp, i.e. the “tramp connection history” resp. the “tramp connection details cache“
    • start emacs

    and it seemed to find a proper “ls” command again.

    I.e. I didn’t follow the other advise, demanding the installation of the newest tramp package.

    Having solved the “ls” issue, I faced these messages:

    Unable to use key file "…id_rsa.ppk" (unable to open file)
Fatal: Received unexpected end-of-file from server

    The windows registry had a couple of entries named “PublicKeyFile” pointing to an outdated location, where id_rsa.ppk had resided before. Changed all occurrences of that entry within the registry (subtree of PuTTY), and that issue was solved.