need to confirm I can change root's login shell to something other than /sbin/sh
troycamp...@gmail.com
change root's login shell to something other
than /sbin/sh:
http://www.blastwave.org/jir/blastwave.fam
Does anyone have a link to a Sun doc that says the same thing?
Best regards,
Troy
tunla
wrote:
I usually do this instead:
------- < /.profile > ---------
if [ -x /usr/bin/ksh ] ; then
exec /usr/bin/ksh
fi
------------------------------------
Then you know that the file system containing the shell and
hopefully
its shared objects are mounted and avaliable , before you saw off
the limb you are sitting on
However with the advent of ZFS and the root pool this is probably
irrellevant. as all binaries and all libraries is in the root pool
anyway.
//Lars
YTC#1
JFDI
Its fine, not problem.
I think it was Casper who once said that if changing the shell (since
S10) breaks the system boot then it is a bug.
If a (legacy) start script does not have #/bin/sh and fails to run as
ksh/bash, then I think the script author needs knee-capping.
--
Bruce Porter
"The internet is a huge and diverse community and not every one is friendly"
http://www.ytc1.co.uk
There *is* an alternative! http://www.openoffice.org/
Andrew Gabriel
No.
You can of course change it, but when you call Sun to say something
doesn't work because of what you did, they'll tell you to change it
back.
Whilst relatively harmless (compared with earlier releases), I tend
to find customers who do this go on to tinker with all sorts of other
things, until they break the system. Recovery from whatever eventually
broke can then be seriously hampered by all the apparently harmless (at
the time) fiddling that preceded it, but collectively it resulted in a
major system outage.
--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
Colin B.
It's relatively safe. It's not necessary.
If you have to change root's login shell, you're using root as a login
account too much. In other words, if this is how you admin a system,
you're doing it wrong.
http://xkcd.com/463/
My general rule for changing a vendor's defaults is that if you can't
explain clearly and precisely why changing them IS safe, you shouldn't
do it.
Colin
Colin B.
> t...@studioc.org wrote:
>> At the very bottom of the following page the author says it's safe to
>> change root's login shell to something other
>> than /sbin/sh:
>>
>> http://www.blastwave.org/jir/blastwave.fam
>>
>> Does anyone have a link to a Sun doc that says the same thing?
>
> JFDI
>
> Its fine, not problem.
>
> I think it was Casper who once said that if changing the shell (since
> S10) breaks the system boot then it is a bug.
>
> If a (legacy) start script does not have #/bin/sh and fails to run as
> ksh/bash, then I think the script author needs knee-capping.
Don't lump ksh and bash into the same category. The former is a 100%
functional superset of /sbin/sh. The latter is not.
Richard B. Gilbert
Find a better author! It's not a Sun specific issue.
If you want to use a different shell, you probably should not be working
as root!
Drazen Kacar
> If you have to change root's login shell, you're using root as a login
> account too much. In other words, if this is how you admin a system,
> you're doing it wrong.
How do you admin a system, if not with root account?
--
.-. .-. Yes, I am an agent of Satan, but my duties are largely
(_ \ / _) ceremonial.
|
| da...@fly.srk.fer.hr
Ian Collins
> Colin B. wrote:
>
>> If you have to change root's login shell, you're using root as a login
>> account too much. In other words, if this is how you admin a system,
>> you're doing it wrong.
>
> How do you admin a system, if not with root account?
rbac.
Or if you do use root, just run your preferred shell when you login.
--
Ian Collins
Andreas F. Borchert
You can have more than one root account, i.e. an account with uid = 0.
And you are perfectly free to set up alternative root accounts with
different home directories and shells. Just make sure that "root"
precedes all alternative root logins in the passwd file.
Andreas.
YTC#1
> t...@studioc.org <troycamp...@gmail.com> wrote:
>> At the very bottom of the following page the author says it's safe to
>> change root's login shell to something other
>> than /sbin/sh:
>>
>> http://www.blastwave.org/jir/blastwave.fam
>>
>> Does anyone have a link to a Sun doc that says the same thing?
>
> It's relatively safe. It's not necessary.
>
> If you have to change root's login shell, you're using root as a login
and now moving to the real world ..........
Its what happens, its how companies operate, I preach the not using it,
but many places I visit use it as a matter of course handing out root
password to everyone.
> account too much. In other words, if this is how you admin a system,
> you're doing it wrong.
> http://xkcd.com/463/
<G>
>
> My general rule for changing a vendor's defaults is that if you can't
> explain clearly and precisely why changing them IS safe, you shouldn't
> do it.
Personally, if the vendor can't explain why not to do it I find that
just as worrying. (saying it *may* break something is not a reason).
Next people will be saying that when hardening a system JASS should not
change roots home dir to /root.
--
Bruce Porter
XJR1300SP, XJ900F, GSX750W, GSX250, Pegaso 650 Trail
POTM#1(KoTL), WUSS#1 , YTC#1(bar), OSOS#2(KoTL) , DS#3 , IbW#18 ,Apostle#8
Richard B. Gilbert
> Colin B. wrote:
>
>> If you have to change root's login shell, you're using root as a login
>> account too much. In other words, if this is how you admin a system,
>> you're doing it wrong.
>
> How do you admin a system, if not with root account?
>
Many people manage to administer a system using sh!
A system administer adds, removes and modifies user accounts. He tries
to ensure that users don't gobble up all the available disk space. He
makes backups.
Non of this requires anything that sh cannot do.
If, while working as root, you need something that sh can't do, you can
always invoke the shell of your choice.
Are you, perhaps, using root too much? Keep in mind that a slip of the
finger, or the mind, while working as root can have disastrous effects!
Drazen Kacar
> Drazen Kacar wrote:
> > How do you admin a system, if not with root account?
>
> Many people manage to administer a system using sh!
>
> A system administer adds, removes and modifies user accounts. He tries
> to ensure that users don't gobble up all the available disk space. He
> makes backups.
>
> Non of this requires anything that sh cannot do.
Certainly. Just like all the programs I'm using don't require anything
that can't be programmed in Fortran. And yet they are not writen in
Fortran.
> If, while working as root, you need something that sh can't do, you can
> always invoke the shell of your choice.
I know. I wasn't advocating changing the root's shell.
> Are you, perhaps, using root too much?
Most definitely. There are too many systems where I don't do anything
else.
Colin B.
> Colin B. wrote:
>
>> If you have to change root's login shell, you're using root as a login
>> account too much. In other words, if this is how you admin a system,
>> you're doing it wrong.
>
> How do you admin a system, if not with root account?
Well, I said you're using root *as a login account* too much.
sudo is good. So is RBAC, once you've set it up. Using sh for short
jaunts into rootland is usually sufficient. Invoking your shell of
choice from the command line is fine, now and then. I still say that
if you have to change root's login shell, you're using it too often.
Colin
Drazen Kacar
> sudo is good. So is RBAC, once you've set it up. Using sh for short
> jaunts into rootland is usually sufficient.
I want shell completion. I could manage without it, of course, but I don't
want to. And other shell constructs which make life more convenient.
> Invoking your shell of
> choice from the command line is fine, now and then. I still say that
> if you have to change root's login shell, you're using it too often.
I never changed root's shell. That's completely inconsiderate of other
people who'd like different shell.
Colin B.
> Colin B. wrote:
(snip)
>> Invoking your shell of
>> choice from the command line is fine, now and then. I still say that
>> if you have to change root's login shell, you're using it too often.
>
> I never changed root's shell. That's completely inconsiderate of other
> people who'd like different shell.
Ah, and that was the original question in this thread. That's all I was
arguing against.
Colin
YTC#1
Sanity check time
Guess what the default shell for OpenSolaris root user is ?
Granted you never log in directly, *but* if it was busted, so would S10
be by now as so much fed back.
The "should I change root shell" question is over.
Users/admins can do what they want with it, its their system not Suns.
If it is a prod system, they will have tested it 1st... won't they ?
--
Bruce Porter
troycamp...@gmail.com
Thanks Lars,
This is a good safety check particularly for older systems.
Regards,
Troy
troycamp...@gmail.com
> Colin B. wrote:
> > t...@studioc.org <troycampbells...@gmail.com> wrote:
> >> At the very bottom of the following page the author says it's safe to
> >> change root's login shell to something other
> >> than /sbin/sh:
>
> >>http://www.blastwave.org/jir/blastwave.fam
>
> >> Does anyone have a link to a Sun doc that says the same thing?
>
> > It's relatively safe. It's not necessary.
>
> > If you have to change root's login shell, you're using root as a login
>
> and now moving to the real world ..........
> Its what happens, its how companies operate, I preach the not using it,
> but many places I visit use it as a matter of course handing out root
> password to everyone.
...or perhaps handing out root to a small number of admins for a large
number of systems.
Regarding some of the other posts I appreciate their concern about
"using root too much".
I completely agree on this point and could add discussion regarding
that point.
I haven't seen any posts yet that would simply confirm via Sun
documentation
that using say "/bin/bash" or "/bin/ksh" would be "ok" or might
present certain technical
issues and basically just confirm the blastwave information when using
Solaris 10 or not.
Thanks,
Troy
troycamp...@gmail.com
> >> Colin B. wrote:
>
> >>> If you have to change root's login shell, you're using root as a login
> >>> account too much. In other words, if this is how you admin a system,
> >>> you're doing it wrong.
> >> How do you admin a system, if not with root account?
>
> > Well, I said you're using root *as a login account* too much.
>
> > sudo is good. So is RBAC, once you've set it up. Using sh for short
> > jaunts into rootland is usually sufficient. Invoking your shell of
> > choice from the command line is fine, now and then. I still say that
> > if you have to change root's login shell, you're using it too often.
>
> Sanity check time
> Guess what the default shell for OpenSolaris root user is ?
yes, thank you.../bin/bash.
>
> Granted you never log in directly, *but* if it was busted, so would S10
> be by now as so much fed back.
>
> The "should I change root shell" question is over.
>
> Users/admins can do what they want with it, its their system not Suns.
Also for consistency sake one would like the same shell in
a heterogenious environment?
> If it is a prod system, they will have tested it 1st... won't they ?
>
> --
> Bruce Porter
>
> "The internet is a huge and diverse community and not every one is friendly"http://www.ytc1.co.uk
> There *is* an alternative!http://www.openoffice.org/
Thanks,
Troy
Ian Collins
>
> Regarding some of the other posts I appreciate their concern about
> "using root too much".
> I completely agree on this point and could add discussion regarding
> that point.
> I haven't seen any posts yet that would simply confirm via Sun
> documentation
> that using say "/bin/bash" or "/bin/ksh" would be "ok" or might
> present certain technical
> issues and basically just confirm the blastwave information when using
> Solaris 10 or not.
What's wrong with simply executing your preferred shell after login?
--
Ian Collins
Cydrome Leader
> At the very bottom of the following page the author says it's safe to
> change root's login shell to something other
> than /sbin/sh:
>
> http://www.blastwave.org/jir/blastwave.fam
blastwave is the last place to look for good tips on anything.
Anyways, you can change the shell for root, but it's not clever or
considered a good thing to do. The less weird changes you make, the better
for you, for upgrades, for recovery situations and the next person to
manage a system.
yes /bin/sh sucks as an interactive shell, just run bash after logging in,
if you have to, it's not a big deal- you can even have a login script do
this for you.
Juergen Nickelsen
> Don't lump ksh and bash into the same category. The former is a 100%
> functional superset of /sbin/sh. The latter is not.
That's interesting, particularly as I have always held some
unspecific and unverified reservations against bash as a replacement
for /bin/sh in scripts. (I value it highly for interactive use,
though.)
Can you give examples where bash is not /bin/sh compatible?
--
The epithet you're looking for is "militant agnostic," and the credo
is "No, I don't know, and NEITHER DO YOU, DAMMIT!"
-- Kevin Martin
Colin B.
> "Colin B." <cbi...@somewhereelse.shaw.ca> writes:
>
>> Don't lump ksh and bash into the same category. The former is a 100%
>> functional superset of /sbin/sh. The latter is not.
>
> That's interesting, particularly as I have always held some
> unspecific and unverified reservations against bash as a replacement
> for /bin/sh in scripts. (I value it highly for interactive use,
> though.)
>
> Can you give examples where bash is not /bin/sh compatible?
#echo "hello \n"
bash's built-in echo statement does not understand back-slashed escape
characters. sh does, ksh does, /usr/bin/echo does, bash and csh do not.
Incidentally, bash 3.25 *in sh compatibility mode*, even when invoked
*as /bin/sh*, STILL does not interpret backslash escapes. I just tried
it on one of our Linux systems with the same results.
This is the standard cue for people to jump in about Posix-compliance
and /[s]bin/sh variations and so forth, but the bottom line is that bash
doesn't do this the same was as sh.
Colin
Chris Ridd
Ctrl-C also works differently in bash and POSIX shells.
# sleep 10; echo keeping going
Hit Ctrl-C. Bash will echo "keeping going", POSIX shells will not.
--
Chris
Oscar del Rio
> Can you give examples where bash is not /bin/sh compatible?
/bin/sh:
# echo "Sleeping before rebooting"; sleep 120; echo reboot
Sleeping before rebooting
^C
#
/bin/bash:
# echo "Sleeping before rebooting"; sleep 120; echo reboot
Sleeping before rebooting
^C
reboot
Dare to try without the second "echo"? ;-)
ITguy
> change root's login shell to something other
> than /sbin/sh:
>
> http://www.blastwave.org/jir/blastwave.fam
>
I don't usually change the root shell on servers, but I have on many
workstations. It's never caused a problem on a good number of
machines. Now that I'm thinking about it, I may just start doing it
on servers as well. There's nothing magical about /sbin/sh, or
keeping "default" values. Who doesn't at least create a /root
directory for the root user instead of just leaving root's files
sprawled in "/"?
The only time I've ever seen an alternate shell cause a problem was
years ago when it was common practice to have separate slices for /
and /usr. If there was an issue mounting the /usr slice at boot, you
couldn't log in to fix it without your shell. I typically only use
separate slices for /, /var, and app/user data, so this isn't an
issue. As mentioned, it's even less an issue now with ZFS roots.
Just my $.02
Richard B. Gilbert
What do you need to do as root that you can't do using sh?
There will always be another shell that does something that sh can't or
won't do but so what? You shouldn't need to do anything, as root, that
sh can't do! I very seldom used root unless I was adding or removing a
user or if I needed to fsck a file system.
Casper H.S. Dik
>Ctrl-C also works differently in bash and POSIX shells.
># sleep 10; echo keeping going
>Hit Ctrl-C. Bash will echo "keeping going", POSIX shells will not.
It also makes it unusable as "$SHELL" in makefile; sub shell will get
their own process group and that is wrong. (Only an interactive
shell should mess with process groups)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Juergen Nickelsen
>> Can you give examples where bash is not /bin/sh compatible?
>
> #echo "hello \n"
>
> bash's built-in echo statement does not understand back-slashed escape
> characters. sh does, ksh does, /usr/bin/echo does, bash and csh do not.
I see. I'd not have expected a /bin/sh do that, but even the Solaris
/bin/sh does it. (And it doesn't do a lot to begin with.) Ash does
not.
Maybe the reason bash and ash don't do it is that it was a SysVism
originally, and AFAIK there have been reservations in the BSD camp
(to which the GNU camp has always been closer) to adopt SysVisms in
general.
But what I find particularly wierd is that ksh93 built under FreeBSD
(5.x, at least) does not do echo "\n" either. *And* not echo "\c",
which is the even bigger nuisance.
--
New processes are created by other processes, just like new humans.
New humans are created by other humans, of course, not by processes.
-- Unix System Administration Handbook
Juergen Nickelsen
> /bin/bash:
> # echo "Sleeping before rebooting"; sleep 120; echo reboot
> Sleeping before rebooting
> ^C
> reboot
>
> Dare to try without the second "echo"? ;-)
Nice example. :-/
--
Var48657=Nur GIF-, png-, Jpg- und JPEG-Bilder k�nnen Antriebskraft. �berpr�fen Sie bitte das Bild, das Sie vorgew�hlt haben.
Colin B.
> "Colin B." <cbi...@somewhereelse.shaw.ca> writes:
>
>>> Can you give examples where bash is not /bin/sh compatible?
>>
>> #echo "hello \n"
>>
>> bash's built-in echo statement does not understand back-slashed escape
>> characters. sh does, ksh does, /usr/bin/echo does, bash and csh do not.
>
> I see. I'd not have expected a /bin/sh do that, but even the Solaris
> /bin/sh does it. (And it doesn't do a lot to begin with.) Ash does
> not.
For the record, zsh does as well.
> Maybe the reason bash and ash don't do it is that it was a SysVism
> originally, and AFAIK there have been reservations in the BSD camp
> (to which the GNU camp has always been closer) to adopt SysVisms in
> general.
Makes sense, but the distinction between BSD and SysV is so old and
hoary that it hardly has any relevance anymore.
> But what I find particularly wierd is that ksh93 built under FreeBSD
> (5.x, at least) does not do echo "\n" either. *And* not echo "\c",
> which is the even bigger nuisance.
Interesting. ksh93 in Solaris (as /usr/dt/bin/dtksh) behaves the same
as /bin/sh.
Colin
Richard B. Gilbert
> Juergen Nickelsen <n...@jnickelsen.de> wrote:
>> "Colin B." <cbi...@somewhereelse.shaw.ca> writes:
>>
>>>> Can you give examples where bash is not /bin/sh compatible?
>>> #echo "hello \n"
>>>
>>> bash's built-in echo statement does not understand back-slashed escape
>>> characters. sh does, ksh does, /usr/bin/echo does, bash and csh do not.
>> I see. I'd not have expected a /bin/sh do that, but even the Solaris
>> /bin/sh does it. (And it doesn't do a lot to begin with.) Ash does
>> not.
>
> For the record, zsh does as well.
>
>> Maybe the reason bash and ash don't do it is that it was a SysVism
>> originally, and AFAIK there have been reservations in the BSD camp
>> (to which the GNU camp has always been closer) to adopt SysVisms in
>> general.
>
> Makes sense, but the distinction between BSD and SysV is so old and
> hoary that it hardly has any relevance anymore.
>
Irrelevant it may be but both sides have partisans who enjoy fighting
about it!
The "shell wars" make me glad that DEC never documented the steps
necessary to enter supervisor mode in the VAX architecture using the VMS
O/S. I think there is ONE third party shell for VMS. I believe it was
the guys at TGV who reverse engineered it.
Anyone can write a Unix shell and nearly everyone did! The resulting
"Tower of Bable" is not something I want any part of! I once counted
ten or so shells in more or less common use!
Sven Mascheck
> Don't lump ksh and bash into the same category. The former is a 100%
> functional superset of /sbin/sh. The latter is not.
Academic reply: It's not 100%.
The most famous (among several): ^ is only equivalent to | in Bourne shells,
--
http://www.in-ulm.de/~mascheck/bourne/common.html
Colin B.
> Colin B. wrote:
>
>> Don't lump ksh and bash into the same category. The former is a 100%
>> functional superset of /sbin/sh. The latter is not.
>
> Academic reply: It's not 100%.
> The most famous (among several): ^ is only equivalent to | in Bourne shells,
Well, I stand corrected! I didn't actually realise that ^ was still used
in that context in /bin/sh.
Colin
Chris Ridd
It is especially handy when the keyboard mapping's wrong, making it
impossible to type a '|'. (eg (some?) UK keyboards when using US
mappings.)
--
Chris
Sven Mascheck
> "Colin B." said:
>> Sven Mascheck wrote:
>> I didn't actually realise that ^ was still used in that context in /bin/sh.
For some reason, Bourne had not documented this backwards-compatibility
feature for his shell. Some vendors added it, but Sun did not.
It don't know scripts using it these days.
But System III even had a script /etc/wall, containing both:
who^sed -e '[..build a commandline..]' | sh
> It is especially handy when the keyboard mapping's wrong, making it
> impossible to type a '|'.
On the historical TTYs of that time (^ and | were introduced with the
Thompson shell on the 4th Edition, about '73) this seems to have been
the very reason (according to D.Ritchie), ^ was much easier to type
than | (e.g. by an escape like \!)
Cydrome Leader
>> At the very bottom of the following page the author says it's safe to
>> change root's login shell to something other
>> than /sbin/sh:
>>
>> http://www.blastwave.org/jir/blastwave.fam
>>
>> Does anyone have a link to a Sun doc that says the same thing?
>
> I don't usually change the root shell on servers, but I have on many
> workstations. It's never caused a problem on a good number of
> machines. Now that I'm thinking about it, I may just start doing it
> on servers as well. There's nothing magical about /sbin/sh, or
> keeping "default" values. Who doesn't at least create a /root
> directory for the root user instead of just leaving root's files
> sprawled in "/"?
This is a really good tip.
I've forgotten to do this on solaris machines before and it make a huge
mess. Just make sure /root is inside / itself and it won't backfire in
anyway.
Canuck57
> At the very bottom of the following page the author says it's safe to
> change root's login shell to something other
> than /sbin/sh:
>
> http://www.blastwave.org/jir/blastwave.fam
>
> Does anyone have a link to a Sun doc that says the same thing?
>
> Troy
What I would consider that was not mentioned is to copy the shell you
want to /sbin.
For example:
cp /usr/bin/ksh /sbin
Then set the root shell to /sbin/ksh
I do this for so if your running a patch cluster and /usr/bin/ksh is
being replaced you don't get kicked out of your shell.
Also, once /root is chmod 0700 rember some thinks like patch clusters
need to be other readable.
Sven Mascheck
> For some reason, Bourne had not documented this backwards-compatibility
> feature for his shell. Some vendors added it, but Sun did not.
PS: added what: a note to the manpage
David Combs
Richard B. Gilbert <rgilb...@comcast.net> wrote:
>Colin B. wrote:
>> Juergen Nickelsen <n...@jnickelsen.de> wrote:
>>> "Colin B." <cbi...@somewhereelse.shaw.ca> writes:
>>>
>>>>> Can you give examples where bash is not /bin/sh compatible?
>>>> #echo "hello \n"
>>>>
>>>> bash's built-in echo statement does not understand back-slashed escape
>>>> characters. sh does, ksh does, /usr/bin/echo does, bash and csh do not.
>>> I see. I'd not have expected a /bin/sh do that, but even the Solaris
>>> /bin/sh does it. (And it doesn't do a lot to begin with.) Ash does
>>> not.
>>
>> For the record, zsh does as well.
>>
I thought that sun always (or *long* ago, anyway) had
csh as the default "interactive" shell, meaning I assume
that tcsh would also be ok for that.
What you guys are talking about is for writing scripts,
which basically exempts csh/tcsh from discussion (correct?).
Bash is promoted for scripts as well as interactive, right,
since that's the default for linux, cygwin, MIT/rms etc ...?
Now these yet other shells (that I know nothing about) like
zfs, etc -- they're also promoted for script-writing too,
not just interactive use?
(Again, csh/tcsh are promoted for anything BUT script-writing,
correct?)
Just making sure my understandings are correct.
Thanks!
David
Richard B. Gilbert
ZFS is a file system not a shell!
Anyone can write a shell and nearly everyone did. There are at least
ten shells in more or less common use. ISTR that there is a "zsh" but
it is not related to ZFS!
<snip>
David Combs
Well, I guess I've got ZFS on my mind lately -- and how!
As I've said before, my hp-1200 laserjet has been acting
like a pretty good heater these days, what with all the
ZFS stuff I've been finding and printing.
OT: one of the best docs on it is maybe that 1000+page book,
"OpenSolaris Bible".
That ZFS is pretty darned cool, but there sure is a lot
to learn about it, and apparently a fair number of ways
to screw up, too.
David
David Combs
>> Colin B. wrote:
>>
>>> If you have to change root's login shell, you're using root as a login
>>> account too much. In other words, if this is how you admin a system,
>>> you're doing it wrong.
>>
>> How do you admin a system, if not with root account?
>>
>
>
Well, I always switch to tcsh: I find it safer, actually.
You know, alias rm to rm -i
Reuse prior arg via !$ -- avoid a retyping mis-key.
History also good help, looking back over prior commands.
But then I'm no real sysadmin -- just one by default; ain't no one else.
So I'm not doing much in root -- no networks, etc.
And, I'm using emacs, in *shell*: su -; suspend, etc. So it's
easy to look way back up above top of screen, grab stuff,
edit it, then execute it as tcsh command.
For the super-simple stuff I do, RBAC seems maybe overkill?
David
(the sole user of the machine)
David Combs
Andreas F. Borchert <comp.uni...@expires-on-2009-10-17.usenet.andreas-borchert.de> wrote:
>On 2009-10-08, t...@studioc.org <troycamp...@gmail.com> wrote:
>> At the very bottom of the following page the author says it's safe to
>> change root's login shell to something other
>> than /sbin/sh:
>>
>> http://www.blastwave.org/jir/blastwave.fam
>>
>> Does anyone have a link to a Sun doc that says the same thing?
>
>And you are perfectly free to set up alternative root accounts with
>different home directories and shells. Just make sure that "root"
>precedes all alternative root logins in the passwd file.
>
>Andreas.
And also change the prompt to say ROOT ROOT ROOT ROOT: (or something)
David
David Combs
>
>The only time I've ever seen an alternate shell cause a problem was
>years ago when it was common practice to have separate slices for /
>and /usr. If there was an issue mounting the /usr slice at boot, you
I mkdir a /PUT-ME-FIRST-ON-PATH dir, and into there
I'd copy eg tcsh, gnu egrep, and so on, so that when
I was down in single-user mode, those would still
be available. (Heck, I should have put an emacs there
too -- works just fine non-gui.)
David
David Combs
Really stupid question: How to make sure /root is inside / itself,
and then just to make it perfectly clear what NOT to do,
what would you do to make sure that /root is NOT within / itself?
Thanks!
David
David Combs
Maybe I have a could-be-fatal misunderstanding, but
I was of the impression that patches didn't go into
effect until you rebooted the machine.
At least not of something you already have running.
(Unless you exit it then rerun the same now-changed
program?)
(Anyway, how does "reconfiguration boot" relate to patching?)
Thanks!
David
Thanks!
David
Andrew Gabriel
dkc...@panix.com (David Combs) writes:
>
> I thought that sun always (or *long* ago, anyway) had
> csh as the default "interactive" shell, meaning I assume
You mean back in SunOS 3 days? ;-)
> that tcsh would also be ok for that.
>
> What you guys are talking about is for writing scripts,
> which basically exempts csh/tcsh from discussion (correct?).
>
> Bash is promoted for scripts as well as interactive, right,
> since that's the default for linux, cygwin, MIT/rms etc ...?
Bash is probably not a good scripting shell, due to being
non-standard in various areas.
ksh is probably the best choice, although I fall back to
[borne] sh for very simple scripts where no ksh-specific
features are required.
> Now these yet other shells (that I know nothing about) like
> zfs, etc -- they're also promoted for script-writing too,
> not just interactive use?
>
> (Again, csh/tcsh are promoted for anything BUT script-writing,
> correct?)
csh is also not good for scripting.
I've never used the same shell for both interactive use and
for scripting. I find the two tasks have quite different
requirements.
--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
Randal L. Schwartz
David> You know, alias rm to rm -i
Bad practice.
"alias del rm -i"
and learn to type "del".
Then, if you're accidentally on a machine without the alias, you
won't get burned badly. You'll just get "del not found".
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Claus Dragon
> >>>>> "David" == David Combs <dkco...@panix.com> writes:
>
> David> You know, alias rm to rm -i
>
> Bad practice.
>
> "alias del rm -i"
>
> and learn to type "del".
>
> Then, if you're accidentally on a machine without the alias, you
> won't get burned badly. You'll just get "del not found".
\rm -rfi will get you anywhere.
David Combs
When you need special features of ksh, you use ksh.
Well, for those (more complex) scripts, how about
perl (now standard on solaris?)?
David
Juergen Nickelsen
> When you need special features of ksh, you use ksh.
Or when you need features that are common with /bin/sh on other
systems but not on Solaris. And no, I am not speaking of Linux (only).
--
So, as the Podembitzer Rebbe told his congregation when he won the
lottery, "I will spend the rest of my life thanking HaShem -- and
chasing women in Las Vegas."