[ILUG] UNIX conventions...

[Brian Scanlan]

On Tue, Nov 16, 1999 at 12:27:17PM +0000, Lars Hecking wrote:
> >     1. root's shell is /sbin/sh on Solaris.
> >     2. unlike /bin/sh, /sbin/sh is statically linked.
> >     3. someone had copied over /bin/sh with /usr/local/bin/bash
> 
>  This is a fscking stupid thing to do. Some generous LARTing is called for.

I concur :)

> >     4. one (or more) patches had put the standard Bourne shell
> >        back in /bin/sh.
>  
>  This is why one should keep a record of changes and have a
>  post-patch install script. I need this here, too, to copy some
>  postfix files back in after applying OS patches.

Default patch installations on Solaris can backout any patch.

> 
> > A while back people had discussed /usr/local and it's place in Linux.
> > This is why /usr/local exists on UNIX boxes.  For the vendor controlled
> > files, but in Linux there are more vendor controlled files.
>  
>  Huh? My understanding is that everything vendor controlled (the base
>  OS, patches) goes into / and /usr, while local additions and stuff you
>  wrote yourself goes into /usr/local (BSD style) or /opt (SysV style).
> 

I find it a lot easier to keep track of --prefix=/usr/loca rather than
--prefix=/opt/packagename - It keeps your path shorter etc. :)

>  I don't think there's normally a need to change the login shell. If you
>  want to try a different shell (permanently), you can always exec one in
>  ~/.login or equivalent. This is documented.
> 
>  The sensible thing to do for an admin is of course, to put bash/tcsh/zsh
>  into /usr/bin, add them to /etc/shells, and ask users at account creation
>  time which shell they prefer.

getusershell() needs correct entries in /etc/shells and /etc/shells needs to
be readable... man shells

>  Some tools are clearly lacking and have obviously not seen any work
>  recently. The sorry excuse for patch comes to mind. The bugs in
>  /usr/bin/fgrep which have been carried over since at least Solaris 2.5.
>  Not bundling a compiler (but I hear Solaris 8 comes with gcc).

 From somewhere off http://www.sun.com/solaris/ea

"The Solaris Operating Environment is also growing as an open development
environment. To provide a common development
environment for both Linux and
Solaris software across SPARC™ and Intel platforms,
Sun Microsystems is working
with with Cygnus Solutions to ensure the continued
availability of GNUPro tools.
Public domain software that complements the Solaris
Operating Environment
continues to be available from
http://www.sunfreeware.com. And as Solaris
software evolves, public software will be
increasingly available. For example, the
Apache Web server, perl scripting language, and
popular utilities are included
with the Solaris Operating Environment. Solaris
software comes with a
complementary copy of StarOffice software, and is
available free of charge
(except for shipping and handling fees) for
personal, educational, and
noncommercial use."

I haven't heard gcc been confirmed...

Incidentally, check this out.

"The Live Upgrade feature lets you install the Solaris 8
Operating Environment and
future releases on a separate partition from the
currently running version of the
software. When installation is complete, a simple
reboot starts the latest release
running on your system. Since Live Upgrade includes
a version migration and
fallback feature, a reboot enables you to fallback
to the previous release without
losing your administration settings."

Ain't that cool? Wonder what'd take to get that working for (say) Redhat Linux.
A chrooted run of the install scripts? Rpm would have to be modified...

Brian.

-- 
"As with most of my theories, this one doesn't hold up to close
scrutiny, but it's surprisingly resilient to casual criticism."