James Carlson wrote: > I. Szczesniak writes: > > > > If it *did* need to be renamed, would there be a barrier to having an > > > > alias? Just have the "-f <x>" handler compare the string against > > > > "cmd" and use an alternate name for that one case. (Not pretty, I > > > > know, but doesn't seem to pose any obvious problems.) > > > > > > From a perspective of consensual software design, it is not a good idea to > > > use a generic name like "cmd", better would be "kshcmd". > > > > ksh93 libcmd exists since a long time and renaming the library will > > break existing scripts and will not be portable unless libcmd on all > > other platforms gets renamed, too. The name is defined by AT&T and not > > J?rg Schilling. > > I agree that changing the name as seen by users (via 'builtin -f') is > a bad idea, but I don't agree that putting plugins in the top level of > /usr/lib is a good idea, nor do I agree that the user interface must > always map directly into the internal implementation.
libcmd isn't just a plugin library. As I explained in an earlier email AST's /usr/bin/ commands are wrappers which call into the libcmd code when their code lives there (e.g. no code is duplicated in this case) and we're planning to do the same in Solaris (there are even patches in the queue right now). > So, I don't see how renaming or moving aside the library will break > any scripts, so long as 'builtin -f cmd' continues to do exactly the > same thing. It won't break such scripts (since libdll's portabilty layer would catch that after some heavy modifications), however we would break existing AST applications and other things. And I am not happy to cause this kind of havoc... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
