In article <1164360025.623611.150110@l12g2000cwl.googlegroups. com>,
thecoolone wrote:
>I tried to add a new user using the command line commands "useradd" and
>"adduser" but with no luck. The user names are added but i cannot login
>into the system using the just created username and password. Whats
>wrong?? y isint it working??
>And also i wanted to know that when i login as a regular user and then
>use "su" in the terminal and then as root in the terminal try to do
>"adduser" command it says "bash command not found". why does this
>happen. im a superuser in the terminal and y cant i execute the
>"adduser" command.

I guess you need to know a bit more about how Unix systems operate.

Look at the man page for su and notice the difference between
"su" and "su -". The latter is what you want when you need to
do work as root, not just have the abilities to modify files, etc.

And when you are running as root/super-user you really should
use the /bin/sh not bash, else you could have some unpleasant
suprises. The only shell other than /bin/sh I'd recommend using
as root is the ksh - NOT the pdksh - but the real one that
David Korn wrote - which is part of the distribution.

Bill
--
Bill Vermillion - bv @ wjv . com

thanx bill for ur reply. and yeah after reading the man pages of su i
realized tat i needed to use su - instead of su.

BTW im curious y did u say to use only /bin/sh as the shell when ur a
root user in the terminal as opposed to /bin/bash and /bin/csh.
cud u tell me the suprises u were talkin abt ??

In article <1164488310.310654.13820@f16g2000cwb.googlegroups.c om>,
thecoolone wrote:
>
>thanx bill for ur reply. and yeah after reading the man pages of su i
>realized tat i needed to use su - instead of su.

That is something many people don't seem to understand -
particularly those who have learned just enough Unix to semi-manage
their application. And learning 'just enough' can be dangerous :-)

>BTW im curious y did u say to use only /bin/sh as the shell when ur a
>root user in the terminal as opposed to /bin/bash and /bin/csh.
>cud u tell me the suprises u were talkin abt ??

In the past bash has had some problems, and I suspect most have
been fixed.

However if you run Unix for any length of time you'll find the
common comment that you should use the shell which is discributed
with the system as the root shell. Some scripts depend on
the way the default shell operates and not all other shells handle
them properly. Be very careful with command line completion, anmd if
you don't think about it you can wind up doing things you don't
wish to do. I've seen people asking how they can get their files
back when they used completion and instead of removing a symlink,
removed all the file to which the link pointed. csh can cause probelms
also.

I have found that the real ksh, the one from AT&T if you get it
yourself, or the one that is distributed with SCO - which is also
from David Korn's sources work quite well as a root shell.

Some may disagree with this however saying never change the root
shell, but I've been doing this for a long time. Since I've run
Unix and Xenix systems since 1983 I wind up with 'vi' as my
all-purpose editor, and the ksh distributed with SCO gives me
vi-like command line editing.

The nice thing about Unix is that there are so many ways to da
anything

The best thing you can do is understand the system - Unix as a
system. Once you do that you can walk into virtually eny
Unix or Unix-like system and fix problms and make it work.
If you learn just the details to run a particular program
you'll never master the system.

I still have on my shelf the classic "Design Of The Unix Operating
System" by Bach. It's a 1986 publication. There were probably
1000-1500 copies in stacks at the technical Usenix conference in
Atlanta in 1986 and this was when it was just released. They were
all snapped up by the end of the day and an emergency shipment came
in the next day. This was the first 'how the system' works book -
but it dates to Unix 5.2. I had been using Xenix/Unix for only
three years at that time, and that book was like a college
education in Unix from my POV.

It's quite old so I don't recommend that - but the idea is to learn
the system and not the details.

Bill
--
Bill Vermillion - bv @ wjv . com

Bill Vermillion wrote:
> In the past bash has had some problems, and I suspect most have
> been fixed.
>
> However if you run Unix for any length of time you'll find the
> common comment that you should use the shell which is discributed
> with the system as the root shell. Some scripts depend on
> the way the default shell operates and not all other shells handle
> them properly. Be very careful with command line completion, anmd if
> you don't think about it you can wind up doing things you don't
> wish to do. I've seen people asking how they can get their files
> back when they used completion and instead of removing a symlink,
> removed all the file to which the link pointed. csh can cause probelms
> also.
>
> I have found that the real ksh, the one from AT&T if you get it
> yourself, or the one that is distributed with SCO - which is also
> from David Korn's sources work quite well as a root shell.
>
> Some may disagree with this however saying never change the root
> shell, but I've been doing this for a long time. Since I've run
> Unix and Xenix systems since 1983 I wind up with 'vi' as my
> all-purpose editor, and the ksh distributed with SCO gives me
> vi-like command line editing.

I use vi too. but find it annoying when i want to find something on the
page. pico is handfull at those times. do u knw of any good site with
Tips & Tricks on vi that stand out.

> The nice thing about Unix is that there are so many ways to da
> anything
>
> The best thing you can do is understand the system - Unix as a
> system. Once you do that you can walk into virtually eny
> Unix or Unix-like system and fix problms and make it work.
> If you learn just the details to run a particular program
> you'll never master the system.
>
> I still have on my shelf the classic "Design Of The Unix Operating
> System" by Bach. It's a 1986 publication. There were probably
> 1000-1500 copies in stacks at the technical Usenix conference in
> Atlanta in 1986 and this was when it was just released. They were
> all snapped up by the end of the day and an emergency shipment came
> in the next day. This was the first 'how the system' works book -
> but it dates to Unix 5.2. I had been using Xenix/Unix for only
> three years at that time, and that book was like a college
> education in Unix from my POV.
>
> It's quite old so I don't recommend that - but the idea is to learn
> the system and not the details.

well i am learning Unix as i go along. Till now i was primarily using
windows and Linux GUI like kde and gnome. now i am getting my hands
into the command line stlye of working. i was reading about grep and
corn and realized that windows doesnt have any equivalent of those and
now i wonder why all those years i was using windows with mouse

On Sun, 26 Nov 2006, Bill Vermillion wrote:

> In article <1164488310.310654.13820@f16g2000cwb.googlegroups.c om>,
> thecoolone wrote:
>>
>
>> BTW im curious y did u say to use only /bin/sh as the shell when ur a
>> root user in the terminal as opposed to /bin/bash and /bin/csh.
>> cud u tell me the suprises u were talkin abt ??
>
> In the past bash has had some problems, and I suspect most have
> been fixed.

I think it has more to do with the way /bin/sh is built. Actually,
/sbin/sh is probably a better shell to use. From an older Solaris system:

-bash-3.00$ file /sbin/sh
/sbin/sh: ELF 32-bit MSB executable SPARC Version 1, statically
linked, st ripped
-bash-3.00$ file /bin/sh
/bin/sh: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, s tripped

As you can see, /sbin/sh is statically linked, which means that it will
still work even if /usr is not mounted. Other shells are dynamically
linked so they have dependencies on /usr:

-bash-3.00$ ldd /bin/sh
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1

This really only affects the login shell for root -- once logged in as
root, one can run another shell.

----- Original Message -----
From: "Whoever"
Newsgroups: comp.unix.sco.misc
To:
Sent: Sunday, November 26, 2006 5:20 PM
Subject: Re: Add user in Unix from command Line


>
>
> On Sun, 26 Nov 2006, Bill Vermillion wrote:
>
>> In article <1164488310.310654.13820@f16g2000cwb.googlegroups.c om>,
>> thecoolone wrote:
>>>
>>
>>> BTW im curious y did u say to use only /bin/sh as the shell when ur a
>>> root user in the terminal as opposed to /bin/bash and /bin/csh.
>>> cud u tell me the suprises u were talkin abt ??
>>
>> In the past bash has had some problems, and I suspect most have
>> been fixed.
>
> I think it has more to do with the way /bin/sh is built. Actually,
> /sbin/sh is probably a better shell to use. From an older Solaris system:
>
> -bash-3.00$ file /sbin/sh
> /sbin/sh: ELF 32-bit MSB executable SPARC Version 1, statically
> linked, st ripped
> -bash-3.00$ file /bin/sh
> /bin/sh: ELF 32-bit MSB executable SPARC Version 1, dynamically
> linked, s tripped
>
> As you can see, /sbin/sh is statically linked, which means that it will
> still work even if /usr is not mounted. Other shells are dynamically
> linked so they have dependencies on /usr:
>
> -bash-3.00$ ldd /bin/sh
> libc.so.1 => /usr/lib/libc.so.1
> libdl.so.1 => /usr/lib/libdl.so.1
> /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
>
> This really only affects the login shell for root -- once logged in as
> root, one can run another shell.

thats true but is just one of the many reasons to "just don't mess with it"

What I'm about to describe has been corrected to a large degree in 5.0.6 and
5.0.7 but even in 5.0.7 still not completely.

I had a 5.0.4 or 5.0.5 system a few years ago where I had _not_ changes
roots shell, but was actually merely logged in as root and had run bash
manually.

While in that state I tried to relink a kernel as part of a tape drive
upgrade.
A perfectly common operation if you are a sco admin & consultant or even a
reasonably active user.
You have to do it for example, any time you change a nic's ip address.

Well the build failed, first time I ever saw a build fail, and it wouldn't
work any more.
I could no longer generate a kernel. That's bad. You can't change anything
about the disk drives or tape drive or nic's ... progress is arrested on
that box. (You _can_ actually do some things without rebuilding but it's not
supported or well documented anywhere or easy or safe or sure or fully
effective even when you get it...)

Eventually I figured it out and it took me most of a weekend to clean it up.
Luckily it was my own box and I had the time and it was more or less OK that
the box was down for that long. (sort of down. it ran on the old kernel
fine, but, I did need those changes I was trying to do in the first place
and the old kernel didn't have them.)

What happened was:

The process of relinking the kernel involves lots of shell scripts that
read, parse, and write back out modified versions of lots of text files.
Some are other shell scripts, some are .c and .h files, some are various
sco-specific (or at least sysv specific) config files.

Many of these shell scripts did not have a bang line at the top to specify
what shell the script should be interpreted with.
That means they get interpreted by whatever shell the user is currently
using.

Because I was using bash, some of these scripts ran in bash, which has many
differences from sco's sh, and among those differences is that the echo
command in sco's sh interprets backslash codes by default, and bash does
not.

So these scripts included commands that looked like
echo "${AAA}\t${BBB}" >> file
and
echo "start of line \c"
if something then do
echo "line middle aaa\c"
else
echo "line middle bbb\c"
fi
echo "...end of line"

So the files the scripts worked on got totally trashed from being properly
parseable by the various things that need to read them, into junk.

Files ended up getting created that with "\t" in them where there should
have had tab characters.
And lines got written in the form of multiple partial lines each ending in
"\c" instead of the single long line they were supposed to be. Those are not
osmetic errors. They completely break the formatting other scripts need in
order to parse them.
It's the difference between some whitespace or word-seperator, and none, in
the case of the tabs.
It's even worse for the \c

When an awk command is searching for word number 3 on a line, but that line
has "blah\tfoo\tbar" instead of "blah tab foo tab bar", there is no
whitespace and the command fails. Or worse, it finds some other part of the
line and tries to use it.
That could be the difference btween say "rm foo" and "rm *" for example if
it faild to see foo in "blah\t\foo\tbar # * delete it *"
There the 3rd word should have been bar, but ended up being *

In my case the error didn't cause any further indirect damage from commands
running amoke with bad input like that. But the direct damage of not being
able to relink a kernel any more was bad enough.

I ended up tracking down the corrupted files and editing them by hand and
got the system working again.

And now I just plain do not use other shells while root on sco boxes, at
least not while doing anything hat might run very complex system level
scripts, which is most anything in scoadmin.

Other things that can get screwed up are merely annoying and it's ok to risk
it. Some printer interface scripts still do not specify the shell so they
can possibly fail or output incorrect print output. Ok if/when that happens
the box is still fine, merely a print job failed to came out cosmetically
bad. But anything at the system level like cron jobs, init and rc startup
scripts, and all the system maintenance stuff that scoadmin is the front-end
for, I don't take any chances. Just leave roots login shell as sh and make
sure you're not running something else manually when you go to do some
things.

But even that failure, as ugly as it was, was at least grossly and overtly
and immediately bad, and thus almost not a problem since I knew about it
right away and was forced to deal with it.

For a few years I used to change roots login shell to ksh, since as far as I
could tell, it was compiled to behave just like the plain sh (that echo
behaviour, for the record, is platform dependant in ksh, ksh93, real korn
ksh, on linux, behaves the same as bash! the ksh docs say to use print or
printf if you really want the same behaviour on any platform. so ksh behaves
just like sco sh, only on sco, not in general)

As far as you can tell, it does in fact work. no obvious problems.
But over several years and lot's of sco boxes, I saw a pattern of a lot more
mysterious problems on the later boxes that I never had on the older ones.
This could be almost anything really since the time frame covers 5.0.6, many
patches and updates to 5.0.6, 5.0.7, and many patches and updates to 5.0.7.
Not to mention revisions to the hardware. Even though we mostly stuck to a
very narrow set of hardware, ie: intel motheroards and either adaptec or lsi
raid cards, that still covers lots of hardware changes over time.
Also some software changed radically. For example, two heavily used (by my
customers) software packages both switched from being native osr5 binaries
to being unixware binaries that run on osr5 via emulation. The emulation is
provided by sco, has been around for several years now and is not only
officially supported but is actualy pushed as the officially recomended way
to write new software for osr5, but I'm not convinced it's solid. both of
those apps have problems ever since that chang that they didn't have before.
But they _mostly_ work, and/or they work but it's only in conert with other
software that they fail. So I've never been able to get sco or the app
endors to take any kind of lok at it. But I know what I see.

I don't change roots shell even to ksh anymore. But by the time I reached
that decision we had almost stopped shipping sco boxes so I doubt I'll ever
be able to build up enough data to say if reverting that change makes the
boxes better on average.
But my gut feeling is that there is something not quite right with the sco
ksh and/or the rest of the system working around it if not ksh itself. It's
almost impossible to reduce the prolems to numbers and clear items. If that
were the case we'd all just fix them and no more problem. The problem is a
system is a large and very complex thing. The vendor does their extensive
testing and building and fixing etc all with a certain set of items all
working in concert, the shell is just one part but a pretty pervasive one,
and then since that's the default shipped shell, it gets millions times more
testing out in the world and fixing as a result of support calls. No matter
how "compatible" some other shell is, it's imposible to be as reliable as
the one getting all that testing and bugfixing and tweaks to the rest of the
system to match it. Some other shell might not be broken necessarily, but
even slight slight differences in behaviour could cause any number of
problems that may be subtle, may only occure under just the right
combination of other circumstances and so only happen rarely, or may have
some effect that is slowly and gradually cumulative that takes a while to
build up to where you can see it or it crashes the box. And then you may
never have a clue thats what it was but may think it was something
completely unrelated, having to do with whatever you think was the most
likely culprit recent activities on the box.

I have one of those mysterious inconsistent problems with the stock sco ksh
that I did actually track down but it'll never get fixed even though I can
reproduce it at will and clearly show that any other shell dropped into the
same exact spot does not cause the problem. Becuase it's so subtle and wierd
and requires just the perfect context. I don't know what else may sometimes
hit this same bug, but one way I found to reproduce it requires 3 specific
elements together. change any one and you don't have a problem., Which is
why none of the respective vendors feel obligated to fix anything since each
element works on it's own.

The way to reproduce the problem is to use sco's stock ksh from within a
sysem() command in filepro on sco openserver 5.any
It also needs to be nested, that is, run filepro, in there have a system
command that runs ksh, in there run filepro, etc...
I built a little test app that recurses like that buildig up nested
shell/filepro/shell/filepro to whatever desired depth, and using whatever
desired shell, and testing for when one of the system() calls fails and
keeping track of at what depth a call failed.
It always produced the exact same sequence of success & failure at the
different depth-of-nesting levels every time it ran, after rebooting, but
most importantly, on 3 differen boxes, with even more importantly (more than
most?) 3 different versions of osr5! 5.0.5, 5.0.6, 5.0.7 . The versions of
filepro were different too but all 5.0 or above.
I don't remember if I tried 5.0.4. I think my last 5.0.4 box was gone by
then.
The version of ksh is nominally the same on all those versions of sco,
ksh88, but there may have been minor changes and rebuilds to it over that
span.
When I tell the test app to use ksh93 or sh or bash or zsh, every single
system() call succeeds.

That right there makes me assume that out of all the million things the
system does from boot to crash, there must be other times & places that
trigger the same bug that makes ksh crash in my test app sometimes.

But you can run a million scripts in ksh and never see a problem since they
don't just happen to be run in just that context. I and I made a test loop
that just nested ksh within ksh to various depths without filepro and that
didn't fail. so as far as sco is concerned ksh is thus proved fine, so see
filepro or the os.
And filepro runs all those other scripts without failing in the same test
app, including ksh even just a different version, and filepro runs that same
test app with ksh on linux, all with no problem, so filepro is thus proved
fine so see ksh or the os.
And the os clearly runs everything else fine, so the os is thus proved fine
so see ksh or filepro.
All 3 parties involved (the os and ksh are the same vendor in this case but
it still holds) have enough proof to say it's not their problem.

On the zsh mailing list recently a person ran into a problem where a script
always used to work suddenly stopped.
It turned out he forgot or hadn't realized he used to run it always in bash
and ony in zsh it failed, and the reason wasn't from anything being broken
but simply array elements in bash start counting from 0 and in zsh they
start counting from 1.
A pretty important difference in behaviour!
Yet you could run a thousand bash and ksh scripts in zsh and never happen to
hit it and you might be led to think they are "compatible" and that it's ok
to just swap one out for the other, and for years even you might skate by
and be lucky and it'll seem true. Yet really it was wrong on day one.

So it is with /bin/sh for root on sco boxes.

You can run any shell you want. You just waive the right to any help with
almost any problem if you use anything other than the stock, shipped,
default.

Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

In article <1164547169.861694.197220@l12g2000cwl.googlegroups. com>,
thecoolone wrote:
>
>Bill Vermillion wrote:
>> In the past bash has had some problems, and I suspect most have
>> been fixed.

>> However if you run Unix for any length of time you'll find
>> the common comment that you should use the shell which is
>> discributed with the system as the root shell. Some scripts
>> depend on the way the default shell operates and not all other
>> shells handle them properly. Be very careful with command line
>> completion, anmd if you don't think about it you can wind up
>> doing things you don't wish to do. I've seen people asking how
>> they can get their files back when they used completion and
>> instead of removing a symlink, removed all the file to which
>> the link pointed. csh can cause probelms also.

>> I have found that the real ksh, the one from AT&T if you get it
>> yourself, or the one that is distributed with SCO - which is also
>> from David Korn's sources work quite well as a root shell.

>> Some may disagree with this however saying never change the root
>> shell, but I've been doing this for a long time. Since I've run
>> Unix and Xenix systems since 1983 I wind up with 'vi' as my
>> all-purpose editor, and the ksh distributed with SCO gives me
>> vi-like command line editing.

>I use vi too. but find it annoying when i want to find something on the
>page. pico is handfull at those times. do u knw of any good site with
>Tips & Tricks on vi that stand out.

What's wrong with / for searching for something in a page?

One thing I do is always run with set nu autoindent nomesg ruler
Since the numbers take up spaces and an additional space after
the number I also set wrapmargin=13. This means things wrap
properly on my sceen when I'm posting and also give an under 70
line-lenght in the posts. I also use par to reformat posts
that aren't wrapped properly.

I learned with a program called vi-learn on an old Xenix system
back about 1983 o4 1984. It's still around. It's just some
scripts that you go through practice lessons. All sorts of little
things in there. Once you get that down, you can go onto other
things. I've been using it for years and have still only used a
small percentage of it's capabilities. What works well is to use
it in combination with less. View the files [with wildcards] in
less and when you find what you want just type v and it brings
up the file in vi.

.....

>well i am learning Unix as i go along. Till now i was primarily using
>windows and Linux GUI like kde and gnome. now i am getting my hands
>into the command line stlye of working. i was reading about grep and
>corn and realized that windows doesnt have any equivalent of those and
>now i wonder why all those years i was using windows with mouse

Well actually Windows CAN have things like that. Many people
suggest cyg-win, but I like the free Services For Unix from
Microsoft. I just checked and it's been updated about 2 months
ago.

It has a LOT of Unix services. ksh, vi, grep, awk, and the list
goes on and on. It's a 250MB download, but it really looks like
Unix, and it's so handy for manipulating many thing in Windows.

My first windows was 1.2 [I think] . Really really ugly.

When DOS 2.0 came out I was it had a hierarchical directory, that
broke the maximum of 512 files you could have on DOS 1.

It looked Unixy. But after 6 months I was so disappointed I
stopped using it and went back to my TRS80s and also CP/M system,
as they were so much faster. It was actually the speed of the
stupid video display that made DOS seem so slow.

I remember on demo I saw with a DOS 2 machine against and LDOS
OS on a Max80 - a hardware workalike.

They'd start a little program from a file on DOS that did nothing
but print the numbers from 1 to 1000 using print statements in
BASIC. They'd start that running and walk across the room to the
Max and then TYPE the same program in and then run it.

THe Max always finished faster. It was a 5Mhz machine, the PC was
4.8MHz - but the video was so slow while the Max used memory mapped
video - it seemed far faster.

And a few months later I parted out the PC as I had gotten a Radio
Shack model 16 - my first 32 bit machine - in late 1983. I moved
to Unix system and never looked back and only use MS when I have
too.

I'm just an old CLI junkie - and since I have a vision problem
80x24 green on black is much easier than virtually all GUIs.

Bill



--
Bill Vermillion - bv @ wjv . com

On Sun, 26 Nov 2006, Brian K. White wrote:

>
> ----- Original Message -----
> From: "Whoever"
> Newsgroups: comp.unix.sco.misc
> To:
> Sent: Sunday, November 26, 2006 5:20 PM
> Subject: Re: Add user in Unix from command Line
>
>
>>
>>
>> On Sun, 26 Nov 2006, Bill Vermillion wrote:
>>
>>> In article <1164488310.310654.13820@f16g2000cwb.googlegroups.c om>,
>>> thecoolone wrote:
>>>>
>>>
>>>> BTW im curious y did u say to use only /bin/sh as the shell when ur a
>>>> root user in the terminal as opposed to /bin/bash and /bin/csh.
>>>> cud u tell me the suprises u were talkin abt ??
>>>
>>> In the past bash has had some problems, and I suspect most have
>>> been fixed.
>>
>> I think it has more to do with the way /bin/sh is built. Actually,
>> /sbin/sh is probably a better shell to use. From an older Solaris system:
>>
>> -bash-3.00$ file /sbin/sh
>> /sbin/sh: ELF 32-bit MSB executable SPARC Version 1, statically
>> linked, st ripped
>> -bash-3.00$ file /bin/sh
>> /bin/sh: ELF 32-bit MSB executable SPARC Version 1, dynamically
>> linked, s tripped
>>
>> As you can see, /sbin/sh is statically linked, which means that it will
>> still work even if /usr is not mounted. Other shells are dynamically
>> linked so they have dependencies on /usr:
>>
>> -bash-3.00$ ldd /bin/sh
>> libc.so.1 => /usr/lib/libc.so.1
>> libdl.so.1 => /usr/lib/libdl.so.1
>> /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
>>
>> This really only affects the login shell for root -- once logged in as
>> root, one can run another shell.
>
> thats true but is just one of the many reasons to "just don't mess with it"
>
> What I'm about to describe has been corrected to a large degree in 5.0.6 and
> 5.0.7 but even in 5.0.7 still not completely.
>
> I had a 5.0.4 or 5.0.5 system a few years ago where I had _not_ changes
> roots shell, but was actually merely logged in as root and had run bash
> manually.
>
> While in that state I tried to relink a kernel as part of a tape drive
> upgrade.
> A perfectly common operation if you are a sco admin & consultant or even a
> reasonably active user.
> You have to do it for example, any time you change a nic's ip address.
>
> Well the build failed, first time I ever saw a build fail, and it wouldn't
> work any more.
> I could no longer generate a kernel. That's bad. You can't change anything
> about the disk drives or tape drive or nic's ... progress is arrested on
> that box. (You _can_ actually do some things without rebuilding but it's not
> supported or well documented anywhere or easy or safe or sure or fully
> effective even when you get it...)
>
> Eventually I figured it out and it took me most of a weekend to clean it up.
> Luckily it was my own box and I had the time and it was more or less OK that
> the box was down for that long. (sort of down. it ran on the old kernel
> fine, but, I did need those changes I was trying to do in the first place
> and the old kernel didn't have them.)
>
> What happened was:
>
> The process of relinking the kernel involves lots of shell scripts that
> read, parse, and write back out modified versions of lots of text files.
> Some are other shell scripts, some are .c and .h files, some are various
> sco-specific (or at least sysv specific) config files.
>
> Many of these shell scripts did not have a bang line at the top to specify
> what shell the script should be interpreted with.

What can I say? Incompetant OS developers releasing scripts without a
suitable #! line?

>>>>
>>>>> BTW im curious y did u say to use only /bin/sh as the shell when ur a
>>>>> root user in the terminal as opposed to /bin/bash and /bin/csh.
>>>>> cud u tell me the suprises u were talkin abt ??
>>>>
>> Many of these shell scripts did not have a bang line at the top to
>> specify
>> what shell the script should be interpreted with.
>
> What can I say? Incompetant OS developers releasing scripts without a
> suitable #! line?

That's a grand and grandly ignorant comment.

Do you have any concept how many linux scripts that are part of the
vendor-supplied base os, where the script did include the bang line, which
said "#!/bin/sh" and which never the less were _bash_ specific ??

Everyone on the planet can rightly be called incompetent and ignorant and
worse by someone else.
As unpleasant as that kernel relink episode was, I understand that it was
quarely _my fault_.
SCO, at that time, was still the hands down _best_ unix for intel if you
want to install and go and have a minimum of risk of and maintenance and
that was only a couple years ago.

Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

In article ,
Whoever wrote:
>
>
>On Sun, 26 Nov 2006, Bill Vermillion wrote:

>> In article <1164488310.310654.13820@f16g2000cwb.googlegroups.c om>,
>> thecoolone wrote:
>>>

>>> BTW im curious y did u say to use only /bin/sh as the shell when ur a
>>> root user in the terminal as opposed to /bin/bash and /bin/csh.
>>> cud u tell me the suprises u were talkin abt ??

>> In the past bash has had some problems, and I suspect most have
>> been fixed.

>I think it has more to do with the way /bin/sh is built. Actually,
>/sbin/sh is probably a better shell to use. From an older Solaris system:

>-bash-3.00$ file /sbin/sh
>/sbin/sh: ELF 32-bit MSB executable SPARC Version 1, statically
>linked, st ripped
>-bash-3.00$ file /bin/sh
>/bin/sh: ELF 32-bit MSB executable SPARC Version 1, dynamically
>linked, s tripped

>As you can see, /sbin/sh is statically linked, which means that it will
>still work even if /usr is not mounted. Other shells are dynamically
>linked so they have dependencies on /usr:

>-bash-3.00$ ldd /bin/sh
> libc.so.1 => /usr/lib/libc.so.1
> libdl.so.1 => /usr/lib/libdl.so.1
> /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1

>This really only affects the login shell for root -- once logged in as
>root, one can run another shell.

I always like statically linked programs for the programs that you
might need to use in system recovery.

As to the Solaris you mention, a few years ago when there were a
lot of startup dot-coms, and old SCO client of mine got involved
with a huge project [a few million went down the tubes in a a few
months because there were 3 people in important places that were in
over their head] and they used Solaris as front-ends to
Apple G4s [in special rack mounts] using Web Object, and
then a dual-CPU Sun running Oracle.

One of the people was a big Linux fan and set the Sun up just like
he'd do with a LInux machine including moving roots directory :-(
The big problem was that /usr was not mountable and almost
everything was symlinked, so it failed on a reboot.

When it crashed it could not fsck the file system as nothing could
be found. And if you put in the OS CD it said there was an OS
intalled and would not continue.

Since it was one of the pizza-box machines and it had two HDs,
that were easily removeable. I swapped the drives, installed
Solaris on the previously unused second drive. Then I fsck'ed
the original drive that was now in the second position, and then it
was just swap the drives back, and proceed to set things up the way
they should have been.

That was the first Sun I had been near in years. One of
the people in later was having trouble with a local Sun machine.
The owner called me in and the person was in the process of
installing the OS for the 3rd time as he could not get the network
up.

I've never seen such a waste of money in such a short time.

They also had been sold a satellite system as their customers were
not in the area where you could usually get anything more than
dialin, so they were going to work with a provider to provied
satellite downlinks for data to these places. That never worked
and I think it was another half-million down the rabbit hole.

Sorry for the drift, but it was the static vs dynamic that stuck
out. I run mainly freebsd for a smallish niche market ISP, and
with the execption of three files, pgrep, pkill and rmail [for the
news system] everything is static. The only drawback is that if
something is wrong in any library you have to rebuild the static
items, but I don't mind that as long as I have recover tools that
will run when most other things wont. I take the belt and
suspendors approach. :-)

Bill

--
Bill Vermillion - bv @ wjv . com

In article <011601c7120d$8a91bc30$931fa8c0@venti>,
Brian K. White wrote:
>>>>>
>>>>>> BTW im curious y did u say to use only /bin/sh as the shell when ur a
>>>>>> root user in the terminal as opposed to /bin/bash and /bin/csh.
>>>>>> cud u tell me the suprises u were talkin abt ??
>>>>>
>>> Many of these shell scripts did not have a bang line at the top to
>>> specify
>>> what shell the script should be interpreted with.
>>
>> What can I say? Incompetant OS developers releasing scripts without a
>> suitable #! line?
>
>That's a grand and grandly ignorant comment.

>Do you have any concept how many linux scripts that are part of
>the vendor-supplied base os, where the script did include the
>bang line, which said "#!/bin/sh" and which never the less were
>_bash_ specific ??

It's like many of the Linux man pages that show a path for a file
which was wrong, because the man pages were copied from BSD with
only a search and replace for Linux.

Why rewrite things when they worked elsewhere seems to be done
quite often, without checking for differences, major or minor.

>Everyone on the planet can rightly be called incompetent and
>ignorant and worse by someone else.

As most of us have by some client who had an empty clue basket.

>As unpleasant as that kernel relink episode was, I understand
>that it was quarely _my fault_.

And those were the ones we learn from.

>SCO, at that time, was still the hands down _best_ unix for intel
>if you want to install and go and have a minimum of risk of and
>maintenance and that was only a couple years ago.

After having a couple of instances of kernel rebuild problems, one
of which started with a set of drivers that didn't like to install
properly so removed all the things it added PLUS some things it
should not have touched, I took a different approach.

I always had two file systems. One that was basically for the OS
alone, and another for all the aps and data.

Then everytime I needed to do maintenance and rebuild a kernel or
make other drastic modifications, I'd unmount everything except
the / file system, make a backup with BackupEdge, and then go to
work.

Then if something failed, I'd remake the / filesystem - to make
SURE that anything that got added and did not get removed would
vanish *poof*.

Then I'd just restore the / file system. With a smallish / for the
OS - tyipically under 1GB - it was less than 5 minutes to backup
the OS, as opposed to about 1.5 hours on that particular system.

The extra 5 minutes to backup paid off in one or two instances,
while >most< of the times things went just fine. It's when things
don't go as you planned, the 20 minute upgrade could take hours and
hours.

Bill

--
Bill Vermillion - bv @ wjv . com

Bill Vermillion wrote (on Mon, Nov 27, 2006 at 03:35:01AM +0000):

[snip]
| Well actually Windows CAN have things like that. Many people
| suggest cyg-win, but I like the free Services For Unix from
| Microsoft. I just checked and it's been updated about 2 months
| ago.
|
| It has a LOT of Unix services. ksh, vi, grep, awk, and the list
| goes on and on. It's a 250MB download, but it really looks like
| Unix, and it's so handy for manipulating many thing in Windows.

I had Microsoft Services for UNIX, but its ksh is a version
of pdksh, so I ditched it after getting AT&T Research's UWIN
(also free), which has the -real- KornShell93.

Right now I'm logged in on my SCO OSR6 system via ssh in UWIN
on my Windows XP system.

Bob

--
Bob Stockler +-+ bob@trebor.iglou.com +-+ http://members.iglou.com/trebor

On Mon, 27 Nov 2006, Bill Vermillion wrote:

> In article ,
> Whoever wrote:
>>
>>
>> On Sun, 26 Nov 2006, Bill Vermillion wrote:
>
>>> In article <1164488310.310654.13820@f16g2000cwb.googlegroups.c om>,
>>> thecoolone wrote:
>>>>
>
>>>> BTW im curious y did u say to use only /bin/sh as the shell when ur a
>>>> root user in the terminal as opposed to /bin/bash and /bin/csh.
>>>> cud u tell me the suprises u were talkin abt ??
>
>>> In the past bash has had some problems, and I suspect most have
>>> been fixed.
>
>> I think it has more to do with the way /bin/sh is built. Actually,
>> /sbin/sh is probably a better shell to use. From an older Solaris system:
>
>> -bash-3.00$ file /sbin/sh
>> /sbin/sh: ELF 32-bit MSB executable SPARC Version 1, statically
>> linked, st ripped
>> -bash-3.00$ file /bin/sh
>> /bin/sh: ELF 32-bit MSB executable SPARC Version 1, dynamically
>> linked, s tripped
>
>> As you can see, /sbin/sh is statically linked, which means that it will
>> still work even if /usr is not mounted. Other shells are dynamically
>> linked so they have dependencies on /usr:
>
>> -bash-3.00$ ldd /bin/sh
>> libc.so.1 => /usr/lib/libc.so.1
>> libdl.so.1 => /usr/lib/libdl.so.1
>> /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
>
>> This really only affects the login shell for root -- once logged in as
>> root, one can run another shell.
>
> I always like statically linked programs for the programs that you
> might need to use in system recovery.


The prevalence of live-cds and now live-dvds makes the need for statically
linked recovery tools much less -- at least for Linux systems.

>
> That was the first Sun I had been near in years. One of
> the people in later was having trouble with a local Sun machine.
> The owner called me in and the person was in the process of
> installing the OS for the 3rd time as he could not get the network
> up.

Was it really a faulty OS install that stopped the network from coming up?
Somehow I would suspect faulty configuration, especially after 3 attempts
to install the OS. Solaris' support for dhcp assumes a setup that may be
atypical in many small environments -- there seems to be no easy way for
the client to define the hostname -- it assumes that this information will
come from the server and without it the server starts up with its hostname
set as "unknown".

FYI, with Microsoft's Small Business Server, the general recommendation is
to install it 3 times! The system is so inflexible that there are many
configuration settings that cannot be safely changed without a complete
re-install and it is expected that it will take someone 3 attepmts to get
it all correct. Yuk!

>

On Mon, 27 Nov 2006, Brian K. White wrote:

>>>>>
>>>>>> BTW im curious y did u say to use only /bin/sh as the shell when ur a
>>>>>> root user in the terminal as opposed to /bin/bash and /bin/csh.
>>>>>> cud u tell me the suprises u were talkin abt ??
>>>>>
>>> Many of these shell scripts did not have a bang line at the top to
>>> specify
>>> what shell the script should be interpreted with.
>>
>> What can I say? Incompetant OS developers releasing scripts without a
>> suitable #! line?
>
> That's a grand and grandly ignorant comment.
>
> Do you have any concept how many linux scripts that are part of the
> vendor-supplied base os, where the script did include the bang line, which
> said "#!/bin/sh" and which never the less were _bash_ specific ??

So, let's understand. SCO's developers did not screw up because some Linux
developers made mistakes? Even if the scripts were not
standards-compliant, this is hardly comparable since the only Bourne shell
variant available on most Linux distributions is BASH, so the consequences
of relying on bash extensions are negligible. Certainly not system-hosing!


>
> SCO, at that time, was still the hands down _best_ unix for intel if you
> want to install and go and have a minimum of risk of and maintenance and
> that was only a couple years ago.

Unix maybe. Unix like -- I rather doubt that. RedHat Enterprise 2.1 has
been out about 4 years, with a lifetime of 7 years. RedHat enterprise
provides stable platforms -- stable both in terms of configuration and
uptimes.

In article ,
Whoever wrote:
>
>
>On Mon, 27 Nov 2006, Bill Vermillion wrote:
>
>> In article ,
>> Whoever wrote:
>>>
>>>
>>> On Sun, 26 Nov 2006, Bill Vermillion wrote:
>>
>>>> In article <1164488310.310654.13820@f16g2000cwb.googlegroups.c om>,
>>>> thecoolone wrote:
>>>>>
>>
>>>>> BTW im curious y did u say to use only /bin/sh as the shell when ur a
>>>>> root user in the terminal as opposed to /bin/bash and /bin/csh.
>>>>> cud u tell me the suprises u were talkin abt ??
>>
>>>> In the past bash has had some problems, and I suspect most have
>>>> been fixed.
>>
>>> I think it has more to do with the way /bin/sh is built. Actually,
>>> /sbin/sh is probably a better shell to use. From an older Solaris system:
>>
>>> -bash-3.00$ file /sbin/sh
>>> /sbin/sh: ELF 32-bit MSB executable SPARC Version 1, statically
>>> linked, st ripped
>>> -bash-3.00$ file /bin/sh
>>> /bin/sh: ELF 32-bit MSB executable SPARC Version 1, dynamically
>>> linked, s tripped
>>
>>> As you can see, /sbin/sh is statically linked, which means that it will
>>> still work even if /usr is not mounted. Other shells are dynamically
>>> linked so they have dependencies on /usr:
>>
>>> -bash-3.00$ ldd /bin/sh
>>> libc.so.1 => /usr/lib/libc.so.1
>>> libdl.so.1 => /usr/lib/libdl.so.1
>>> /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
>>
>>> This really only affects the login shell for root -- once logged in as
>>> root, one can run another shell.
>>
>> I always like statically linked programs for the programs that you
>> might need to use in system recovery.
>

>The prevalence of live-cds and now live-dvds makes the need for
>statically linked recovery tools much less -- at least for Linux
>systems.

That doesn't work too well when your servers are physically
located away from you. My connection to my servers is about 2500
miles long by wire - but about 10 miles by land. However it's a
pain to work on servers in a colo - as everything has to be done
standing in front of the racks - as they are spaced fairly close
together. I have an access card that gives me 24x7 access to the
building. And when we lost a Cisco 72?? - I arrived about 3AM and
was the only person in the building - but they do watch from the
main center near Denver. CDs and DVDs recovery isn't a viable
option in that instance, and That applies to all systems, not just
linux.

>> That was the first Sun I had been near in years. One of
>> the people in later was having trouble with a local Sun machine.
>> The owner called me in and the person was in the process of
>> installing the OS for the 3rd time as he could not get the network
>> up.

>Was it really a faulty OS install that stopped the network from
>coming up?

It was diddling with the stock layout of the System. It was not
just the network - the entire machine would not boot. It came up
with needing to fsck the file-system but all the tools that were
needed were on the fs that needed to be fscked.

>Somehow I would suspect faulty configuration, especially after 3
>attempts to install the OS. Solaris' support for dhcp assumes a
>setup that may be atypical in many small environments -- there
>seems to be no easy way for the client to define the hostname
>-- it assumes that this information will come from the server
>and without it the server starts up with its hostname set as
>"unknown".

No DHCP there. The client accessed the servers through Gnat boxes
with public, DMZ, and private links. All IPS were static out of
our assinged IP pool.

>FYI, with Microsoft's Small Business Server, the general
>recommendation is to install it 3 times! The system is so
>inflexible that there are many configuration settings that
>cannot be safely changed without a complete re-install and it
>is expected that it will take someone 3 attepmts to get it all
>correct. Yuk!

And that is really stupid. On the FreeBSD servers I've changed IPs
dynamically on the fly. It's handy when you need a server upgrade,
and swap the IPs with the running system and the replacement
system. It's been awhile since I've done that, but the upside
is that there was less than 30 seconds of inaccesability when I
deleted one of the IPs on the main server, and then enabled that on
the new machine.

Now that I know how stable my machines are I can just change the
raw configs, and reboot remotely -as when I did the above I was not
sure how stable they would be on a reboot.

I don't recall the last time I sat down and installed any OS from
CD/DVD as I routinely rebuild the OS from source when there are
security fixes. The change of the FS from the typical inode size
to the new ones - with twice the entries - so it's only the largest
files that use indirect blocks - means being at the machine to
be able to re-make the FS to the current model, from UFS to UFS2.

Bill


--
Bill Vermillion - bv @ wjv . com

In article <20061127193655.GA15305@trebor.iglou.com>,
Bob Stockler wrote:
>Bill Vermillion wrote (on Mon, Nov 27, 2006 at 03:35:01AM +0000):
>
>[snip]
>| Well actually Windows CAN have things like that. Many people
>| suggest cyg-win, but I like the free Services For Unix from
>| Microsoft. I just checked and it's been updated about 2 months
>| ago.
>|
>| It has a LOT of Unix services. ksh, vi, grep, awk, and the list
>| goes on and on. It's a 250MB download, but it really looks like
>| Unix, and it's so handy for manipulating many thing in Windows.
>
>I had Microsoft Services for UNIX, but its ksh is a version
>of pdksh, so I ditched it after getting AT&T Research's UWIN
>(also free), which has the -real- KornShell93.
>
>Right now I'm logged in on my SCO OSR6 system via ssh in UWIN
>on my Windows XP system.
>
>Bob

Thanks for that reminder Bob. I'd almost forgotten about that.

Bill

--
Bill Vermillion - bv @ wjv . com

Brian K. White typed (on Tue, Nov 28, 2006 at 06:07:28AM -0500):
|
| Thats just me though. JPR says he's ben running tcsh as his interactive
| shell for root for years without a problem.

A bit more detail: the entry for 'root' in all my /etc/passwd files
continues to default to /bin/sh.

For my interactive efficiency I add a login called 'boss' which uses
tcsh and which has the same uid/gid as 'root':

Here on my OSR 6.0.0 system (where tcsh, latest version, is supplied
by SCO in /bin):

jpradley:jpr 232# head -2 /etc/passwd
root:x:0:3:JPR-root:/:
boss:x:0:3:JPR-boss:/:/bin/tcsh

I run any and all utilities (netconfig, link_unix, mkdev, divvy,
custom, compilations, whatever) from a 'boss' login; it has never
caused me any grief whatsoever.

--
JP
==> http://www.frappr.com/cusm <==

On Tue, 28 Nov 2006, Brian K. White wrote:

>
> ----- Original Message -----
> From: "Whoever"
> Newsgroups: comp.unix.sco.misc
> To:
> Sent: Tuesday, November 28, 2006 2:48 AM
> Subject: Re: Add user in Unix from command Line
>
>
>>
>>
>> On Mon, 27 Nov 2006, Brian K. White wrote:
>>
>>>>>>>
>
> As for the linux vendors with bash-specific sh scripts? IMO they should keep
> writing in bash and just put bash at the top and not sh

Well, there are differences in Bash's behaviour depending upon how it is
invoked.

>
>>> SCO, at that time, was still the hands down _best_ unix for intel if you
>>> want to install and go and have a minimum of risk of and maintenance and
>>> that was only a couple years ago.
>>
>> Unix maybe. Unix like -- I rather doubt that. RedHat Enterprise 2.1 has
>> been out about 4 years, with a lifetime of 7 years. RedHat enterprise
>> provides stable platforms -- stable both in terms of configuration and
>> uptimes.
>
> I decided it makes more sense to pick a dist, almost any dist, but just pick
> one and stay with it and deal with it's quirks, including version to version
> changes, rather than always using a new dist each box. I ended up settling
> on suse and so I don't know too much about rhel, but I'm very glad you
> included "in terms of configuration" in that. Because of that I'll take your
> word on that.

I use a variety of Distros: RHEL, Gentoo and most recently Ubuntu. Gentoo
is definitely not stable in terms of configuration. On the other hand, it
does provide an OS with the latest capabilities. RHEL on the other hand is
supposed to be supported with updates for 7 years, with packages that
should install without any changes to configuration files. To this end,
RedHat take security fixes and back-port them into the older versions of
the packages. There are some exceptions, though: things that must change,
such as grub.conf, after a new kernel is installed (and this should be
done automatically by the kernel package installation).


>
> Though I have an aquaintence linux consultant who would say other things
> about the goodness of rhel. He claims to have found some brokenness in their
> perl, something that is actually a problem else he wouldn't care, and
> despite having the expensive rhel support, and despite him being able to
> explain and reproduce the problem in no uncertain terms, they still haven't
> fixed the problem either for the client or in the dist as a whole.

Probably fixing the brokenness would break something else.