FAQ

So far people who don't read manuals don't read this either... I may call it README.*PLEASE* in the future, but then the same people won't be able to get ftp it... :-)

See http://www.tcsh.org/MostRecentRelease for download locations.

On some machines the tty is not set up to pass 8 bit characters by default. Tcsh 5.19 used to try to determine if pass8 should be set by looking at the terminal's meta key. Unfortunately there is no good way of determining if the terminal can really pass 8 characters or not. Consider if you are logged in through a modem line with 7 bits and parity and your terminal has a meta key. Then tcsh 5.19 would set wrongly set pass8.

If you did like the previous behavior you can add in /etc/csh.login, or in .login:

    if ( $?tcsh && $?prompt ) then
        if ( "`echotc meta`" == "yes" ) then
             stty pass8
        endif
    endif

If you don't have pass8, maybe one of these would work..

    stty -parity -evenp -oddp cs8 -istrip   (rs6000)
    stty -parenb -istrip cs8

Finally, tcsh will bind all printable meta characters to the self insert command. If you don't want that to happen (i.e. use the printable meta characters for commands) setenv NOREBIND.

These programs are broken. Background jobs should not try to look at the tty. What happens is that dbxtool looks in stderr to inherit the tty setups, but tcsh sets up the tty in cbreak and -echo modes, so that it can do line editing. This cannot be fixed because tcsh cannot give away the tty. Pick one of the following as a workaround:

    dbxtool < /dev/null >& /dev/null &
    /usr/etc/setsid dbxtool &

If that does not work, for dbxtool at least you can add "sh stty sane" in your .dbxinit

Your system does not support NLS. Undefine NLS in config_f.h and it should work fine.

Csh sources are now available with the 4.4BSD networking distributions. You don't need csh sources to compile tcsh-6.0x.

Newer versions of the ftp daemon check for the validity of the user's shell before they allow logins. The list of valid login shells is either hardcoded or it is usually in a file called /etc/shells. If it is hard-coded, then you are out of luck and your best bet is to get a newer version of ftpd. Otherwise add tcsh to the list of shells. [For AIX this file is called /etc/security/login.cfg.] Remember that the full path is required. If there is no /etc/shells, and you are creating one, remember to add /bin/csh, /bin/sh, and any other valid shells for your system, so that other people can ftp too :-)

Well, cmdtool tries to do its own command line editing and the effect you get is one of using an editor inside an editor. Both try to interpret the arrow key sequences and cmdtool wins since it gets them first. The solutions are in my order of preference:

1. Don't use suntools
2. Use shelltool instead of cmdtool.
3. Unset edit in tcsh.

Unset edit in tcsh.

Unset edit in tcsh. Using shelltool instead of cmdtool does not fix this.

Maybe you need to use 'rlogin -8' to tell rlogin to pass 8 bit characters.

Anonymous ftp to prep.ai.mit.edu:/pub/gnu/dirent.tar.Z

Your <sys/ioctl.h> file is not ansi compliant. You have one of 3 choices:

1. Run fixincludes from the gcc distribution.
2. Add -traditional to the gcc flags.
3. Compile with cc.

It is a bug in the unbundled optimizer. Lower the optimization level.

Hp terminals use the arrow keys internally. You can tell hpterm not to do that, by sending it the termcap sequence smkx. Since this has to be done all the time, the easiest thing is to put it as an alias for precmd, or inside the prompt:

    if ($term == "hp") then
        set prompt="%{`echotc smkx`%}$prompt"
    endif

Note that by doing that you cannot use pgup and pgdn to scroll... Also if you are using termcap, replace "smkx" with "ks"...

Make sure that the interrupt character is set to ^C and suspend is set to ^Z; 'stty -a' will show you the current stty settings; 'stty intr ^C susp ^Z' will set them to ^C and ^Z respectively.

    >sh.c:???: `STR???' undeclared, outside of functions [gcc]
    >"sh.c", line ???: STR??? undefined [cc]

You interrupted make, while it was making the automatically generated headers. Type 'make clean; make'

You are probably logged in to the cray via telnet. Cray's telnetd implements line mode selection the telnet client you are using does not implement telnet line mode. This cause the Cray's telnetd to try to use KLUDGELINEMODE. You can turn off telnet line mode from the cray side by doing a "stty -extproc", or you can get the Cray AIC to build a telnetd without KLUDGELINEMODE, or you can compile a new telnet client (from the BSD net2 tape), or at least on the suns use: 'mode character'.

This is another manifestation of item 5. Just add the pathname to tcsh in /etc/shells and everything should work fine.

If this happens complain to your vendor, to get a new version of NIS. You can fix that in tcsh by defining YPBUGS in config.h

Their csh does not have job control either. Try:

        % script
        % cat > /dev/tty

You have defined REMOTEHOST and your DNS is not responding. Either undefine REMOTEHOST and recompile or fix your DNS.

        http://www.imada.sdu.dk/~blackie/dotfile/

        http://www.dotfiles.com

For example

    ./tcsh
    echo $$
    591
    ./tcsh
    kill -6 591

Will kill everything, since hup will be sent to all tcsh processes. To avoid that you can set stty -hupcl, but it is not recommended.

Try using rsh -8; this option is undocumented on some systems, but it works. If that does not work, get and use ssh/sshd. You'll be better off from a security point of view anyway.

This is a problem with lack of ABI compatibility between the two systems. The only solution is to recompile.

This is because the termcap/terminfo description lies about the ability of the terminal to use tabs. At least on Compaq/DEC Alpha OSF/1 3.x and 4.x systems, stty -tabs will cause problems.

You can read the manual page section titled [NEW FEATURES] listing features that tcsh adds to csh.

You can read Tom Christiansen's [Csh Programming Considered Harmful], a document advocating that csh (and by extension, tcsh) should not be used for writing shell scripts.

XXX: Need to find something about [bash], but bash is sh-compatible and has many of the same interactive features of tcsh (command completion does not appear to be as flexible, though).

[Curtains up: introducing the Z shell] has a pretty good rundown on zsh. Aside from the arguments about csh being evil, tcsh appears to compare well with zsh [zsh]. Zsh is sh and ksh compatible, with many of the interactive features of tcsh.

On FreeBSD, by default, the up arrow is set to "history-search-backward", rather than the default "up-history". As a result, if you type (part of) a word and press up arrow, you'll see previous commands that match the prefix. Pretty useful, actually, although it takes some getting used to. You can use bindkey to see your settings, and to rebind up & down differently if desired.

Christos