Re: unecessary binaries

[Bob Proulx]

> I recognized that the binaries of vdir, dir and ls are mostly the same.
> 
> I don't understand why we build up three binaries instead of one.
> It would be enough to build ls. vdir/dir could be make available
> 
> a) through link recognition.
> b) aliasing in the shell
> c) tunneling in a shell script.
> 
> What do you think of removing those binaries ?
> At least option c) is possible on every unix system.

I don't know the particular history of vdir and dir.  But the topic of
links to different names comes up periodically with regards to ls and
other programs.  Here is what the GNU coding standards have to say.

  http://www.gnu.org/prep/standards_16.html#SEC16

     Please don't make the behavior of a utility depend on the name used
  to invoke it.  It is useful sometimes to make a link to a utility with
  a different name, and that should not change what it does.
  
     Instead, use a run time option or a compilation switch or both to
  select among the alternate behaviors."

Therefore option a) goes against the general coding standards.  Many
sites install 'ls' as 'gls', for example, and it if it were installed
as 'gdir' would it still know to behave that way?  And since the
programs are small in size there is little penalty for including a
fully defined binary.

Option b) for 'dir' and 'vdir' is personally more favorable to me
since those commands are not standard commands but GNU extensions.
Therefore it would be nice to avoid them entirely.  However, that
means that a user must be savvy enough to add those as aliases to
their environment.  Users most likely to benefit from those commands
are least likely to know how to do that.  Having them as real commands
provides a nice benefit with little cost.  It helps people familiar
with DOS to transition to UNIX with less frustration.

Option c) is certainly possible.  But now you have the behavior of
your program bound tightly to the behavior of another program.  Which
means that if someone replaces /bin/sh with zsh, or tcsh or ash or
even if the standards change the defined behavior of /bin/sh your
completely unrelated utility may misbehave or crash entirely.  Also,
GNU utilities run on both newer POSIX /bin/sh systems and older Bourne
shell /bin/sh systems.  Common syntax would be required.

The killer is that many POSIX shells which are based on ksh will load
and run any $ENV file that is present.  User's frequently set ENV to
be an environment file commonly ~/.kshrc (this was a derivative of the
csh ~/.cshrc but for ksh and named by ENV so as to be general purpose)
or other named file.  Bash supports ENV but generally is better off
without that ENV set.  Running shell scripts in an environment with
ENV set are frequently broken by misconfigured contents of those
files.  I believe bash (as sh) avoids that POSIX breakage but at least
both HP-UX and IBM AIX both ship POSIX compliant /bin/sh programs that
implement that breakage exactly.  Therefore a program is less fragile
and will work correctly in more environments than a shell script.

Bob