Tag Archives: transfer

lancat: Zero-configuration network transfer option

Quick on the heels of pyncp, I got a short note about Graham Edgecombe’s lancat.

2015-04-08-6m47421-lancat-01 2015-04-08-6m47421-lancat-02

As you might imagine, lancat works a lot like pyncp, with a couple of exceptions. Yes, it’s intended as another fire-and-forget, zero-configuration network transfer option. And as you can see in the pictures (which I snapped a little too early), one machine “sends,” and another “receives,” and they listen for one another in the mean time.

A couple of small differences though. And not just that lancat is written in ruby, and pyncp was in python (and ncp was in C).

First, lancat is apparently desingned to work like a pipe, with your source file redirected into it on the sending end, and out of it on the receiving end. This might lend itself to use in scripts or with other tools.

Second, lancat’s function is determined by a flag, not by interpreting a command in sequence. That might prove more convenient, or at least quicker than typing out a full command for pyncp/ncp to interpret.

Aside from that, lancat works much as might be expected, but comes with the same caveats as pyncp did: There is no provision for security (or compression) unless to force it before and after.

But there are tools for that, and given that lancat handles pipes and redirects well, it shouldn’t be a big issue. 😉

pyncp: Quick and easy network transfer

This will be quick and easy today, since pyncp is a clean and straightforward tool.


If you remember waaay back, almost two years ago, we looked at ncp as a quick alternative for network file transfer. pyncp accomplishes much the same thing, but apparently sticks to python for its magic.

There are no exquisite flags for pyncp, but the program has to be installed on both the source machine and the destination. One machine “pushes” a file with pyncp push file.txt, and the other “polls” for it with pyncp poll. You don’t need superuser privileges or passwords — you don’t even need to know how to manage the network. One pushes, one pulls. Or polls, I guess I should say.

That’s it. If you want an encrypted transmission, I believe you might have to do that manually, and decrypt after arrival. Same goes for compression, but if you’re managing a series of file transfers over an open network, you should be doing those things manually anyway.

I only tested pyncp over my home network, so I have no guarantees how it will behave out in the wide open world. pyncp is in AUR as pyncp-git; my Debian search turned up nothing.

socat: You want it? socat’s got it

Back when I mentioned netcat, I said that no matter what I wrote, I’d be underemphasizing how useful and powerful it was.

The same holds true for socat, which is probably more flexible and more detailed than netcat, if such a thing is believable. Like netcat it’s primarily a network piping tool, but just a skim through the man page tells you it’s taken the idea to a different level. 😯

I could claim some experience with netcat, but socat was new to me until today. But here’s what I collected from around the Web, in terms of fun things to do with it:

Create a virtual network interface:

socat -d -d tun: tun:

Not that I’m short on network interfaces, but that’s a pretty cool stunt. Thanks go to JustChecking for mentioning that one.

socat can also pull in or redirect data delivered from other programs, which makes it useful in other ways.

date | socat - GOPEN:/tmp/capture,append

And of course, if you take a peek in /tmp/capture now, you’ll see the date listed. Not a huge leap forward for mankind, but has potential if you think about it. Thanks to linux.com for that one, and for this one — creating a virtual private network over ssh:

socat -d -d  \
    TUN:,up \
    SYSTEM:"ssh root@server socat -d -d  - 'TUN:,up'"

I have to admit, that’s clever. One more here, this time from My Stuff:

socat UNIX-LISTEN:/tmp/.X11-unix/X1,fork \

Supposedly this attaches itself to the Unix socket created in an X window session, and redirects to an external site. I admit this one I didn’t try, and since the My Stuff page dates back to 2008, it’s possible this doesn’t work like described. An interesting idea though, and lots more on that page.

It’s possible to create software that is so flexible and precise that it is both amazing and bewildering at the same time. socat is proof of that.

siphon (and ‘Siphon): For simple network transfers

I’ve got two programs named siphon. One of them actually is called Log Siphon, and the other is just siphon. And unfortunately, only one will get a proper shakedown today.

Log Siphon is a “Event Management & Monitoring System,” and I’d be happy to give it a spin, except that you have to apply to download a 15-day trial copy.

Not sure what that’s about. 😦

So I turn to the other siphon, which gave me flashbacks to 1998 for a second, because I thought it was a throwback to Direct Cable Connection. You get a bonus point if you remember what that is. 😕

But actually siphon sends files over a network connection, given just an address and perhaps a destination folder. Take a look:

2014-04-26-6m47421-siphon-listening 2014-04-26-6m47421-siphon-sending

Granted, that’s just doubling back to myself, but it seems to work. I don’t have an arrangement that would allow me to actually loop it across a router or hub right now. 😦

siphon is exceptionally simple, but needs to be running on both machines to work. No daemons, just one listening and one sending. Remind you of anything?

The first criticism of siphon will be that there’s no provision for security or encryption. If I understand the home page, it’s intended to be Unixy, and so you should be looking for ancillary tools to handle that for you, if those things are concerns.

siphon is not the only tool in its class, but it has a charm to it. I am reminded of things like woof and ncp, both of which are clean and crisp ways of doing the same thing.

Now if only I could find a way of setting up an Direct Cable Connection. … 😯

netsed: Does for the ‘net what sed does for …

I can see the usefulness of netsed, and I can get it running, but I can’t seem to arrange it in a way that would be suitable for a screenshot. Hence …


Sorry, that’s all you get. 😦

netsed should do the same thing as sed, and swap out strings of characters as they pass — this time, through network connections.

Perhaps I had my hopes up, but I was expecting to be able to substitute every occurrence of the word “program” on this site with “cheeseburger.” A weak attempt at comedy. 🙄

It appears to be working though, and a new version was released a few months ago. So short of the fact that, once again, I can’t seem to get the program to perform, I have no reason to doubt this is a useful gadget.

See, this would have been so much funnier if the word “cheeseburger” kept appearing … 😕

ncp: Possibly the easiest yet

Being a bit of a klutz when it comes to networking, I’m always on the lookout for easy ways to streamline file transfers and stuff like that.

For a long time I relied on nfs in classic client-server arrangements to handle transfers. They are a little cumbersome to set up, but nothing someone with mediocre networking skills (like me) can’t handle.

A few years ago I finally tried scp. I jumped ship immediately, and mostly relied mostly on that and rsync for a while.

A few weeks ago I mentioned woof, which is probably the most useful in terms of offering (or accepting) a file across wider networks.

But now I think I may have a winner in the least-intensive, least-intricate and least-invasive categories for local areas: ncp.

It’s so dead simple and so utterly painless that I can only wonder why it took me years to find it. One machine does this:

npush target.file

And the other does this:


And if all goes well:

2013-04-21-solo-2150-ncp 2013-04-21-vgn-nw50jb-ncp

Voila. Not even network addresses — not even aliases for network addresses are needed. You could do it on a busted laptop with only five working keys. 😯

I’ll let the home page explain how ncp works; the details are better explained than I could do here.

For my own part I’ll probably handle most of my in-house transfers this way from now on. It’s just too darned easy.

P.S.: Thanks to jerryjerry for pointing it out.

woof: The simple single file server

Here’s nifty toy, with a clever name too: woof, short for “web offer one file.”

2013-03-19-solo-2150-woof-01 2013-03-19-solo-2150-woof-02 2013-03-19-l3-e7548-woof

It’s a one-shot, single use server with a very primitive web interface for uploading as well.

Naturally, between in-house machines it might be easier to use something like scp, rsync or even a standard nfs arrangement.

But the cool part of woof, in my meager opinion, is that all of those things probably require a running daemon.

woof just awaits a connection, and sends its information. Of course, there’s no security, probably no encryption unless you do it manually, and so forth.

I only ran into one jam with woof, and that was trying to send files out beyond my router.

For whatever reason, I couldn’t arrange woof to listen beyond my home network. I blame my router settings, but if you have any ideas, I am willing to listen.