Columns formats and command exec in donnatella

Freshly pushed to the branch next on donnatella's github are a few commits, some fixes and other improvements here and there of course, as well as the addition of command exec, allowing to execute a command line as a command, and have its output be the command's return value.

We'll see how this can be used, but first as some improvements and fixes were done on column types, let's have a quick look at how columns work in donna.

As you may already know, most things in donna aren't hard-coded, but can be configured. Columns are no exceptions, in fact donna doesn't provide columns, but columntypes.

That is, you have the "engine" of a column, that you can configure the way you want, and this combination of an engine, or columntype, a set of (generic & columntype-specific) options, and a name of course, are what's known as a column.

Options can be things such as e.g. the format to use for dates, but also which property to use. For instance, a file has 3 properties containing a date (a timestamp, really) : mtime, ctime, and atime.

And in donna, there's a columntype "time" which can be used with timestamps. Which information will be shown is simply a matter of configuration: option property defines which property it will use.

You can show the mtime, or the atime, or create two columns, one for each. And if in the future some nodes were to have yet another timestamp in a new property, you could very easily add a column for it.

Formats

Some columntypes do not really offer to format the information they show. The columntype name will show the node's name, and there's not much to configure there. (Though it does offer a few options when it comes to sorting.)

But for others, not everyone likes the same: when it comes to dates, permissions or even sizes, you might have your habbits, your preferred formats.

As hinted before, donna will let you configure things to your liking. But instead of simply listing a few of the most common formats, allowing you to pick whichever fits you best, columntypes use a format string, often set via option format

Sizes

It might not seem like there's a lot of choice when it comes to sizes, but some might want a rounded size to the best fitting unit, others rather have the raw size (in bytes), while some might like a size always given in KiB or MiB for instance.

All of those are available, and once again thanks to the use of format string, you can combine them, e.g. you could use %R (%b) to have the size rounded (to best-fitting unit), then the raw size in bytes in between parenthesis.

Of course, if you like to save your pixels, you might like to stick with one, and put the other one in the tooltip. Indeed, most columntypes will also have an option to set the format string to be used for tooltips, as each column can provide its own tooltip.

Dates/Times

Format strings for dates are pretty common, and supported specifiers should allow you to show your dates exactly how you want them. As always, via a right-click on the column header, submenu "Options/Column Options/Column" will list a few common formats you might like. Of course, the "Custom" option will let you enter the format of your choice.

Supported specifers are the ones provided by GLib's g_date_time_format() and should cover all possible needs. One thing that can come in handy and is missing, though, is the age.

While having the actual date/time is obviously good, sometimes all you want to know is how long ago was that file modified. So, donna adds specifier %o to show just that, how much time as passed since the timestamp (or is left, should it be in the future). E.g: "1h 23m ago"

Simple, and potentially of great help at times.

There's also %O which does the same, but works with a few other options, so you can define a limit, and another format string to fallback to once the limit is reached. E.g. show the age as long as the timestamp is from the last 7 days, then back to a "regular" date/time format.

User/Group/Permissions

The same columntype, perms, handles the permissions, as well as the user (owner) and group. Of course, as seen before, you can have all information in the same column, or create as many columns as you see fit.

For permissions, the classic "rwxrwxrwx" format is available obviously. There is also a specifier to try and limit the space required, showing only one group of permissions, i.e. only one "rwx" group, the one that applies to you (e.g. group if you're not the owner of the file, but are in the group).

There's also one to always show three letters, in lowercase when you do not have the permission, in uppercase when you do. Additionally, the letter will be in a color to give out extra info: in color "none" when the permission isn't available to anyone, in regular color if other has permission, in color "group" if group has it, and in color "user" if user has it.

Permissions are checked in that order, meaning that while with color "user" only the user (owner) has the permission, while with regular color the permission if available to other, but might also be available to user and/or group.

Of course, all mentioned colors are configurable; Defaults have green as color "user", blue as color "group" and gray as color "none".

Quick example: if you see "RWx" with the "R" in black, the "W" in green and the "x" in gray, it means you can read & write, no one can execute, and only user can write. Had the "W" be in blue, it meant the group could write, whereas other could not (not saying anything about owner).

The same color can also be used for user (owner) & group names: the user name can be in color "user" when you are the owner, and the group name can be in color "group" when you're not the owner, but are in the group. IOW your name will be in green indicating you have user permissions, if not the group name will be in blue when you have group permissions. If neither are in color, you have other permissions.

Provider exec: environment variables

Provider exec allows to execute command line. It is now possible to use enviroment variables in said command line, which will be resolved to their values upon node creation.

Now when creating a node, location is processed and environment variables are resolved. $FOOBAR will be replaced with its value (if any), quoted (to make things easier). $"FOOBAR can be used for as-is value. Use $$ to include a literal dollar sign.

This is all done on node creation, so the node's location will then be the resolved string (i.e. this isn't a shell-like parsing or anything.)

This allows to use $SHELL to open a new terminal, or $EDITOR to edit a file using the correct eidtor, instead of needing to "hardcode" which editor to use in the config.

Execute something, as a command!

As seen above, executing something has been possible with donna since day one, via provider exec. In fact, donna has a few modes where it will either simply start it, or wait for it to be done, it might also parse the output expecting a full filename per line and process them as search results, or start things inside an (embedded) terminal emulator.

But now, you can also use command exec() to execute something. How is that different, you ask?

Well, it means donna will wait until the process is over, and then have its output by used as return value of the command. Of course, that return value could then be used as argument to yet another command...

Quick example: Are you familiar with autojump? It's a tool that given some "keywords" (partial path component) will find the most commonly used match, and show its full name on stdout.

So, if you wanted to go to /var/cache/pacman/pkg you could use something like autojump cac pk and it would respond with the desired path.

Usually you'd use j which would then automatically change to the resulting directory. How about doing the same in donna?

Simply create a new alias, as such:

[donna/aliases/j]
replacement=command:tv_set_location (:active, @exec (autojump
suffix=))

And now, pressing : in donna then enterring j cac pk will do extactly the same, and jump to /var/cache/pacman/pkg directly.

This is, of course, only one example.

Updating autojump's database

Of course, to have "complete" support of autojump in donnatella, there's one more thing required. Everytime you actually change location, you should let autojump know about it, so it can update its database.

This can be achieved via new event "notify-dirname" which is trigerred whenever the current dirname (i.e. current location in fs) is changed. So, simply adding the following:

[events/notify-dirname]
autojump=&autojump -a %d

Will do the trick.

Updating your config to benefit from all of this

Now, there's still work to do when it comes to upgrades in donna. Specifically, there isn't currently a way to update/import new defaults, so that is a manual operation. Archers, think of this as some king of .pacnew handling! ;)

Here's the patch to update your donnatella.conf from v0.2.0:

  1. diff --git a/misc/donnatella.conf b/misc/donnatella.conf
  2. index b6b2a03..bb1ec4f 100644
  3. --- a/misc/donnatella.conf
  4. +++ b/misc/donnatella.conf
  5. @@ -814,16 +814,16 @@ trigger=command:tv_set_visual_filter (%o, size:>=%mM)
  6.  trigger=command:tv_column_edit (%o, %n, name)
  7.  # F6 to edit focused item (vim in a terminal)
  8.  [key_modes/donna/key_F6]
  9. -trigger=exec:!vim %:n
  10. +trigger=exec:!$EDITOR %:n
  11.  # F9 to view focused item (less in a terminal)
  12.  [key_modes/donna/key_F9]
  13. -trigger=exec:!less %:n
  14. +trigger=exec:!$LESS %:n
  15.  
  16.  # Terminals
  17.  [key_modes/donna/key_t]
  18. -trigger=exec:!bash
  19. +trigger=exec:!$SHELL
  20.  [key_modes/donna/key_T]
  21. -trigger=exec:>bash
  22. +trigger=exec:>$SHELL
  23.  
  24.  # selection stuff -- note that this required a patched GTK (to invert range)
  25.  [key_modes/donna/key_v]
  26. @@ -957,12 +957,12 @@ trigger=command:tv_save_tree_file (%o, @ask_text (Save Tree As...,Enter the name
  27.  name=Open Terminal Here
  28.  icon=terminal
  29.  is_sensitive=has_ref
  30. -trigger=exec:!WORKDIR=%:n bash
  31. +trigger=exec:!WORKDIR=%:n $SHELL
  32.  
  33.  [context_menus/tree_views/terminal_nw]
  34.  name=...In New Window
  35.  is_sensitive=has_ref
  36. -trigger=>WD=%:n bash
  37. +trigger=>WD=%:n $SHELL
  38.  
  39.  [context_menus/tree_views/tree_visuals]
  40.  type:context-type=empty

Note that this obviously doesn't include the autojump support used as example, though all you need is what was said: the alias to trigger autojump, and the event to update its database.

Where to get it?

For Arch Linux users, you can use donnatella-git in the AUR to easilly get it. Or simply clone the git repo from github and compile things yourself.

For a a complete list of all changes/bug fixes please refer to the git log.

And in case you read all that and are wondering what donnatella is, or are looking for more information, download links, etc please refer to donnatella.

As always, bug reports, suggestions or any other form of constructive criticism is very much welcome. You can open issues on github, use the thread on Arch Linux forums, or simply email me.

∞ Posted 20 April 2014

Top of Page