On 16/12/13 15:21, Robert Qualls wrote: > The fact that one-word command names are such a limited resource > means that they shouldn't be used by obscure programs.
openvt is probably older than some of the people on this mailing list (its git history starts in 2007, but the man page is dated July 1996), and at the time it was written, it was probably no more obscure than anything else in the Unix toolbox. Unless you have a time machine, it's far, far, far too late to object to its former name. Whether you like it or not, there is no central authority that names software, and no way to prevent people from naming their software badly (unless we empower governments to do so, or something, but I don't think anyone really wants that). The closest thing we have is that distributions (most visibly Debian, but I'm sure "app stores" also do this a lot) sometimes refuse to include a piece of software in their distribution because its name is too generic, or because it collides with something they already have. See the extensive mailing list threads regarding Node.js in Debian for an example that happened in public. > I think we need to have a group of people sit down and hammer out > something before we get too far into the future. Like, there should > be some kind of POSIX Command Standard or something that keeps > track of reserved keywords that do obvious things. And then what? How does this group impose their world view on the other 99.99% of the world? POSIX is not a forced standard <http://utcc.utoronto.ca/~cks/space/blog/tech/TwoSortsOfStandards> and cannot unilaterally impose requirements on Unix distributors. freedesktop.org is even less like a forced standard than POSIX: it can document things that the major desktop environments agree on, but has no way to coerce any of them. François Revol wrote: > Btw, debian already has something do deal with this issue > (although not exactly meant for this one but rather competing > programs for the same purpose): > https://wiki.debian.org/DebianAlternatives Alternatives are specifically *not* for this purpose: they are for the situation where running "generic-name --options args" (for at least some subset of the possible options/arguments) does the same thing whether generic-name points to one implementation or another. For instance, if openvt didn't have the "open" alias, and the generic name "open" was managed by alternatives, it'd be OK if xdg-open and gvfs-open were registered as implementations of "open"; you could type "open http://blahblahblah" (interactively, or in a script) and have more or less the same thing happen. It would not be OK for an "open" alternative to have openvt and xdg-open as implementations - if you have a script which runs "open", either it wants to open a new virtual console, or it wants to open a file. Either way, getting the other meaning is not acceptable. We can never fix that for open(1), because it's too late. Authors of new software can avoid it by namespacing generic names, which is why we have things like gnome-disks and kde4-menu; or by using non-generic "brand names", which is why we have Evince, Firefox and Amarok instead of "document viewer", "web browser" and "audio player". S _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg