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

Jerome Leclanche adys.wh at
Sat Dec 21 22:34:39 PST 2013

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

On Sun, Dec 22, 2013 at 6:28 AM, Robert Qualls <robert at> wrote:
> 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.
> On Sat, Dec 21, 2013 at 10:46 PM, Jerome Leclanche <adys.wh at> wrote:
>> I have to agree. Regardless of the decision on xdg's side, the
>> debian-specific "open" binary shouldn't exist.
>> J. Leclanche
>> On Sun, Dec 22, 2013 at 4:43 AM, Ma Xiaojun <damage3025 at> wrote:
>>> On Sun, Dec 22, 2013 at 4:23 AM, Matthias Klumpp <mak at> wrote:
>>>> 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".
>>> 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
>>> xdg at
>> _______________________________________________
>> xdg mailing list
>> xdg at
> _______________________________________________
> xdg mailing list
> xdg at

More information about the xdg mailing list