> > Nevertheless, if there are _any_ scripts that use > it, unless you get > > rid of all 29 (or however many) links to it, I > don't see any incremental gain > > by removing some of them. > > Am taking the conservative approach here by removing > only those > commands which could not possibly return true. It > would be great to > be able to remove all processor truth value commands, > but the risk > of breaking existing scripts is too high. > > This is an attempt to get rid of as much clutter as > possible without > breaking anything. (And in the process, get tiny > benefits like making > tab-completions of command names in bash more > relevant, though that > is not the main intent of this case.) > > And you are right. There are more of these commands > which are not > listed in the manpages and are also not relevant any > more -- the > Motorola m68k series, for example. Plan to add these > to the case. > We might end up with just the following left behind > -- sun, sparc, > i386, i486, i86pc -- and have all of these deleted > (along with the > ones listed in the original 1pager): > > /usr/bin/sun[234]* > /usr/bin/mc68* > /usr/bin/m68k > ky.
Little as I like this, at least it would be more consistent to get rid of more of them. And I've tried the missing command experiment on all of sh, csh, ksh, and bash; as long as -e isn't in effect, all those shells happily proceed past a missing command (well, happily save for an error message), so I have to admit breakage would likely be little or none. Of those you just mentioned, it might be worth keeping sun4m for awhile, since AFAIK Solaris 9 (last that could run on sun4m) is still supported, and thus a script might exist such that it would still be true on Solaris 9 (and might be a nice gesture for it to be silently false on newer versions rather than false with shell error messages). The sun4m link could always be removed later, when no longer true on any still-supported version. -- This message posted from opensolaris.org _______________________________________________ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
