> 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 _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils
