nnn – a terminal-based file manager

nnn, findable at https://github.com/jarun/nnn, is a terminal-based file manager written in Go, which claims high performance and has a pretty flexible set of functionalities including:

  • Can spawn your favorite $VISUAL $EDITOR to edit files
  • Bookmarks (haven’t used)
  • Fuzzy searching for files
  • Pin frequently used files/directories
  • Mount and manage archives
  • Lots of plugins https://github.com/jarun/nnn/tree/master/plugins to extend its behaviour

I have, several times, scheduled tasks (taskwarrior!) to poke some more at nnn. It seems inevitable to not go anywhere.

Why that is finally occurred to me; the reason is that my workflow that would be most relevant to this takes place inside emacs, in the Dired mode.

There are some neat things in nnn, notably the fuzzy searching, which would lend itself to somewhat more nondeterministic searches for Files Of Interest. However, the learning curve of switching to a dramatically different tool is not to my taste.

If you’re one of the vi crowd, this may be to your taste; it seems interesting. (I was tempted enough to keep it lurking in my task list for a couple months.)

My saga with tmux

I have been a longstanding user of GNU screen, a terminal multiplexor, which is loosely a terminal-oriented equivalent to an X window manager. For a fair number of years now, I have been using tmux instead; it was written more recently, starting from scratch, with BSD license, and so is somewhat smaller, perhaps faster, and leaves behind features that weren’t of much interest.

What I do with this

I commonly set up tmux sessions when I first log onto a system, and set up some sub-terminals tied to useful tasks such as:

  • Command sessions – I’ll always have some terminals ready to run commands
  • Log tails – if I am debugging something, I will set up a tail -f command in a virtual terminal to watch the logs, so that I may quickly switch to that terminal and see what has recently happened
  • ssh sessions for command sessions running on remote hosts (on my laptop, these will be mosh sessions
  • kubernetes sessions – command sessions where the CLI environment is set up for one k8s environment or another

Further tools

The awesome-tmux Github site has a whole lot of useful links to “meta-tools” for use with tmux, various of which I have found useful:

  • tmuxinator allows setting up a whole tmux session complete with numerous virtual terminals connected to commands and environments
  • gitmux puts git status information into the tmux status bar, which is nicer than putting it (as I have done with zsh) onto the start or end of the command line
  • tmux-continuum will automatically save the state of a tmux session environment so that a complex environment may be automatically recreated. This is pretty cool as a “perhaps better than tmuxinator” thing; with tmuxinator, it’s easy to restart, but you need to add environment configuration manually to tmuxinator configuration, whereas continuum picks that up automatically. There are definitely advantages and disadvantages in both directions; tmuxinator will tend to have a “cleaner” environment, but you need to do more work to get that cleanliness.

Also playing with 3mux

3mux was inspired by tmux and by the i3 window manager; it makes more natural use of the mouse, has a claimed-more-sane set of keybindings, and claims a shorter learning curve.

I have played with it a bit; in view that I had gotten through the GNU Screen learning curve many years ago, that’s not so much something I’d account as good, and the differences have proven demerits to me. Also note that there’s lots of third party projects improving on tmux that don’t naturally automatically apply to 3mux.

Other References

I did a talk in 2015 on Screen, Tmux, Byobu, the Secret Terminal Brains!!!

See also my web page on GNU screen, which has further links about tmux and related tools.

lm – list manual pages

I have wanted this for… probably half of my life?

lm (see https://woozle.org/papers/plan9.html) apparently existed in Plan 9 many years ago; it wraps apropos (and is similar to man -k) so that instead of just listing names and sections of manual pages, it sets up the line to have the man section whatever command at the start of the line, so that the gentle user may copy and paste this to a command line, because that’s almost certainly what the gentle user intends to do next.

I reimplemented it as a zsh function, because, well, why not?

(|N/A:default)cbbrowne@cbbrowne2 /tmp> lm ()
{
  apropos -l "$@" | sed 's/(.) ((.)) * - /man \2 \1 # /'
}

So, how does this work?

(|N/A:default)cbbrowne@cbbrowne2 /> lm dockerfile
man 1 docker-build # Build an image from a Dockerfile
man 1 docker-builder-build # Build an image from a Dockerfile
man 1 docker-image-build # Build an image from a Dockerfile
man 5 Dockerfile # automate the steps of creating a Docker image
(|N/A:default)cbbrowne@cbbrowne2 />

Awesome, no?

fasd – a smarter cd

Once upon a time I used to use https://github.com/wting/autojump as a way for my systems to help me quickly navigate to my favorite Directories Of Interest. Basically, it did (and similar tools also do) the following:

  • cd is instrumented to capture directory locations each time one visits a new directory, and store them in a wee sort of database
  • an alternative “cd” command is introduced that attempts to Do What I Mean. It takes the input, and sees what stored directory best matches, with a bias towards frequently used directories

autojump was written in Python, which is no grand problem; I did some poking around, and discovered a newer tool, https://github.com/clvv/fasd, which has similar capabilities, perhaps more, and has a slightly smaller footprint, being implemented in “POSIX shell,” so it can happily run on common shells such as Bash (and my fave) zsh.

So far, I have just been using the “zz” functionality that picks the seemingly-most-relevant directory. It does a fine job of this.

It is doubtless a good idea to poke some more at this; running “fasd a b c” searches recent directories for highest-relevance files containing “a” “b” and “c”, fairly successfully. Throwing multiple strings pulls up an interesting list:

cbbrowne@karush ~> fasd tmux conf
1 /home/cbbrowne/.tmux.conf
12 /home/cbbrowne/GitConfig/InitFiles/tmux/tmux-home.conf

Without much effort, this locates tmux configuration files; that’s looking pretty attractive…

Warring with My Tasks

The local LUG had a talk recently about Task Warrior, which inspired me to give the tool a poke.

I have had excessively fragmentary handlings of outstanding ToDo items, where I have assortedly used:

  • Index cards to note things, but this is really ephemeral; I tend to turf them quickly, and only the most immediate things would get captured here, and evaporate as quickly. These can get clever; I didn’t get enough into that, I’m not hipster enough for that!
  • For a while (and this has gotten to be pretty distant in the past) I used todo.txt to capture things to do. Unfortunately, there’s not much of a synchronization mechanism, so I at one point ran the iOS app on my (still around somewhere) iPod Touch, later on Android phones, with occasional copying onto Unix desktop. But because coordinating versions amounted to doing by-hand git patching, this was way less useful than wanted.
  • For quite some time, I used Org Mode files for my grocery list, syncing between desktop and mobile devices using SyncThing. This was decently viable, actually, allowing me to manage the document on desktop (with a lovely big keyboard and big screen for mass editing) and on mobile device (so the list is handy to mark off purchases). Once in a while, I would push completed items into a side file for posterity. I also copy this data to a Git repository (for arguably “more posterity”); it is not as automated as it ought to be, trying to automate Git checkins was more troublesome than it ought to be.

But in November, at the above mentioned talk, I installed Task Warrior on my phone and decided to give it a try. FYI, I run it in a Termux session on my phone. There do exist a couple of TaskWarrior apps, but I have not yet been able to get them to sync to my taskd server. I am happy enough with the Termux-based CLI access. Perhaps I should set up a web server as an alternative interface? We’ll see…

Overall Configuration

I have the app (apt-get install taskwarrior) installed on a variety of hosts:

  • Work desktop, which syncs against central taskd
  • Chromebook laptop, syncs against central taskd
  • Home server Karush, which hosts taskd and has client syncing against taskd
  • OnePlus 5 (Android phone), where termux hosts the app, syncing against taskd

I installed taskd on a server at home. This was a bit of a pain in the neck; setting up users and certificates is fairly fiddly as also is setup of each client. It took a few tries to get it all working, and I went through a couple of user UUIDs before I was done. It comes with a systemd unit file; I have not thus far had that work, so I have to browse through history (boo, hiss!) to find the right command to restart it properly upon system reboot it took some effort to get that working properly.

One interesting thing I noticed; when syncing got “deranged” and I wound up on a new user UUID, I found that, in order to get things unstuck, I had to edit ~/.task/backlog.data. Note that this file contains the UUID of the user that it intends to sync against. (I’m not 100% sure; this may be the “local” idea of the UUID of the user…) The removal of the UUID at the top of that file led to the local instance of task generating a new UUID and proceeding.

Usage

I basically started out by tossing in all sorts of tasks that popped up, without too much intentionality, just making sure that knowledge about upcoming Things To Do got captured. I wasn’t sure what projects or tags to use; it is out of seeing a bunch of tasks that need to be classified that the patterns will emerge. I am basically just 3 months into this, so while some patterns have emerged, there are plenty more to come.

  • It turns out that tagging with +home and +work is mighty useful, for the simple reason that it allows en-masse deferral of tasks. At the end of the work day, I find it handy to simply defer items to another day thus:
    task +work status:pending wait:tomorrow
    It would probably be valuable to defer things further, so that my list of things to do immediately does not get randomly cluttered.
  • COVID-19 has changed the above a bit; work from home means that the separation is entirely less obvious
  • I have been adding in lots of periodic tasks as they pop up:
    • Paperwork tasks such as filing copies of pay stubs, bank statements, tax documents, and bills of importance
    • Preparations for annual events
    • Reminders for mailing list moderation
  • Some projects have been emerging, but not quickly or well. It is easier to think about adding tags, and occasionally a tag emerges as being important enough to call it a project.
  • I am (still!) not using dependencies nearly much as I probably ought to.
  • As “wishful thinking,” I’d like it if I could have grocery items dependent on a “go to grocery store” task, and have the children pop up as current the moment I arrive at the store and mark that first task done. That also means I’d like it if the children were being “masked” as not ready to proceed (ergo not listed) until I get there.
    • In reviewing Tomas’ presentation, I found A Better Way to deal with this, which is to use contexts. If my grocery items all have +metro as the locational tag (my nearby grocery store is called Metro), then I can define the relevant context:
      task context define metro +metro
      then
      task context metro
      More inclusions and exclusions could be done; in any case, it is clearly useful to use some contexts so when in a particular place, the set of tasks are restricted to those of relevance.
  • Projects (indicated by adding project:taxes.2019 or project:bugzilla.20721 or project:website) are evidently more useful than I had thought, once I start using the dotted notation to allow hierarchical subprojects. They had appeared to be way less useful than labels, but hierarchy changes that. Both are good things (in moderation!) and are good used together.

Future Items

  • Another few months of patterns hopefully leads me to get a bit smarter about how I’m using this, particularly with regards to deferring items I can’t do immediately.
  • I need to get the “sorta graphical” Android client working; need to fight with the configuration to get that working.
    Update 2020-05-07, I finally found documentation that helped me on this… https://www.swalladge.net/archives/2018/03/17/taskwarrior-taskserver-syncing-tutorial/ had the crucial aspect that I needed to copy a trio of .pem files (certificate data for my user and for my taskd server) into /Internal Storage/Android/data/kvj.taskw/files/one-of-the-subdirectories
  • I find, regrettably, that I don’t very much like the Android client
  • There are some interesting analytical reports such as task burndown to get some longer term patterns out of it. For that to provide value requires more data collection.
  • I imagine I should be automating some task management, such as having things like the following:
    • TaskWarrior should draw a feed of tasks from bug reports. There’s an extension to pull from Github
    • We’re apparently getting into Scrum work; it would be neat to pull Jira tasks into TaskWarrior automatically
  • There’s an Emacs mode; wait, wait, that’s actually comparatively complete, despite being exceeding brief. It works, and is already useful.
    It probably would be worth extending this to allow operations other than ‘a’ (to add a task) and ‘g’ (to refresh the list), to have a set of interactions one might perform on visible items. The Kubernetes interaction mode for Emacs has some relevant examples.
  • I’m told hooks are interesting, and certainly grasp the broad concept from the way that Emacs uses hooks really really a lot…
    At first glance, it seems less interesting than I had expected…
    • One use case is to automatically commit changes to Git; that is broadly interesting, but I think I can live with that taking place pretty periodically rather than continuously. Especially in that I switch clients a lot, so that keeping consistency would require a lot of Git synchronization.
    • Another usage is to rewrite tasks.
      An interesting example was to change notations, so @projectname would be used to specify project, which is shorter than project:projectname. As above, this needs to run “everywhere” which seems less than convenient. (Again, needs Git repo synchronization, this time for the repo containing the hooks.)

Conclusions

I have been happy enough with my experiences with TaskWarrior, and will be continuing to use it. There are clearly plenty of features I am not using yet, some of which may make sense to poke at further.

A wee jot about Mosh

I have been using Mosh for quite a number of years now; it is a notionally “mobile” shell that nicely supports devices with intermittent connectivity. On occasion, I have used it as an alternative protocol to ssh when using my laptops/tablets/phones to connect to shell sessions.

Its main merits (to me) are that:

  • Sessions can survive even fairly long connectivity outages. The more I use tmux to manage sessions on servers, the less that matters, but it is still a useful convenience particularly with connections from my phone.
  • Rather than replaying every keystroke (or every receipt of a character of a log file /bin/cat’ed to stdout), it maintains the state of the screen, so it can refresh the screen, skipping over long-irrelevant output, which is an extraordinary network performance improvement if one is browsing server logs…

Curiously, every so often, and this is why I thought to blog about this, I periodically still get forwarded notifications that people continue to report on issue #98 which I helpt report on back in 2012. I was a bit nonplussed this week to notice another update to this that indicates that people are continue to use (or at least reference) my circa-2012 workaround to issues getting Mosh to connect across systems with slightly differing ideas of UTF-8. I suppose I should be proud that my workaround (which is to explicitly pass LANG and LC_ALL values to mosh client and server programs) continues to seem a relevant solution. I have shell scripts lurking around that are almost 8 years old for doing mosh connections in my local environments that use this. I am, however, a wee bit disappointed that nearly 8 years of further development hasn’t made it unnecessary to tweak these environment aspects.

It is a somewhat happy thing that Mosh’s code base is stable enough (and I note it’s included in numerous Linux and BSD distributions, as well as having support in Android apps such as JuiceSSH) that it is, of late, seeing new commits only every few months.

Oh Shell

I have been poking for a while at the Oh Shell, presented at the 2018 BSDCan. It observes that there are a bunch of things about shells that tend to be painful, which has led to a whole bunch of shells coming out that are (exceedingly thin) veils over other programming languages, which then naturally attends them being of no general interest.

Here are a set of problems that Michael Macinnis pokes at:

  • Undefined variables – bash has an option to gripe about such, but it’s no default
  • varadic functions
  • word splitting versus lists
  • return values 0-255 – somewhat intentional, so that functions look like processes
  • global variables are mostly all that’s available
  • little modularity is possible because everything is in the global environment. This is somewhat like a worse version of Lisp dynamic scope
  • tortured syntax, particularly for variable expansions/rewrites


He presents a variety of mechanisms to try to solve these problems:

  • same syntax for code and data (conses)
  • richer set of data types (strings, symbols, number tower, lists, and some more sophisticated bits
  • first class environment via define/export
  • Kernel like Fexprs – enabled by first class environment. See John N Shutt’s thesis, vau: the ultimate abstraction
  • support dynamic communication patterns – see Squeak (Pike and Cardelli)

The shell is implemented in Go, making it pretty natural to do the “dynamic communication pattern” bit via GoRoutines. It is mostly an implementation of Scheme, with a largely Unix-y syntax. The main places where it deviates towards Scheme (that I have thus far noticed) are:

  • It has a preference for prefix notation for arithmetic rather than infix
  • The “:” character indicates subsumed evaluation of blocks, which is loosely like a (let (()) ()) structure.

I’m not yet sure that it’s enough “cleaner” than other shells that it is worth going in on to any special degree. The modularity aspects would prove quite interesting, if libraries of code using them were to emerge. The absence of libraries for the existing shells is unfortunate. You can certainly find a zillion extensions for Bash and Zsh, but in the absence of deep modularity, the connections can only be very shallow. You’re just a captured environment variable away from making that extension blow up…

Happy 2020

It sure has been a while since the last time I did up a blog entry…

A thing for 2020 is to do so slightly more frequently, perhaps somewhat systematically. I suppose I’m one of the exceedingly independent “non-herdable cats” of the https://indieweb.org/ movement. I’m not especially following anyone else; just following the loose principles that…

  • I should generate my own content
  • On my own web site
  • Hosted on my own domain

Rather than depending on the vagaries of others’ platforms. If you’re depending on Google Plus to publicize your material, oops, it’s gone! And the same is true for other platforms like Facebook or centralized “syndication” systems.

I won’t be getting rich by having someone’s ads on my site, but, again, that’s not a stable source of monies for much the same reasons suggested about material syndication.

The above is all pretty “meta”, and shouldn’t interest people terribly much. What I probably ought to be writing about that might be somewhat interesting would be about things like the following:

  • I have been fooling around with TaskWarrior, a somewhat decentralized ToDo/Task manager, which is allowing me to track all sorts of things I ought to be doing.
    The interesting bit of this is that I’m capturing a whole lot of “things to research”, which tends to point at software I probably ought to consider using, adapting, or, just as likely, ignoring, due to it not being interesting enough.
  • My web site nearby is managed using SGML/DocBook, which is a toolset that is getting increasingly creaky. I’d quite like to switch to another data format that is easier to work with. Some ideas include OrgMode and TeXinfo. I did some poking around to try to find tools to convert DocBook into such; the tools seem to only be suitable for reasonably small documents, and I have 122K lines of SGML, which makes that choke…
  • I have been fooling around with Oh shell (it’s written in Go, and essentially implements Scheme behind the scenes) as a possibly better shell. I’m trying to collect better thoughts as to why that might be a good idea. (I’m not sure Oh is the right shell though)
  • My cfengine 2 configuration management scripts are getting mighty creaky. Initial research focusing on SaltStack and Ansible showed off that those sorts of tools are totally not suitable to the problem I am solving, which is that of managing configuration (e.g. – dotfiles) and the differences needed in differing environments (e.g. – home versus work, servers versus laptop)
  • I’m poking at using Tmux more extensively. I started using GNU Screen in the early 20-noughts, and switched to somewhat simpler to manage tmux a few years ago. There are now tools like tmuxinator for managing sophisticated tmux-based environments, and it looks like that could be quite useful.
  • The big “work” thing I have been gradually chipping away at is Kubernetes. I tend to build batch processes, so this functions quite differently than usual documented use cases.
  • Apparently I should look at some “scrum” tools for task boards; some searching found a bunch of tools where research tasks are queued up in TaskWarrior to get dropped on me at some point…
  • I need to revisit my EmacsConf 2019 notes to see what sorts of things are worth poking at more.

Mailman subscriber lists

As part of “due diligence” for some mailing lists I am involved with (for Slony, see slony-backups ), I discovered the need to dump out Mailman mailing list subscribers.

There is a script to do this, written in Python, mentioned on the Mailman wiki, accessible as mailman-subscribers.py

I’d kind of rather have something a bit more version-tracked, so I poked around at GitHub, and found larsks / mailman-subscribers

That was a little out of date; the last code was from a couple of years ago, so I forked, updated to the latest, and suggested that “larsks” pull it, which he did, quite quickly.

The “kudos” bit is that I noticed a bit of a blemish, in that the mailing list password was required to be on the command line, thereby making it visible to anyone with access to /usr/bin/ps on one’s system. I submitted a feature request, and Lars was so kind as to have this feature added so quickly that by the time I had the prototype of my Slony “subscriber backup” script working, I immediately needed to change it to make use of the lovely new password-in-file feature. Nice!

Installing git-annex from Debian unstable

Installing git-annex from unstable

I happen to be a supporter of Joey Hess’ Git Annex Kickstarter project; no big bucks, but it seemed a good thing to help out.

I got in the stickers, that were my “project reward,” and figured I should start playing with the new results. I’m particularly keen on the planned Android client, but I should make some use of it before that comes available.

There’s good news, and bad news:

Good news
He has added in an assistant to provide interactive help in setting up repositories. It’s included in debian unstable, in a version released September 24th.
Bad news
I generally prefer using packages from debian testing, and it has a version released July 24th, well before any of this, and without any of Joey’s recent enhancements.

Fortunately, drawing in the September/~unstable~ version isn’t too terribly difficult. My /etc/apt/preferences.d/simple configuration has Pin-Priority values that prefer stable over testing, testing over unstable, and unstable over experimental (where enormous potential for breakage lies!).

As a consequence, installing the testing version is pretty easy, albeit involving an option I had to go looking for:

root@cbbrowne:~# apt-get -t unstable install git-annex
... leads to loading ...
Get:1 http://ftp.us.debian.org/debian/ unstable/main git-annex amd64 3.20120924 [7,411 kB]

And, with a run of % git annex webapp, it’s up and running!

Worth observing… The documentation tree includes the entirety of Joey’s blog documenting his development efforts.  Possibly excessive, but it’s certainly not to be called inadequate documentation.