on Tue, Nov 20, 2001 at 07:44:37PM -0500, Brenda J. Butler (bjb@achilles.net) wrote:
>
> I hit reply too soon, I meant to copy this to the list. Here it is.
>
>
> --
> bjb@achilles.net
> Consider registering as a bone marrow donor
> http://www.bloodservices.ca/english/ubmdr
> From: "Brenda J. Butler" <bjb>
> Date: Sun, 18 Nov 2001 14:14:22 -0500
> To: Ian Balchin <fables@imaginet.co.za>
> User-Agent: Mutt/1.0.1i
> Subject: Re: Newbie comments & queries
>
> On Thu, Nov 15, 2001 at 09:21:35PM +0200, Ian Balchin wrote:
> > Hi, all,
> >
> > Brenda told me not to go into root so I have tried to obey her
> > commands. I did go into root & change the permissions of the various
> > files so that I can work with them logged in as 'ian'. Have copied
> > them all as .old so can restore to original state if the mess gets
> > out of hand.
RCS can also be handy for config files. This is a version control
system. I've stopped using it on my config files (I do back up my
system at least weekly), but you could do:
$ cd /etc
# Create the archive directory
$ mkdir RCS
# Initialize files
$ rcs -i $( find . -type f -maxdepth 1 )
# Check in all files, unlocked.
$ ci -u $( find . -type f -maxdepth 1 )
# To work on a file:
$ co -l resolv.conf
$ vi resolv.conf
...you probably *don't* want to follow what I just outlined above as RCS
changes file permissions. Some files under /etc are meant to be updated
(e.g.: /etc/mtab) by system processes as state changes.
> That's ok: spend most of your time as ian, and only become root when
> you have to (just as you've done above). Then if you make a mistake,
> you will most likely do it as ian, and the repercussions will be much
> less. You will only (for instance) wipe out all ian's files, instead
> of all the files on the system. It would be a hassle, but at least you
> wouldn't have to re-install the whole system and start from scratch.
Good advice.
> > I have got a coloured prompt now. Blue for ian, red for root.
>
> Hmm, not sure I recommend coloring your root prompt. The root prompt
> is already different: it has a # instead of a $ or %.
Frankly, I prefer the '$' prompt. My root prompts are highlighted, I
also have a keybinding for root terminals under WindowMaker with a
different background color as another visual hint.
> Try not to customize your root account too much.
I disagree, though I'll weasel a bit.
Make your environment comfortable and effective _for you_, *while* not
compromising system security or integrity in the process. This is a
learning process.
> The reason is that if you break your user login files or otherwise
> mess up the system, you will have to log in as root to fix things.
However, when you log in as root in such cases (usually in single-user
mode), root starts uninitialized. In single-user mode, root's home
directory is /, not /root, and there are minimal shell initializations.
So most root environment tweaks won't be effected by default.
> Make the root account dependent on as few extras as possible, and you
> will be able to log in to it even though many things are broken. From
> there you will be able to repair the system. The root account is both
> the "super-user, I can do anything, bwa-ha-ha-ha" and the emergency
> tool kit for desperate situations.
There's some truth to this. Don't gum up root to the point that it
bites you for doing so. But realize that when you're invoking root as
an emergency "I need to fix the system" account, it already minimizes
the level of modification on the account.
<PATH discussion -- I agree with Brenda's diagnosis>
> > Will be off the list for a few days, but really appreciate the help
> > so far, even if your email appears unanswered all are read,
> > digested, and appreciated
>
> No problem. I also attend to the list in a bursty way. (am away for
> a couple of days at a time)
I'm also enjoying this. Ian's a quick study. And it's helpful to see
problems from the (able) newbie's perspective. Fun, even. And I
(re)cover ground I don't go over frequently.
> By the way, wrt bashrc and profile files, I might have said that the
> shell sources both the $HOME/.bashrc and the $HOME/.bash_profile file.
> I guess I was wrong, it does one or the other, and you do have to
> source the .bashrc from the .bash_profile to get the .bashrc stuff to
> execute in your login shell.
>
> I was assuming that bash and cshrc are more alike than they really
> are. Sorry for the confusion.
RTFM ;-)
Seriously, I flip through the bash manpage periodically, I don't have it
memorized. As I just wrote above, instructing the newbies means
revisiting docs and finding out how things work.
From the bash man page:
The following paragraphs describe how bash executes its startup
files. If any of the files exist but cannot be read, bash reports
an error. Tildes are expanded in file names as described below
under Tilde Expansion in the EXPANSION section.
When bash is invoked as an interactive login shell, or as a
non-interactive shell with the --login option, it first reads and
executes commands from the file /etc/profile, if that file exists.
After reading that file, it looks for ~/.bash_profile,
~/.bash_login, and ~/.profile, in that order, and reads and executes
commands from the first one that exists and is readable. The
--noprofile option may be used when the shell is started to inhibit
this behav ior.
Note that this behavior is *far* superior to that of many Unix shells in
which *either* the system *or* the user's profile scripts are sourced,
but not both. Bash allows setting systemwide profiles while allowing
users to modify their configurations as well. The hoops I've jumped
through in the past....
When a login shell exits, bash reads and executes commands from the
file ~/.bash_logout, if it exists.
A good place to put a "/usr/bin/clear" command.
When an interactive shell that is not a login shell is started, bash
reads and executes commands from ~/.bashrc, if that file exists.
This may be inhibited by using the --norc option. The --rcfile file
option will force bash to read and execute commands from file
instead of ~/.bashrc.
When bash is started non-interactively, to run a shell script, for
example, it looks for the variable BASH_ENV in the environment,
expands its value if it appears there, and uses the expanded value
as the name of a file to read and execute. Bash behaves as if the
following command were executed:
if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
but the value of the PATH variable is not used to search for the
file name.
[Continued discussion when invoked as 'sh' or with POSIX flags set.]
Peace.
--
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What part of "Gestalt" don't you understand? Home of the brave
http://gestalt-system.sourceforge.net/ Land of the free
Free Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org
Geek for Hire http://kmself.home.netcom.com/resume.html
Attachment:
pgpguvxaQkTSr.pgp
Description: PGP signature