open: No application knows how to open *

[theScrabi]

• fish --version: fish, version 2.7.1
• uname -a: Linux 4.15.0-24-generic Tabcompletion of cd in / makes you go home #26-Ubuntu SMP Wed Jun 13 08:44:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
• OS: Linux mint 19

After upgrading my OS from 18.3 to mint 19 which is based on ubuntu 18.04 I could not use the open command any more giving me this message:
an not get a file descriptor referring to the console

[faho]

Our open function simply calls a tool provided by your OS. On Linux that's "xdg-open" - which in turn will defer to a DE-specific tool.

I'd imagine you get that same error when you do xdg-open whatever?

If so, there's not much we here can do - I'd report it to Mint or your DE.

[theScrabi]

All right thanks, thoxdg-open worked flawlessly, open still failes:
https://asciinema.org/a/IrcT1pd1yl6Af0uOjhfpHrWGQ

however alias is a workaround :)

[faho]

however alias is a workaround :)

Huh? That should result in basically the same thing, as alias is just syntactic sugar around functions.

I'd love to see the output of type open!

[theScrabi]

Oha thats interesting:

$ type open
open is /bin/open

$ open --help
Usage: open [OPTIONS] -- command

This utility help you to start a program on a new virtual terminal (VT).

Options:
  -c, --console=NUM   use the given VT number;
  -e, --exec          execute the command, without forking;
  -f, --force         force opening a VT without checking;
  -l, --login         make the command a login shell;
  -u, --user          figure out the owner of the current VT;
  -s, --switch        switch to the new VT;
  -w, --wait          wait for command to complete;
  -v, --verbose       print a message for each action;
  -V, --version       print program version and exit;
  -h, --help          output a brief help message.

$ open --version
open from kbd 2.0.4

Here is the package where the command was in:
https://packages.ubuntu.com/bionic/kbd

[faho]

Ah, okay, that explains it.

We skip our open function when there's a command by that name, like macOS has. The idea there is that if the command already does the right thing, then it's superfluous.

In this case there is a command called open, but it's something quite different (and I'd expect much less used). In fact it's not even an actual binary but a compatibility symlink - see https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/342581 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732796.

There are a few things we can do:

• Nothing - always a crowd pleaser.

• Try to see if it's this open and then still define the function.

• Always define the function, but give xdg-open higher precedence than open.

• Only skip the function if uname = Darwin.

The second one is harder to do than it appears - do we read the --help output? What if the tool does not support --help but launches an application for it?

The fourth is one of those things that I abhor - there are more operating systems, and they change.

The first is annoying for users on Ubuntu, Debian and Fedora (at least, I know Arch does not ship the symlink), but it might change in future - the Fedora maintainer agreed a month ago to drop it, so this might just solve itself.

So we either do nothing, or the third thing.

[theScrabi]

The fourth is one of those things that I abhor - there are more operating systems, and they change.

I'd vote for the fourth solution as well.

[ridiculousfish]

IMO it was a mistake for fish to ship an open function (dates from 1.x) in the first place. But "re-routing" open to xdg-open will be even more confusing. I'm fine with doing nothing here, it does seem like it will solve itself.

Closing, thanks for filing!