Subject: Re: aliases in kde
To: Hume Smith <hclsmith@glinx.com>
From: Jasper Wallace <jasper@pointless.net>
List: netbsd-users
Date: 02/25/2000 20:57:01
On Fri, 25 Feb 2000, Hume Smith wrote:

> >> Where do you define your aliases?
> 
> >> ~/.cshrc or ~/.login or ~/.xsession (don't know if that works)?
> 
> 
> I'll just chuck in my random comments here.  Folx, please jump on any
> serious misconceptions i put in.  Forgive me if the asker already knows it
> well :)
> 
> 
> .login is "startup" stuff for, how should I call them, "dumb terminal
> sessions"?  The things you get from login, via a serial terminal, the
> console, telnet, rlogin, etc.

yes, i'm not sure that all shells execute .login tho.

> .xession is startup stuff for X sessions.  It's thus analogous to .login,
> except by the nature of X it tends to start a lot of programs.  One big
> difference is that your session terminates when .xsession completes (.login
> just falls off the end and goes to a prompt), so the last thing run by
> .xsession has to hang around for awhile.  

yup. .xsession has sucumbed to the wonders of some strains of unix being
more equal than others - some want it to be executable (chmod u+x
.xsession), and some want it to be called .Xsession (unix has case sensitave
filenames).

The other X start up files that users need to know about it .xinitrc - if
you start X with 'startx' rather than xdm/kdm/gdm it will be used instead of
.xsession. (startx is a shell script wrapper around xinit).

Symlinks are good for dealing with this kind of thing:

lrwxr-xr-x   1 jasper   staff       9 Aug 12  1999 .Xsession -> .xsession
lrwxr-xr-x   1 jasper   staff       9 Aug  3  1999 .xinitrc -> .xsession
-rwxr-----   1 jasper   staff    1464 Jul  5  1999 .xsession


> .login and .xsession are only run once per session, in your "topmost" shell.
>  Thus they should be used for the per-session things, like background tasks
> and environment variables.

yes.

> .cshrc is run by every invocation of csh and tcsh (usually - seems to me
> there's a switch to tell the (t)csh not to).  It should thus be used to
> initialise things *internal* to (t)csh, ie which are not inherited from the
> caller... that's *shell* variables (made by set instead of setenv in (t)csh)
> and aliases.

yup.

The one thing that completly confused me when i started playing with unix
was the fact that shell vairables and environment vairables where different
things that appeared to be the same, (that was in sh, and before i'd found
'export').

-- 
    They were so ignorant! Young men and women, educated very carefully to
be apolitical, to be technicians who thought they disliked politics, making
them putty in the hands of their rulers, just like always.
    - Frank Chalmers in Kim Stanley Robinson's "Red Mars".