On Wed, 2007-12-12 at 01:49 -0800, Khoa Ton wrote: > Ralf Corsepius wrote: > > On Wed, 2007-12-12 at 00:01 -0800, Dean S. Messing wrote: > >> Ralf Corsepius wrote: > >> : On Tue, 2007-12-11 at 21:29 -0800, Dean S. Messing wrote: > > > >> : [1] http://cvs.savannah.gnu.org/viewvc/gnustandards/gnustandards/standards.texi > >> : > >> > >> Thanks, Ralf, for enlightening me. I wrote "new coding standards", > >> above, in response to Stepan Kasal's remark that "GNU Coding Standards > >> now declare ...". I suppose the latter is literally true even if the > >> Standard was defined in 1992. > >> > >> Of course, with this new knowledge, I will feel as free as a bird to > >> boldly ignore the Standard (in this respect) seeing how several other > >> prominent linux executables (busybox, lvm, dump/restore, halt, to name > >> a few) have been blithely ignoring it for more than a decade. ½:-) > > > > Well, of cause it's everybody's freedom to ignore the "insights" others > > have accumulated over many years. But also consider, there are good > > reasons why these recommendations exist and why some people consider > > programs changing their behavior upon program name to be mal-designed. > > > > Ralf > > I would appreciate explanations or pointers to the reasons why some > people consider programs changing their behavior upon program name to be > mal-designed. In short: It's unreliable. A lengthier answer: There are several aspects: 1. GNU programs tend to be installed under alternative names, often in parallel to OS-vendor supplied programs, often into the same directories or at least into the same PATHs as OS-vendor supplied programs. Think /usr/bin/make vs. /usr/bin/gmake vs. /usr/bin/gnu-make vs. /opt/gnu/bin/make vs. E://com/linuxmake.exe vs. ~/check (because some user copied over /usr/bin/<app> to ~/ because wants to experiment with it). Any heuristic to examine argv[] or argv[0] can't avoid to fail somewhere or at least can't avoid to be somewhat unreliable/unsafe. It's completely out of an implementors/coders control what a user might be using as final program name. 2. Technical limitations. Checking a program's name is not as trivial as it might seem. - Some OSes mandate program suffixes. A well known example is "*.exe", but there might be naming conventions on $WEIRDOS, coders/implementors have never seen before. - On some OSes, argv[0] is not available (E.g. some embedded OS don't support it), on some OSes argv[0] carries an absolute path, on some OSes only a program's basename. Now consider that these limitations are pretty easy to overcome. - GNU Standards recommend recommend using an option instead of name-magic. Most programs already will have option processing, so the price of adding them should be pretty small. - An alternative to using options is would be to split the executable and build several separate apps from them. > For statically linked executables in disk space critical environments, > busybox's use of this mechanism is rather elegant. _statically_ linked in _space critical_ environments. ... That's a special case, which would touch different questions. Just take the GNU Standards as "recommendations, generations of smart people have invested their brains in" - They are not a law. They help circumventing some issues commonly met on "standard GNU platforms", but they also have trade-offs and come at a price. Ralf -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
