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

ddir: Echoes of tree

If you’ve taken a look at the old blog in the last day or so, you’ll know that I’m closing up shop at the end of the month.

The long and boring explanation is over there; the short and snappy one is here: It’s been a decade since I started writing out my Linux experiences there, and two and a half years of chasing down console software here — a lot more than I anticipated on either side.

Suffice to say it’s time for me to move on to new things. I’m also putting an end to the name, so if someone offers you advice in the future and calls themselves “K.Mandla,” it’s not me. 😕

For today, I have ddir to show. It’s not terribly beautiful, but I think you will see its usefulness.

I’ve known about ddir for a while, but to be honest, whenever I’ve needed something like ddir, I just grabbed tree (which I see now is listed nowhere on this site. 😡 ) They are very similar, as I’m sure you’ll admit.

And given that ddir seems to only offer ASCII characters as output, tree offers a small visual improvement. True, it’s the difference between 1982 and 1983 in console graphics, but it’s there.

ddir’s “help” flag will spit out its man page if you ask, and its few options are there for your perusal. Probably of most interest is the -d flag, which will prune the output (get it? prune? tree? ) to directories only.

ddir is a basic tool and probably something an introductory-level CS student could replicate on a Saturday night as a party trick, but you can probably see a few uses for it. It’s in Debian as just “ddir,” but I don’t see it anywhere in Arch.

And the obvious post for tomorrow will be … tree. 🙄

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.

go2: The obvious name for the tool

Last year’s avalanche of directory-switching tools is still reverberating in my ears. I would never assume I found them all, but I am pleased that I’ve found so many. Here’s go2, which is another of the same vein.

go2 is a clever name, since your effectively asking to “go to” some place else. I can appreciate a witty name … although the more I think about it, maybe it’s not so much witty as it is obvious. 🙄

Append go2 with a string and it will try to find a directory in your tree that matches it. Give it the -r flag and it will search through all your root directory, which makes it quick and easy to jump across wide chasms in your system.

The first time you run go2, it will fit itself into your .bashrc, and from then on you can access its finer features without any hassle. Aside from that, I saw very little configuration that go2 needed.

If go2 runs into a situation where there is more than one option, it will prompt you for a choice. If your target is too fuzzy, that can take a little while.

go2 is in Debian, but I didn’t see it in Arch or AUR. go2 has a few other options that you might not see in other fast directory-switchers, but I will leave them to you to discover. To be painfully honest, cd and tab completion are usually enough for me.

If you need a little more oomph at the prompt though, this might be helpful.

commacd: Just so long as you know where you’re going

The home page for commacd insists that it is not a fast directory switcher, and so I’ll refrain from calling it that. It does make switching directories a lot faster though.

But I can see where the difference lies. Things like z or j or j2 or autojump or fasd all tried to apply their own algorithms to switching patterns. commacd, on the other hand, trusts you to know where you are and where you want to go, and then takes you there.

commacd, as you have inferred, ties the cd command to the comma sign. In that sense it works exactly the same.

kmandla@6m47421: ~$ , downloads/
/home/kmandla/downloads

kmandla@6m47421: ~/downloads$

But if I have a nested directory and I know where I want to go, commacd suddenly makes it much easier.

kmandla@6m47421: ~$ , /u/s/j
/usr/share/jack-audio-connection-kit

kmandla@6m47421: /usr/share/jack-audio-connection-kit$

On my system, the only path that has the initials u then s then j is /usr/share/jack-audio-connection-kit, and commacd wisely expands my request to match it, and moves me there.

If there’s any doubt, commacd asks for permission.

kmandla@6m47421: ~$ , /u/s/e
0	/usr/share/emacs/
1	/usr/share/enchant/
2	/usr/share/et/
: 2
/usr/share/et

kmandla@6m47421: /usr/share/et$

A double comma works in reverse, but in the same way as well.

kmandla@6m47421: /usr/share/et$ ,, s
/usr/share

kmandla@6m47421: /usr/share$

Since “share” is in my path and it starts with an s, commacd moved me there. If there is more than one part of my path that starts with that letter, I get moved to the uppermost folder.

kmandla@6m47421: /lib/kernel$ cd /usr/lib/modules/3.16.4-1-ARCH/kernel/net/llc/

kmandla@6m47421: .../3.16.4-1-ARCH/kernel/net/llc$ ,, l
/usr/lib

kmandla@6m47421: /usr/lib$ 

Triple commas are wilder, allowing you to jump anywhere within your tree, not just your path. For example. …

kmandla@6m47421: .../3.16.4-1-ARCH/kernel/net/llc$ ,,, sound
/usr/lib/modules/3.16.4-1-ARCH/kernel/sound

kmandla@6m47421: .../modules/3.16.4-1-ARCH/kernel/sound$ 

And that might be the best feature of commacd: jumping well beyond your $PWD to a folder that’s only tangential to where you are at a particular moment.

No more backtracking to a common branch and then tab-completing down to the folder you want. With a little guidance and the reassurance that you know where you are and where you want to go, commacd will just take you there.

There’s no real downside to commacd, except perhaps that you need to have an idea of where you’re going. If you’re just exploring the bowels of /usr/src or looking for an errant file, it won’t help you much to have that kind of flexibility in changing directories. You might be better with the traditional cd command.

commacd “installs” by sourcing with your .bashrc or .bash_profile, so there’s no compiling and no need for a second program. It keeps no logs, has no daemons and doesn’t care if you like sysvinit or systemd. 😉 It’s wonderfully transparent and so light you won’t even know it’s there.

I like this one a lot, and it’s definitely worth trying out … just don’t call it a fast directory switcher. 😉

cdargs: Changing directories, quickly and visually

I am an avid user of Midnight Commander, and I will admit I sometimes use it as a navigation tool, and not just as a file manager. By that I mean, I can oftentimes navigate to obscure folders more quickly with mc, provided the lynx-like navigation setting is enabled.

That lets right arrows descend into directories, and left arrows bounce back out. Press CTRL+O, and bingo, your shell is there, in the directory. So you have a four-way folder navigation tool and sometimes — not always, but sometimes — it works faster than tab completion.

I’ve seen similar tree navigation with other tools; ranger is the first one to come to mind. ranger’s speed and popularity both depend to some degree on its quick and nimble navigation.

So why not a tool that just navigates directories, and leave it at that? Why not cdargs?

I’m pitching navigation speed and yet I can’t really demonstrate that in a static image. You’ll have to imagine working your way through your own file tree with the arrow keys, quickly bounding between folders with the grace of a gazelle, finally punching the Enter key with authority, and making your selection. Very satisfying.

cdargs also has some bookmarking capability, so you can add hot links to folders you use often. And technically speaking, cdargs has two “modes,” one for the browser and one for the list, and you can switch between them with the TAB key. More high-speed high jinx.

cdargs itself is meant as a drop-in tool for the shell, so ideally you should hunt down the cdargs-bash.sh file or the cdargs-zsh.sh file that should be included, and source them to add that function. I can’t speak to the zsh version, but the bash script adds the cv command, which turns cdargs into a proper directory switching tool.

Just about the only other thing I think I should say about cdargs is, this might be a good tool for command-line newcomers. There’s a visual element here that will probably appeal to people who aren’t yet used to thinking of a file structure as a tree that needs to be traversed. Supplying this and explaining the up-down-left-right arrangement might save some time.

But other than that, I can’t find much more to say about cdargs; the man page and help flags will probably guide you toward menu-based fast directory switching enlightenment. I see this is in both Arch proper and Debian, so it’s quite prolific. …

Oh, wait: No color. 😦 Oh well, nothing’s perfect. 😉

bashmarks: The simple solution

We’ve been through plenty of fast-directory switchers, like j and j2, or z or popd and pushd, and a lot of others (and there are still more to come 🙄 ). But I don’t recall seeing something like bashmarks before, which lets you give a nickname to your path, and recall it in the future.

bashmarks works as a shell script you can either trigger through your .bashrc file, or source directly as you need it. The git package offers to “install” it to .local/bin, but I found it just as usable in its raw form, sourced with . bashmarks/bashmarks.sh whenever I felt I wanted it.

Once you’re hooked in, bashmarks gives you about five commands, all single letters that trigger or control nicknames to folders in your system: “s” saves a path, “g” goes to a path, “l” lists the bookmarks, “d” deletes one and “p” prints the path held in a bookmark.

And basically, that’s all.

kmandla@6m47421: /usr/src/nvidia-96.43.23$ l
downloads            /home/kmandla/downloads
home                 /home/kmandla
nvidia               /usr/src/nvidia-96.43.23

kmandla@6m47421: /usr/src/nvidia-96.43.23$ g home

kmandla@6m47421: ~$ g nvidia

kmandla@6m47421: /usr/src/nvidia-96.43.23$

bashmarks saves its data in ~/.sdirs, and I doubt anyone would complain if you wanted to hand-edit that file, and still move seamlessly around your system.

There are two big reasons I enjoy using this. The first is tab completion with bashmarks, which is such an obvious addition that it would be a huge mistake if it hadn’t been included. The difference between g d[TAB] to get to /home/kmandla/downloads and cd /h[TAB]/k[TAB]/d[TAB] is enough to make bashmarks a useful tool.

The other reason is more philosophical, I suppose: If I was going to create some sort of “fast directory switching” tool, it would probably work like this. It’s the most obvious solution to me.

I’ve seen a lot of other directory switching tools that use stacks or frequency or priorities to try and analyze and predict where I want to go. bashmarks takes the simple path, lets you assign names, and goes where you tell it. And it does that without compiling intricate binaries, background daemons or gnarled dependencies.

It’s even got a tiny bit of color. 😉

And since I’m feeling generous today, and because it does such a bang-up job, I’m going to give out a K.Mandla gold star to bashmarks: ⭐ Don’t spend it all in one place. 😉 Enjoy!

ngp: Find it and edit it, in one deft motion

These days I seem to be finding less and less tools that really grab me, and more and more that seem to fall short of the mark somehow. ngp is one of the former, and this one I think I shall keep around.

ngp is like a recursive, colorized, interactive grep. If you take the output of ack, make it navigable with a selection bar, then add the ability to jump straight into a selected file with your $EDITOR, you’ll have an idea of what ngp does.

So for example, this

 ngp -r ion

Takes me straight to this:

And from there, if I highlight a line and press enter, I jump into $EDITOR and can adjust as necessary. Leave the editor and ngp reclaims the terminal, showing the same results but with red text, so I know I already traveled there. Very smooth. 😎

ngp strikes me as a tool someone would invent where they see themselves repeating the same task over and over, and relying on two or three terminal windows to track their progress. And if you work in text files a lot, or through trees of code, I imagine ngp would save you some time finding certain problems, and fixing them.

ngp can be a little finicky, so watch your flags carefully. And I might have compared it to grep but it’s not feature-compatible, so don’t start throwing wild strings of flags at it and expecting it to munch them down the same way grep does.

But for a find-and-replace or find-and-edit or search-and-destroy at the console tool, ngp has everything tied up in one, nice, neat package. A well-earned, albeit completely valueless, K.Mandla gold star: ⭐ Enjoy! 😉