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

[Simon McVittie]

On 24/12/13 02:38, Liam R E Quin wrote:
> On Sun, 2013-12-22 at 00:28 -0600, Robert Qualls wrote:
>>  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