rmlint: The potential to purge

I am behind the power curve today, because of some real-life obligations. I am going to grab something quick and easy so as not to fall behind; things are going to be even busier into the weekend.

This is a snapshot of rmlint in action:

rmlint cruises through your directory tree, and offers to remove files it thinks are duplicates, zero-byte or hollow folders. And as you can see, given enough space, it will take its time to come up with a menu of potential excisions.

I did say “offers,” which is an important distinction. rmlint’s output is a little unexpected: By default it generates a script that will remove suspicious targets, but doesn’t outright eliminate them.

Which is a good thing; it means you have the option to adjust its list, and it also means you take the next step — running the script — with conscious aforethought. You can’t blame rmlint for whacking apart your /usr/lib folder if you told it specifically to do it.

I like rmlint for a number of reasons — it’s rare that I see a system cleaner, it takes the safe route by creating the script, and it has a smidgen of color.

But that’s about all the time I have today; I’ll get deeper into something tomorrow … I promise. 😉

ncdt: An interesting evolution

Quick on the heels of tree and ddir, a loyal reader pointed out ncdt, which takes the tree model and adds a small feature or two.

As you can see, ncdt adds the size of files and directories as part of its default display. So in situations where it’s useful to see directory structure and size — such as labeling removable media, like CDs — it is probably more useful.

Unfortunately, I see no options to adjust what ncdt shows, so there are no “human-readable” (which I prefer) output flags or the like. What you see is what you get.

ncdt also promises to show “special” data for mp3 files, but the Debian version as well as the version I built on my Arch system from the Debian source package showed nothing. Even the sample screenshot in Debian doesn’t show anything “special” for mp3 files. Hmmm. 😦

It’s possible that there is an added dependency that I don’t have, or perhaps the mp3 files I tried post-date what ncdt is capable of analyzing. I checked the ReadMe and source files, but I got no hints. And the only home page I have for ncdt is the Debian package page above.

No matter. ncdt adds a little to the tree model and could probably, at one time in the past, show a little information about mp3 files. It’s an interesting evolution, even if it still needs some attention to reach fruition.

tree: Two and a half years later. …

I think I have just enough applications to round out the month, before calling it quits. Of course, as luck would have it, somehow I made it through 30 months of text-based applications without mentioning tree. So there will undoubtedly be something leftover at the end.

Mentioning ddir first was probably wise though, since tree does most (if not all) of what ddir can do, and then some. I never did find an option in ddir for line-drawing characters, but tree does that by default, has options for color, can use ANSI lines and even codepage 437 graphics (which may or may not produce decent lines on your machine, without the help of cp437).

And perhaps of interest to higher programming powers than I, tree also has options to export to XML and JSON. It’s not terrifically beautiful, but I can see where that would be a great option to have available.

But that’s about all there is to say about tree. It does much the same as yesterday’s program, just with a little more panache. In Debian, in Arch, in … just about everything, I think.

Now, having mentioned tree, I can safely rewrite all those posts from all these past years about software that relies on tree, like pstree and pass and. … 😯

peat: Pete and Repeat are sitting on a fence. …

Here’s a simple python tool that jumps into action when a file changes: peat.

peat is built to execute a command of your choosing, and requires only a list of files to watch as input. As you can see above, probably its most basic use is just to send a message to the screen to announce a change.

But it seems capable of executing almost anything as its target, so you could set it to clean up files, compile a code snippet and run it, or … something completely different.

The syntax to get peat running can be a small challenge; by default peat wants a list separated by whitespace. Check the flags if you want to feed it a list separated by newlines or blank spaces.

I should also mention that in Arch, peat wouldn’t run without calling specifically for python2. On the other hand, it seemed to run without any oddball dependencies or bizarre python libraries, so it may be that it will run well on a vanilla system with no added weight.

I feel like I should mention the long list of file event watchers that are available, so it may be that using python as the basis for a file watcher is still too cumbersome.

And given that their list of features is as wide and long as the list itself, the choice becomes a little more academic. peat is worth investigating if you are comfortable with python and if its advanced handling doesn’t intimidate you. But remember there are many others in the running.

realpath: It’s the real thing

I am apparently still suffering the unintentional side effects of my long-ago decision to dump everything from coreutils, bsd-games and util-linux back into my list. Because yesterday I realized I still had a zero-byte file for realpath hiding in my vimwiki folder. 😡

These things are like rabbits. Turn your back and they’ve multiplied.

realpath belongs to the coreutils family, and I am not being kind by suggesting it has no real function or can’t solve an issue. Remember when I prattled endlessly about basename and dirname? realpath solves some of the issues that I mentioned with those programs.

Here’s what it looks like in action:

kmandla@6m47421: ~/temp$ realpath test.txt 
/home/kmandla/temp/test.txt

kmandla@6m47421: ~/temp$ realpath .
/home/kmandla/temp

Oh, K.Mandla. Thank you sooo much for showing that. Thank you sooo much for solving my existential crisis with realpath. K.Mandla, your grimy little blog is a fount of wisdom.

Hey, my little blog may be grimy, but at least it’s legit, original content. Can’t say that about a lot of Linux “news” sites. 👿

Back to business: realpath, as you can see above, returns the path of the target you specify, or as the man page so verbosely explains, “prints the resolved path.”

Before you close this tab, here’s one more example:

kmandla@6m47421: ~$ realpath sdb1
/media/sdb1

O-ho. What’s this? Well, I keep a symlink in my home directory that targets a mount point — with that, I can abbreviate mount /media/sdb1 to just mount sdb1, no difference.

realpath returns the real path 🙄 of the symlink, rather than just its location in my home folder. Now we’re cooking.

realpath will accept a few flags, but they strike me as particularly discrete cases for links, and tune realpath‘s output more than I would ever need. Double-check them if you feel you may want them.

So there it is. And unless I’m mistaken — again — this really is the last title from coreutils.

I think.

dirname: That slash-mark filter you always wanted

I should probably mention dirname out of coreutils today, since it effectively reverses what we saw the other day with basename. This is easier to show than explain.

kmandla@6m47421: /usr/share/pixmaps$ dirname /usr/share/pixmaps
/usr/share

dirname strips away the directory and shows only the path up to the final folder. In the example it was the current directory — you get the same results from dirname $(pwd) — but you can feed it any path (or more than one), so it’s not correct to say “your current directory.”

If you feed dirname a path and file name, you get the path of to the file, which is where dirname becomes useful.

kmandla@6m47421: ~$ dirname /home/kmandla/downloads/list.html.txt 
/home/kmandla/downloads

Now you can effectively strip away the filename from a string, and leave only the path to it.

kmandla@6m47421: ~$ dirname $(find /usr/share/pixmaps/ -type f -iname "*png") | sort -u
/usr/share/pixmaps
/usr/share/pixmaps/pidgin
/usr/share/pixmaps/pidgin/animations/16
/usr/share/pixmaps/pidgin/buttons
...

So I know I have png files somewhere inside /usr/share/pixmaps, /usr/share/pixmaps/pidgin, and so on.

Now comes the strange part: If you give dirname a file in your current path, you get a lonesome dot.

kmandla@6m47421: ~$ dirname .bashrc 
.

This strikes me as odd behavior, since this is also dirname‘s response:

kmandla@6m47421: ~$ dirname /home/kmandla/.bashrc 
/home/kmandla

The man page comes to the rescue this time, and after reading that, I would hazard to guess that dirname is just traipsing along the string until it reaches the last slash, then dumping everything before that to STDOUT. No slashes means … a dot. 😕

And my suspicions are confirmed with this:

kmandla@6m47421: ~$ dirname this/is/a/test
this/is/a

So basically dirname is a filter for slash marks, and whether or not that represents an actual folder tree on your system is … moot. 🙄

dirname is useful in the same way as basename, but again, I can’t give you any tried-and-true uses that aren’t specific to my own real-life adventures. I leave it to you to come up with something earth-shattering and life-changing to use with dirname. It’s not an impossibility, even if it is just a slash-mark filter. … 😉

inotifywait, inotifywatch and incron: A package deal

I have two or three related titles I’d like to combine today, but I know I probably won’t do justice to any of them. The first two are inotifywait and inotifywatch from the inotify-tools suite, and the other is incron. All of those rely on inotify‘s filesystem notification to alert you when something in storage has changed.

We’ve seen tools like this before — like wendy or watchfile.sh or fsniper or entr — and for the most part, everybody has their own ways of doing things. inotifywait is something valadil mentioned a few months ago, and his (her?) example was good as a starting point. I’ve modified it a little bit:

kmandla@6m47421: ~$ inotifywait vimwiki/index.wiki && echo "File changed!"

The net result being:

inotifywatch works a little differently, keeping track of changes and events and offering a table of results at the end.

kmandla@6m47421: ~$ inotifywatch -t 30 -r vimwiki/*
Establishing watches...
Finished establishing watches, now collecting statistics.
total  access  attrib  close_write  close_nowrite  open  delete_self  filename
25     5       0       0            10             10    0            vimwiki/index.wiki
15     3       0       0            6              6     0            vimwiki/ffff.wiki
15     3       0       0            6              6     0            vimwiki/yyyy.wiki
10     2       0       0            4              4     0            vimwiki/nnnn.wiki
5      1       0       0            2              2     0            vimwiki/cccc.wiki
5      1       0       0            2              2     0            vimwiki/fd.wiki
5      1       0       0            2              2     0            vimwiki/fselect.wiki
5      1       0       0            2              2     0            vimwiki/jjjj.wiki
5      1       0       0            2              2     0            vimwiki/ncmpcpp.wiki
5      1       0       0            2              2     0            vimwiki/yohackernews.wiki
4      0       1       1            0              0     1            vimwiki/.index.wiki.swp
4      0       0       0            2              2     0            vimwiki/pppp.wiki

The main point should be visible here: That you can collect statistics on folder or file usage just by letting inotifywatch run, rather than hinging an action on a file changing.

incron is the last one of these three, and I do it the most disservice by not having anything to show for it. There are two reasons for that; one is that it would take quite a bit to get it configured and working, and second, I couldn’t show you anything specifically incron was doing.

That’s because incron is a cron-style daemon that relies on file changes to trigger events, rather than time periods … which does make me wonder if the “cron” suffix — which I always took to be a mnemonic for “chron,” as in “chronological” — is really appropriate.

Naming conventions aside, incron would only trigger some other program, and I’d be handing you a screenshot of an unrelated program, and saying, “That’s incron. See? See?” 🙄

Regardless, if you find yourself triggering a lot of specific events on a variety of file changes, you might want to consider setting up an incron array, rather than a battery of inotifywait commands.

I think that’s good for now. Any one of these tools could be an alternative to the three or four home-grown ones we’ve seen in the past. Depending on your needs and resources, of course. 😉

moreutils: Exactly what it claims to be

If you had a collection of random text-based tools that bolstered the traditional Unix toolset, what would you name it? moreutils, of course.

Problem is, moreutils isn’t really a program unto itself, so much as it is a group of other, scattered utilities. So no screenshot this time. But I’ll tell you that it includes such classics as:

• chronic, which eats all a program’s output, unless the program ends with an error;
• combine, which allows you to mesh files with binary operations — imagine merging files based on an xor function;
• ifne, which springs into action when an application ends with no output … but is reversible; and
• vidir, which allows you to edit the contents of a directory … imagine the trouble you could get into with that.

There are a lot more, and most of them rather clever. Almost all of them could be accomplished with a little command-line kung-fu — for example, chronic is basically equivalent to >/dev/null 2>&1.

But like any good program, they’ve simply made life easier for you.

Now, before the Unix zealots start to blow a gasket, just take your blood pressure medicine and relax a little. Best I can tell, moreutils isn’t part of any distro by default, which means your idyllic little world of pristine 30-year-old software is unsullied by the younger generations.

And if you’re one of those people who likes to tinker with new tools and maybe get things done more easily, take heart, moreutils is available in the repos of every major distro I checked. Which means so long as you have a connection to the great beyond, you can probably install it.

And with that, we can move deeper into the M section. …

gcp: Seemingly worthy, possibly flawed

I love being able to see what my computer is doing. What most often frustrates me is when a computer is apparently busy, but gives me no feedback to be sure.

This was the issue a few months ago, when I talked about Advanced Copy. gcp scratches that itch for me too.

And I would speak of gcp in the same glowing terms I used with Advanced Copy, except for one strange issue: I get error messages when I try to use this in an X-less environment. 😯

For posterity’s sake, or for debugging purposes, this is the error message that appears in a virtual console.

Traceback (most recent call last):
  File "/usr/bin/gcp", line 678, in 
    gcp = GCP()
  File "/usr/bin/gcp", line 205, in __init__
    raise e
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11

It works fine in a terminal emulator in a graphical environment. But shifting to a console gives that error. I’m not good with debugging, but that’s a little sad.

Perhaps the issue is in the dependencies. Still, I’d sure hate to think that something as simple as a copy tool with a progress bar would rely on all of X to get the job done.

More than likely I have done something wrong. That’s usually the case. Yes, let’s blame it on K.Mandla. 😳

And I see a package called gcp in Debian, and that might be the same. Perhaps it works. Let me know if it does.

I looked for a bug tracker or some sort of feedback mechanism, but I don’t know if it’s available. In the mean time I’ll stick with Advanced Copy, even though gcp was quite promising.