Making man pages easier to read

The abundance of man (short for manual) pages in Unix and Linux systems is amazing, (almost) all commands are well-documented, and so are the programming APIs that a developer like me need to access on a daily basis. The only problem is that the default reader for them, the man command, displays them as text in a terminal window.

You can coerce the GNU man program to output manual pages as PostScript, however, but you need to feed that into a program that can display the PostScript. I use evince, the GNOME Document Viewer, for that. Unfortunately, there is some sort of interoperability issue here that, at least on my installation, blocks copy-paste from the generated PostScript.

I found that if I convert the PostScript to PDF using ps2pdf, copy-paste works. This is a lot to type to open a single manual page, however, so I ended up writing a script for it. Since I used to write a lot of Perl scripts earlier, the script also lets me look up the Perl manual using perldoc (which can be told to output nroff, the input format for manual pages, so that it can then go through the whole chain and end up as PDF).

This is what my little script has evolved to now. Since I have it running on several different machines, it does some detection of which software is installed, but it does need GNU man and GNOME evince at the very least (or you can replace it with the PS/PDF viewer of your choice). If ps2pdf is installed, it displays a PDF version for better interoperability. You can ask it for a manual page, to read perldoc from a file, or look up the perldoc manual by entering perldoc entry as the parameters. YMMV.

#!/bin/bash
# gman: Display manual page as PDF
# Written by Peter Krefting <peter AT softwolves.pp.se>
# SPDX-License-Identifier: BSD-2-Clause

if [ -z "$1" ]; then
  echo "Usage: gman perldoc <page>"
  echo "Usage: gman <file> | <manpage>..."
  echo
  echo "  Displays manual or perldoc documents as PDF"
  echo "  <page>     Perldoc page to display"
  echo "  <file>     File to open (perldoc or man)"
  echo "  <manpage>  Manual page to display"
  exit 0
fi

if [ -x /usr/bin/mktemp ]; then
  TEMPFILE="$(mktemp "$TMPDIR/XXXXXXXXXX.ps")"
elif [ -x /usr/bin/tempfile ]; then
  # Disable "tempfile is deprecated. Use mktemp instead", since we tried that...
  # shellcheck disable=SC2186
  TEMPFILE="$(tempfile --suffix .ps)"
else
  echo 'FIXME: Unable to create temporary file!' >&2
  exit 1
fi
if [ -f "$1" ]; then
  # Perldoc on file, unless manual file
  if [[ "$1" == *.[0-9]* ]]; then
    man -Tps "$1" > "$TEMPFILE"
  else
    perldoc -onroff -d"$TEMPFILE.nroff" "$1"
    man -Tps "$TEMPFILE.nroff" > "$TEMPFILE"
    rm "$TEMPFILE.nroff"
  fi
elif [ "$1" = "perldoc" ]; then
  # Perldoc manual
  if [ -n "$3" ]; then
    perldoc -onroff -d"$TEMPFILE.nroff" "$2" "$3"
  else
    perldoc -onroff -d"$TEMPFILE.nroff" "$2"
  fi
  man -Tps "$TEMPFILE.nroff" > "$TEMPFILE"
  rm "$TEMPFILE.nroff"
else
  # Assume manual page
  man -Tps "$@" > "$TEMPFILE"
fi
if [ -x /usr/bin/ps2pdf ]; then
  ps2pdf "$TEMPFILE" "$TEMPFILE.pdf"
  ( evince "$TEMPFILE.pdf" 2> /dev/null ; rm "$TEMPFILE.pdf" ) &
  rm "$TEMPFILE"
else
  ( evince "$TEMPFILE" 2> /dev/null ; rm "$TEMPFILE" ) &
fi

Displaying EML attachments in Vivaldi on Linux

Until recently, I have been using the old Opera Mail client for my work email. Opera Mail 12 was released in 2013. Being almost ten years old by now, it is starting to show its age with lack of support for newer standards. Since I really like the way the Opera Mail client works, I was really looking forward to the work done by the amazing Vivaldi team (where a lot of my old colleagues from Opera Software ended up, together with a lot of other amazing people), on their Vivaldi Mail client.

As my $DAYJOB uses Microsoft 365 for their email, we have several Outlook users in the house, and sometimes I happen upon a forwarded email sent in .eml format, and while Vivaldi actually uses this format to store email internally, it cannot display an attachment in this format (at least not as of October 2022). An eml file is basically just a bare email message, so it should be easy to read, right? Apparently, not so much. Googling around mostly recommended installing Thunderbird and import it there. That question did have an interesting answer recommending mhonarc, using it to convert to HTML. I ended up expanding on that, writing a script that converts to HTML and then calls back to my stand-alone Vivaldi e-mail instance. I have this as /home/peter/bin/eml-viewer (if you’re using the main instance, remove the –user-data stuff, otherwise replace it with a path to your configuration directory):

#!/bin/bash
if [ ! -e "$1" ]; then
    echo 'eml-viewer file.eml'
    exit 1
fi
OUT=$(mktemp --suffix .html)
/bin/mhonarc -single "$1" > "$OUT"
/bin/vivaldi-stable --user-data-dir=/home/peter/.config/vivaldi-standalone "$OUT"

The next step is to connect this up to open .eml files. For this, we need to create a matching .local/share/applications/eml-viewer.desktop file:

[Desktop Entry]
Version=1.0
Name=EML Viwer
GenericName=EML Viewer
Comment=View Outlook EML file
Exec=/home/peter/bin/eml-viewer %U
StartupNotify=false
Terminal=false
Icon=mail-mark-unread
Type=Application
Categories=Viewer;
MimeType=message/rfc822;

And finally, make it the default application for opening eml files:

xdg-mime default eml-viewer.desktop message/rfc822

This will leave the temporary HTML files in your temporary directory, so take care about sensitive data if on a shared computer. Set $TMPDIR to somewhere private and clear it periodically.

Reading Icalendar (.ics) file from Outlook on Linux

At $DAYJOB, email is handled through Microsoft’s Office 365, and with that I occasionally get event invitations in Microsofts’s internal format. As I am using an IMAP-based e-mail client (since I cannot stand Outlook Web Access), actually reading those invites can be a bit difficult.

With the default settings, the invitations are presented as a link into the Outlook Web Access client, with only the subject of the event readable (as the email subject). Everything else is completely hidden from the user. Thunderbird does have some built-in code that downloads the calendaring information and displays it to the user, but I am using a different email client and only get the web link.

Entering Outlook Web Access and going into the settings, there is a setting to present invites as Icalendar files (MIME type text/calendar, extension .ics). Enabling this changes the emails so that the event text is presented in the message body, but all the important details, such as start time and location, are only present in the Icalendar file. And while the calendar is “readable” in the sense that it is a text file, it is not readable in the sense that it is easy to find out what it says.

I am running Linux on my desktop, and do not have any calendaring software installed, so nothing wants to pick up the .ics file. And reading it in a text editor isn’t easy. There are several timestamps, and it takes a while to figure out that it is the third DTSTART entry that contains the event start time:

$ grep DT attachment.ics
DTSTART:16010101T030000
DTSTART:16010101T020000
DTSTART;TZID=W. Europe Standard Time:20211103T100000
DTEND;TZID=W. Europe Standard Time:20211103T142500
DTSTAMP:20211102T150149Z

Trying to find software that will just view an ics file in a readable format isn’t easy. I don’t need calendaring software on my desktop (I do have a calendar app on my phone that I could use, though), but it would be nice to display it.

After some intense web searching, I found mutt-ics, a plug-in for the textual Mutt e-mail client. I am not using Mutt, but running the script on the ics file did produce readable output:

$ python ./mutt_ics/mutt_ics.py /tmp/attachment857.ics
[...]
Start: Wednesday, 03 November 2021, 10:00 CET
End: Wednesday, 03 November 2021, 14:25 CET

That’s a step forward. The next issue is that I am using a graphical e-mail client, and this is a text-mode script. The e-mail software runs “xdg-open” to open the file, so I had to create a few items to get it working. First, a script wrapper that runs the script and shows the output using “xmessage” (other software also works, I have not yet found out how to get xmessage to display UTF-8 text properly, so I might need to replace it eventually):

#!/bin/bash
python /home/peter/mutt-ics/mutt_ics/mutt_ics.py "$1" | iconv -c -f UTF-8 -t ISO8859-1 | xmessage -file -
exit 0

Next step was to make a .desktop file that defines the script as a handler for the text/calendar MIME type:

$ cat /home/peter/.local/share/applications/view-ics.desktop
[Desktop Entry]
Type=Application
Version=1.0
Name=View iCalendar
Exec=/home/peter/bin/view_ics
Terminal=false
MimeType=text/calendar;
StartypNotify=false

And to tie it all together, I have to register it as the default handler for text/calendar by running xdg-mime:

xdg-mime default view-ics.desktop text/calendar

There, now running “xdg-open file.ics” opens a xmessage dialog showing the calendar details in a new window. Managed to get it working just in time, the meeting starts in twenty minutes…

Watching the WWE Network on Linux: an update

A few years back, I wrote about how I had to set up WINE to be able to watch the WWE Network from Linux, as they are using an incompatible DRM (Digital Restrictions Management) system, which is not supported on Linux. I have been using the set up pretty much unchanged since, while updating various components.

At one point I had to stop upgrading Firefox, as it started using features from newer versions of Windows that were not supported under WINE. I had configured WINE to make Firefox think it was running under Windows XP, and Firefox had since dropped XP support. If I try to claim a newer version of Windows, Firefox failed to connect to the Internet. The version I stopped at is version 53.0, which means that I am running an old, vulnerable Firefox version for this. This means do not use this browser for anything but watching WWE Network! Doing so may trigger an invulnerability somewhere.

I did keep my Flash Player up-to-date, but the latest Adobe Flash Player update (version 32) failed to run under WINE. Why I do not know, perhaps they also started using APIs that WINE does not support. I upgraded my WINE installation to the latest stable version (4.0), but to no avail. It was still hanging.

The only solution I have found so far has been to downgrade to Adobe Flash Player version 31. I had to dig a bit to find the download page for archived versions of Flash Player, and from there I ran the uninstaller and then downloaded the 31.0.0.153 archive. From that archive I installed the NPAPI Flash Player (31_0_r0_153/flashplayer31_0r0_153_win.exe) and now I have a working setup again.

So, an up-to-date WINE version, but an ancient Firefox and Flash Player. I hope WWE update their web site soon to something a bit more modern that work from Linux as well, but nothing has happened for the last five years, so I am not holding my breath…

Gemini PDA first impressions

I loved the Psion range of PDAs back in the late 1990s and early 2000s, for a while I had a Revo which was perfect for keeping a calendar and such on-the-go, but it eventually broke down and was replaced by smartphones.

My first smartphone was the Sony Ericsson P800; the OS was Symbian, the successor to the EPOC OS of the Psions, but now with just a touch screen and no keyboard. The follow-up units in the P series all had keyboards, and so did my first Android phone, Sony Ericsson’s X10 Mini Pro. But after that it has been touchscreen only. Nice for watching movies and reading web sites, but a nightmare to write longer texts, like this, on.

Enter the Gemini. Launched as a crowdfunding project on Indiegogo in February of 2017, I fell in love with the idea immediately. With the same form factor as the Psion 5mx, with an almost-full keyboard just large enough to type on with more than two fingers, and designed by ex-Psion folks, it looked like the device I had been missing since the Revo died.

Sometimes a laptop is just too big, and the netbooks from a few years ago were simply just too cheaply done, but this form factor is just perfect for typing on the go, like onboard a bus like I am just now.

I got my device earlier this week, and already it has replaced my laptop on several occasions. There is room for improvements, sure, the keyboard is not quite perfect yet and Android might not be the best fit. I have not had time to install the Linux dualboot image just yet, but I expect to spend most time there, as long as the 4G data works there.

All in all, I am very happy with the device. I backed it immediately after reading about it in The Register, as number 10. There are now over 5000 backers, so there seems to be a market for a device that has been missing from the market for 15 years.

Sound output from the wrong jack

Debian recently released an update to their stable release, version 8.7, and with it an update to slightly more recent Linux kernel version (up to 3.16 from 3.2). Well, that would be nice to have I thought, and updated my office workstation and rebooted. Everything looked fine, it even picked up and updated the Nvidia graphics driver that I always have problems with. But then, when I tried to play radio over the Internet, the sound suddenly started blaring out from a speaker inside the chassis that I didn’t even know it had, instead of my connected proper speakers.

So, first I thought the driver was broken, so I rebooted back to the old kernel. Still wrong, then I turned power off and back on and started the old kernel, still the wrong output. Strange.

I have a HP Z220 Workstation (from 2013) at the office, with an “Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)” audio controller, with a Realtek ALC221 chip (as per output from lspci -v and /proc/asound/card0/codec#0). It took me an hour of intense googling to find the correct set of keywords to find something, but apparently most English-language threads use “jack” for the outputs. I should have known that.

I eventually stumbled on this ArchLinux thread from 2014 which mentioned a tool called hdajackretask that can be used to rearrange the outputs from the HDA cards. Debian distributes this utility in the alsa-tools-gui package. After installing the package and changing the output type I managed to get sound playing through my speakers again.

hdajackretask screenshot, setting "Green Line Out, Rear side" to "Line out (back)"

Screenshot from hdajackretask, used to select output devices from an HDA audio card

Now to actually get some work done. That is Mondays for you.

End of an era

The day had to come, I knew it, I just postponed it for as long as possible. But now it is time to move on, it is time to close down my Fidonet system for good, over twenty years after setting up my first system. My Fidonet history has been going through a lot of different setups, starting out with reading off BBSes using Blue Wave, through a simple point setup with Terminate on MS-DOS, moving on to an OS/2-based system using SquishMail using timEd and Fleet Street as readers, even serving as the Swedish shareware registration agent for Fleet Street for a few years at the Fidonet peak in the late 1990s.

I then moved to a Linux-based system using CrashMail II (for a while, running timEd through an MS-DOS emulator under Linux, before GoldEd was ported to Linux), and lately using a Usenet News reader and the JAMNNTPd software. During my tenure as a Debian developer, I had a lot of this stuff packaged for Debian, but I haven’t checked if they are still there. I have just been using the stuff I compiled several years ago, but lately it has simply stopped working. Maybe my message bases have broken completely, I don’t know, and considering how seldom I read them, I figured now was the time to shut the system down for good.

It is still a bit sad, I remember the peak around 1996–1998, when I moderated a chat area and had enforce a limit of 50 posts per day per author, else it would overflow completely (remember, this was at the time where it could take a day or three for the messages to propagate). Now I don’t know how many years it has been since anyone even posted a single message in any of the derelict Swedish areas. There is some activity in the international areas,

Good-bye, Fidonet!

Watching the WWE Network on Linux

Okay, I confess, I am a fan of pro wrestling. You know, that weird US-American show-style wrestling where people pretend to beat each other up? Hulk Hogan and Ric Flair? No, okay, then you don’t need to continue reading.

Anyway, I am a fan, I even have a website dedicated to it, and I am subscribed to the WWE Network, an on-line channel where WWE broadcast their live events and I have access to their back archive. I subscribed when they opened international subscriptions back in August 2014, and among others, I have watched it on my PCs running Linux. It has worked flawlessly, until a few weeks ago, when it started developing error messages and then stopped playing completely.

Contacting their technical support didn’t help, once they heard about me running Linux they just stopped responding, both on Facebook and e-mail. Despite it having worked perfectly before, apparently since it is unsupported they do not want to look at ways of fixing it. So, what to do?

I ended up finding a workaround in installing the Windows (32-bit) version of Firefox and Flash Player under WINE. While it was easy enough to find the download link for Firefox, finding a working installation for the Flash plug-in was a bit more difficult. The normal plug-in download page didn’t work, as the installer was just a placeholder that downloaded the real installer, which it was unable to do under WINE. I managed to find a page with an off-line installer, a page that started with a big warning that it is going to be taken away next year.

Installing those and launching the Windows Firefox, I am able to play videos again. There are a few issues, the audio is not 100 % synchronized with the audio, but it at least is better than not playing at all.

I now have a workaround, but I still hope they will fix it properly soon.

Just a simple mail server installation

So, the mail server at work died on Wednesday. It was running Microsoft Exchange and died so utterly completely that even with several hours of premium support from Microsoft, they were unable to get it up and running again. Being one that comes in fairly early in the morning, and already am managing a few internal servers, I was asked to set up a new box using Linux or whatever.

Can’t be too difficult, huh?

Well, that depends. In this case, I needed to have it authenticate users against an Active Directory server and support mail aliases set up in its user database. After doing a fair amount of googling around, I found a few guides that helped me along the way. I started out with iRedMail and continued by configuring it to talk to the Active Directory server. Never having worked with AD or Kerberos before, it took me quite some time to get Kerberos working (tip: have a look at what the DNS thinks is the domain name of the KDC, in our case it was “BT.LOCAL” in all uppercase; use anything else as the Kerberos realm and all I got was cryptic error messages).

I had some hurdles to overcome, getting postfix to authenticate with Active Directory’s LDAP server was fairly easy once I a) had the unprivileged account that could do LDAP lookups (using the “Administrator” account for that does not work), and b) reduced the LDAP query so that it would actually find the users I was looking for (tip: make a dump of the LDAP directory and look at the lowest common denominator for the lookup keys).

Then I had the problem of Dovecot, which handles local mail delivery and IMAP/POP, could not read the mail that it had stored in mailboxes. It turned out that since I had set up Kerberos so that the AD users were available as Unix users, and had the recipient domain (“bt.local” from above) in “mydestination”, Postfix would always setuid the LDA. I had to remove the domain from there and add it to the list of virtual domains for that to work.

All in all, it took me about a day and half to get the thing set up. Not bad for the first time. I did set up Git to version-control all the important configuration files so that I can track my future mistakes and revert to a working configuration.

Now to get the SMTP SASL configuration working