gdisk: A familiar face

I’ll try to keep this one quick; I am already short on time this weekend because of personal obligations. But I also think gdisk is something that resembles fdisk enough (and even perhaps cfdisk and some other partition tools) that mentioning it at all is a rehash of sorts.

Anyway, feast thine eyes:

gdisk, for what I have seen, just about matches fdisk keypress for keypress, with the major difference being its relative comfort in working with the newer generation of hard drives that use GUID partition tables and not MBR style.

Wikipedia tells me the changeover took place sometime around 2009, and so it doesn’t surprise me that I use it so rarely. The newest, most powerful machine I have in the house right now is 8 years old, and I’m wondering if it isn’t time for me to upgrade that. …

I wouldn’t want to fall behind on the times, now would I? 🙄

prettyping.sh: An irrefutably prettier ping

prettyping.sh is a very straightforward tool: It’s a shell script that gives a little more pizazz to the traditional ping tool.

And seeing that screenshot gives you 90 percent of what you can accomplish with prettyping.sh. By default, all of prettyping.sh’s flair is turned on, and with the few hard-wired options that have to be set for the translation to ping. It’s colorful, clean, nicely arranged and a breeze to use.

But as always, I must offer a few points that stick out. In the hope of course, that they will be smoothed over in the future.

First, the legend is visible by default, and as luck would have it, it’s intended for about 150 or 160 columns (I didn’t count it out exactly; please forgive me). That’s all fine and dandy, but I honestly am not sure how often I run a terminal of that width, especially for a ping tool. So I find myself omitting the legend, which is pretty, but a little skewed.

Second, prettyping.sh’s output is very much like spark, with gradated characters of set color arrangements representing ranges of values returned from ping. Fair enough, and I see a general logic to the legend.

The problem is probably obvious though: In a virtual console, you might not get that same effect. I tried it on a random machine in my collection, and what I got was a blotchy mess of unprintable boxes, in varying colors, both in the output and in the legend.

So you’re more or less trapped in an emulator if you decide to make regular use of prettyping.sh, which might mean you’re also trapped in a graphical environment. Which might defeat the purpose of this entire escapade. (Let me know if you try prettyping.sh in a framebuffer terminal emulator, and whether or not you get the correct effect. You might.)

Another caveat: The link above may or may not be the original prettyping.sh. Shell scripts, in my observation, get traded around like spare pencils, and sometimes contort without earning a new name. I know the link for prettyping-hg out of AUR points to a dead MyOpera page, so it might be that there are three or four variants around.

The link I gave at the start was one I found on my own, that led to a posted source. I see that it’s also the source link for the prettyping package in AUR.

I also wish someone had renamed it to pretty-ping.sh, because I see the word “typing” in there, every time I read it. How’s that for a shallow and pointless criticism? 🙄

If you can overlook these faults or eccentricities, prettyping.sh is a very nice text-based interface for watching pings over long periods of time. There are a lot of ping tools out there (we’ve seen plenty, even in recent weeks), so if it doesn’t suit you, there are options available. 🙂

ips: Intelligent process monitoring

My apologies for the quiet space yesterday; I had some holiday-related travel to suffer through, and it wasn’t possible to update until this morning.

In return for your patience, I would like to offer ips, an intelligent process monitoring tool that has a lot in common with things like top, or perhaps procps.

If I understand ips correctly, most of its data is procured through /proc, and translated into an abbreviated format that is displayed in the style you see above. The details of the Summary section would require a little more space than I can afford today; take a look at the man page for a breakdown.

ips strikes me as both highly flexible and relatively easy to control; what you see above used the loop, curses, sort, noroot and a few other flags, for a relatively easy-to-follow top-like monitor. There are a lot of other options to pull from though.

ips also has a “graphical” mode that I feel I should mention, but it’s not particularly spectacular. Take a look if you like.

ips is in Debian, but I don’t see it in Arch/AUR, and I can’t find an original home page. It’s a little difficult to pin down since the name is “ips,” and quite a few other things obscure my searches. It’s a piece of cake to build ips in Arch from the Debian source though, so it’s not a huge issue.

I like ips, but it’s a little overkill in some respects, and isn’t quite as brief and quick as something like htop or just plain top. Still, if you’re looking for something unconventional and less popular than those two, ips is an idea. ips … the hipster process monitor. 🙄

logtop: Kind of like a *top … for a logs

I’m not a log nut. I mean, I don’t spend hours poring over logs to try and find the source of my angst (I’m not a terribly angsty person though).

I do know that’s a favorite hobby for some people and professions, and to that end, logtop may be exciting.

logtop is kind of like a *top, if it makes sense to watch a log continually for updates and changes. And as the author suggests, using logtop in this sense

tail -f /var/log/pacman.log | ./logtop

is much the same as doing this

watch 'tail /var/log/pacman.log | sort | uniq -c | sort -gr'

Bt you could say that equating logtop to that line means it’s not adding much to the classic black-and-white Unixy tools you probably already have.

And given that tail already has an -F flag for following log updates, it might not seem like logtop is actually an improvement.

My example doesn’t do much justice to logtop though, since it is prepared to handle much heavier and more dense log updates, as might happen with machines more powerful and active than my puny Pentium 4.

And given that logtop is prepared to calculate and show line rate stats and contort its output to follow specific formats, I’d be doing a great disservice to logtop by dismissing it out of hand.

But I’m not the best judge of these things, since I already confessed that watching logs was something I do rarely at best. Those of you who find solace or salary in staring at logs … you are the target demographic here. 😉

dothost and lddot: Looking good, feeling fine

Well, after a day or two of completely scrambling my scheduled posts — and even revisiting an application that I had already mentioned a year ago 😳 — I have some catching up to do.

Please accept this as a double post, and hopefully make up for a little lost ground. Here’s lddot and dothost, respectively, both from Jakub Wilk and both in AUR (but not in Debian).

 

Just because you prefer a text-based lifestyle doesn’t mean you can’t be a visual learner. dothost and lddot both cater to that, by generating neatly arranged flowcharts with the help of Graphviz and perl-graph-easy.

By themselves, the output is strictly textual, so if you can’t get access to either of those ancillary programs, you won’t get all the pretties you see above. And it should go without saying that some of the more complex arrangements are going to require extensive screen real estate. Don’t expect them to squish everything into 80×24.

I suppose you could argue that neither offers much information that isn’t available through ordinary ldd-ish or traceroute-ish tools.

And judging by their help flags, neither tool is particularly flexible or extensive, beyond generating the plain text output required by the next program in line. So if you’re looking for something with a thousand tweaks all accessible by CLI flags and XML conf files … these probably aren’t it.

But you gotta admit: They’re looking good. 😉

sonar.py: Sounds from the deep

I got sonar.py from a regular contributor who doesn’t like to be named, along with a note mentioning that it only does one small thing, and probably wouldn’t be too interesting on the whole.

Au contraire … I think it’s quite interesting, even if the best parts of sonar.py are lost in this medium. As you might have guessed, sonar.py mimics the Hollywood sonar-sound trope, playing a specific tone for both the ping and pong.

But the tipster was right on the other point — aside from that one audio pattern, sonar.py doesn’t show much information. Or rather, there are other ping utilities that show much more.

On the other hand, if you just want an audible for a server status, and don’t care so much about statistical analysis, sonar.py might be a good choice.

Now we just need a ping tool that plays The Bloop, and maybe a few more creepy noises. 😐

xrestop: The irony is palpable

I am not surprised that there is a top-like tool for monitoring the X Window system. After all, there is a plethora of *top tools aimed at any aspect of your hardware or information flow, and X is not that special.

On the other hand, the fact that xrestop is intended to run in a console is ironic at the least.

I know it works, but I also think that most any text-based tool works smoother than something running under X, the slug. That’s just my generalized opinion, and I’m not bashful about it.

But a text-based tool that gives readouts on X system demands is far too ironic to leave alone.

xrestop itself is not in any way disappointing or flawed — in fact, it does a great job showing what is running, what is taking up time and what is most demanding on any particular display. It can accept specific display addresses and report on those, adjust its refresh delay and a few other options through command flags.

All in all, it’s at least as good as some of the other top-esque tools that are out there, aimed at other aspects of your computing experience.

Still … I would have expected something … well, graphical. After all, doesn’t a graphical load monitor aimed at the graphical subsystem just … make sense? 😕 Maybe not.

tagfs, xtagfs, dhtfs and more: Tag, you’re it

For some reason, the last file tagging utility I mentioned, tagsistant, touched off a flood of suggestions on tagging titles. Four or five came from just one contributor alone, and I got e-mails about two or three more from other counties.

I didn’t know file tagging tools were so prolific. I’d always just relied on directory trees as the simplest way to arrange things, but now it seems I am living in 1988. 😐

Anachronistic me aside, I’m terribly grateful for all the suggestions. But the sheer volume — and the time it would take to build, set up, learn, playtest and evaluate all of them — means I must go the short route, and list them here as potentially interesting to you, the reader.

I don’t like doing this because there are undoubtedly some very useful tools in here, and it levels the field between the truly genius and the truly jejune. It’s hard to spot a real winner in a crop this dense though, so if you can attest to any one of these, please give us a steer.

• Dantalian: By the home page’s admission, a “multi-dimensionally hierarchical tag-based transparent lightweight file organization system.” This struck me as closest to tmsu, which I liked best of what I’ve used.
• debtags: If I understand correctly, debtags is the Debian solution for tagging the tens of thousands of titles in their collection, and that’s quite a testament. tagcoll, if I read the wiki right, is the go-to tool for manipulating the tags. I don’t know (but perhaps you do) if debtags or its underlying structure are applicable beyond that project itself.
• dhtfs: A tagging system that sports “dynamic directory hierarchies based on tags associated with files.” That suggests to me that the directory structure will evolve as the tags are applied, which is either attractive or horrifying, depending on you. Personally I’m curious in a morbid kind of way, because I like to manage the way things are arranged on my system. Perhaps I shall set up a dummy system and try it out, just for kicks.
• django-tagging: Kevin sent this one by e-mail, but I don’t have any experience with django, and I think this might go way beyond what I could investigate.
• flickerfs: This one might be oddball of the group: I believe this latches on to your flicker account and allows you to work the tags in use there. But I don’t use flicker, and so I might be way off base with this one. Thanks to Lars for suggesting it though.
• pytagsfs: I see this in Debian with the description, “arranges media files in a virtual directory structure based on the file tags,” which might mean it works something like dhtfs for audio files. I might give this one a try later. The home page listed on the package page doesn’t seem to be related to the project, though.
• stagfs: A “proof-of-concept non-hierarchical FUSE file system deriving structure from independent tag files.” The term “proof-of-concept” says to me that it wasn’t intended for actual use, but it might be a viable product, so don’t take my word for it. I am quite frequently wrong. 😦
• tag-fs: I have my doubts about this one, only because the downloadable source file is all of 36.7Kb, and the trunk is suspiciously concise. Also, it doesn’t appear to have seen updates since 2008, which is not necessarily a bad sign, only a little worrisome.
• tagfs: Not to be confused with the previous project, this has seen more recent updates and appears to be (have been?) a more complete effort. It also seems to have an approach like tmsu or tagsistant, and I can see where it might have inspired those two titles. Another of Eric Davis‘s suggestions from a month ago.
• tracker: tracker confuses me a little bit: Apparently this is a plugin for Nautilus, but I also see that there are things like tracker-utils in Debian, so maybe there are text-based tools that can run it too. If you use GNOME you may want to investigate further. If they can’t be split off from the graphical component, then. … 😦 Thanks to Jonas for the note.
• xtagfs: I have a strong suspicion this is intended as a tool for Macs, but I won’t discount it out of my relative ignorance about Mac-related software. And sometimes I see where tools written for Macs are implantable in Linux systems. You probably know better than me. … 😐

Of course, like I implied earlier, I simply don’t have the time right now to work with every title here, and so there may be one or two in there that are not only incapable or inappropriate, but impossible. My apologies if you stumble across something so useless as to be laughable. I feel obligated to share the information I receive, since people are kind enough to pass it my way. Just remember, as always, your mileage may vary. Happy tagging. 🙂

tagsistant: Tagging with a different approach

After my great delight at trying tmsu, I was willing to try out tagsistant on Eric Davis‘s suggestion. And between the two of them, I think Eric is right: tmsu might be a better fit for me too.

I can see similarities between tmsu and tagsistant; both use directory trees to arrange tags, and to show combinations between them. tagsistant seems very intuitive when it comes to finding mixed tags, with a simple plus sign showing combinations, and so forth.

tagistant “tags” files by “copying” them into a tag folder, which means adding an entire subfolder is a lot easier than tmsu was. And you can tag a directory itself, without necessarily applying the tag to files inside it. I can see where that might be preferable, and the home page suggests that will keep the database slim.

tagsistant is also file-manager friendly, and I suppose the same thing could be said about tmsu. Once I had a few files tagged and cross-tagged, I could work my way through the directory tree with Midnight Commander, and see how files were arranged between tags.

Probably the best part of tagsistant was the setup. The home page shows you in simple steps how to create a tag system, tag individual files and work the query process. It’s a very comfortable introduction.

My complaints against tagsistant are also simple and fairly straightforward: Perhaps biggest, there’s no way I could see to query the tag system without working through the folder tree.

With tmsu I could just ask it outright what tags were applied to a file, but I don’t see an analogue for that in tagsistant. Please point it out to me, if I’m just being dense.

Second, I see no expedient way to apply multiple tags at a time. The copy-file-to-tag motif is an interesting approach, but it doesn’t lend itself to adding three or four tags at once. I prefer tmsu’s approach, of just listing tags in quick succession.

That might go back to my first, and this last point, just that the tree structure for tagsistant is a useful format, but can be very cumbersome without a file manager. Tab completion helps, but each query up or down the tree is going to require some backspacing, correction and possibly even retyping. My advice? Pick a quick file manager.

(Of course, maybe if you could combine this with something like commacd, you might have a very powerful combination. … 😐 )

tagsistant is by no means an unusable tool, and depending on your files and tags, you may prefer this over other options. Definitely look through the advanced documentation, because it will help you with a lot of tagsistant’s finer points.

As for myself, I’ll stick with tmsu, unless one of Eric’s other recommendations wins me over. … 😉

WiFiScanner: Wonderfully geeky

I know this is foolish, but I love tools that have a lot of glitter and dash, even if I haven’t a single clue how to use them.

WiFiScanner is a program that apparently last saw updates way back in 2008, but still compiled for me in Arch, and with a little prodding, worked well:

The trick for me was to use the -C flag to specify the driver for my card, and to make sure the terminal was large enough. WiFiScanner wants plenty of space. 🙄

But I’m willing to coddle it this time, because the results were wonderfully geeky. Lots of flashing numbers, lots of data readouts spinning past in a blaze, little animated graphs, tons of statistics all ticking upward more and more. …

Of course, I haven’t a clue what it all means, but it’s great fun to watch.

I shouldn’t act so naive; I can read enough from the home page to know that WiFiScanner is a tool for … ahem, testing the security of wireless networks, and perhaps if I was more of a security geek, I’d know exactly what to do with all that information.

I can only think of one complaint about WiFiScanner, and that’s because I don’t know enough of how to use it that I might have real suggestions. Here’s my one complaint: The H key shows a help menu, but it’s interspersed with the flow of data in the lower half of the screen. So it zips off the display within seconds. That’s hardly helpful. 😦

If you really want to get your hands dirty with WiFiScanner, poke around in the doc folder of the the source package. There are complete instructions on how to build this in Debian and control it once it’s up and running. Provided you know what you’re doing with it, of course.

As it is, I’m just a babe in the woods, enjoying all the flickering lights and thinking how this would freak out the technophobes in my office, and make them think I was some sort of computer genius. 😀

Either that, or they’d have me arrested on some made-up hacker charge.