That's actually a really cool concept. J. Leclanche
On Sun, Dec 22, 2013 at 6:28 AM, Robert Qualls <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>> On Sun, Dec 22, 2013 at 4:23 AM, Matthias Klumpp <[email protected]> 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 >>> [email protected] >>> http://lists.freedesktop.org/mailman/listinfo/xdg >> _______________________________________________ >> xdg mailing list >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/xdg > _______________________________________________ > xdg mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xdg _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
