gist: So long as I am eating crow. …

I might as well go ahead and get a second helping of humility. After royally fumbling klick, I need a second smack in the head to acknowledge my error with gist.

Yes, I’m afraid I can’t just pretend I didn’t flub this one too.

My mistake was confusing this for another pastebin-style uploader, and discounting it on the grounds that the other one required an account signup. Sorry. After 1100 posts and ~1500 software titles, it gets hard to keep track. I should have a list or an index online somewhere. … 🙄

The real tragedy is, when compared to other pastebin tools I’ve seen in the past two years — like elmer or uppity or some others — gist is one of the better ones.

Some of gist’s cooler functions that I’ve noticed: automatic URL shortening through git.io, direct hookups with both xclip and xsel, updating existing gists with just the address hash, and one-time account authorization with the --login flag. Nifty.

One thing I’ve seen other tools do that I don’t see offhand in gist: Access to several different hosts. But I suppose that’s the nature of the tool, and what’s available through Github Gist.

At this point, with the landscape of pastebin tools largely dependent on what site they can access, I imagine the choice of tools might shift to what services the target site offers. For that reason it might make sense that gist wins fans among programmers.

Just from the upload page you see in the screenshot, you can fork an uploaded snippet, watch revisions and clone it off the page. I can see the appeal among coders; someone’s random list of words quickly becomes the next killer app.

So hopefully now I’ve done my penance for both klick and gist, and made up for one mistake and one misunderstanding. 😐

googlecl: Cutting corners with everything Google

My office uses Google Documents for almost everything it does. We all have GMail addresses and even our primary site is managed through Google, although the intricacies escape me.

I concede that it does streamline some things, but only because I have to. I’m still no fan of the cloud, and I never have been, and probably never will be.

Having said all that, I can see where googlecl would be very, very useful in our office for bulk management of e-mail lists or contact information. Just as a very brief example:

 

That’s the same example that appears on the home page, so I suppose pixellating much of those images was unnecessary. All the same, I think you should get the point. With something as simple as google contacts add and a little data, I get a corresponding addition to my online Contacts list.

Which is what you would probably expect. And it likewise goes without saying that googlecl can handle not only GMail Contacts, but also Blogger posts, YouTube uploads, Calendar events, additions and edits to Documents, and just about every other aspect of your collective Goo-perience, from the command line.

I can’t go into too much detail on invididual commands and configuration, mostly because each Google aspect has its own rasher of options and specifics. If you’re genuinely interested — and again, for my daily workload I already see a few places this can be useful — you’ll need to look closely on your own.

Probably the one thing I like best about googlecl is what you see in the terminal screenshot above: Rather than require a configuration file setup, googlecl simply links you to the API authentication page, and prompts you for the passcode. It does save a step, and gets you moving a little faster with the entire Goo-perience.

And I tip my hat to that. I never have and never will concede my own private and personal information to The Almighty Cloud, and have serious worries on behalf of anyone who does. But I’m taking this to work on Monday, and seeing if it will help cut a few corners. 😐

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. …

wgetpaste: A healthy collection of features

I have a link to the home page for wgetpaste, but it gives me nothing but a 404. Perhaps it has moved.

 

Ordinarily I’d look to the Debian repositories for a backup source package, but it’s not in Debian. So this time, Arch saves the day. 😉

wgetpaste uploads text to pastebin-ish services, much like curlpaste or elmer or others. Judging by the -S flag, wgetpaste supports about five or six upload hosts, but I’ll be honest and admit I didn’t try all of them.

As far as code languages, you have your choice of about 180 that wgetpaste claims to support — and no, I didn’t check all of those either. Some of them I never even heard of. 😯

But as you can see, a quick default run through wgetpaste sent my test file out into the wild blue yonder, and it arrived safely and intact at bpaste.net, the default host.

There are a couple of other options worth mentioning. wgetpaste can use tee to show you what it’s sending out. It can also interface with the X clipboard, like uppity does. And it has an option to send a URL to tinyurl.com, kind of like surl does.

So I suppose, if you wanted some of the functions of other tools, or features of other text-paste tools, wgetpaste might be a good choice.

uppity: Not the last, nor the least, pastebin-ish upload tool

Just by virtue of alphabetical order, uppity is arriving near the end of a long list of pastebin-ish upload tools.

I’ll try to give it the same measure of attention that its competitors received, even if I am beginning to wonder why there are so many of these tools, and if there is a requirement somewhere for CS majors to write a program to upload a code snippet to the Internet.

uppity, in conjunction with dpaste.com, worked fine for me, and I was able to apply a description to the short text file I uploaded. uppity supports quite a few different services, and there’s always the chance that it will fall out of favor with one or more of them. But uppity cleared the first hurdle — do what you promise — without incident.

kmandla@kl-mkc96: ~/temp$ head output.txt
001,Fanny Moreno,902 Kennel Ln,Indianapolis,IN,46206,(317) 901-6298,77,7299714f
002,Geraldine Adams,479 Flanty Terr,Burlington,NC,27215,(919) 114-2613,67,4f77e31d
003,Mario Meyer,482 Shalton Dr,Auburn,NY,13021,(315) 918-2187,77,8ffaf55c
004,Clare Flynn,676 Dorwin Rd,Addison,IL,60101,(708) 811-9115,41,1fc9ade7
005,Refugio Mcfadden,603 Plymth Terr,Akron,OH,44309,(216) 277-6958,56,0027b74b
006,Chance Mcclure,279 West Street Terr,Akron,OH,44309,(216) 759-8910,69,d17459d3
007,Wilma House,854 Burnet Dr,Appleton,WI,54911,(414) 872-1644,56,f21e179c
008,Charity Newman,770 Rider Blvd,Detroit,MI,48233,(313) 167-2599,47,fb3f7ce2
009,Chester Ross,337 Genesse Blvd,Seattle,WA,98109,(206) 987-2809,85,22cfce3c
010,Preston Higgins,729 Limetree Ln,Orange,NJ,07051,(201) 377-8402,61,cfa29694

kmandla@kl-mkc96: ~/temp$ uppity -s dpaste.com -d "Sample address database." output.txt
Uploading output.txt: 100%
http://dpaste.com/1GJ7FD5

The variety of features available between services is probably what accounts for some of uppity’s options; there are specific flags for language (code language, not spoken language 😉 ), expiration, description and nickname, to name the majority. It will also mash together separate files into one whopping upload, if you ask nicely.

uppity also makes a point of listing the languages supported for each service with the -L flag, so if you’re looking for one that will enhance a specific block of code, that might be useful to you.

And I also see, but didn’t test, features specific to a graphical environment, to including reading from the X clipboard and writing to X’s primary selection buffer, both of which need xclip installed to make use of.

The beauty in that, as I see it, is uploading your code snippet, then immediately pasting the link from the selection buffer, without the added step of opening a browser or highlighting the displayed text.

I like uppity for doing the job and having the forethought to add a few time-saving shortcuts. As it is, I rarely need a pastebin-ish service, but when the time comes I’ll make a point of hunting down uppity again, and giving it the chance to impress again.

termrec, ttyrec, tty2gif and others: Pretty as a picture

I realize now, well after digging deep into the T section, that I should have broken apart a lot of the programs listed here and clumped them together in megaposts, like I did with 2048.c.

I’m going to do that again now with a series of applications that are intended to convert terminal output into a replayable format, and beyond. Knowing that, you might correctly infer that there’s not much to show. You would be correct. In other words, no screenshots. 😦

Recording what happens in the terminal is not new. If you remember script, the granddaddy of terminal recorders, you’ll know that this idea has been around for decades, and there’s nothing new in piping the output of your terminal screen (emulated or not) into a recorded session. The novelty comes in the variety of tools that will do it for you.

I intentionally skipped over one of these programs — termrec — a week or two ago. I’ll take care of that one today, and I also have nh_recorder, ttyrec, ttygif and tty2gif, plus a bonus at the end and an online solution to mention. For each one I’ll try to give a quick rundown on the high points and low points, and my overall impression.

Let’s go.

nh_recorder:

Pros: Very light, very transparent. Could be good for extreme cases where nothing else seems to function, or over specific network connections. Cons: Only dumps to a file; needs its counterpart, nh_player, to replay. No practical control outside editing the code. Seems to only update a line at a time. I.e, no real animation effects, only periodic line-by-line refreshes.

Overall: This might be just a primitive tool intended for use with old versions of NetHack. It works, even if it’s not really practical.

ttyrec

Pros: Supports remote sessions. Can start an application directly, instead of spawning a subshell (a la script). Can append existing recordings. Has playback and timer tools. Cons: Clips the terminal size, which means you may end up with large empty areas if you record ncurses applications. Only sends output to its own format. No compression options.

Overall: This is a step up from nh_recorder, but it’s frightening that it slices away at the terminal area and leaves large black swaths where your application should be. I hope that was something I did wrong. Regardless, it lacks some of the features that the upcoming applications have.

ttygif

Pros: Converts ttyrec format files into animated gifs, by playing back ttyrec files and using imagemagick‘s import command on them. Cons: Somewhat haphazard in its delivery. Two-step process; ttygif makes a slew of specifically named images, then relies on an included shell script to concatenate them. Final product should be a recording of the terminal session, in gif format. Relies on imagemagick.

Overall: Just too spattered for my liking. Even short recordings create a mess in your directory. The only time I can see where this would be a good approach is if I needed to edit out specific frames of a recording, and even then it would be a chore. Conceivably this could allow some control over frame quality and delay though.

termrec

Pros: Automatic compression. Support for ncurses applications. Compatible with ttyrec. Option to append recordings. Will save in several formats. Can jump straight into an application, instead of spawning an additonal shell. Cons: Some screen corruption in playback of ncurses applications. Terminal size clipped. No automatic conversion to gifs.

Overall: This is step up from ttyrec, but it still seems to suffer the two main faults of its predecessor: I’ve seen a lot of corrupted playback, especially with full-screen console applications. And clipping the available recording area makes it only marginally useful to me.

tty2gif

Pros: One tool for the entire process — record, save, and convert. Control over filenames in both the saving and conversion process. Can replay its own binary save files. Automatic conversion to gif, if desired. Cons: Sometimes tricky to play back a file without overwriting it. Relies on imagemagick. No automatic compression. No control over image format, or flags passed to imagemagick. Can eat memory like a pig — I’ve seen it gobble a gigabyte for a 20-second 80×24 recording. Sometimes corrupts the output image, but only very rarely.

Overall: This is the one I use, mostly because it will record the entire terminal area, and generally it doesn’t garble the end result. I have accidentally overwritten a recording while trying to play it back, but the conversion to gif is convenient and thus far without fault (the one time it did create gobbledygook was probably my error). With a few small improvements, this could be the clear winner. If it doesn’t get a handle on memory consumption, it’s not going anywhere though.

The gifs you’ve seen over the past week or so were made with tty2gif, and I’ve more or less implanted it into my system after tinkering with the other four. It’s possible that there are others, but between script and these others, you should be able to find one you prefer.

Now a bonus goodie: termcast

termcast lets you broadcast terminal sessions live, a la twitch.tv or some other streaming video sites. I can’t say that I built up an entire system to show my own terminal sessions — the tools are there for that — but I did watch a game or two of nethack that someone else was playing.

termcast relies on ttyrec for broadcast, but you can watch a game with only telnet. I’m not sure if the same issues with corruption or terminal size persist through termcast. I know I did see some garble in the games I watched, but I assumed that was from differences in terminal environments or something related to telnet.

And as promised, an online solution: showterm.io

I got a link a long time ago to showterm.io but forgot what the name was, making it rather tricky to hunt down. James T. sent me a working link a few weeks ago, so I’ll credit him with the catch.

The showterm client installs through gem or by straightaway downloading the binary from the home page. Recording and uploading a session provides you with a link, which you can use to view the session or share with others.

If I remember correctly, I was able to upload a recording from an X-less machine, but it probably goes without saying that you’ll need some sort of graphical environment to view the link. I tried this quite a while ago, but I seem to remember elinks throwing its hands up in frustration when I fed it the showterm.io page.

---

I think that’s all for now. Taking these six or seven applications and loading them all on one post has taken a nice chunk out of my list, especially since there’s nothing in particular I can show for them, one by one. 😉

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. 😉

surl: No, not “surly.” Just surl

So far I’ve seen about a half-dozen pastebin-interface-type tools for the console, but I do believe surl is the first URL-shortener.

kmandla@6m47421: ~$ surl -c http://www.google.com -s tinyurl.com
http://tinyurl.com/1c2

You can check that and see if it works. I don’t know what the expiration is for tinyurl.com, but you can trust me. I’m from the Internet. 🙄

surl definitely falls into that category of “Oh, of course, that’s so obvious” tools. Before I came across it I never thought once about a tool to send URLs through shortening services, and reply with the link.

Now I have to wonder why there aren’t more. 😦

There probably are, and I just don’t know about them. Every day, something new. … 🙂

You can jam URLs straight into surl if you like, or pipe them in backwards if that’s your thing. surl is also, apparently, capable of parsing strings of text and pulling out URLs, and replacing them with shortlinks in its output. That’s pretty clever.

surl’s repertoire is likewise impressive, and since some of its clientele requires passwords or API keys, the fact that surl can handle those minor details is even more impressive. I won’t bore you with a list of what surl knows; install it and the --help flag will list them.

Bad news for Debian fans: This one doesn’t appear in your repos. If it’s any consolation though, I am fairly certain it wouldn’t take much effort to get it installed.

I might keep surl around for a little while longer; it’s not often that I need a shortened URL, but I want it on hand when I finally do. 😉

pastebinit: As in “pastebin it!”

I keep reading pastebinit as pasteb-init, as if it was some sort of newfangled startup script spawned by systemd or something.

That, of course, is way off the mark, since pastebinit — as in “pastebin it!” is another cli-driven pastebin uploader.

pastebinit is not the only such tool available, since we’ve seen haste, curlpaste, elmer and quite a few others in the past year.

The usefulness of pastebinit or any of the others is more or less dependent on the pastebin you want to use. If pastebinit doesn’t mesh with your bin of choice … well, I guess that makes pastebin clients a little bit like instant messengers.

pastebinit handles quite a few different target sites though, not the least of which is the one you see above.

Double-check which ones your version handles; there are quite a few in the current Arch version:

- cxg.de
- fpaste.org
- lpaste.net
- p.defau.lt
- paste.debian.net
- paste.drizzle.org
- paste.kde.org
- paste.openstack.org
- paste.pound-python.org
- paste.ubuntu.com
- paste.ubuntu.org.cn
- paste2.org
- pastebin.com
- pastebin.mate-desktop.org
- pb.daviey.com
- slexy.org
- sprunge.us

I like pastebinit, but I don’t find it particularly easier or more convenient to use than any of the others. And given that I only rarely use pastebins, this might not be the killer app for me. 😕

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. 🙄