Re: Add user in Unix from command Line


----- Original Message -----
From: "Whoever" <nobody@xxxxxxxxxxxx>
Newsgroups: comp.unix.sco.misc
To: <distro@xxxxxxx>
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:


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!

Rather the other way around.
I wouldn't call SCO's or any of the linux vendors developers exactly
incompetent.
Those scripts at least in the sco case were probably a conscious design
choice and it was probably the right one for the time.
The only other bourn-ish shell available for sco was ksh which sco
themselves supplied and so some of ksh's configurable options were set to
match what sh does and bash was not yet invented and then practically
unheard of until relatively recently, since most sco systems didn't have a
compiler until relatively recently when they decided to start including the
key linker parts which allows one to use gcc.

In that context, and also remembering that this long ago pc's were not
nearly as fast as now and little optimizations like not forcing a new shell
to load with every script startup made a measurable difference, I don't
think those scripts were automatically wrong.

Later when the context has changed, they started giving away the linker with
the base os which allows everyone to have a compiler, and not only bash but
several bourn shells have popped up and are available on sco, and pc's are
so much faster,
only now does it make more sense to have all scripts throughout the system
specify the exact shell they need because only now is it no longer a safe
assumption.

But this was originally supposed to be an answer to "why leave roots shell
as sh on sco?"
Thats the answer. Whether it makes sco a good or bad system is irrelevant in
that it doesn't change what you should do. All that is relevant is that,
when, for whatever reason, you find yourself
installing/maintaining/fixing/using a sco box, you should not change roots
login shell (ie, in /etc/passwd) from sh or at least the stock ksh88 (ksh93
is available but it's not 100% safe for using as the root login and base
system sh that cron jobs and rc scripts etc will all use)
In MY opinion I go further to say you shouldn't even use the stock ksh for
roots login shell and even avoid running other shells manually/interactively
as root unless you are careful to back out to the stock shell before running
any of the system utils like scoadmin.
Thats just me though. JPR says he's ben running tcsh as his interactive
shell for root for years without a problem.
*shrug* in 5.0.6 and even more since then sco has tried to clean up all
those scripts.
Some other parts of the system like cron already take care of running their
child scripts in a particular shell themselves.
Maybe they did a good enough job and it's not so much of an issue any more.
Myself, I do still put "exec ksh" at the bottom of root's .profile so that I
have bash-like convenience in the interactive login shell (on 5.0.6 or later
thanks to a special .kshrc sco started providing at that point) and when I
run scoadmin or anything else, it's at least getting run by a compatible
shell if there are any lingering scripts that don't specify. Yet since
root's login shell is still sh, all the start up and init and cron and any
other background tasks all get run in the stock sh that they were written
for and which doesn't have that problem I found where ksh crashes under just
the right circumstances.

But Bill made a recommendation based on his experience which was an attempt
to point out to someone the 100% solid way to go. Any other way is probably
90% solid and that's good enough really. You suffer a failure or problem
once in a while and it costs some time figuring it out or reinstalling after
you give up, etc.. but no one dies from it. In fact as the consultant you
probably get lots of billable hours from it, but then that gets into asking
what kind of consultant you want to be and whether you car how you make your
money. But pointing out what isn't obvious at first and requires many
iterations and a few failures before the pattern emerges and the way to
avoid the failures derived from that pattern, is exactly what experience and
advice is good for.

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
It's neither reasonable nor good use of brains to expect all those new
generation kiddies writing this stuff to write scripts that are really
least-common-denominator crude portable sh, since these are linux vendor
supplied base os scripts and the vendors are certainly in a position to
assure that bash is always supplied right along with the scripts as part of
the same package or as a dependancy in the package managers. Even if they
would write in old sh, I don't think they should since it's a pointless step
backwards in efficiency. Why keep forking a child to run `expr ...` instead
of using built-in math today?
Write in bash (or zsh, or ksh) and just specify the shell unambiguously.


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.

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. I'd have
to agree with him on that. What exactly are you paying for if not for
freedom from having to conquer problems like that on your own or hire a
consultant to do it for you?
But I don't buy into sles either so I can't comment much on the worth of the
various enterprise linux's
I tried sles for a while but I ran into a smattering of compatibility issues
and it wasn't worth it to resolve them.

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

.

Relevant Pages

  • Re: Add user in Unix from command Line
    ... This really only affects the login shell for root -- once logged in as ... Some are other shell scripts, some are .c and .h files, some are various ... And now I just plain do not use other shells while root on sco boxes, ... For a few years I used to change roots login shell to ksh, ...
    (comp.unix.sco.misc)
  • Re: Apparently, csh programming is considered harmful.
    ... Can someone please explain why bash sucks? ... boot scripts without bashisms. ... I don't understand why everyone insists on POSIX compliance for portability ... with shell scripting. ...
    (freebsd-questions)
  • Re: conversion of csh scripts to bash
    ... > I recognize that bash is the superior shell, but like many people, I was ... > first exposed to csh 12 years ago because that's what everyone in my ... Note that shell programming sucks in general, ... I would certainly not write bash specific scripts, but instead, ...
    (comp.unix.shell)
  • Re: question about Dash
    ... bash isn't - well it has whats called bash-isms ... Both are POSIX compliant as far as I can tell. ... so it cannot run scripts using them. ... shell on many UNIXes, and sometimes was even used as /bin/sh. ...
    (Debian-User)
  • Re: ld-elf.so.1: Shared object"libintl.so.6" not found
    ... Kris Kennaway wrote: ... >>is my kernconf and a few rc scripts. ... Back to the shell :-) ... my default shell for root is bash. ...
    (freebsd-questions)
Loading