Add user in Unix from command Line - SCO

This is a discussion on Add user in Unix from command Line - SCO ; 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?? ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: Add user in Unix from command Line

  1. Add user in Unix from command Line

    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.

    And finally i would like to know if there is a way to manually add a
    user in the centos remotely from the command line. This is very
    important to me right now.

    any advice is welcomed.

    thanx in advance


  2. Re: Add user in Unix from command Line

    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

  3. Re: Add user in Unix from command Line


    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 ??


  4. Re: Add user in Unix from command Line

    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

  5. Re: Add user in Unix from command Line


    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


  6. 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.



  7. Re: Add user in Unix from command Line


    ----- 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!


  8. Re: Add user in Unix from command Line

    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

  9. Re: Add user in Unix from command Line



    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?


  10. Re: Add user in Unix from command 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!


  11. Re: Add user in Unix from command Line

    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

  12. Re: Add user in Unix from command Line

    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

  13. Re: Add user in Unix from command Line

    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

  14. Re: Add user in Unix from command Line



    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!

    >


  15. 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!


    >
    > 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.


  16. Re: Add user in Unix from command Line

    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

  17. Re: Add user in Unix from command Line

    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

  18. Re: Add user in Unix from command Line

    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 <==

  19. Re: Add user in Unix from command Line



    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.


+ Reply to Thread