open(1) removed from Debian? (was: 'open' instead of 'xdg-open' for usability?)

[Ma Xiaojun]

Hi, List:

I admittedly like the usage of "open" command in OS X (maybe Haiku also).

As far as I know, neither POSIX nor LSB mentions open(1) at all. It is
not a goal for toybox project either:
http://www.landley.net/toybox/status.html
In other words, it is not a standard and no one uses it.

The good news is now that, console-tools, the package provides open(1)
in Debian, is being removed recently, if I understand correctly:
http://packages.qa.debian.org/c/console-tools.html

[Thomas Kluyver]

Post by Ma Xiaojun
The good news is now that, console-tools, the package provides open(1)
http://packages.qa.debian.org/c/console-tools.html

I think it's still provided in the kbd package:
http://packages.debian.org/sid/amd64/kbd/filelist

Thomas

[Jerome Leclanche]

If xdg went ahead with the rename, and if debian included that update,
that would create a conflict on that package. I don't know what they
would do, but since the command is pretty much deprecated, I can
assume they would drop /bin/open from kdb and warn users. The reason
it's still there is they've had no reason to drop it.
This is imho a distribution problem.

J. Leclanche

Post by Thomas Kluyver

Post by Ma Xiaojun
The good news is now that, console-tools, the package provides open(1)
http://packages.qa.debian.org/c/console-tools.html

http://packages.debian.org/sid/amd64/kbd/filelist
Thomas
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Ma Xiaojun]

Bug filed for Debian's kbd package:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732796

For some reason I forgot to include a title...

[Ma Xiaojun]

Btw, I don't find "I like open better" a good justification for
dropping it from kbd - you are asking essentially for an API break
which has unforseen consequences if we just swap some binary names on
shell, especially with shell-scripts which are not included in Debian.

Given giant API breakage like making sh Dash instead of Bash or
probably a init system change someday. I fail to see any reason to cry
about this tiny little API change.

Standard is irrelevant here, as it is "just" a binary name, and
popularity is something to argue about.

It is "just" a symbol link that exists for no merits.
Have you read the open(1) ?
Does it encourage people to use "open" at all?
The history in the context of 1996 isn't boring, Ah?

I am not the kbd maintainer, so it's up to them to decide a rename (or
more precide, it's upstream's decision). I like "open" for files more
too, but unless kbd is the only user of that command, renaming it will
cause problems.

It seems that kdb upstream is not claiming open(1); it's a Debian "extension".
http://www.kbd-project.org/manpages/index.html
http://sources.debian.net/src/kbd/1.15.5-1/debian/kbd.links

xdg doesn't have to claim open(1) overnight either. It's just that the
current usage of open(1) is a waste of namespace.

[Jerome Leclanche]

I have to agree. Regardless of the decision on xdg's side, the
debian-specific "open" binary shouldn't exist.
J. Leclanche

Post by Ma Xiaojun

Btw, I don't find "I like open better" a good justification for
dropping it from kbd - you are asking essentially for an API break
which has unforseen consequences if we just swap some binary names on
shell, especially with shell-scripts which are not included in Debian.

Given giant API breakage like making sh Dash instead of Bash or
probably a init system change someday. I fail to see any reason to cry
about this tiny little API change.

Standard is irrelevant here, as it is "just" a binary name, and
popularity is something to argue about.

It is "just" a symbol link that exists for no merits.
Have you read the open(1) ?
Does it encourage people to use "open" at all?
The history in the context of 1996 isn't boring, Ah?

I am not the kbd maintainer, so it's up to them to decide a rename (or
more precide, it's upstream's decision). I like "open" for files more
too, but unless kbd is the only user of that command, renaming it will
cause problems.

It seems that kdb upstream is not claiming open(1); it's a Debian "extension".
http://www.kbd-project.org/manpages/index.html
http://sources.debian.net/src/kbd/1.15.5-1/debian/kbd.links
xdg doesn't have to claim open(1) overnight either. It's just that the
current usage of open(1) is a waste of namespace.
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Robert Qualls]

Although I was the one that brought this up, after what has been
discussed so far, I definitely don't think xdg should own the open
command, either through link, rename, or script. It's possible the
user will want xdg-utils but will prefer to have open associated with
something other than xdg-open. Having a specific implementation own
open would basically be making the same mistake again, even if in a
milder way.

Instead, I think open belongs in a separate project for high-level,
user-facing commands that's basically just a bunch of wrappers that
can be easily personalized by users and maintained over time. This
way, the community can have a discussion about what commands should be
kept and how they should be implemented.

I'm currently working on prototypes of some of these, namely: open,
convert (ffmpeg+imagemagick for now), build, download, package
(universal package manager that uses conversion utilities (and maybe
docker?) to install foreign packages). I plan to have something
fleshed out and on github in January or Febuary. Maybe a pretentious
manifesto document.

Robert Qualls.

Post by Jerome Leclanche
I have to agree. Regardless of the decision on xdg's side, the
debian-specific "open" binary shouldn't exist.
J. Leclanche

Post by Ma Xiaojun

Btw, I don't find "I like open better" a good justification for
dropping it from kbd - you are asking essentially for an API break
which has unforseen consequences if we just swap some binary names on
shell, especially with shell-scripts which are not included in Debian.

Given giant API breakage like making sh Dash instead of Bash or
probably a init system change someday. I fail to see any reason to cry
about this tiny little API change.

Standard is irrelevant here, as it is "just" a binary name, and
popularity is something to argue about.

It is "just" a symbol link that exists for no merits.
Have you read the open(1) ?
Does it encourage people to use "open" at all?
The history in the context of 1996 isn't boring, Ah?

I am not the kbd maintainer, so it's up to them to decide a rename (or
more precide, it's upstream's decision). I like "open" for files more
too, but unless kbd is the only user of that command, renaming it will
cause problems.

It seems that kdb upstream is not claiming open(1); it's a Debian "extension".
http://www.kbd-project.org/manpages/index.html
http://sources.debian.net/src/kbd/1.15.5-1/debian/kbd.links
xdg doesn't have to claim open(1) overnight either. It's just that the
current usage of open(1) is a waste of namespace.
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Jerome Leclanche]

That's actually a really cool concept.
J. Leclanche

Post by Robert Qualls
Although I was the one that brought this up, after what has been
discussed so far, I definitely don't think xdg should own the open
command, either through link, rename, or script. It's possible the
user will want xdg-utils but will prefer to have open associated with
something other than xdg-open. Having a specific implementation own
open would basically be making the same mistake again, even if in a
milder way.
Instead, I think open belongs in a separate project for high-level,
user-facing commands that's basically just a bunch of wrappers that
can be easily personalized by users and maintained over time. This
way, the community can have a discussion about what commands should be
kept and how they should be implemented.
I'm currently working on prototypes of some of these, namely: open,
convert (ffmpeg+imagemagick for now), build, download, package
(universal package manager that uses conversion utilities (and maybe
docker?) to install foreign packages). I plan to have something
fleshed out and on github in January or Febuary. Maybe a pretentious
manifesto document.
Robert Qualls.

Post by Jerome Leclanche
I have to agree. Regardless of the decision on xdg's side, the
debian-specific "open" binary shouldn't exist.
J. Leclanche

Post by Ma Xiaojun

Btw, I don't find "I like open better" a good justification for
dropping it from kbd - you are asking essentially for an API break
which has unforseen consequences if we just swap some binary names on
shell, especially with shell-scripts which are not included in Debian.

Given giant API breakage like making sh Dash instead of Bash or
probably a init system change someday. I fail to see any reason to cry
about this tiny little API change.

Standard is irrelevant here, as it is "just" a binary name, and
popularity is something to argue about.

It is "just" a symbol link that exists for no merits.
Have you read the open(1) ?
Does it encourage people to use "open" at all?
The history in the context of 1996 isn't boring, Ah?

I am not the kbd maintainer, so it's up to them to decide a rename (or
more precide, it's upstream's decision). I like "open" for files more
too, but unless kbd is the only user of that command, renaming it will
cause problems.

It seems that kdb upstream is not claiming open(1); it's a Debian "extension".
http://www.kbd-project.org/manpages/index.html
http://sources.debian.net/src/kbd/1.15.5-1/debian/kbd.links
xdg doesn't have to claim open(1) overnight either. It's just that the
current usage of open(1) is a waste of namespace.
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Liam R E Quin]

Post by Robert Qualls
[...]
open belongs in a separate project for high-level,
user-facing commands that's basically just a bunch of wrappers that
can be easily personalized by users and maintained over time. This
way, the community can have a discussion about what commands should be
kept and how they should be implemented.

Some GNU/Linux™[1] distributions use a parallel mechanism for
system-wide customization, update-alternatives, which uses
a /etc/alternatives/ directory and symbolic links to activate different
system components such as libraries, JVM, /usr/bin commands etc.

A danger in customizing shell-level commands is that shell-scripts can
become hard to debug remotely and hard to share.

I'm personally in favour of keeping xdg-open and not making a grab for
"open", because it helps people remember that the user of a script might
be running a different desktop environment, and that "xdg-open
instructions.txt" might not (for example) bring up gedit by default for
them.

Others mentioned OS X, but it should be remembered that OS X doesn't
support multiple desktop environments in the way that's the entire
raison d'etre for the xdg effort...

Liam

[1] Linux is a trademark of Linux Torvalds.

Post by Robert Qualls
I'm currently working on prototypes of some of these, namely: open,
convert (ffmpeg+imagemagick for now), build, download, package
(universal package manager that uses conversion utilities (and maybe
docker?) to install foreign packages). I plan to have something
fleshed out and on github in January or Febuary. Maybe a pretentious
manifesto document.
Robert Qualls.

Post by Jerome Leclanche
I have to agree. Regardless of the decision on xdg's side, the
debian-specific "open" binary shouldn't exist.
J. Leclanche

Post by Ma Xiaojun

Btw, I don't find "I like open better" a good justification for
dropping it from kbd - you are asking essentially for an API break
which has unforseen consequences if we just swap some binary names on
shell, especially with shell-scripts which are not included in Debian.

Given giant API breakage like making sh Dash instead of Bash or
probably a init system change someday. I fail to see any reason to cry
about this tiny little API change.

Standard is irrelevant here, as it is "just" a binary name, and
popularity is something to argue about.

It is "just" a symbol link that exists for no merits.
Have you read the open(1) ?
Does it encourage people to use "open" at all?
The history in the context of 1996 isn't boring, Ah?

I am not the kbd maintainer, so it's up to them to decide a rename (or
more precide, it's upstream's decision). I like "open" for files more
too, but unless kbd is the only user of that command, renaming it will
cause problems.

It seems that kdb upstream is not claiming open(1); it's a Debian "extension".
http://www.kbd-project.org/manpages/index.html
http://sources.debian.net/src/kbd/1.15.5-1/debian/kbd.links
xdg doesn't have to claim open(1) overnight either. It's just that the
current usage of open(1) is a waste of namespace.
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Ma Xiaojun]

Post by Liam R E Quin
A danger in customizing shell-level commands is that shell-scripts can
become hard to debug remotely and hard to share.

True. But you can even customize /bin/sh on Debian/Ubuntu.

Post by Liam R E Quin
I'm personally in favour of keeping xdg-open and not making a grab for
"open", because it helps people remember that the user of a script might
be running a different desktop environment, and that "xdg-open
instructions.txt" might not (for example) bring up gedit by default for
them.

Fail to see the connection. I guess xdg, if it stands for X Desktop
Group, would be obsolete soon if people move to Wayland or Mir based
desktop.

BTW, I happen to know one breakage caused by Linux not having open(1) like OS X.
https://github.com/swaroopch/byte_of_python/issues/8

[Dominique Michel]

Le Tue, 24 Dec 2013 12:59:13 +0800,

Post by Ma Xiaojun

Post by Liam R E Quin
A danger in customizing shell-level commands is that shell-scripts
can become hard to debug remotely and hard to share.

True. But you can even customize /bin/sh on Debian/Ubuntu.

Post by Liam R E Quin
I'm personally in favour of keeping xdg-open and not making a grab
for "open", because it helps people remember that the user of a
script might be running a different desktop environment, and that
"xdg-open instructions.txt" might not (for example) bring up gedit
by default for them.

Fail to see the connection. I guess xdg, if it stands for X
Desktop Group, would be obsolete soon if people move to Wayland or Mir
based desktop.

Simply, it is a big differences between desktops like Gnome that like
to think for the users and the system about how they must be doing
things, and force the installation of idiotic softwares like *kit.
Other desktops like Fvwm-Crystal let the user and the system do
their job without interfering at all with them.

Wayland is another issue, its compatibility layer will just be a never
finished job, X and all its extensions is just too complex, and just
because of that, even if the idea behind wayland is good, in practice
it will be a complete mess that will break hundreds of good working
programs. Wayland may be good for the mobile or the game market, but I
think in the desktop market, X will continue to exist a long time, just
because many users will favour a good working system over a broken one.
Or they will look for alternatives.

Generally speaking, I don't like the actual tendency of many GNU/Linux
actors which are, exactly like with the commercial software,
thinking the never the better. Because of that, GNU/Linux is becoming a
huge mess. I try Debian Sid the other day: What a failure! Even the
cgroups are broken, a useful kernel function! But sure, it take more
time to learn how to use the kernel, than to believe that systemd is a
good working software. Systemd idea is good, but like many recent new
Linux software, its implementation is a total mess.

Dominique

Post by Ma Xiaojun
BTW, I happen to know one breakage caused by Linux not having open(1)
like OS X. https://github.com/swaroopch/byte_of_python/issues/8
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Sanel Zukan]

Post by Ma Xiaojun
Fail to see the connection. I guess xdg, if it stands for X Desktop
Group, would be obsolete soon if people move to Wayland or Mir based
desktop.

I doubt this will happen, for two reasons:

* there is code and software written using 'xdg' prefix
(e.g. xdgmime) so unless someone feels extremely boring to rename
all of that for the sake of new technology, better spent time on
something else

* how much Wayland/Mir will replace X, we will see. From my
experience, product that tries to fix too much and promises too
many things, well...

Post by Ma Xiaojun
BTW, I happen to know one breakage caused by Linux not having open(1)
like OS X. https://github.com/swaroopch/byte_of_python/issues/8

Does Windows has open(1)? Looks like these days people like to buzz
how OS X has this and that and we should have the same thing on
Linux. Why not use OS X instead?

Best,
Sanel

[Jerome Leclanche]

Windows uses "start".

I honestly still feel the "open" command should be reserved for this.
Maybe we should make a recommendation to distributions, but leave the
choice up to them at least for the time being.
J. Leclanche

Post by Sanel Zukan

Post by Ma Xiaojun
Fail to see the connection. I guess xdg, if it stands for X Desktop
Group, would be obsolete soon if people move to Wayland or Mir based
desktop.

* there is code and software written using 'xdg' prefix
(e.g. xdgmime) so unless someone feels extremely boring to rename
all of that for the sake of new technology, better spent time on
something else
* how much Wayland/Mir will replace X, we will see. From my
experience, product that tries to fix too much and promises too
many things, well...

Post by Ma Xiaojun
BTW, I happen to know one breakage caused by Linux not having open(1)
like OS X. https://github.com/swaroopch/byte_of_python/issues/8

Does Windows has open(1)? Looks like these days people like to buzz
how OS X has this and that and we should have the same thing on
Linux. Why not use OS X instead?
Best,
Sanel
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Kevin Krammer]

Post by Ma Xiaojun
Fail to see the connection. I guess xdg, if it stands for X Desktop
Group, would be obsolete soon if people move to Wayland or Mir based
desktop.

I think it is more reasonable to assume it stands for cross desktop.
Most xdg specification and technologies are about sharing data and/or
implementations between desktops/worspaces and between applications using
different technology stacks.

There are a couple of X11 related specifications, such as the XDND spec, but
most are not dependent on any specific technology or implementation, e.g.
desktop-entry spec, mime spec, icon spec and so on.

Post by Ma Xiaojun
BTW, I happen to know one breakage caused by Linux not having open(1) like
OS X. https://github.com/swaroopch/byte_of_python/issues/8

Looks like the implementors either had not thought about cross platform
integration or had no information about things outside the platform they are
working on.

But it looks like there was some helpful comment addressing the latter, i.e.
providing information about respective integration hooks on other platforms.

Whether the autor(s) will address the issue then depends on whether they want
cross platform support or not. If they have no use or goal to support running
their software on non OSX platforms, then they are unlikely to put efforts
into it.

Cheers,
Kevin

[Thomas Kluyver]

Post by Kevin Krammer

Post by Ma Xiaojun
BTW, I happen to know one breakage caused by Linux not having open(1)

like

Post by Ma Xiaojun
OS X. https://github.com/swaroopch/byte_of_python/issues/8

Looks like the implementors either had not thought about cross platform
integration or had no information about things outside the platform they are
working on.

I think it would be beneficial for 'open' to work the way that people
writing scripts on OS X expect, i.e. an alias to xdg-open, because it's not
obvious that it is a platform specific thing.

Of course, you'd still need to consider cross platform compatibility for
Windows, but people are used to assuming that similar shell commands work
across posix-y platforms, while Windows is a very different ball game.

Thomas

[Kevin Krammer]

Post by Thomas Kluyver

Post by Kevin Krammer

Post by Ma Xiaojun
BTW, I happen to know one breakage caused by Linux not having open(1)

like

Post by Ma Xiaojun
OS X. https://github.com/swaroopch/byte_of_python/issues/8

Looks like the implementors either had not thought about cross platform
integration or had no information about things outside the platform they are
working on.

I think it would be beneficial for 'open' to work the way that people
writing scripts on OS X expect, i.e. an alias to xdg-open, because it's not
obvious that it is a platform specific thing.

Well, a quick check would have revealed that it is.
Cross platform development always requires testing on the targetted platforms,
one can not simply assume things.

Even if a tool or command with the same name exists it might have different
capabilities, arguments or options.

Even if it is the very same tool, which already is quite unlikely, it could
come in different versions with different capabilities, etc.

Post by Thomas Kluyver
Of course, you'd still need to consider cross platform compatibility for
Windows, but people are used to assuming that similar shell commands work
across posix-y platforms, while Windows is a very different ball game.

Assumptions are always at risk of not turning out to be true.
Even if something is specified in a standard and is compliance checked it is
still necessary to test since compliance checks will often not be all
encompassing.

On this particular case I am not sure if the open command is part of a
standard, compliance checked or not.

Cheers,
Kevin

[Thomas Kluyver]

Post by Kevin Krammer
Well, a quick check would have revealed that it is.
Cross platform development always requires testing on the targetted platforms,
one can not simply assume things.

But I don't go and check that simple commands like cp or grep will work on
a Mac. It's easy to see how someone could have assumed that 'open' is a
similarly common command and would work on Linux systems. Of course you can
blame developers who make incorrect assumptions, but why not aim to make
the obvious assumptions correct?
.

Post by Kevin Krammer
Even if a tool or command with the same name exists it might have different
capabilities, arguments or options.

That is a valid concern - OSX's open has several options that xdg-open does
not (currently). But I think the benefit of having a similar obvious way to
load files and URLs outweighs that. Developers are also familiar with
common commands like cc and make being provided by different
implementations that may support different options.

Thomas

[Kevin Krammer]

Post by Thomas Kluyver

Post by Kevin Krammer
Well, a quick check would have revealed that it is.
Cross platform development always requires testing on the targetted platforms,
one can not simply assume things.

But I don't go and check that simple commands like cp or grep will work on
a Mac.

Depends on the arguments you provide to these commands.
We all know very well that these commands can vary in capabilities, behavior
and understood commandline switches a lot depending on platform.

Post by Thomas Kluyver
It's easy to see how someone could have assumed that 'open' is a
similarly common command and would work on Linux systems. Of course you can
blame developers who make incorrect assumptions, but why not aim to make
the obvious assumptions correct?

I am not blaming anyone for making assumptions, correct or otherwise. I am
just saying that assumptions need to be verified. Either by research or by
testing.

Just to be clear I also do not blame the developers for not testing on Linux
or not caring about supporting their software on Linux.

Post by Thomas Kluyver

Post by Kevin Krammer
Even if a tool or command with the same name exists it might have
different capabilities, arguments or options.

That is a valid concern - OSX's open has several options that xdg-open does
not (currently). But I think the benefit of having a similar obvious way to
load files and URLs outweighs that. Developers are also familiar with
common commands like cc and make being provided by different
implementations that may support different options.

It will still need testing, so there is no magic bullet.

If the software vendor does not want to use a different code path in their
main software and rely on calling 'open' then they can simply ship a trivial
shell script that forwards the arguments to xdg-open.

Or do it the other way around and use a simple redirector on OS X, with the
additional benefit of not having to know the installation path since 'xdg-
open' is likely not used by anything else on the platform that is not xdg-
open.

Cheers,
Kevin

[Simon McVittie]

Post by Robert Qualls
open belongs in a separate project for high-level,
user-facing commands that's basically just a bunch of wrappers that
can be easily personalized by users and maintained over time.

If it uses such generic command names, then no distribution should
package this (at least without renaming them); it's a namespace
land-grab which fails the "would it be OK if others in my position did
what I'm doing?" test.

Some GNU/Linux distributions use a parallel mechanism for
system-wide customization, update-alternatives, which uses
a /etc/alternatives/ directory and symbolic links to activate different
system components such as libraries, JVM, /usr/bin commands etc.

In the distribution where update-alternatives originated (Debian), the
distribution's policy is very clear about its unsuitability for groups
of commands that are not at least broadly compatible. (For instance,
xdg-open and gvfs-open could probably be in the same alternative group,
but xdg-open and openvt can't.)

A danger in customizing shell-level commands is that shell-scripts can
become hard to debug remotely and hard to share.

Yes. I would go as far as to advise: don't use single words as
executable names. If you want "friendly" names for interactive use, you
can use the alias functionality in your interactive shell (e.g. 'alias
open=xdg-open' in ~/.bashrc would do what you want, assuming your
interactive shell is bash); aliases don't work in scripts, but that's a
net positive if you ever want to be able to share the script with
another system.

S