Midnight Commander customizations (Part 1) ==========================================

First draft: 2026-01-08
Published:   2026-01-28

Overview

Although I am using GNU Midnight Commander for many-many years, there are three options at the bottom of the Command menu which I never tried before, namely editing the extension, menu, and highlight group files. Maybe I was a bit intimidated in my subconscious, why would I want to edit these, sounds quite internal, do not fix what ain't broke, and so on. But lately I seem to be in a phase where I become quickly frustrated by small inconveniences, which for some reason didn't bothered me before. My latest endeavors with MC skins have brought these config files into my attention, so let's find out how can we use these to make some useful customizations.

Before I start describing these options in detail, I would like to note how the underlying config files are laid out. In the `/etc/mc` directory, among others we can find the following files:

filehighlight.ini: Highlight group file
mc.ext.ini: Extension file
mc.menu: User menu file

These constitute the system-wide global configuration. As a normal user, invoking the related items in the Command menu copies the global file to `~/.config/mc` if it does not exist already, and opens that.

When invoking as root, we are presented with the choice to open the system global or the user config file (latter pointing at `/root/.config/mc`). I would like to mention here that before editing the the system-wide instance, it could be advantageous to make a backup, because I could not find the defaults stored under `/usr/share/mc/` (unlike for the skins).

Highlighting groups

While composing the theme I had to deal with file highlight colors as well. For example I opted not to differentiate source-type files there, but if someone is using that feature (I imagine most of the other skins have this enabled, including the default one), it might be desirable to have additional extensions added to `[source]`. This is how to add Rust source files, for instance:

> --- filehighlight.ini.bkp
> +++ filehighlight.ini
> @@ -33,3 +33,3 @@
>  [source]
> -    extensions=ada;asm;awk;bash;c;c++;caml;cc;cgi;cpp;cxx;diff;erl;go;h;h++;hh;hi;hpp;hs;inc;jasm;jav;java;js;m4;mak;mjs;ml;mli;mll;mlp;mly;pas;patch;php;phps;pl;pm;prg;py;rb;s;sas;sh;sl;st;swift;tcl;tk;tsx;xq
> +    extensions=ada;asm;awk;bash;c;c++;caml;cc;cgi;cpp;cxx;diff;erl;go;h;h++;hh;hi;hpp;hs;inc;jasm;jav;java;js;m4;mak;mjs;ml;mli;mll;mlp;mly;pas;patch;php;phps;pl;pm;prg;py;rb;rs;s;sas;sh;sl;st;swift;tcl;tk;tsx;xq
>

Another thing I did here, is adding `.bkp` to the `[temp]` temporary file category. This is more obscure compared to `.bak`, but I like to use it myself as it is still perfectly clear for anyone else what it is, yet exactly because it is seldom used officially by software packages and distributions, I can be pretty confident if I see one on one of my computers, it was probably me creating that file. This is how to add this to the highlights:

> --- filehighlight.ini.bkp
> +++ filehighlight.ini
> @@ -23,3 +23,3 @@
>  [temp]
> -    extensions=~;$$$;bak;part;tmp
> +    extensions=~;$$$;bak;part;tmp;bkp
>      regexp=(^#.*|.*~$)

File extensions

It is nice to have highlight colors set up the right way for less common file types, but it would also be desirable to be able to configure MC for better support and integration of these types. This is what the extension file is for: to set exactly what commands will be run upon invoking Open (Enter on current file), View (F3) and Edit (F4). There are extensive descriptions of the format in the file header, and we get many built-in cases so it is easy figure out. I did not have to add anything major, just a couple of simple tweaks that are perfect to demonstrate how this works.

XCF

Gimp is my go-to raster image editing program, and when I am in the process of working on something that does not have any definitive exported results yet, I end up with just an XCF on the filesystem. As we are talking about images, the filename is often not enough to identify a specific project, naturally it would be better to see, to be able to quickly check what it is - in a faster way compared to firing up Gimp every time. At this time of writing I am using the Eye of Gnome application - `eog` in short - as primary image viewer, but unfortunately it does not support XCF files. On my system the default for almost every image format seems to be `display` (part of ImageMagick), which is kind of okay as a fallback but I do not like how it does not do automatic scaling on open.

Through the power of `mc.ext.ini` we can change how .xcf files behave in MC:

> --- mc.ext.ini.bkp
> +++ mc.ext.ini
> @@ -557,4 +557,6 @@
>  [xcf]
>  Shell=.xcf
> -Open=/usr/lib/mc/ext.d/image.sh open xcf
> +View=%view{ascii} /usr/lib/mc/ext.d/image.sh view ALL_FORMATS
> +Open=convert %f -layers merge /tmp/xcf_preview.ppm && eog /tmp/xcf_preview.ppm
> +Edit=/usr/lib/mc/ext.d/image.sh open xcf
>

MC has these internal scripts in `/usr/lib/mc/ext.d` like `image.sh` that are often referred in this config file, they contain commands for viewing and opening actions for common file types that can be reused. For XCF it directly starts Gimp of course, here I am reassigning this to Edit as this is not a file format that is expected to be edited by hand in a text editor. The Open action is changed to a little one-liner script that invokes ImageMagick's `convert` program to merge the layers and export the image as a temporary file, which can be displayed by `eog`. I am using the PPM (Netpbm pixmap) format, which - for those who are not familiar - can be treated as a portable alternative to BMP, without any compression so easy on resources, making it ideal for this kind of inter-process transfer. Finally just a word about what is called in View: this is used by default at many other image formats, and just displays some image metadata with the help of `exiftool` and `identify` programs. Note that in the case of XCF, it is useful that the number of layers is included on the output.

SVG

I seldom do vector work so I am not nearly as familiar with Inkscape compared to Gimp. Matter of fact I usually wait installing it on a machine until absolutely necessary, so in the meantime I need a way to inspect SVG files. Gimp is able to import them and it seems to be the default fallback on my system without Inkscape, but again I prefer `eog` which is quicker. Edit is kept unassigned as SVG is actually a "human-readable" XML.

> --- mc.ext.ini.bkp
> +++ mc.ext.ini
> @@ -575,7 +575,7 @@
>  [svg]
>  Shell=.svg
>  ShellIgnoreCase=true
>  View=%view{ascii} /usr/lib/mc/ext.d/image.sh view svg
> -Open=/usr/lib/mc/ext.d/image.sh open svg
> +Open=eog %f
>
>  [webp]

I would like to briefly mention that it was a conscious choice not to apply the ampersand '&' to launch `eog` in the background. Although that would be highly desirable in my opinion for every program (typically graphical) that is opened in a separate window, as MC would not be "disabled" in the meantime; it is not used in `ext.ini` at any other place neither, so I opted to retain consistency here. Spoiler alert: this does not stop us though to devise a method of opening applications in the background via the user menu, as we will see later in Part 2 of the article (link to follow).

RAR

In a previous life, on Windows my go-to file archiving package used to be WinRAR for an unknown reason. I am not using it for some time now, but still I encounter .rar archives here and there mainly in backups, that were created on my home PC. As you might know WinRAR is trialware, and even the command line version in Debian is in `non-free`, so one has to observe the licensing requirements to use it. The main alternative is `unrar-free` but it has a couple of drawbacks: its file lister output is not compact enough, and it is not compatible with MC's built-in virtual filesystem script (`/usr/lib/mc/extfs.d/urar`). Extraction itself works fine though. There are other programs claiming rar-compatibility like `unar` and `7z`, but I had little luck with those; although the virtual extfs function seem to work on the surface, in many cases they could not read the files themselves.

While the following tweaks do not solve the main problem, they offer minor improvements:

> --- mc.ext.ini.bkp
> +++ mc.ext.ini
> @@ -299,6 +299,6 @@
>  [rar]
>  Regex=\\.r(ar|[0-9][0-9])$
>  RegexIgnoreCase=true
> -Open=%cd %p/urar://
> -View=%view{ascii} /usr/lib/mc/ext.d/archive.sh view rar
> +#Open=%cd %p/urar://
> +View=%view{ascii} lsar -l %p && unrar -t %p | tail -n2
>

The main change here is using `lsar` from the `unar` package for the file listing when invoking View. I much more prefer its layout (mainly because it is one line per file), but I have kept the summary line from `unrar-free` showing the total uncompressed size. Also the virtual filesystem view was disabled on Open, maybe I will think of some solution in the future, either extracting to `/tmp`, or actually taking the time to fix the urar extfs script (which would not be easy so as not to break compatibility with the other non-free tools). For now this just saves me an error message when I hit Enter forgetting it does not work.

Parchive

The PAR2 specification (short for Parity Archive) and its implementing package Parchive with the command line `par2` tool is a widely used, industry standard solution in archiving and data verification. In summary these can be used not just to confirm the integrity of files, but also to repair them to some degree, depending on the required redundancy set on creation. I will cover `par2create` in some more detail in Part 2 of the article (link to follow).

> --- mc.ext.ini.bkp
> +++ mc.ext.ini
> @@ -1146,5 +1148,6 @@
>  # Parity Archive
>  [par2]
>  Type=^Parity Archive Volume Set
> -Open=/usr/lib/mc/ext.d/archive.sh open par2
> +View=par2verify %p; read -p "Press Enter to continue..." dummy; echo ""
> +Open=par2repair %p; read -p "Press Enter to continue..." dummy; echo ""
>

As you can see I have added verification to View, but Open is not that different from the default action, but I wanted to include a confirmation prompt. I have felt that I would like to pause to see if there were any problems, and a pager cannot be used as every update to the progress percentage would show up in a new line. The trailing newline just ads a visual break that helps when more invocations follow each other.

Up next

I wanted to include the user menu configuration here as well, started writing it but you know how it goes: this is similar to a code review so I am always having new ideas for improvements, and the section just kept on growing ever longer. So I have decided to break the article in two parts, let's hope it would not take long to finish the second one.