I have always detested all the symbolic linking crap that SCO impletemented
with 5.0.x. I once read it was implemented so upgrades and roll-backs, etc
would be easier. But I have never seen a good working upgrade scheme yet
from SCO. So I doubt if it works anyway. Even certain supplements can get
you in big trouble.
In the meantime, simple-minded folks like myself get very frustrated doing
admin with everything linked to
/opt/Here/There/5.0.A234/Everywhere/Some.Where.Else.20EB./bla bla bla.
Shouldn't they just abandon the link stuff and return to a 3.2.4 file layout
(I am now backing away from my monitor expecting responses)
Would you be so kind as to tell us which ones, so the rest of us don't
also get into big troouble?
| In the meantime, simple-minded folks like myself get very frustrated doing
| admin with everything linked to
| /opt/Here/There/5.0.A234/Everywhere/Some.Where.Else.20EB./bla bla bla.
In just what way are you hampered in ANY administrative chore by ANY
> Would you be so kind as to tell us which ones, so the rest of us don't
> also get into big troouble?
I once installed SMP and rs504c supplement in the wrong order. SCO said
roll back and install in correct order. But that did not work as advertised.
I rolled back rolled forward, sideways, installed/uninstalled, etc for 8
hours then just blew it away and did it right.
I also did an upgrade from... 5.0.4 to 5.0.5 I think. I followed
instructions EXACTLY, it got to the point where it said "Everything
succeeded, restart your PC" and it failed to boot afterwards. A month or so
later, I saw where SCO officially said "just don't do it."
> | In the meantime, simple-minded folks like myself get very frustrated
> | admin with everything linked to
> | /opt/Here/There/5.0.A234/Everywhere/Some.Where.Else.20EB./bla bla bla.
> In just what way are you hampered in ANY administrative chore by ANY
I have seen you comment before about the "tar" example. Where it saves links
instead of the original file. I have been snared by that one. I know there
is an option to get around that (after my screw-up). Other tasks like
looking for files, printer scripts, etc. The long links are just a hassle
for me. They have never hampered you in any way?
I guess I just don't see what benefit they provide - just increased
complexity without tangible benefit. For me, it makes the process of
selective restores a pain.
Do you see great (or any) benefit from all the link stuff?
I'll tell you what drives me crazy. "cd-ing" to a system directory, then
when I'm done, trying to "cd ..", and instead of being where I want, being
in the middle of some bizare symlink world... (This is very common in the
/usr/internet and /usr/net/servers areas...)
That's a horse of an entirely different color,
I don't think anyone at SCO would defend the schema today.
It was wonderful in theory; it is miserable in practice.
> I'll tell you what drives me crazy. "cd-ing" to a system directory, then
> when I'm done, trying to "cd ..", and instead of being where I want, being
> in the middle of some bizare symlink world... (This is very common in the
> /usr/internet and /usr/net/servers areas...)
Use "cd -L .."
"John DuBois" <jo...@sco.COM> wrote in message
I don't think using ksh as root's shell was ever a bad idea. Csh, for
sure, but ksh, as a superset of sh, should not have caused any problems,
given that the startup scripts never used any particularly esoteric
But even having root use csh, tcsh, bash, zsh or any other shell of
your liking, I doubt it's a problem if you force all of the /etc/rcX.d
scripts to be run by /bin/sh (by making sure they start with #!/bin/sh),
as well as bcheckrc and anything else that runs at boot time.
The only problem with ksh is its built in functions. It is
*possible* that some /bin/sh script might inadvertently have
defined a function that happens to have the same name as a
ksh built-in. I really don't think there are any now, but
there's no reason to fret about it: you can USE ksh with
extreme ease without changing root's shell, thus leaving the
critical startup scripts running under sh.
That's the way I set up my system: I create a .kshrc with
the stuff I want (set -o vi; PS1='$PWD # ') and I add a
ENV=/.kshr; export ENV to the .profile (that's harmless to
/bin/sh). Then, after logging in, I just type "ksh".
If you don't want to modify .profile, you could just type
"ENV=/.kshrc ksh" or, if all you wanted was the command
recall and editing functionality, just use "ksh -o vi",
which is what I do when I login to other sites.
See http://pcunix.com/Unixart/ksh.html also.
There hasn't been any problem using ksh as root's shell since somewhere around
the 3.2.0 or 3.2.2 timeframe. There were a few administrative scripts that
used functions that conflicted with ksh builtins (e.g. select()), and some that
used the archaic '^' as the pipe character, not recognized by ksh.
Back in the XENIX days, I not only used ksh as root's shell, I made /bin/sh be
a link to /bin/ksh since there was no #! facility to let the users use my ksh
scripts, and it just required cleaning up a handful of scripts.
I've had ksh as the default shell for years, and haven't experienced
any _visible_ problems because of it yet.
Fulko Hew, Voice: 905-333-6000 x 6010
Senior Engineering Designer, Direct: 905-333-6010
SITA Airport Services Fax: 905-333-6050
777 Walkers Line, Email fu...@wecan.com
Burlington, Ontario, Canada, L7N 2G1
until lasrt week, I had always detested that idiotic set-up too. Actually I
still do, but at least I have one positive experience about it now...
a client of mine called me up, "no one can work, no one can log in..." after
a a little q&a with him it is apparent that somehow /bin has been erased.
no problem... I'm brilliant, I'll think of something...
he did happen to have one non-root login session running at the time with
shell prompt access. (IE: not an application-only user login)
I had him set PATH=$PATH:/var/opt/K/SCO/blah/blah/blah/bin
this gavce us most of the /bin commands back for our immediate use in that
shell session, however, brilliant as I am I couldn't figure out how to get
"su" to not look for /bin/sh. so we had no "su" to use to recreate /bin.
but we did have "ftp localhost" which let us login as root and create/delete
directories at least albeit with inaccurate permissions.
so I made a tar of /bin from another system of the same
version(intentionally just tarring up the symlinks and their permissions)
ftp'd to this box, untarred into user directory, then moved into real
directory via "ftp localhost", then *finally* we could "su", whereby we
untarred again, as root, over top of /bin to fix up the permissions.
the observant may ask "uh... backup tape? recovery boot floppy?"
funny you should ask!
As it happens, he had no good backup for some weeks, knew it was a problem
that should be dealt with soon, and was in the process of upgrading ctar
when this happened. rough quote "the guy from ctar was on the phone with me
helping me install it... something wasn't right and so we ran the uninstall
script, that's when everything stopped working. the ctar guy said "well I
gotta go..." and vanished, so I figured I'd call you guys before I really
on reflection, I bet there was some even simpler way(s) to restore the
system given the situation described. I actually contemplated a little "for
i in *" one-liner to create the new symlinks, but the thought of talking the
guy through typing it all in and the chances of it working, and doing no
harm, ... I almost let myself cheat and just create a single link from
/var/whatever to /bin, but it was almost no more difficult to just unpack a
tar and get it all back the way it is "supposed" to be
in any event, since the real files were really still there, it was damned
handy to be able to start off by just editing $PATH and having instant use
of most of the commands again to use in restoring the missing links. "su"
would have saved an hours worth of brain-sweat, but ls, cp, mv and such
were kinda handy too :)
Brian K. White http://www.squonk.net/users/linut
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
the reason, since he mentiones "a long time ago" was probably the one I read
of in the xenix manual, which was not concerned with syntax compatibility at
all, but was concerned about the binaries themselves
/bin/sh was compiled static and fully self-contained, whereas ksh was
compiled using shared libs, and they didn't want you to ever be in a
position where root could not login, even in single user, because the
libraries were on a filesystem
that has been unmounted for some reason, that wasn't mounted in single-user,
or which had crashed, or maybe something just confused the library loader
like a bad LD_LIBRARY_PATH or some such.
It doesnt' have to be all that long ago.
Last fall I had to fix a machine that had - among other things -
the root shell changed. The machine was a Sun web server - it had
to be that for some specific software.
The person was a rabid Linux afficionado - one whose motto seemed
to be "If you aren't running Linux you aren't even worth my time to
spit upon". [Worse than the worst Mac addicts of a few years ago].
Anyway - the system hiccuped for some reason - probably a power
flicker - and the file system was not clean on startup. The best
you could get was the bios comming up [server with only serial
communcations], a message that fsck wouldn't run, a 'no-shell'
error and I also beleive a no-directory error.
In an effort to make it look like his Linux system he moved the
root home to a mountable partition - and it's sort of hard to work
from one of those when you can't mount it. But he also replaced
the root shell with a bash shell - and it was dynamically linked.
There should never by any dynamic linking in any program that root
would have to use in a system clean up mode - which means that
everyting in /sbin, /bin, /etc, should be static. Means the system
will usually run if someone screws up a library during an upgrade
The only way to fix the above machine was to take it off-site,
pull he HD, mount it on another system, perform the normal
incantations to make it clean again, and put it back. And they
still didn't change it after that :-(
Bill Vermillion - bv @ wjv . com
I trust you've noticed the contents of /sbin on the current OSR 5?
XENIX had only static shared libaries, all under /shlib, which noone in their
right mind would make its own filesystem (no symlinks either). But, I suppose
someone might muck around with the libraries themselves.
Well no, that ain't it. ksh was not included with standard SCO until
sometime in UNIX 3.4.1 or 3.4.2. I remember 3.4.0 didn't have it.
And by golly, this looks like the TA, but I can tell it has been revised a
bit over the years: TA# 104320
I quotefrom the TA:
"By default, the "root" login uses the standard Bourne shell, /bin/sh. This
is in fact necessary for correct system operation; the default shell of the
"root" login must not be changed. Changing it can lead to mysterious "Bad
Hertz Value" messages from programs such as df(C) and mount(C) and may have
more serious consequences. "
But nobody noticed the Saleen S7..
hehheh :) I was going to quote : "OS/2 Rules!"
>> >I had to chuckle thinking about this thread (oh yes, I started it).
>> >It is like we are all a bunch of old men sitting on the park bench,
>> >arguing the merits of ksh, symbolic links and the good old days.
>> >And why we were doing it, that red Porche convertible that just
>> >sped down the street had "Linux" spelled out on it's license plates
>> Which was promptly blown away by the silver Saleen S7 with
>> the license plate that read "FreeBSD" :-)
>But nobody noticed the Saleen S7..
How could you not notice one of those. It just jumps out at you
where-ever it is. Not to notice one of those you'd have to
be blind or dead or both.
For those who are not familiar with it, the S7 is your atypical
American made high-performance street legal racing machine.
427 cubic inches. 550HP at 6400 RPM. Top speed in excess of 200MPH.
0 to 60 in under 4 seconds. Carbon-fiber body. At $375,000 it's a
great stocking stuffer at Christmas.
At only 41 inches high it's only 1 inch higher than my all-time
'lust-for' machine - mid 60's era Ford GT-40. I remember being in
the pits at the 24 hours at Daytona and have/had photographs of
them with holes in the fenders, being worn out from the inside by
the sand/dirt being thrown up by the tires after running in
the 150MPH range for 24 hours straight. That was a DOHC V8 and the
Saleen has the cam in the block - only sacrificing 200HP or so.
For those not familiar with the Saleen - www.saleen.com.
For the more mundane there is their modified Ford Explorer.
Neat cars, but I much prefer sleepers over BRTMs (Bright Red Ticket
I got some very interesting comments from an instructor at a driving school
at Seattle Internation Raceway. He was in a BMW M5 and had been looking at
my ``UNIX DR'' license plate when the M5 got close enough to read it at the
end of the straight before I would leave him behind through the twisty part
of the course. He had told his student to stay as close to me as he could,
and try to do exactly what I was doing. My car is a box stock 1990 Subaru
INTERNET: bi...@Celestial.COM Bill Campbell; Celestial Software LLC
UUCP: camco!bill PO Box 820; 6641 E. Mercer Way
FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
My brother sent me a postcard the other day with this big satellite photo
of the entire earth on it. On the back it said: ``Wish you were here''.
-- Steven Wright
> "Tony Lawrence" <to...@pcunix.com> wrote in message
> > Bill Vermillion wrote:
> > >
> > > In article <e6QA6.2232$Uu6.2...@monger.newsread.com>, Bob Meyers
> > > <oregon...@yahoo.com> wrote:
> > >
> > > >I had to chuckle thinking about this thread (oh yes, I started it).
> > > >It is like we are all a bunch of old men sitting on the park bench,
> > > >arguing the merits of ksh, symbolic links and the good old days.
> > > >And why we were doing it, that red Porche convertible that just
> > > >sped down the street had "Linux" spelled out on it's license plates
> > > >:)
> > >
> > > Which was promptly blown away by the silver Saleen S7 with
> > > the license plate that read "FreeBSD" :-)
> > But nobody noticed the Saleen S7..
> hehheh :) I was going to quote : "OS/2 Rules!"
I still wear my OS/2 tee shirt "fast pane relief", but always under
something. One of the best tee shirts ever made.
ksh was included with XENIX 2.3.4, and perhaps 2.3.2.