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

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

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

tdu (and dugroup): I can think of no better title

I don’t mind being wrong, so long as it’s in the right direction.

A year ago I thought tdu was somehow not working. It was an honest mistake; I couldn’t remember how or why it worked when I used it years ago, and thought it had fallen into disrepair.

Quite to the contrary though:

The missing ingredient was that tdu, like ccze and some other utilities, really doesn’t do anything by itself — instead, it expects data to be piped through it. Ergo,

du -a | tdu

gives you an explorable tree showing file sizes and structure. Easy as pie.

Most of what you can extract from du comes through in tdu, although I notice that some conventions, like the human-readable flag -h, seem to pollute the output.

tdu has a few commands while running, most of which you can skim through by pressing the ? key. Perhaps most interesting are n, which sorts by name, or S, which sorts biggest to smallest.

For what it’s worth, there’s a second, lesser utility on the tdu home page, called dugroup. That lets you clump files in groups according to type — backup, image, sound file, etc. — when they appear in du’s output.

As you can imagine, tdu’s output can change a little bit with that thrown into the mix.

tdu’s home page describes it as “a text-mode disk usage full-screen folding outline doohickey utility thingamabob.” I honestly can’t think of a better title than that. 😉

ncdu: You need this tool

Just this morning I ran out of space on a small external drive that I use for system backups and stashing the odd ISO image.

And the first thing I grabbed after the error message was ncdu.

ncdu is one of the best tools available that doesn’t fit neatly into any one category. It’s not quite a file manager, even though it does have some fundamental file management functions.

And it’s not a tree navigator, even if it does display its information in a basic array of nested directory links.

What it does instead is run through the tree, find file sizes and show what’s taking up space. And at times, that can be the most amazing thing.

ncdu’s help screens appear with the ? key, which makes it very easy to learn. Sorting, reverse sorting, display options and error messages are all listed there.

The conventional du and df tools are fine and dandy, and I wouldn’t suggest replacing them at all.

I can say though that ncdu replaced them for me, years ago. And I still use it, even today. 😐

lifelines: A family tree, some assembly required

This little adventure in console applications is barely half finished, and I’ve already run through a huge array of software I otherwise would have never seen.

Part of that is because my own interests just never swing that wide. lifelines is a good example of that.

I don’t have any interest in family history; our branch is more or less the mutts and I’m content with that.

It’s cool to see lifelines work though, even in the very superficial fashion you see above. I know for certain that is barely a sliver of what lifelines does.

If genealogy is your gig, you probably already know about lifelines, and for what little I know of the art of tracing family histories, it’s biggest draw might just be that it’s completely free.

Of course, something like this might need your input to be useful. Some assembly required. 😉