Stupid bash question

[Khoa Ton]

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