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...@gmail.com> 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 <damage3...@gmail.com> wrote: >> On Sun, Dec 22, 2013 at 4:23 AM, Matthias Klumpp <m...@debian.org> 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". >> 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 >> xdg@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/xdg > _______________________________________________ > xdg mailing list > xdg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
