What is this doing in the first example in the readme?
> open https://api.github.com/repos/lmorg/murex/issues
As a Mac user, I'd expect that to launch a web browser, but it appears to be downloading and parsing the JSON?
> open https://api.github.com/repos/lmorg/murex/issues
As a Mac user, I'd expect that to launch a web browser, but it appears to be downloading and parsing the JSON?
This naming conflict is actually one of my regrets within Murex. I was a couple of years into development on this shell before I obtained a mac test system. I think most of the Murex users in the early days were also Linux users too. So I wasn't aware of the conflict until there was already too much code written in Murex to be worth the risk renaming the builtin.
However can mitigate this by running `exec open ...` -- you can set that as an alias as well, eg
alias o=exec open » 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
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.
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.
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.
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!
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…
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???”
echo 'Something or other' | sed 's/or/and/'
echo 'Something or other' \
| sed 's/or/and/'You can just end each partial line of such long commands with a pipe sign and keep writing the rest of the overall command on subsequent lines, except for the last partial line, where you just press Enter to complete and run it.
> As a Mac user, I'd expect that to launch a web browser
As a Linux user I would expect the exact same thing.