Hacker News Reader

Comment by hnlmorg | Hacker News Reader

That's not the same thing. On macOS it is a Mach-O executable:

  » file ${which open}
  /usr/bin/open: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
  /usr/bin/open (for architecture x86_64):        Mach-O 64-bit executable x86_64
  /usr/bin/open (for architecture arm64e):        Mach-O 64-bit executable arm64e

Whereas on Linux it is a shell alias. Doesn't appear to be universal either (doesn't exist on Arch, for example). It was a recent change too, added to Debian 11 (released 2021), which is years after it was added to Murex.

As an aside, I wouldn't be at all surprised if the `open` alias was added to Debian to copy (and I mean this affectionately) macOS. Otherwise `xdg-open` might have just been called `open` from the beginning.

View on HN

> As an aside, I wouldn't be at all surprised if the `open` alias was added to Debian to copy (and I mean this affectionately) macOS. Otherwise `xdg-open` might have just been called `open` from the beginning.

xdg-open was called xdg-open because the name open was already taken by another Linux command - to run a program on a new virtual console. However, since virtual consoles are used far less than they once were, eventually people decided to reserve the obvious name for the common function - so open got renamed to openvt, and open became an alias for xdg-open. It also helped prevent the confusion for people coming from macOS to Linux, trying to use open and getting a completely different command instead, and then asking “why do I have to put xdg- first???”

I'm not sure what this comment want's to tell us.

There is the same command function wise on Debian Linux. Alias or not makes no difference.

Debian Linux is the base of almost all Desktop Linux boxes out there. (There are of course niche distris, but the overwhelming majority is Debian based; I count Ubuntu as Debian based.)

There is nothing "specific" to my shell environment. Having the `open` alias available the default. I would need to change things manually to diverge form this default. That would be "specific to my shell environment", not the other way around.

Historically `open` comes form NextStep, so actually Apple copied it.

On Linux it's usually a symlink as there are other implementations then the one in `xdg-utils`, and there have been also other programs with that name in the past.

I think you're being a little unfair here:

First of all you describe it as an alias, which is very different to a symlink. A symlink is a file so will be available system wide. Whereas an alias is only available to shells that have had that alias added to (and it's pretty common for embedded shells, like in IDEs, to not pick up default aliases). So my points were about aliases not symlinks.

For what it's worth "open" doesn't exist on my Ubuntu servers either. And it was added to Debian only 2 years ago. Murex has been around for nearly a decade. So I can hardly be blamed for adding a builtin with the same name as something that hadn't yet been added to Linux.

> Historically `open` comes form NextStep, so actually Apple copied it.

Apple didn't copy NextStep, they bought it and ported/rebranded a lot it's tech. Also I wasn't claiming Apple invented the concept of "open". I was saying I suspect Debian got the idea from macOS.

---

Anyway, this is all moot because the `open` builtin (Murex) already checks if `open` is a TTY (ie you're not piping the output of `open`). You can define how commands get opened when it's a TTY as well https://www.murex.rocks/docs/commands/openagent.html -- this is how Murex can inline images into the terminal -- so i can just add a "if no open agent is defined fallback to exec open" type condition. Then everyone is happy.

As to why `open` builtin reinvents `xdg-open` -- well that's because Murex needed something cross platform and there wasn't a reliable way to do that at the time. So I had to roll my own. Now the landscape has changed somewhat, I daisy chain the builtin to call the system `open` command on supporting platforms.

> I think you're being a little unfair here

Maybe. But I just don't know why this discussion started in the first place. There is a `open` command on likely almost every desktop Linux box. So it's not Mac specific (which was my sole point in my first comment in this thread).

> Right, you said "alias" multiple times earlier. Symlinks and aliases are not the same thing.

You're technically correct. My fault!

I've called it alias as it's a symlink coming form the Debian alternatives facility. The alternatives mechanisms manages system wide command "aliases"… I should have been more exact in this point.

> I was saying I suspect Debian got the idea from macOS.

I have no prove but I doubt that. There were other tools on Linux called `open` before MacOS X came along as far as I know. The whole thing seems to be rooted in BSD (where NextStep got it's Unix parts form).

> For what it's worth "open" doesn't exist on my Ubuntu servers either.

Makes perfect sense. It's a desktop tool.

> And it was added to Debian only 2 years ago.

I don't think so. I had `xdg-utils` and it's `open` command installed for many years. It's at least 17 years old:

https://cgit.freedesktop.org/xdg/xdg-utils/refs/tags

> Anyway, this is all moot because there are easy workarounds for the naming conflict

I agree. The Debian alternatives system was made exactly to handle this kind of name conflicts around commands. So there's no big issue, indeed!

`xdg-utils` has been around. But we're talking about the `open` symlink specifically. Here's the Debian 11 changelog: https://www.debian.org/releases/bullseye/amd64/release-notes...

Interesting!

I'm running Debian Testing so I had this command in fact since many years. Didn't know that it's actually quite "new".

Now I can understand how it could happen that Murex created a command name conflict. External tools don't test against Debian Testing most of the time…

Reply on news.ycombinator.com