moreutils completes the shell's toolbox

vidir

There are some situations that require you to manually modify outputs produced by commands like ls or find . Most of the time, this is done during preparations for other actions. For example you may want to prepare an archive or process files directly, such as deleting a bunch of files.

The moreutils package has a special tool, vidir , that does exactly this. It loads the contents of a directory that by default will be the current directory, or it can load specified parts of the directory (vidir *.jpg ) to a preset editor. The environment variable $EDITOR , or alternatively $VISUAL , define this editor. In order to edit the search results obtained, you should pipe the results from find into vidir . This means you will be able to do things like edit subdirectories with find | vidir - .

The format used by the program is somewhat surprising at first. Each line begins with a line number which vidir uses after the editor shuts down as a way to figure out which files are to be removed. For example if you delete line 18 of the temporarily created file in the editor, then vidir attempts to delete the file contained in line 18 as well. The analogous action of creating files this way does not work. However, you can rename files by changing the name in the file. These name changes are accomplished by reversing the line numbers.

The capability of vidir is highly dependent on the power of the editor that is used. For example, Emacs lets you perform complex, rule-based substitutions and deletions. Having said this, this particular editor comes with its own very powerful interface for the filesystem.

mispipe

Pipes rank among the most powerful constructs in shells. Indeed there is no more effective mechanism for transferring data between different processes. Consequently, pipes are used… a lot . However, by default, many shells only evaluate the return value of the most recent command of a pipe. If one of the previous commands called in the pipe results in an error, then the shell will either not notice this, or it will not respond adequately. This can happen for example in a short circuit test, ||, && .

Many pipes consist of just two commands. The first generates the data, and the second processes it. At this point, it would be important to react if an error has occurred during the first step. This is where mispipe comes into play. It evaluates the return value of the first command.

The command below always generates the output Ooops when there is no file matching the missing* pattern. This occurs because the ls command has generated a return value of 2 . The return value for the grep command doesn't matter here. When the ls command detects matching files, grep filters out all of the lines containing a 1 .

$ mispipe "ls -l missing*" "grep 1" || echo Ooops