Howdy!  I've just got a few questions about setting up the unix shell.
        First, I currently possess just enough knowledge of Unix to get
myself in trouble.  Therefore, before I start trying to change things that
I'm unfamiliar with, I thought I'd ask........ (ooooo, what a concept)
        I'd like to set up the .cshrc and .login scripts, and then change to
using the C-Shell.  I understand the process of changing from BBS to the
C-shell as a default.  The question that never seemed to get answered
in any of the other threads about picking a shell is what commands are
NECESSARY, USEFUL, or USELESS in these two files?  I plan on spreading
my time pretty equally between mail, bbs, newsgroups, possibly a little
ftp, and therefore would like to keep from over optimizing my shell for
one specific task.
        One feature that I very strongly desire is to have my prompt while
in the shell display the current directory, much like the ms-dos command
'prompt $P$G' does.
        Thank you for the assistance.

                                Roger

129 responses total.

The .cshrc file is executed every time you start a C shell, both at login
and when you start it as a subshell (e.g. when you "shell out" from bbs).
It normally contains aliases, i.e. shorthand notations that you wish to
define for commonly used commands.

The .login file is executed only when you log in, not when you start a
subshell, and is executed *after* .cshrc.  It should contain any commands
that you wish to execute every time you log in, including commands that
set "environment variables" which tell applications your terminal type,
execution path, preferred editor, and possibly other things as well.

You can also create a .logout file that is executed when you log out.

Here's a sample .cshrc file that is a shortened version of the one I
used to use when csh was my login shell, with a couple of additions:
------
if ($?prompt) then
    set           history=200
    alias hi      history
    alias tset    '/usr/ucb/tset -s \!* >/tmp/ts.$$ ; source /tmp/ts.$$ ; rm
    /tmp/ts.$$' alias md      mkdir alias rd      rmdir alias dir     ls -l
    alias lf      ls -F alias sane    'stty cooked -cbreak echo erase "^H" kill
    "^U" intr "^C"' alias cd      'chdir \!* ; set prompt="$cwd \! % "'
endif
------
The 'tset' alias facilitates setting your terminal type in your .login
(see below), and the 'alias cd..' command puts your current directory
in your prompt, as well as the current command number (useful when you
invoke the shell history mechanism).

Here's a sample .login:
------
umask  22
set    path=($HOME/bin /usr/local/bin /usr/ucb /bin /usr/bin /usr/games .)
setenv MANPATH '  /usr/local/man:/usr/man'
setenv MAILREADER elm
setenv EDITOR     vi
setenv VISUAL     vi
setenv EXINIT     'source ~/.virc'
setenv NETHACKOPTIONS \
                'name:Brunhilde-V,dogname:Fjord,female,number_pad,nopickup'

stty   intr '^C' kill '^U' erase '^H'
tset   -m 'dialup:?vt102' -m 'su:?vt102' "$TERM"
mesg   y
cd     .
clear
------
The umask command determines the initial protection when you create files.
'22' means 'read & execute permission for all, write permission only for
owner'.

'setenv EXINIT ...' causes the vi editor to execute an initialization file
called .virc in my home directory every time it starts up.

The stty command sets my interrupt, line kill, and erase characters to my
preferences.

The tset command causes me to be prompted for my terminal type when I log
in, taking vt102 as the default if I just hit return.

'cd .' initializes my prompt to contain the current directory and command
number (see the cd alias in .cshrc).

I prefer to put environment variables in .cshrc, but that's mostly due
to using other environments (i.e., X11 with xdm) where .login may never
get run.

You may want to use tcsh instead of csh.  Tcsh is an enhanced version of
csh that, among other things, includes "prompt metacharacters" for stuff
like current working directory, hostname, etc.  You can look at my
.cshrc and .login for info on how you might use this.

I also like to make short, two-character environment variables for
commonly-referenced directories.  In my work, that includes things
like the UUCP directories.  This way I can type "tail $us/Log"
instead of "tail /usr/spool/uucp/Log".

Thanks for the tips.  At least I'll have a place to start now.

Hjelp!  I turned my messages off about a week ago ad now even though I changed
the input so my messages would be back on "(messages off)" appears when I 
finger my own handle.  shouldn't "mesg y" turn my messages back on?

Not immediately.  Your .login file is run only when you log in, so any
changes to it won't take effect until your next session.  Is it ok now?

This response has been erased.

I thikn it's working fine now...

How do I put commands into my .profile so that they execute when I log
in.  I'm thinking specifically of setting up some aliases so I can
shorten long commands that I am finding myself typing a lot lately?

 aliases go in the .cshrc file. 
if ($?prompt) then
    set           history=200
    alias j       jove
 alias callbook  telnet electra.cs.buffalo.edu 2000
alias hi      history
    alias d       du
    alias free    df
    alias c      cal
    alias pi      pico
    alias pm      pine
alias a bye
alias p bbs
alias l   lynx
    alias z       elm
    alias a       logout
    alias hi      history
    alias g       backgammon
    alias bye     logout
    alias p       bbs
    alias fo      fortune
alias sun         telnet paladine.hacks.arizona.edu
alias e       exit   
alias ch      change
unsetenv TERMCAP
set term=vt100
endif
 This is my file. enjoy.

ah, the first attempt.  Thank you Omni, I'm learning already!  However,
for me to use this solution I'd have to change my login shell to csh
and I'm a bit afraid to do that right now...Waitaminute...my default
shell is bbs, so ergo my login stuff is set for sh not csh, however, my 
default shell is csh (that's what I get if I type "shell" at picospan.
so, help me out here, If I CREATE a .cshrc with aliases in it, will that
get run when the csh is brought up from my shell pico command? or is .cshrs
I mean .cshrc only looked at when you log in, and then never again no 
matter what?

Every copy of csh always sources commands from .cshrc when it starts,
even subshells, even non-interactive shells.
If it is a login shell it follow that by sourcing .login

cool, so my idea in #10 will work then!  Boy this is scary, I'm beginning to 
understand this Unix stuff.  What exactly is the definition of "source"?  
I infer it means something like "read and act upon", but I'm wondering 
exactly how does one define it?

It takes the file in question as a list of csh commands to be executed -
a script, in other words.

"source" is like telling MS-DOS to run a batch (.bat) file, except the
Unix version of batch files is much more flexible.

In unix, if you give command "foo" and there is a file "foo" on your path,
it will execute  it.  If it is a shell script, this means it will start a 
subshell to take its command from foo. Thus if your "foo" script
changed an environment variable or a shell variable, it would lose effect
when the shell terminated at the end of "foo". The parent shell's
variables are not affected by commands executed by a child.

There is only one way around this limitation. The "source" command.
This command is built into the shell and causes the shell itself to
temporarily take its commands (its source) from a specified file.

Since .cshrc and .login files tend to want to change variables and stuff,
they must be "sourced" rather than executed. That's why I use the
terminology. csh "sources" the .cshrc and .login files, rather than
executing them.  

This distinction (when not properly made) confuses all newbie shell scripters.
So it turns out to be fairly important. I hope I explained it clearly.

You explained it poifeckly.

Since Unix is multi-tasking, there's a distinction between "sourcing"
and "executing" that simply isn't meaningful in DOS.

This response has been erased.

[But what I wouldn't give to stick a "&" at the end of some DOS commands...]

Re #17:  Hmm, perhaps you're right.  I'd always assumed the environment
in DOS was a chunk of memory independent of COMMAND.COM, but now that I
think of it, you can set its size when you run COMMAND.COM, so it
makes sense that each instance has its own environment.

Valerie is very definitely right.
Um.  Note that source is not a program, and couldn't be, and is not
available in sh.  <sigh>

Oops.  But there's a facility in sh with almost the same effect, namely
using a dot (period) as a command with a shellscript as its argument.
The script has to be slightly special, if I recall, as it sees the
calling shell's (or script's) arguments rather than any you may have tried
to provide on the command line.  I don't know whether source works this
way.

Yes, "source" works the same way as ".".  Essentially, all they're
doing is temporarily redirecting the shell's standard input to a file.

So you get backward environment-passing at the expense of forward
parameter-passing.  Often a very attractive trade - but sometimes I've
wanted *both*.

I encountered that very problem in writing some shell scripts at work.
I solved it by aliasing the command I wished the user to invoke to
first execute a script (with forward args passed) and then source a
temp file conveniently left behind by the script. (ick)

I think there may be a more elegant way of doing this, that replaces the
temporary file with judicious use of backquotes, but I haven't figured it out.

Seems to me I've done things like that.  I wasn't able to figure out
a more elegant way either.

I've been getting something really weird now when I log on to grex. I get
the normal progression of text, motd annoucnement, etc, and then the mail
prompt. But instead of the grex% prompt being at the bottom of the screen,
now it jumps up to the top.  This has happened for about the last 4 times
I've called in. I thought it was line noise at first, but not now. How
do I get it to go back to staying at the bottom of my screen?

        Pattie

It's definitely coming from the tset -Q $TERM in your .login file.
I am not sure why the behavior is new, but it may be related to recent 
changes made to various termcap files. Others may be able to provide more info.

You may be able to get by without that tset altogether. 
Try commenting it out (with a leading #) and then log in again and see if
everything is working OK.

I've been noticing that behavior also, and I'd prefer the old way because
when it jumps to the top it partially overwrites the old screen, but 
doesn't compeltely clear it, creating a definite "garbage" effect. 
And clearing the screen would ntalk ihengsi@grex.cyberspace.org
Hello?
Are you there?
Hello??

did I just post my attempt to reply to "talk" in this response?

Hmm.  This may be related to some termcap changes I made recently.
I'll check it out.

I've been having these problems also

I as well am having this problem.  I am using a vt102 term.  I wouldn't be
all that upset if it weren't for the 'garbage' effect that Tom speaks
about above (re#28).

If you could change it so that is clears the screen as it puts the prompt
at the top of the screen, I would be very happy!  (I could stop using
'clear' as my first command.)

I'm seeing it too, John, & it's pretty clearly just about exactly since
you said you had upgraded these things.  (I use vt100.)  One of life's
little irritations.

Pattie, the kludge is that after you have read the motd etc. you enter
clear
to clear the screen, so that you don't wind up overprinting what's already
there.  (Or, for those of you who log directly into the bbs, !clear from
a Picospan prompt.)

I hate jumping on the bandwagon, but yes, I've seen those
same problems when I log in.

I use vt100 also

Dave,

The way I dealt with it was to go into mail if I had new, or the use the
clear screen option in Zterm.

        Pattie

PS, glad to see others piping up!

I think the screen clearing thing would be great.

I vote for retaining past behavior, and making folks that want the screen
cleared do something explicit themselves.

I don't mind the screen clearing, in fact, I am used to it.  Most other
systems that I have telneted into, when they do the TSET, will clear the
screen.  What I don't like is placed at the top of the screen without it
first clearing away the old stuff.  It makes for a mighty messy start.

I wouldn't mind clearing, but I wish it would clear,
not just go to the top.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss