stftp: The simple terminal FTP client

I’m all about full-screen, intuitive, colorful interfaces to programs. I don’t really care if something has been done before (everything has been done before), unless you’re reinventing the reinventing of the reinventing of the wheel. Just give me a good interface and a decent perspective on the task at hand, and I don’t care if your program was written in 2012 or 1992 — it’ll work for me.

Here’s stftp, which — with the possible omission of color — hits all three of those criteria. Among FTP clients, stftp is in a crowded box. But among full-screen console FTP client applications, it’s standing tall.

The bottom line is a status bar. The top is a breadcrumb trail. Everything in between is selectable. Navigation is by arrow keys, with left and right moving you up or down in the tree. Press enter on a folder and you move in, but press enter on a file and you download it. Other one-letter keypresses are for uploading, deleting or filtering.

My trusty memory script says stftp is running on a little over a megabyte of memory, which may or may not vary with the depth of your travels and the lists it needs to manage. Still, +/- 1Mb is a svelte number.

I don’t use FTP clients very often, and I know some clients are a lot more feature-full than this (combined FTP and torrent client, anyone?) but I really like stftp for its clean interface and obvious arrangement. I’d jump at the chance to use this over, for example, gFTP, which always irritated me as a rancid excuse for an application. 👿

Now if only we can get some color in stftp. … 😀

wput: The same, just in reverse

You might remember wget from last week — the omnipresent hyperflexible download tool that doubles (and triples) as a site crawler, mirror utility and download manager.

What would be great is if there was an opposite tool, one that followed much of the same structure and flag options as wget, but — wrap your head around this one — uploaded things, instead of downloading them!

Well, believe it or not, such a tool exists. And as luck would have it, it’s named … wput!

kmandla@6m47421: ~$ wput --help
Usage: wput [options] [file]... [url]...
  url        ftp://[username[:password]@]hostname[:port][/[path/][file]]

Startup:
  -V, --version         Display the version of wput and exit.
  -h, --help            Print this help-screen
  -b, --background      go to background after startup

Logging and input file:
  -o,  --output-file=FILE      log messages to FILE
  -a,  --append-output=FILE    append log messages to FILE
  -q,  --quiet                 quiet (no output)
  -v,  --verbose               be verbose
...

No screenshot this time, because no matter how clever or convenient wput is, I would still need a destination for my upload example. And as far as I know, there aren’t many sites that offer free, anonymous, one-time FTP uploads. What’s that about?!

No matter. If you’re used to the style and arrangement of wget, you’ll appreciate that some of the controls are similar. The -q, -v, and -a flags carry the same meaning to wput as wget, and I see a few more that look the same.

Of course, a lot of them are also different, which can’t be avoided. For example, the -nc flag in wget, which stood for “no-clobber” and prevented re-downloading and overwriting files that appeared locally, is instead “no-continue” for wput … as in, don’t resume a partially uploaded file.

Like I said, there’s no way around some of those. But if you’re accustomed to wget’s way of doing things, wput might feel natural.

It looks like wput hasn’t seen many updates in the past few years, which you can interpret as feature-completeness, or just a drift toward complacency. It doesn’t bother me much, mostly because I don’t think FTP hasn’t changed much either. I would be surprised if wput hadn’t kept up with FTP. 🙄

So there it is, your reverse-gear wget. Now if only I had a spare computer around here, to set up an FTP server and actually try it out. …

tnftp: The *BSD counterpart

My experiences with the *BSDs is extremely limited, but I am taking it on faith and on the advice of Wikipedia that tnftp is the default ftp agent in NetBSD, FreeBSD, OpenBSD and some others.

It may be that I am mistaken, in which case I was provided with bad information. 😳

If that is the case though, I can only hope that *BSD users have better luck that I do with it. It seems that regardless of the host, nothing seems to connect. If I use the traditional ftp available through Arch’s inetutils, I have no problems.

An added irony, as you can see in the screenshot, is that tnftp is finding the correct IP address, but still insists it can’t connect. Perhaps I should be supplying a user name or a specific port, but it seems every variation ends up the same.

It’s a little disappointing, but as I always do, I first assume the problem is mine. No doubt I am missing a step somewhere, or have misconfigured something.

And I have no reason to assume that tnftp doesn’t work at all. It seems foolish to think that some of the most bulletproof software available on the planet would rely on a less-than-functional ftp client. Add to that it’s in both community and Debian.

For those keeping count, this little adventure has thus far collected a rather impressive menu of ftp clients. So even if tnftp doesn’t work for you either, you still have the choice of

• ftp
• cmdftp
• ncftp
• lftp

and Midnight Commander, if you’re willing to acknowledge its ability to open ftp addresses like normal, everyday folders. Plus anything that happens to crop up between here and the last of the Z section.

So don’t throw in the towel just because this one doesn’t work for you. 😉

pure-ftpd: Adventures in the service sector

My experiences with managing ftp servers is exceedingly thin.

All the same, I do enjoy boasting about a bare-bones server I set up about eight years ago, using a busted-up 300Mhz laptop without a hard drive, a Xubuntu 6.10 live CD, a USB key and vsftpd. And with that sparse recipe, managed to transfer some files from my brother, who lived in another part of the world.

(And yes, that’s how far *Ubuntu has fallen, given that it could run live on a machine with only 256Mb of memory and still have a sliver of space left over for file transfers. I’m afraid to see how heavy it has become. 😯 )

Point being, I’m usually on the other end of the ftp adventure. I’m more experienced with clients than servers. lftp, ncftp, cmdftp, even plain ol’ ftp if need be.

Servers just never enter my sphere. All the same, here’s pure-ftpd, in the best way I can show that it works.

 

That’s the Debian version of the server running off a Linux Mint live CD, with my Arch machine accessing it through the network. I didn’t actually go through the entire setup, because it’s gone as soon as I turn off the Mint system, and I haven’t really anything to transfer … except maybe that screenshot. 🙄

I can’t tell you what’s the best server system, and I’m not experienced enough to know what to look for anyway, so if you have a particular one you like, I suggest you stick with it.

On the other hand, if you have a leftover 300Mhz laptop with no hard drive and a dusty Xubuntu 6.10 live CD, and maybe a USB drive to stash files on … well, why not give pure-ftpd a go?

Worse comes to worst, I can tell you firsthand that vsftpd will work, even if pure-ftpd doesn’t. 😀

ncftp: As the alphabet goes, so go FTP clients

It seems as we make our way further and further through the alphabet, fellow traveler, that FTP clients boast of more and more features.

ftp started us out as the baseline application. cmdftp was there already, as a cohort. lftp added a few thingamajigs, like torrent handling.

Midnight Commander — if you can accept the idea of a file manager interloping into the world of FTP access — adds a visual arrangement that appeals to others (like me). And, technically speaking, file management. 😕

And now we have ncftp, whose home page insists it has even more bells and whistles.

I have to admit some ambivalence over the features available to a command-line FTP client. Although, I do look for things like progress meters, resuming downloads, directory tree downloading and site bookmarking, as features of other programs.

So out of fairness in reporting, I’m content to acknowledge ncftp has those features, and yes, they are (more than likely; I haven’t tested them all) advantages over the classic ftp application.

I’ll also admit that the addition of ncftpput and ncftpget means you can hot-wire shell scripts to do FTP uploads and downloads too. Plus ncftpbatch and ncftpspooler, which I hardly got a chance to touch, but add two flavors of bulk FTP handling.

Now you can see why I feel FTP tools get better and better the further into the alphabet we go. I expect “zzzftp” will handle transfers, balance your checkbook, make a pot of tea and teach your child to program in C, all at the command line. 🙄

lftp: Teaching an old dog to do new tricks

I do believe lftp was the first console-based FTP client I used in Linux. And I remember trying that after working with things like WS_FTP and Filezilla and thinking, “Geez, is this how people do this in Linux?”

Of course the answer to that is “no,” and I know that now, but it does amuse me to think that I assumed anything FTP would happen in a terminal emulator in Linux.

lftp has its origins way back in 1996, can handle any number of protocols including direct server-to-server, and can run on machines as lowly as 486s, if the supporting OS is there, I presume.

Blah blah blah. Tell me about the torrent client!

That’s right, don’t let your system administrator find out, but lftp can handle torrent traffic too. It’s fairly simple and doesn’t nearly have the frills that some others do, but you can kill two birds with one stone now.

My only fear is that this will usher in an age of lftp becoming a jack-of-all-download tools, and I prefer applications find their focus and concentrate on it.

Regardless, it’s nice to see a program with such an extensive history picking up a few new tricks to stay apace with technology. 🙂

P.S., last update was in October. 😀

ftp: The classic, in action

I’m going to give out one more bonus today, because fsniper may or may not be working, and because I’m getting close to the end of the F section.

Here’s ftp, which you may know from experience, may know by reputation, or may not know. Any of the above are possible.

On my Arch system, ftp is part of inetutils, and shares company with some fine tools — like rcp, telnet and a few others. Debian keeps it in inetutils-ftp, so it’s apparently been broken out of the original set. That’s cool.

ftp runs much like you might expect, if you were to type in all the commands that otherwise are handled by graphical clients like gFTP or FileZilla. It’s not exactly a full-scale console application, like Midnight Commander is when it accesses FTP sites.

But ftp is not much different than any other trapped terminal command-line application. It has a man page if you don’t know the protocol, and is fairly forgiving if you make a mistake.

Yes, it’s a classic, but … no color, no fullscreen application … I know, I am easily disappointed. I try to be open-minded, I really do.

But I’ll be sticking with Midnight Commander as a text-based FTP tool. It’s just got what I look for. 😐

edbrowse: Be afraid. Be very afraid

What would happen if you took a text editor that nobody really thought about, exposed it to massive does of gamma radiation, and cut it loose to rampage text files, your file directory, your e-mail and the Internet beyond?

Well, first thing is, you’d hear a lot of crying and whimpering in the background. That would be emacs fans openly weeping in their lukewarm chay while vi fans rubbed their temples and whined about how life isn’t fair. And edbrowse would be to blame for that.

You remember ed, of course — the surly, ungainly, tight-lipped text editor that everyone usually laughs about before dismissing as an holdover from the Unix of 30 years ago.

Well, someone got it into their head to take ed and pump it full of steroids, teach it how to navigate directory trees, how to handle e-mail and how to traverse the Internet. And the result is pure, unadulterated evil.

But in a good way. 🙄 Much of the original ed is still here, and I’d venture to guess (but I can’t be 100 percent sure) that anything ed can do, edbrowse can do too.

And now edbrowse can navigate between directories, list their contents, delete files and so forth — so you have a file management function. And it can tackle e-mail now, both reading and sending. And it can pull pages from the web and browse them. And FTP. And negotiate SSL. And open multiple sessions. And escape to a shell. And wrangle JavaScript. And safely delete files to a trash folder. And write-protect directories. And use manage “buttons” on web pages. And convert to UTF8. And play an audio buffer. And more.

Yes, this is where the wailing and gnashing of teeth come in. You can smell the fear in the air.

ed alone was easy enough to pat on the head and send to the dustbin of history, and laugh at behind its back. But this new ed, this edbrowse. …

This is a force to be reckoned with. 😯

cmdftp: About as simple as it gets

When a program’s home page insists the intent is to be simple and small, it’s usually a good sign.

That’s cmdftp, and like a lot of ftp clients I’ve seen for the console, it behaves like a shell.

If you need some sort of visual arrangement you might be better sticking with something like Midnight Commander. I usually do.

But for sheer svelte-ness, it’s going to be hard to find an FTP client with as much function that takes up as little space. cmdftp weighs in at a mind-blowing 60Kb. That’s right, 60. Kilobytes.

So, no color, no graphical arrangement. On the other hand, fully functional, speedy and smaller than a grain of sand.

Should be an easy decision. 😉