From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Wed, 4 Sep 2002 04:36:57 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 318 ************************************************** Tuesday 03 September 2002 Number 318 ************************************************** Subjects for today 1 Re: FHS : Dave and Natalie" **= Email 1 ==========================** Date: Wed, 04 Sep 2002 19:52:50 -0800 From: "Dave and Natalie" Subject: Re: FHS On Sat, 31 Aug 2002 00:00:44 +0200, Andreas Buening wrote: >> Another point here is that we could put /bin at the beginning of %PATH% >> so utilities that have OS/2 equilavients could also go here. > >You mean e.g. "more"? We could at least recommend this. For some >cases we'd better avoid name clashes, e.g. using "gpatch.exe" >instead of "patch.exe" for the GNU patch executable. > > Yes for things like "more". While eg gpatch is an idea the problem is if importing scripts from other systems they may still look for patch. >[snip] > >> Perl is usually in /usr/bin > >The question is what's usual? On most Unix systems shell >utilities like perl (and also awk, bash, tcsh) seem to be in >/usr/local/bin. We have to define once and forever where these >tools have to be found because they'll be hardcoded in lots of >scripts like #!/somewhere/perl. > Thats interesting, I haven't looked at too many *nixs, mostly just Linux. I'd imagine that they are put into /usr/local because they are not part of the main dist. Most shell scripts that I've seen seem to point to /usr/bin or don'r point anywhere and let the path point to the location. I think that any binaries that are distributated in UnixOS2 should go into /usr/bin (except those in /bin) and if anyone wants to update a shell eg the newest perl they can put it into /usr/local. This would mean that any script that is distributated should be considered broken if it does not point to the standard location or just name the shell. eg #!perl >Btw. what do you think about docs in /usr/share/{man|info} >(FHS compliant, but requires >./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/man >for _all_ packages.) >versus /usr/{man|info} (not FHS compliant but we can drop two >extra configure options)? > >[snip] I'm lazy and have been mostly using /usr/man|info. Having said that I think we should try to follow FHS standard and use /usr/share/* I was running Debian unstable when Debian made the move from /usr/man|info|doc to /usr/share/* and it was a bitch, every package had to be updated. If you think about it having the autoconf tools install into /usr/man|info|doc can be considered a bug and may well change inwhich case we would have to do --mandir=/usr/man etc. Debian finally compromised on installing in /usr/share/* with symlinks in /usr/doc for /usr/doc/share/doc. Unluckily we don't have symlinks which severly limits us Dave who is way behind on his email