Det er to vesensforskjellige måter å tilby et ferdig oppsett av tcsh på. Den enkleste måten er å ha en katalog (/local/skel) der det ligger et sett med filer for oppsett av shellet. (all.cshrc, all.login). Brukerne får initielt en fil som bare bruker disse filene vha. source-kommandoen. Brukerne kan da legge til egne ting/modifikasjoner i sine private filer, samtidig som de automatisk blir oppdatert på modifikasjoner som er gjort i de globale filene. Det siste punktet er særs viktig. Hvis man for eksempel flytter en rekke programmer til en annen katalog, er man avhengig av å endre verdien av PATH-variabelen for alle brukerne!
Med et slikt oppsett har brukerne også muligheten til å endre sine oppstartsfiler slik at de ikke lenger bruker felles-filene. I slike tilfeller må det være brukernes eget ansvar å sørge for å holde seg oppdatert når endringer blir gjort!
For å unngå dette, har man muligheten til å gjøre kjøringen av enkelte felles oppstartsfiler tvunget. Dette kan forenkle systemadministratorens oppgave noe, men samtidig mister brukerne en mulighet som kan være viktig for enkelte. ksh, tcsh og bash har alle muligheten for dette. ksh og bash vil lese /etc/profile hvis denne finnes, mens tcsh vil bruke /etc/csh.cshrc, /etc/csh.login og /etc/csh.logout.
Som de fleste er klar over, har csh (og tcsh) to oppstartsfiler: .cshrc og .login. Det er viktig å være klar over forskjellene mellom disse.
.cshrc blir alltid lest når et nytt shell startes opp. Denne fila skal altså brukes til oppsett av shellet selv. Her bør man sette opp ``shell-interne'' ting, dvs. variable, prompt, og alias. Pass særlig på at denne fila aldri gir noe output, siden dette kan forvirre en rekke applikasjoner.
Den viktigste shell-interne variabelen er PATH, som spesifiserer hvilke kataloger som skal søkes for å finne programmer. Her bør man alltid spesifisere kataloger for lokale programmer (/local/bin, /depot/bin, /appls/bin e.l.) foran systemets kataloger (/usr/ucb, /usr/bin, etc), slik at man har muligheten til å erstatte utvalgte systemprogrammer med egne, modifiserte utgaver når (ikke hvis) det blir ønskelig.
Tcsh har også en rekke andre shell-interne variable som kan settes hvis man ønsker å aktivisere spesiell funksjonalitet i shellet. Disse bør man helst ikke benytte i et felles ``default-oppsett''. Et eksempel er noclobber-variabelen, som spesifiserer at man ved enkel redirigering til fil ikke skal kunne slette innholdet av en fil. Ved første øyekast kan det se ut som om dette er nyttig for uerfarne brukere, men et slikt ``sikkerhetsnett'' vil ofte gjøre mer skade enn nytte.
Alias spesifiseres oftest i den felles .cshrc fila. De fleste alias vil bare være nyttige ved interaktiv bruk, derfor er det vanlig å teste om shellet er interaktivt (ved å se på prompt variabelen) før man lager aliasene. Når man setter opp standard alias gjelder mye av den samme problematikken som for shell-variable: man må passe seg slik at man ikke gjør brukeren en bjørnetjeneste. Et alias som jeg dessverre ofte ser satt opp som standard-alias for nye brukere er alias rm 'rm -i', for at brukeren ikke skal slette filer uforvarende. Dette aliaset er direkte destruktivt - av to årsaker: Brukeren vil venne seg til at ``rm'' kommandoen ikke er så farlig, og brukeren vil få for vane alltid å svare ja på slike ja/nei spørsmål.
Ting som bare påvirker andre applikasjoner, ikke shellet selv, hører hjemme i .login.
.login blir kjørt når man logger inn, og blir kjørt etter .cshrc. Det viktigste som skal gjøres i .login er håndtering av terminaltype, setting av environment variable, og (hvis ønskelig) gi ut en egen melding (motd).
Håndteringen av terminaltype er blitt endel redusert, i og med at de fleste faktiske terminalene er blitt borte. Termcap/terminfo databasene er oftest større enn man noensinne trenger. Det man faktisk behøver er xterm, og vt100/200/300 seriene, siden de fleste terminaler og terminal-emulatorer er basert på disse. Helst burde man aldri trenge flere, men av og til trenger man dessverre terminaltyper som sun, hp, hpterm, decterm, aixterm og enda mer hjerneskadde ting!
For terminalemulatorene som går under et vindussystem trenger man å håndtere forandringer i størrelsen ved hjelp av X sin ``resize'' kommando, og vanligvis vil man også ha med en sjekking av DISPLAY-variabelen.