"Vadik V. Vygonets": > Well, it's sure sacred, but I think it won't hurt much to put there > one symbolic link, because if you have a network with linux boxen > and other unices, say, Suns, FreeBSD boxen and SGIs, the sysadmin > will probably set users' shells as /usr/local/bin/tcsh. Using that logic, we must also make links for lots of other programs: bash rc es zsh python perl gawk mawk gcc gzip gtar ...to mention just a few. They're all likely to be used in many important places and installed in /usr/local on many systems. Add water, instant slogan dept.: Whenever reliability is required, any argument using the word "probably" is suspicious. > Or is it better to document it and the sysadmin will set the link himself? Yes. Especially since lots of systems do not call /usr/local/bin by that name. Many places call it /local or /usr/my-stuff or something like that, partly because well-meaning installation scripts make harmless-but-sometimes-disastrous changes automatically. After /usr/local has first been created during the first installation, packages should leave it alone. We make an small exception to packages that create /usr/local/lib/emacs/site-lisp and similar directories, but that's not an excuse for more exceptions. (And IMHO we shouldn't do even that, but I'm in a minority on that one.) People who administer large networks with many different operating systems know what they are doing or learn it quickly. Being helpful is OK, but it's better to keep things clean (so that good local solutions are easier to integrate) than guess badly. -- Please read <http://www.iki.fi/liw/mail-to-lasu.html> before mailing me. Please don't Cc: me when replying to my message on a mailing list.
Attachment:
pgpnxnQXt3Ws7.pgp
Description: PGP signature