I would like to change the login shell to bash for both root and my regular
account, but no explicit choice for bash occurs in the drop down list on
Account Manager.
A test user account was created, "/usr/bash" was entered manually for login
shell, "add shell environment files to home directory" was checked, and the
account login seems to proceed normally to a functioning bash shell. I had
previously invoked bash from a command prompt.
The dropdown list of shell choices includes /usr/bash for the new user, but
not other users after selecting "change login shell" in Account manager. I
assume that manual entry of "/usr/bash" and checking the shell environment
option would work for previous users as well.
Is this approach likely to cause any problems?
Thanks,
David P. Lurie
>
>Is this approach likely to cause any problems?
>
>
>
I've run into problems logging in through XDMCP and straight into X on
the console on 5.0.5 with bash as my login shell. There are a few
scripts here and there that need to be updated, but we're going back a
few years for me now and it's all a little hazy. They might have fixed
these problems in 5.0.6 or 5.0.7 but if bash is not in the selection
list, it's not something I'd bet the house on.
--
Scott Burns
Mirrabooka Systems
Tel +61 7 3857 7899
Fax +61 7 3857 1368
/usr/bash?? Not /usr/bin/bash?
| The dropdown list of shell choices includes /usr/bash for the new user, but
| not other users after selecting "change login shell" in Account manager. I
| assume that manual entry of "/usr/bash" and checking the shell environment
| option would work for previous users as well.
|
| Is this approach likely to cause any problems?
I'd just go into /usr/lib/mkuser and concoct entries for bash, which
can easily be patterned on those already present for other shells.
--
JP
I use the various Cygwin utilities, including Xwin to get a remote X
desktop.
Haven't tried to get a console login to X from the test user with bash login
shell, as currently at home. However, roundabout (Win XP remote desktop ->
Win XP on office LAN through VPN tunnel, with Xwin connection to server from
the XP system on the LAN for speed) XDMCP login loaded without problems.
An xterm window opened with a bash shell on the X desktop, as expected. I
was able to load the CE editor, and successfully load a keymap.
The welcome mail to the test user from the system indicates that the
nonstandard shell was flagged:
Welcome to SCO OpenServer!
Your login shell is atypical; please contact the
system Accounts Administrator if you wish this changed.
I believe that the configuration changes JPR suggested would get rid of this
problem, although it may not matter if no functional consequence. Those will
need to wait until I have a free time over a weekend, in case the changes
generate a test of RecoverEdge.
David P. Lurie
For the root user, yes. The root user's shell is used for many things
other than just a user (you should have a user with lots of privileges to
do most admin anyway).
As most here will advise you, don't use bash as your default root shell.
Invoke it manually, or from the root user's profile instead.
Now, as for it not showing up in the menu's, I can't help there. Possibly
an entry in /etc/shells will help.
bkx
YMMV.
I looked in /usr/lib/X11/scologin, which contains Xsession, Xsession-csh,ksh
and sh, but no Xsession-bash. Haven't had a chance to look at the config
files JPR mentioned to see if they would create Xsession-bash. Another
reason to keep loading bash from the command prompt for now.
David P. Lurie
>root shell Invoke it manually, or from the root user's profile
>instead.
I recall seeing some weirdness in the past coming in to fix systems
and found the root shell had been changed to csh.
I've seen enough weirdness in bash that it's not good to put it in
for root. That being said I've put in the ksh as root shell with
no problems at all, and all the advantages. But that is just a
data point of 1 person on several systems.
Bill
--
Bill Vermillion - bv @ wjv . com
And add /usr/local/bin/bash to /etc/shells
But I still hold that it's not adviseable to use bash as root's login shell
or even as a temporary interactive shell in some cases. I'd say someone in
some position of knowledge agrees with me. Witness that even the latest
gnutools that include all kinds of nice gnu stuff, still does not include a
/usr/gnu/bin/bash. I think it's ok to have it on the system so that odd
scripts that just assume all unixes have bash have some chance of running
without needing to be hand-edited.
On any 5.0.6 or later box, if you just set root's login shell to /bin/ksh in
/etc/passwd, (and make sure your VISUAL or EDITOR environment variable is
unset or at least not set to "vi") you will find the shell acts enough like
bash for most people.
You can even back-port this behaviour to earlier boxes by just copying the
.kshrc and .profile from a 5.0.6 or later box. (tab-completion won't work on
the earlier boxes unfortunately)
most programming syntax that anyone actually uses day to day works the same
in ksh as bash, and the .kshrc & .profile provides most of the same
interactive candy (up/down arrows browse command history, left/right arrows
allow command editing, tab-completion, etc...)
There are a couple things that might get used a lot by some prople that
don't work. Ctrl-V is an example.
Unless you have a very specific and non-trivial reason to use bash, I do not
recommend making root's shell bash. The system has been using sh and ksh for
20 years and their behaviour has not changed much the whole time. bash is
pretty close but not the same and while most scripts have been updated over
the last year or two (or three) so that they specify a shell at the top
rather than trusting the the current interactive shell or roots defined
login shell is the same /bin/sh it always was, it's still just plain not a
safe assumption that throwing in this deviant element into the works will
not cause any problem, anywhere, ever.
If bash shows up in a stock install, or at least in gnutools, and in
/etc/shells (without putting it there myself), and in mkuser/bash
THEN I'll consider it OK, and when (not if) things break, I'll complain to
SCO.
You really shouldn't even use ksh as roots /etc/passwd login shell, but at
least that's extremely well tested by now.
--
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
> -----Original Message-----
> From: listm...@xenitec.on.ca
> [mailto:listm...@xenitec.on.ca] On Behalf Of David P. Lurie
> Sent: Monday, February 23, 2004 9:19 PM
> To: distri...@xenitec.on.ca
> Subject: bash as login shell
>
>
> 5.0.7 with all update and maintenance packs, security patches
>
> I would like to change the login shell to bash for both root
> and my regular account, but no explicit choice for bash
> occurs in the drop down list on Account Manager.
If I remember correctly, changing root's login shell is a bad thing. There
are startup scripts and such that rely on root's login shell being the
bourne shell. (At least they used to, I'm not sure if this is still true.)
If I want a different shell for root, I usually just include that as the
last line of root's .profile. I know it's not the "right" way to do it, but
it hasn't caused me any problems...
Fabio
I infer, Brian, that you have not installed an Update Pack on 5.0.7,
otherwise you could be using /usr/bin/bash, /usr/bin/tcsh, or
/usr/bin/zsh.
For many years, I have left /bin/sh as root's shell, but I far prefer to
use tcsh for interactive sessions. Here are the first two lines of my
/etc/passwd file:
root:x:0:3:JPR-root:/:
boss:x:0:3:JPR-boss:/:/usr/bin/tcsh
(That used to be /usr/local/bin/tcsh on all systems -- including
Unix 3.2v4.x -- before the UP provided its own tcsh.)
One of my customers has left /bin/sh in place for root, but ends
/.profile with a call to /usr/local/bin/bash. This doesn't disturb any
cron programs or rc scripts.
--
JP
The mkuser scripts won't do that. I rolled my own Xsession-tcsh script.
--
JP
We use ksh for the root shell on all of our OSR boxes. Have been doing so
for many years without incident.
bkx
# grep root /etc/passwd
root:x:0:3:Jeff Hyman [root]:/:/bin/ksh
- Jeff Hyman