Since 4.2BSD, Berkeley UNIX systems have restricted
chsh
(or a command like it) to change your login shell
only to a shell that's listed in the file /etc/shells
.
That's partly a safety feature, like requiring you to type your old password
before you can change to a new one: it keeps other people from giving you a
strange login shell as a joke.
It's also for security - a way for the system administrator to give a list of
shells that are robust enough to run peoples' accounts.
The usual "approved" shells are the Bourne and C shells.
If you want to use another shell as your login shell and your system has
/etc/shells
, ask the system administrator to add your shell.
The shell will need to be stored in a secure system directory to make it
harder for system crackers to corrupt the shell.
If the system administrator won't approve your login shell, here's a
work-around.
It lets you log in with an approved shell, then automatically replace the
shell with whatever you want.
(For background, see article
51.9
.)
If your login shell isn't C shell, use
chsh
or a command like it
to change it to the C shell.
If your new shell will be bash
, you can skip this step.
Otherwise:
In your home directory, make a
hard or symbolic link (18.4
)
directory,
to your shell.
Use a name starting with a minus sign (-
);
this makes the shell
act like a login shell (51.9
)
.
For example, to make a symbolic link in your home directory named
-ksh
to the shell /usr/local/bin/ksh
, type this command:
./
|
% ln -s /usr/local/bin/ksh ./-ksh
|
Add lines to the top of the
.cshrc
(2.2
)
file that replace the csh
process with your login shell.
(The
exec
(45.7
)
command replaces a process.)
If you use a Bourne-type shell
that reads the .profile
file at login time,
use lines like these:
TERM
su
if
$?
|
# OVERRIDE DEFAULT LOGIN C SHELL TO USE ksh.
setenv SHELL /usr/local/bin/ksh
# IF $TERM SET (BY login OR rlogin), START LOGIN SHELL.
# UNFORTUNATELY, THIS MAKES su USE A LOGIN SHELL TOO.
if ($?TERM) then
cd
exec -ksh # USE "LOGIN SHELL" SYMLINK IN $HOME
else
exec $SHELL
endif
echo "******** WARNING: exec ksh FAILED ********"
|
If your new login shell will be bash
, you can replace the line
exec -ksh
above with:
exec $SHELL -login
because bash
has a -login
option that tells it to act
like a login shell.
Simple, eh?
If your new login shell is a csh
-type shell that also reads
.cshrc
, you need to add a test to .cshrc
that prevents an
infinite loop.
This test uses the SH_EXECD
environment variable (6.1
)
as a flag:
# OVERRIDE DEFAULT LOGIN C SHELL TO USE tcsh.
if (! $?SH_EXECD) then
setenv SH_EXECD yes
setenv SHELL /usr/local/bin/tcsh
# IF $TERM SET (BY login OR rlogin), START LOGIN SHELL.
# USE switch, NOT if, DUE TO csh BUG WITH IMBEDDED else.
# UNFORTUNATELY, THIS MAKES su USE A LOGIN SHELL TOO.
switch ($?TERM)
case 1:
cd
exec -tcsh # USE "LOGIN SHELL" SYMLINK IN $HOME
breaksw
default:
exec $SHELL # USE NON-LOGIN SHELL
breaksw
endsw
echo "******** WARNING: exec tcsh FAILED ********"
endif
The C shell may not find your new shell (-ksh
or -tcsh
)
unless you have the current directory (.
) in your
search path (8.7
)
(put it at the end of your path!).
You may also be able to use an
absolute pathname (14.2
)
to the new shell, but that could hide the leading
minus sign (-
) and the shell might not act like a login shell.
Is there a chance that your new shell might be missing some day?
For instance, is it on a network filesystem that might be unavailable?
Then it's a good idea to wrap the new code above with a test:
-e
|
if (-e my-new-shell
) then
...code to start new shell...
else
echo "*** WARNING: new shell failed. Using csh. ***"
endif
|
Test your new setup:
Try commands that start
subshells (38.4
)
,
like
su
, rsh
, and so on (2.7
)
,
to be sure that they start your new shell.
Put the csh
command
set echo
(8.17
)
at the top of your .cshrc
file to be sure your commands there are working.
Type a command that will work only in your new shell (not in a C shell).
Use the
ps
(38.5
)
command
ps
$$
(on System V, ps
-f
-p
$$
)
to look at your new shell process ($$
is your shell's
process ID number (38.3
)
).
Before you log out of this shell, try logging in from somewhere else (2.4
)
to be sure your new shell startup files work.
You're set to go.
If your login shell isn't listed in /etc/shells
, the
ftp
(52.7
)
program
(actually, the ftpd
daemon (1.14
)
)
may refuse to transfer files to your account.
That's partly to stop ftp
access to your system through special accounts
that don't have passwords, like sync
, who
, finger
, and so on.
If you use the workaround steps above, though, that shouldn't be a problem;
you'll have an approved shell listed in /etc/passwd
and ftp
usually doesn't run your login shell, anyway.
|
|