Hacker News Reader

Comment by simula67 | Hacker News Reader

About a year back I was tasked with porting an installer for a proprietary product to work on Linux. I wanted to show the log files to the user in the graphical installer and I ended up using xdg-open, which as it turns out opens text files in Firefox, even though light weight editors are present on the system.

I also found that some scripts had the hashbang line as /bin/env which works on RHEL, but not on SuSE.

I have also been trying to write some scripts that work across multiple distros. Detecting distros is wierd. "lsb-release" is not present in most distros. "/etc/issue.net" is present in some, but not on ArchLinux.

No wonder ISVs find it hard to support Linux. I suspect the technical side of this problem is probably trivial, the leadership side, not so much.

View on HN

/bin/env was always a bad idea. Way before Linux was even a thing, every Unix used /usr/bin/env - and that was the point of it being used to find an interpreter. Red Hat (where I worked at the time, man years ago) realised the mistake, but alas didn't want to break compatibility.

'lsb-release' was always hilarious: the one thing about Linux that is almost standard is that the LSB tools are never present.

Why is this a bad idea?

Because the whole point is portability, so hardcoding /bin/env when the rest of the world is using /usr/bin/env makes it nonportable!

I'm still confused should I use: #!/usr/bin/env python #!/usr/bin/python

And why?

IIRC not all distros will put executable binaries in /usr/bin/, but even those that don't will usually provide /usr/bin/env (even as a symlink), which will then search your path for python. In summary: /usr/bin/env is more portable. I'm unsure whether "#!/usr/bin/env python" is equivalent to #!python.

You should use:

    #!/usr/bin/env python

or preferably

    #!/usr/bin/env python2

    #!/usr/bin/env python3

env supposed to always be in /usr/bin, while python doesn't. On FreeBSD for example it is in /usr/local/bin because it is not integral part of the OS.

> xdg-open, which as it turns out opens text files in Firefox, even though light weight editors are present on the system.

It opens text files in Emacs here – did you configure your system to associate the text/plain mimetype to Firefox? (The following mostly for anybody who is interested):

  $ xdg-mime query filetype <file>

will print the mimetype of <file>.

  $ xdg-mime query default <mimetype>

will print the default .desktop file associated to this mimetype, i.e. the application that is run if you do xdg-open. That application can be changed using

  $ xdg-mime default <.desktop> <mimetype> [<mimetype>*]

Maybe that particular distribution was misconfigured to have the default for text files be Firefox, but overall I don’t find the behaviour particularly surprising.

From what I understand from the parent post is that xdg-open on any given system does not seem to work in a repeatable way.

I've never encountered a system where xdg-open did something I didn't expect. It's basically the linux variant of windows' double-click and OSX's open. If I did it on a text file and it would open it in Firefox I would think "Jeez what idiot chose Firefox for text files" not "Jeez xdg-open is useless".

I thought `xdg-open` is the Linux' variant of Windows' `start`.

It opens the file. In which particular way it opens that file of course depends on the system in question – I don’t have Emacs on my phone, I don’t want xdg-open to attempt to open text files with Emacs on my phone.

Whether or not the apparent distribution default of opening text files with Firefox makes sense is an issue somewhat orthogonal to whether xdg-open works – in that particular case it may have been misconfigured to open files with Firefox, but that doesn’t mean it a) didn’t open the file (it did) nor b) in a completely unreasonable way (the file was still displayed and such).

xdg-open chainloads a desktop-environment specific loader if available, and only if not, uses a heuristic to determine what program to load. Currently it supports three different loaders for various KDE versions, two Gnome loaders (one of which is shared with Mate, which also has its own loader supported), and one for each Xfce, LXDE and Enlightenment.

If none of those are found, xdg-mime will be used. Relying on xdg-open to work sanely across desktops, much less across distributions, is… optimistic at best.

I worked on some large commercial software for Linux for many years that had to support a wide variety of Linux installs (old and new), I can vouch for it not being easy. The technical side of supporting Linux in this environment can be very difficult.

There are, as you note, issues with the locations or presence of certain files, directories, and scripts. That's one part of the problem, but probably the easier one to solve (we had a whole big function that would try to detect how to open a URL by checking for xdg-open and older variants, checking configuration for KDE/GNOME/etc., and then falling back on detected browsers). This also has to be done for opening arbitrary files using their assigned program.

What's more complicated are library dependencies. Depending on system installs on GTK+ isn't always enough. You may need features not available on that install, due to version issues. You may have to work around versions of system libraries that have a bug present on one particular distro due to a custom patch.

Themes and icon sets are a problem if you hit any version compatibility problems. Your UI can appear broken if you reference icons that aren't registered on that system (generally an issue on older installs). This actually gets complicated quick in some cases.

So as an ISV, you have a couple of options for how you approach all this. You can limit the distros and versions you support, putting out builds for each. This is a perfectly fine strategy if you can get away with it, but not everyone's going to be able to use your program in that case.

Another option, which is what we did, was to basically ship everything we needed along with the program. Libraries (glibc, gtk, x11, everything we were forced to ship for compatibility), icon sets, themes, etc. You then try to dynamically figure out which modules you can load from the system, and which you need to load from shipped modules. You also need to handle setting up paths for anything like icon sets and fallback themes you may need, and deal with the compatibility issues that can occur from that (older versions of the XDG icon theme spec didn't have a properly-functioning fallback system when specifying multiple icon theme directories).

If you ever need to do anything more specialized (support for hardware devices, anything using D-BUS on older installs, more specialized window management abilities), you run into a whole new set of issues.

These days I focus almost entirely on web-based software, so that sort of wide range of compatibility problems are entirely behind me. (Ahem.)

It would be great to still file bugreports for anything you think could be improved in e.g. a distribution. I help out with Mageia. There's often various things which are simply overlooked or people aren't aware of. Obviously your bugreport could be ignored or not dealt with, but it doesn't have to be. It's a small investment to hopefully (years later) have less things to deal with.

I do the same when packaging upstream software. Sometimes there are build problems due to configure(.ac) not checking for dependencies properly. I'll then open a bugreport that these checks should be added. All that small stuff helps quite a bit.

A lot of the problems we hit were due to having to support many versions of many distros, not so much a particular bug in one distro. That said, we filed bugs, provided patches, and even drafted XDG specs for some of the issues we were dealing with.

The problem is, even if we filed a bug report with a patch for a 3.0 release of some distro, and it was fixed in 3.1, we still had to support 3.0. That meant code that worked with both the buggy 3.0, and the fixed 3.1. That's not a big deal when isolated to one distro or one component, but we're talking all the major distros, various third-party libraries, etc.

We may have been a bit nuts, trying to keep such a wide variety of environments supported, but that said, we also got really good at it, and it meant we didn't have to force customers to make changes to their system that they didn't want to make. The products ran on distros so old that they still only shipped GTK 1.2 (though we eventually finally walled off some of the older ones when we started supporting only 64-bit processors).

> I have also been trying to write some scripts that work across multiple distros. Detecting distros is wierd. "lsb-release" is not present in most distros. "/etc/issue.net" is present in some, but not on ArchLinux.

Try /etc/os-release first (http://www.freedesktop.org/software/systemd/man/os-release.h...). It should be present in all modern distros (even if they don't use systemd).

Reply on news.ycombinator.com