I used the venerable less as my pager for a long time, but I wanted something more Emacs-like. And what could be more Emacs-like than Emacs? Fortunately I found Kaushal Modi's excellent eless shell script, which runs an instance of Emacs that's been adapted to make it work like a pager.

But that was almost 5 years ago, and while much of the core functionality from eless remains in my version — which I've not very imaginatively named empager — I've made a lot of changes to it, both to add functionality and so that it works as much as possible like Emacs does when I use it as an editor. It doesn't work exactly the same because I want it to function in as many environments and situations as possible (such as on newly-installed systems), so empager

• doesn't use any external packages: it only uses ones that are bundled with Emacs,
• doesn't assume that internet access is available, and
• has a minimum of external dependencies: as much as possible is contained in the script itself.

The added functionality includes:

• saving search strings and register contents across invocations (which can be useful when reopening the same file after closing it prematurely, or when looking for the same pattern in different files)
• allowing the line number at which it is to be opened to be specified for each file (using a syntax similar to the one Emacs itself uses)
• allowing the version of each file to open to be specified, provided it's under git or CVS version control
• supporting as many of the less program's command line options as could be reasonably easily implemented (or, in a few cases, ignored), at least when they don't conflict with the Emacs-like options that empager accepts
  • for example, if the -F option is specified and only one file (or source) is being paged then its contents will be written directly to the screen without starting Emacs if (and only if) those contents will all fit on a single screen
• easy saving of positions: each shifted positive digit (e.g. '!' for '1') saves point (that is, the current cursor position) in the register whose name is that digit, and the digit itself jumps to the position saved in that register
• opening the current file in your main Emacs instance (using the e command), with point on the same line
  • since files in a pager can't usually be edited, many single characters (like e) are repurposed to run commands

If you end up trying out empager you may notice that there are some "idiosyncratic" keybindings. They almost always correspond to custom keybindings that I use in my main Emacs editor, and may not be to everyone's tastes. In which case you can edit your copy of the script to create a custom Emacs-based pager of your very own.

find . -name '*.txt' | xargs p

MANPAGER=empager
export MANPAGER

alias py2='PAGER=bempager python2'
alias py3='MANPAGER=bempager python3'

alias lman='MANPAGER=less man'

"\C-p": " 2>&1 | p"

curl wttr.in/:help

curl wttr.in/:help 2>&1 | p

This is a brief post about a short sed script I wrote called org-quick-tangle that can very quickly tangle an org mode file, but that works properly only on certain files. Specifically, it

• only respects :tangle header arguments on source blocks (that is, on #+begin_src lines) and completely ignores any others, such as those specified in properties drawers,
• writes all of the code blocks (that it doesn't omit) to its standard output, ignoring any destination file that may have been specified for them, and
• does some special handling of anything that looks like a Lisp comment line (though it's very unlikely that this handling will have any effect on tangled source code that's written in non-Lisp languages).

While it should work to tangle any source code within the limitations outlined above, the primary reason I created it — and the only thing I use it for currently — is to generate an Emacs Lisp file from my literate Emacs configuration.

How fast is it? On my not overly powerful desktop machine it tangles my 1.4MB kitchen-sink org mode configuration file into the corresponding 627KB Emacs Lisp file in about 40 milliseconds, which is all but instantaneous. In comparison, on the same machine the script that uses org-babel-tangle-file to do the tangling takes about 2 minutes. However, the slower script's results do include links back to the org mode file, so I usually use org-quick-tangle to save time testing my Emacs configuration changes (which savings can be considerable if I end up having to tangle multiple times) and then once I'm sure that the changes work correctly I'll use the org-babel-tangle-file-based script once to tangle the final Emacs Lisp file.

Hopefully you'll find this sed script useful in reducing the time you spend tangling, whether it's your Emacs configuration or some other source code.

There seems to be an endless supply of solutions to the problem of moving around the filesystem quickly and efficiently. So what's one more?

I knew that rather than something that made it easier to switch to the most recently or most frequently visited directories I wanted my "relocation" command(s) to be deterministic, so that execution of the same command line would always switch to the same directory (assuming no changes to the underlying directory structure, and assuming the same initial working directory when switching to a directory with a relative pathname). That would make it easier to use the relocation commands in non-interactive situations like executing command lines retrieved from the command history and when "stacking" commands: that is, when typing a command or sequence of commands into the terminal while waiting for an earlier long-running command to complete.

Near the top of the file named relocate-functions.sh in the repository are instructions for setting up the commands that we'll be discussing, so we don't cover that here. We also use the short names/aliases for relocation commands, which get defined only if you use the "easy" installation method. If you choose to define your own aliases instead¹ then it's recommended that at least the one that's equivalent to the r alias be given a fairly short name, since the more you have to type the less convenient switching directories will be.

rs alias dir

rs ed ~/.emacs.d

rs b ~/backup

rs -f b ~/bin

r ed themes

r ed s

Also: /home/jgm/.emacs.d s -> site-packages, snippets
/home/jgm/.emacs.d/saved

r ed z

r ed .he

r ed .he.s

r ed he.s

Searchdown provides a simpler, pithier and (arguably) more standard interface for find … and find … | xargs … commands, with additional support for find … | xargs grep … commands.

If you need to list or operate on some or all of the files under one or more directories (where for our purposes a file is under a directory if it's directly in that directory or if it's under one of that directory's subdirectories) it's hard to beat the standard find command. Among its advantages are:

• it comes preinstalled with most UNIX-like operating systems (as do xargs and grep),
• it's reasonably fast in most cases and allows the user to improve its speed and efficiency based on their knowledge of the files being searched, and
• its options for selecting which files to find are all but comprehensive: I don't think I've ever had a set of criteria that I couldn't translate into find options.

It does have some disadvantages when used interactively, though:

• many of its options - including some of the most commonly used ones - are both long and nonstandard (e.g. -file instead of --file or -f),
• you always have to specify at least one directory: there's no default (and can't be, as a consequence of the command's syntax)
• by default it doesn't properly handle pathnames containing spaces or other special characters, and
• it can be overly persnickety about the ordering of some of its options: order does often affect the results and efficiency of its search, but in some cases - the -mindepth and -maxdepth options are where I've most often encountered it - find (or at least the GNU version of find) will complain about where an option appears in a command but will then carry on running that command, so presumably it wasn't confused about what was intended, just displeased.

The main reason that I wrote searchdown was that find commands - including ones combined with xargs - were among the ones that I used the most, and were also some of the longer commands to type. I didn't need the implementation to change, just the interface, at least for the sorts of find commands that I used frequently. So I wrote a Python program that

• provides a simpler, more standard and less verbose command line interface, and then
• builds and runs the corresponding find command.

The options and arguments that searchdown takes are all described in its usage message (with some delegation to the find command's documentation), so I won't repeat that here. Instead I'll give some examples of how I use it, which is often by way of the shell aliases and functions defined in the searchdown-aliases.sh file that's included in the searchdown git repository.

But first things first. The name of the searchdown command itself is pretty long: it's more than twice as long as find. Not an auspicious start! Personally I feel that short command names should be reserved as much as possible for use by the user for (aliases for or symbolic links to) the commands that they use the most often, so I tend to give my programs longer names and then define shorter aliases for them.

In the case of searchdown I give it the alias sd, which is how it'll appear in the examples below. More accurately, sd is an alias for a shell function (defined in searchdown-aliases.sh) that sorts the results and runs them through the default pager program, and also assumes that when it's given a single non-option argument that it's a regular expression to search for in all of the matching files. So for example the command

sd Som.thing

is equivalent to the find command

find -O2 . -print0 | xargs -0r grep -I -D skip -d skip -H -n 'Som.thing'

(where most of the grep command options just cause directories and binary and device files to be ignored). Note that pathnames containing spaces or any other special characters - including newlines - are handled properly.

Sometimes you just want to list all of the files of a given type: the command

sd -tl

will list the pathnames of all of the symbolic links under the current directory by running the find command

find -O2 . -type l | sed 's_^\./__'

(where the sed command just removes ./ from the start of any pathnames that start with it). The sdl alias from searchdown-aliases.sh does the same thing, and the sdf and sdd aliases do the same thing but for regular files and directories, respectively, instead of symbolic links. And all three aliases work like sd does in that if they're given a single non-option argument then they assume it's a regular expression to search for in all of the files that are found. I use commands of the form sdf foo quite a bit.

Another type of searchdown command that I find useful finds a subdirectory when I can only remember the start of its name

sdd -p Pre

the end of it (sdd -s Suf) or some fragment of it (sdd -c Part). And of course the sdf, sdl and sd commands can be used in place of sdd to search for files of other types, or of any type.

Emacs users might find the -fb option handy: for example

sd -D src -D doc -fb

will list the pathnames of all of the backup files - that is, files that end with a tilde (~) - that are under either the src or the doc subdirectories of the current directory. All of the files that are found can then be deleted by rerunning the command and adding -- rm to the end of it:

sd -D src -D doc -fb -- rm

which is equivalent to running the find command

find -O2 'src' 'doc' -name '*~' -print0 | xargs -0r rm

(The fb alias can be used in place of sd -fb.)

And as some final examples I often use searchdown's -e option to only match files with a given extension (where the extension can be specified with or without a leading '.'): sd -e mp3 (or sde mp3) will find all of the MP3 files under the current directory and (like the sd, sdf, etc. commands) the command sde txt Som.thing will find all of the lines that match the regular expression 'Som.thing' in all of the text files (that is, files with the .txt extension) under the current directory, ignoring any other files. If you often grep or operate on files with a given extension - markdown files, for example - then it can be worthwhile to define a shell function or alias for that type of file. There are already several defined in searchdown-aliases.sh that you can base yours on.

I hope this gives you some idea of what searchdown can do, and whether it's something you'd find useful. I've been using it for a few years now and I find that I go for months at a time (or even longer) between direct uses of the find command. In fact, if I hadn't used the find command for so many years before that - and if I didn't use it from time to time in shell scripts - I'm not sure how well I'd remember it's syntax! But you don't have to worry about that either: just add the -n option to any searchdown command and it'll output the equivalent find command without running it. (Or use the -v option to both output the command and run it.) This can be useful for generating find commands for use in shell scripts where you don't want to add a dependency on another script (i.e. searchdown).

https://ineverynook.com/auth/invited/public464808186

to sign up for a free trial account (where you just have to choose a username and (longish) password and provide any e-mail address) and give InEveryNook.com a try. But if you get lost or stuck or run into problems then read on ….

InEveryNook.com is a web app that helps you, your guests and the people you live with find things in your home by helping you record and keep track of where everything is. Then when you're looking for something you can enter what you're looking for into the search box at the top of most of the app's pages (including the sign in page) and get a list of all of the matching items in your home, along with their locations. And your guests (if you've allowed it) and the people you live with can do the same thing.

The app also makes it easier for you to add your things to it by providing lists of common items and storage places that you can select from. And it provides some other, related features like allowing someone to report it when they discover that you're low on, out of or missing an item that they searched for.

I created InEveryNook.com because while in an ideal world I'd have everything organized and in the first (or even second or third) place I'd look for it, I came to realize that realistically I won't ever manage that, and even if I did it wouldn't stay that way. Plus one only has so much storage space, so things that are used infrequently end up in out-of-the-way places - like the backs of cupboards or in boxes on high shelves - where it's easy to forget that you even have them, let alone find them again when you need them. But I figured that it was realistic for me to (eventually) go through all my stuff and (with a little reorganizing here and there along the way) record where each item is stored so that I could search for it again later. Which is where InEveryNook.com comes in. Now I just have to finish adding everything ….

Anyway, I hope you find it useful. If you encounter any problems or if you have a question or comment then please feel free to e-mail me about it. (Or about anything else here, for that matter.)

User interface. I spend most of my time on the command line, in Emacs or using a web browser, so consequently most of the programs here are command line (CLI) programs. Some of the Emacs Lisp code here may provide a more advanced/complex user interface, but since I use the terminal version of Emacs I wouldn't expect anything too fancy.

Platforms. I haven't run anything but Linux for quite some time, so for the most part my software has only been tested on that operating system. It should work on all Unix-like OSes (like MacOS or the BSDs), so if a particular program doesn't then please report it via its GitHub page. But some of my programs may (usually inadvertently) assume that reasonably current versions of the GNU implementations of core and other utilities are being used: unless it's fairly straightforward to make such a program work with other implementations the "fix" will be for you the user to use recent versions of the GNU implementations of the relevant programs.

Standalone shell scripts. In general I prefer that each of my scripts be self-contained so that just the one file can be copied to another machine and it will just work (assuming the programs that it executes exist there, of course). However, this does result in common and boilerplate code being duplicated across scripts. (This isn't really a maintenance problem for me since my scripts are generated from an org mode file in which a given piece of common or boilerplate code appears only once and is inserted into each of the generated scripts using noweb-style references.)

Commit histories. The GitHub commit histories tend to be very shallow. This is primarily because locally I use CVS rather than git for my personal projects. (Hey, if it's good enough for OpenBSD.) There doesn't seem to be any easy way to convert files from a CVS repository into a git repository, so for the most part I just added the current version of each program to a new git repository and then pushed it to GitHub. Of course, any and all future changes will show up in git. And I may include with some posts a short history of the program: the date when the program was first written (or at least committed) if nothing else, but also any changes of note.

Origins. When a program of mine is based on someone else's code or even inspired by someone else's idea I do my best to indicate that in the source code: in the comment at the top of the file if it applies to the whole program, or at the relevant point in the body of the program if it only applies to that part of the program. Unfortunately the oldest of my programs don't contain this information, and so what their origins and inspirations were has been lost.

Copyright and licensing. You should check the individual programs to be sure, but the code of mine that's up on GitHub should be covered by the GPL3+ license: that is, version 3 or later of the GNU General Public License.

One final note: these programs have been written over a number of years, so you may notice variations in the style and techniques (and idioms) used.

There are any number of ways to get your computer to do math, but I wanted a command line program to quickly, easily and in as natural a way as possible do basic calculations like summing a few numbers, calculating an item's after-tax price or doing basic unit conversions. I also wanted it to operate on both integer and real values and give results to a reasonable number of decimal places.

Of course, I wasn't going to implement the part that did the actual math since existing programs already do that. One of the earliest versions of my calc script was just a minimal wrapper around one such program: bc. Aside from code to output a usage message my script's implementation was basically

echo "scale=2; $*" | bc

which combined all of the command line arguments into a single expression for bc to evaluate, after setting the default number of digits after the decimal to 2 (which is sufficient for most calculations and ideal for ones involving (my local) currency). Note that the result from bc may be an integer or may have fewer or more than the default number of digits after the decimal depending on what's appropriate for the particular computation.

(Also note that the default number of digits after the decimal affects intermediate as well as final results of calculations, and so the result of a calculation with fewer digits after the decimal may not just be a rounded - or even truncated - version of the result of the same calculation done with more digits after the decimal.)

This version worked pretty well, especially with = (that is, a single equals sign) as a symbolic link to calc:

= 2 + 2
= 12.34 + 56.78 + 90.12
= 5 / 3
= '42.5 * 17'
= 42.5 \* 17

Having to quote or escape multiplication signs to protect them from being expanded by the shell into every file in the current directory was less than ideal, but a simple - if a little brute-force - change

echo "scale=2; $*" | tr 'x' '*' | bc

fixed that. Now the 'x' character could be used as a multiplication sign as well:

= 42.5 x 17

722.5

So now the four basic mathematical operations could be used without having to quote or escape anything. Parentheses still required - and still do require - escaping or (usually easier) quoting, however:

= '(23.40 + 12.34) x 1.12'

40.02

The final tweak - until very recently - was to allow the default number of digits after the decimal to be customized on a per-session or a per-command basis. The implementation effectively became

echo "scale=${CALC_SCALE:-2}; $*" | tr 'x' '*' | bc

which allowed the CALC_SCALE environment variable to be used to specify that default:

= 5 / 3
export CALC_SCALE=4
= 5 / 3
CALC_SCALE=8 = 5 / 3
= 5 / 3
CALC_SCALE=
= 5 / 3

And that's where it stood until I looked at it again in preparation for writing this post. While it's still not a very long script its core is definitely no longer a one-liner. But calculations can now include the mathematical constants pi and e, as well as the sin(), cos(), atan(), ln() and exp() functions, and the default number of digits after decimal is now easier to customize:

• the CALC_SCALE environment variable's name was too long for convenient use on the command line, so the sc environment variable can also be used: sc is intended for use with a single invocation of calc, while CALC_SCALE should be used over larger scopes
• if the program's basename is an equals sign (=) preceded by one, two or three digits then the number that those digits represent will be the default number of digits after the decimal

(A program can be given an additional basename by creating a symbolic link to it: for example, executing ln -s calc 15= will create a symbolic link that can be used to perform calculations with a default of 15 digits after the decimal place.)

So calculations like the following are now possible:

= 2 x pi x pi
export CALC_SCALE=5
= 2 x pi x pi
sc=8 = 2 x pi x pi
= 2 x pi x pi
8= 2 x pi x pi
9= 'sin(1.2) x sin(1.2) + cos(1.2) x cos(1.2)'
sc=10 = pi

Will I use this additional functionality often enough to warrant the added complexity? I'm not sure. But if I didn't add it then there wouldn't be any way for me to find out. It's not a huge increase in absolute complexity in this case (even if it is in relative complexity), but I think the same reasoning applies to other, larger programs as well. Of course, I could always remove the new code if it turns out I don't use it, but who ever does that?

As a final note, Emacs users can use the quick-calc command to access similar functionality, as I recently found out. Well, rediscovered actually, since it turns out that I've had a keybinding for it in my Emacs configuration since 2018 and had completely forgotten about it: a not uncommon occurrence.