Ralf Corsepius wrote:
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
I appreciate your concise and thorough explanations, Ralf.
Khoa
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
