Tag Archives: directory

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

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 

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

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 

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

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. πŸ˜‰

z and z: A tale of two z’s

Remember my little rant from a few weeks ago, the one about single-character application names? If you don’t it’s just as well. I usually regret my rants. That one was no exception.

The point comes through though, since I have two z’s to report — this one and this one.

2014-07-05-6m47421-z-01 2014-07-05-6m47421-z-02

The z on the left is an intuitive compression-decompression tool. By all rights it should sense whether a file should be compressed or decompressed, and come up with the right results. If you remember atool or dtrx or unp, think of it as one of those, with enough smarts to do the opposite, if need be.

I did run into a few problems with z — the z on the left, that is. Compression seemed to sputter in the Arch version, while it looked for something called compress at /usr/bin/. It wasn’t finding it, and so half of what it could do, it couldn’t.

The z on the right is another fast directory switching tool. It’s by the same author as j and j2, and seems to follow the same pattern.

If you place the z.sh script somewhere in your $PATH, and change the $_Z_CMD variable to just “z”, then you should start building a database of recently visited directories. From there you can jump straight to a particular one by prefixing it — or part of it — with just “z”.

In theory, of course, and there is more to it than just that. It works acceptably well, although personally I’m not much of a fan of fast-directory-switcher-gizmos, and so a lot of it is probably lost on me.

So there are the two z’s, and I’d like to just take one last second to remind everyone out there who is working on building The Next Great Killer App, The Program That Will Change Life As We Know It, The Application That Consumed The Entire Universe In One Slobbery Gulp, to please — please — think rationally for just the briefest moment, and give your program a name that’s longer than just one stupid letter. 😑

wendy: Under wendy’s watchful eye

I know we just saw watchfile.sh the other day, but I can’t account for the whims of alphabetical order.


tsar11 sent a link three or four months ago to a reddit post about wendy, which monitors files (or directories, for that matter) for changes, and then executes a command as a response.

As you see there, it could be something as simple as a message on screen, or it could be as complex as an order to recompile a program.

wendy can discriminate between file modification, file creation and file deletion, which is handy. If I had told it to spawn a warning only when a file was created, that gif probably would have been shorter. πŸ™„

wendy also knows enough to keep quiet when told, or to poll at distinct intervals. All nice touches.

I don’t have any complaints about wendy. It seems to handle more complex cases than watchfile.sh, works better than fsniper did (for me), and seems to work at least as well as entr.

wendy’s home page shows edits within the past few months, so if you find there’s a feature it lacks (for one, I’d like to see the option to discriminate actions based on either modification, deletion or creation), the author is probably listening.

In the mean time, your homework will be to daisy-chain all four of these together and see what kind of ruckus erupts as a result. 😈

watchfile.sh: Perhaps the best thus far

It’s been a while since fsniper, and even longer since entr. Here’s watchfile.sh, which also watches files for changes, and then executes a command.

It’s a little difficult to show, so you might have to use your imagination. There are several ways to cue it; in my test runs, this:

./watchfile.sh test.txt cat test.txt

was enough to refresh the screen with my edits, when I saved test.txt back to disk from another terminal window.

That’s not the only way to use watchfile.sh, and the help flags will give you ideas on other methods. For example, you can monitor the output of a second command, and when that changes, execute a third command.

I like watchfile.sh a lot better than either fsniper or entr. fsniper was a bit more complex, and in the end, didn’t quite work. entr, on the other hand, worked fine, but expected to receive updates through a pipe, which is a tiny bit clunky.

But watchfile.sh is very straightforward and very flexible, and does what it promises. And I like that the task is reduced to an easily dissected script, rather than complex code.

So my advice, if you have to pick one of the three, is to go with watchfile.sh. Unless of course, you have another method you prefer. πŸ˜‰

vdir: Consult your doctor before beginning this, or any other exercise program

The tip for the day will be, “How to save yourself at least one keystroke, several times a day.”

But first … a test. Which one of these is vdir and which one is ls -l?

total 80
-rw-r--r-- 1 kmandla users 7711 Jun 14 13:18 output-01.txt
-rw-r--r-- 1 kmandla users 7768 Jun 14 13:18 output-02.txt
-rw-r--r-- 1 kmandla users 7712 Jun 14 13:18 output-03.txt
-rw-r--r-- 1 kmandla users 7792 Jun 14 13:18 output-04.txt
-rw-r--r-- 1 kmandla users 7788 Jun 14 13:18 output-05.txt
-rw-r--r-- 1 kmandla users 7739 Jun 14 13:18 output-06.txt
-rw-r--r-- 1 kmandla users 7753 Jun 14 13:18 output-07.txt
-rw-r--r-- 1 kmandla users 7749 Jun 14 13:18 output-08.txt
-rw-r--r-- 1 kmandla users 7754 Jun 14 13:18 output-09.txt
-rw-r--r-- 1 kmandla users 7715 Jun 14 13:19 output-10.txt
total 80
-rw-r--r-- 1 kmandla users 7711 Jun 14 13:18 output-01.txt
-rw-r--r-- 1 kmandla users 7768 Jun 14 13:18 output-02.txt
-rw-r--r-- 1 kmandla users 7712 Jun 14 13:18 output-03.txt
-rw-r--r-- 1 kmandla users 7792 Jun 14 13:18 output-04.txt
-rw-r--r-- 1 kmandla users 7788 Jun 14 13:18 output-05.txt
-rw-r--r-- 1 kmandla users 7739 Jun 14 13:18 output-06.txt
-rw-r--r-- 1 kmandla users 7753 Jun 14 13:18 output-07.txt
-rw-r--r-- 1 kmandla users 7749 Jun 14 13:18 output-08.txt
-rw-r--r-- 1 kmandla users 7754 Jun 14 13:18 output-09.txt
-rw-r--r-- 1 kmandla users 7715 Jun 14 13:19 output-10.txt

It’s a trick question, I admit it. vdir by default looks like, smells like, tastes like plain old long-form ls. And unless you’ve got color settings or special aliases piping particular flags back into ls, they’re obvious twins.

In fact, their flags are dead ringers. They both arrived in your system on board coreutils. Their man pages are so close as to be copied-and-pasted. The similarity is uncanny.

So what’s the point? Why bother bringing vdir into the picture, if it’s just an ls knockoff?

Beause “v-d-i-r” is exactly one character shorter than “l-s-space-dash-l”.

And given that a 70kg person burns a whopping 50 calories typing for a half an hour … and the commonly accepted words-per-minute calculation is standardized to five-letter words … and a 40 wpm typist covers 1200 words in 30 minutes, pounding out 6000 keystrokes in that amount of time. …

I do believe, if my calculations are correct, each keystroke burns 0.0083 calories. Aha! I just saved you 0.0083 calories, which you can spend walking to the refrigerator, if you like. 🌯 |_|

Oh wait, were you trying to lose weight … ? :/

sl: The other sl

I spent my obligatory 30 minutes this morning trying to figure out what had broken to spew garbage all over my screen in the place of Firefox. Then I realized it was Firefox, in some new and mutated flavor.

Once the hate had flowed through me, I sat down and started looking for options, and so I type to you now from Pale Moon, and so far things are as good, if not better.

All that aside, it’s time to look at the other sl, the one kwlblt mentioned and nobody seems to know about. Or at least I sure didn’t know about, until last week.


I really, really like this. Rather than just rely on the strict ls rundown, sl categorizes files, shows you how big they are if they’re unusually large, how old they are if that is also unusual, if links are broken, if files are executable, etc., etc.

sl is also smart enough to lump directories according to their contents. So for example, my wallpaper directory shows up under the “images” heading, and not just as a folder.

It’s a much more practical, human-ish approach to directory contents. And it has color! πŸ˜€

I don’t see this as a replacement to ls, so much as an amplification. There’s information that is more handy from ls, and there is some that is more intuitive in sl. I hope to use both.

And all this time, it was hiding behind that ascii locomotive. Tsk, tsk. … πŸ™‚

popd and pushd: The original fast directory switching

I’ve run across more than one fast directory switcher in the past 15 months, most notably fasd and j and j2. What you might not know is that the bash shell comes with a primitive fast directory switcher … of a sort.

popd and pushd are built-in commands in bash (and zsh, I believe) that work with a manageable stack of directories that you can bounce between. And since it’s been a while since we actually dug in to one of these tools, it’s probably a good time for an in-depth look at pushd and popd.

Compared with fasd et al., pushd/popd may take a little getting used to. Here’s a simple example:

kmandla@lv-r1fz6: ~$ pushd /usr/share/
/usr/share ~

kmandla@lv-r1fz6: /usr/share$

When I use pushd and a directory, I bounce straight to that location, and the path is put into the directory stack. pushd by itself effectively swaps entry Nos. 0 and 1. Either way, pushd‘s output is the current directory stack, from left to right, zero on up.

I can check what’s in the stack and the order with dirs (I like dirs -v, personally).

kmandla@lv-r1fz6: /usr/share$ dirs -v
 0  /usr/share
 1  ~

kmandla@lv-r1fz6: /usr/share$

The stack works LIFO, meaning last-in-first-out: The last (or newest) item added to the the stack is the first one used.

Zero (or the leftmost entry) is your current directory; you can cd to a new location without interfering with the stack. I can also add another destination if I like.

kmandla@lv-r1fz6: /usr/share$ pushd /lib/kernel
/lib/kernel /usr/share ~

kmandla@lv-r1fz6: /lib/kernel$

Now I have three in the stack. If I want to bounce back to a previous directory, I use popd to “pop” out the zero entry and jump to No. 1 in the stack.

kmandla@lv-r1fz6: /lib/kernel$ popd
/usr/share ~

kmandla@lv-r1fz6: /usr/share$

Note that I jumped back to /usr/share, and that /lib/kernel was removed from the list. The whole stack shuffles up one space.

If I had a lot of directories in the stack, I could successively popd through them until I arrived back where I began, and the stack would be empty.

kmandla@lv-r1fz6: /home$ dirs -v
 0  /home
 1  /boot
 2  /lib/kernel
 3  /usr/share
 4  ~

kmandla@lv-r1fz6: /home$ popd
/boot /lib/kernel /usr/share ~

kmandla@lv-r1fz6: /boot$ popd
/lib/kernel /usr/share ~

kmandla@lv-r1fz6: /lib/kernel$ popd
/usr/share ~

kmandla@lv-r1fz6: /usr/share$ popd

kmandla@lv-r1fz6: ~$

It’s not ideal if you have a series of directories you want to keep, and it’s hard to imagine how it works if you’re trying to visualize it like “bookmarks.” It’s not really like that at all.

In fact, it might be easier to think of it like a stack of plates: You can “push” a plate onto the top of the stack, and then “pop” out whatever is on top.

And aside from pushing and popping, there are some rudimentary management tricks. You can use dirs -c to clear the stack, -l lists them longhand and -p prints them in plain form. Using a plus or minus displays the number of entries from the left or right in the stack, respectively. Remember again that the leftmost is No. 0, and they increment as you move to the right.

popd and pushd work differently with the plus or minus; popd “pops” out the Nth entry from the left with minus, and from the right with a plus. pushd rotates the stack a certain number of steps to the left or right, with plus or minus.

kmandla@lv-r1fz6: /home$ dirs -v
 0  /home
 1  /boot
 2  /lib/kernel
 3  /usr/share
 4  ~

kmandla@lv-r1fz6: /home$ pushd +1
/boot /lib/kernel /usr/share ~ /home

kmandla@lv-r1fz6: /boot$ pushd +2
/usr/share ~ /home /boot /lib/kernel

kmandla@lv-r1fz6: /usr/share$ pushd -2
/home /boot /lib/kernel /usr/share ~

kmandla@lv-r1fz6: /home$ pushd -1
/usr/share ~ /home /boot /lib/kernel

kmandla@lv-r1fz6: /usr/share$ dirs -v
 0  /usr/share
 1  ~
 2  /home
 3  /boot
 4  /lib/kernel

kmandla@lv-r1fz6: /usr/share$

Note that each time, the list was shuffled and the current working directory changed.

Final tip: If it annoys you that popd always dumps an entry off your stack, start relying on pushd +N, which will just cycle you through the list. And remember: pushd by itself just swaps Nos. 0 and 1 in the stack, effectively bouncing you between two directories. 😎 Aha! You can thank me later. πŸ˜‰

“Modern” fast directory switchers might have more conventional features, but for sheer lightness and convenience, pushd, popd and dirs are reliable and useful. Not bad, for software that dates back to 1976. 😯

If you want more guidance, try the bash reference manual, or enter help with any of pushd, popd or dirs. The learning curve is not too steep, but it may take some getting used to.

Enjoy. πŸ˜‰

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

Midnight Commander: The industry standard

I know there are people who manage files and directories strictly from the command line, and eschew file managers as a general rule.

Personally I see no problem with that. There are some file- or directory-oriented chores that are better left to other tools, and not file managers.

It’s equally true that there are some times when a file manager is just the easiest and quickest way to do the job.


I’ve mentioned Midnight Commander probably a thousand times in the past six or seven years, between this site and the old one. For my money, it’s still the best tool for moving things around gracefully and quickly.

Like everything, it has its share of peculiarities. But most are easily overcome through the drop-down menus and a quick glance at the man page.

mc is theme-able, can handle FTP transfers, can decompress archives into virtual directories (so you don’t have to decompress a file to skim through it), has custom menus and key sequences, mouse support, built-in editor, built-in viewer, file associations, bookmarking, tab completion, and a lot more. And best of all, it’s actively — very actively — maintained.

Oh, and it has color. :mrgreen:

I called it the industry standard in the title, and I don’t think that’s a misnomer. Any text-based file manager (or graphical, for that matter) has to stand up to mc before I’ll consider adding it to my stable. mc shows where a newcomer is obscure, incomplete, obtuse or just inconvenient.

And I guess that’s the best I can say about a program — that it’s what I use to judge others. 😐