I often use the UNIX command line tool scp (secure copy) to copy a file to a remote server. However, scp has one major drawback: It doesn’t support resuming a transfer. So whenever I’m transferring a file and something comes up which interrupts my transfer–which is bound to happen–I’m cursing away at scp. The solution? Use rsync. It is overkill for most things I do, but when a transfer is interrupted, it is handy. Now, on to the doing.
I want to transfer the file “myFile” to the server “remoteMachine”, which I do with scp:
scp myFile remoteMachine:dirToPutIn/
(You should know this already if you’re reading this in the first place.)
(Muzak while the transfer is in progress; a loud wail and the sound of hair being torn out by its roots as the transfer comes to a grinding halt.)
Time to resume the file with rsync, which I do thusly:
rsync --partial --progress myFile remoteMachine:dirToPutIn/
The “–partial” argument is what does the trick. I added “–progress” because I like to see how the transfer is going; rsync understandably doesn’t show this by default as it is mostly used for purposes which don’t require live progress reporting (e.g. scheduled backups).
Because I know I’ll have this problem again at some point, I have created an alias in my shell’s (zsh) configuration file (~/.zshrc):
alias scpresume="rsync --partial --progress"
I know that rsync and scp are not necessarily related, but the name “scpresume” reflects the purpose of the task I wish to do. And getting it done is what matters the most after all.
Update:
Jan pointed out in a comment that rsync communication is not secure by default, and that you should use tunneling to achieve secure communication. Andi provides the solution which is quite simple: Use --rsh=ssh (use ssh as the remote shell). Thus, our alias from before would look like this:
alias scpresume="rsync --partial --progress --rsh=ssh"
April 5th, 2006
I stumbled upon a nifty trick for quickly switching keyboard layouts in console mode on Linux: simply make the commands asdf and aoeu load Dvorak and Qwerty, respectively. I have seen different solutions using scripts and programs, but those are overkill and don’t fit my situation. I chose the simple way out by creating aliases in my shell’s settings:
alias asdf="xmodmap ~/.dvorak_layout"
alias aoeu="xmodmap ~/.norwegian_layout"
As I don’t use the standard Dvorak layout, I found it easier to do it with xmodmap than anything else; I used it before and it works well. I created the Norwegian layout file (the actual layout of my keyboard is Norwegian) to keep it simple and consistent. This way, anyone who needs to type on my computer doesn’t get lost.
September 10th, 2005
I’m a Dvorak typist (yes, it’s better, stop asking) and really enjoy the Dvorak layout that comes with Mac OS X. I like it especially because it allows me to easily enter characters which happen to be outside of the A-Z range. I press Option-S to enter “ø” and Option-F followed by A to enter “ä” for example (these examples are based on the keys’ physical position on my iBook’s US Qwerty keyboard). Although a bit difficult to get in to, it is much better than other flavors of the Dvorak layout, which try to solve the problem by having separate keys for each character. But that introduces the problem of jumbling the keys around once more, and still doesn’t allow me to easily type “ménage à trois avec Synnøve et Amélie”. As if that wasn’t enough, characters I often need (< , >, [, ], {, }, ~) also scatter like antelopes running from a predator. The OS X flavor of Dvorak let’s me have my cake and eat it, too.
At work I use Ubuntu Linux on my primary machine, along with my iBook and a machine running Windows XP [sound of an old sailor choking on his snuff and spitting heavily]. The Dvorak flavors included in Linux distributions suffer from the symptoms mentioned above. I have been resorting to replace “æ”, “ø” and “å” with their phonetic or historic counterparts (”ae”, “oe” and “aa”), respectively), which obviously is suboptimal. There had to be a better way.
The biggest part of the problem was to learn how the keyboard configuration files work, and how the system treats them. The documentation for the different solution candidates I could come up with was–as it sadly is with many open source projects–scarce and poor, and left me back at square one. (If you feel like bashing me for the previous statement, you’ve probably been there yourself. So don’t start.)
I ended up circumventing the problem entirely and did what I should have done from the start: I simply copied the layout from Mac OS X. It was a fairly simple process. First I exported the OS X Dvorak keymap by issuing the command xmodmap -pke >> outputfile. After copying file to my Linux box, I manually replaced the key codes [1] using xev for reference. A little bit of testing and error correction followed and that was it. Satisfied with the results, I renamed the file .xmodmaprc and placed in my home directory (.xmodmap is read at login).
For anyone out there interested in using my layout, I have made it available for download.
As for the Windows box, it is controlled by Synergy, so I really don’t have to worry about its layouts [2]. For anyone using multiple with machines with one monitor each, I highly recommend giving Synergy a go.
[1] I chose the Windows key as the modifier key, as I have absolutely no other use for it. It works quite well, especially because it’s in the same spot as the Option key is on my iBook’s keyboard.
[2] For the record, switching keyboard layouts on Windows is the definition of pain in the ass. If you ever used Windows with a non-English keyboard, you probably had it switch back and forth randomly. Imagine the same scenario where only M, W and the number keys are in the same place!
August 24th, 2005