The problem is `cmdtool' and bash fighting over the input. When scrolling is enabled in a cmdtool window, cmdtool puts the tty in `raw mode' to permit command-line editing using the mouse for applications that cannot do it themselves. As a result, bash and cmdtool each try to read keyboard input immediately, with neither getting enough of it to be useful.
This mode also causes cmdtool to not implement many of the terminal functions and control sequences appearing in the `sun-cmd' termcap entry. For a more complete explanation, see that file examples/suncmd.termcap in the bash distribution.
`xterm' is a better choice, and gets along with bash much more smoothly.
If you must use cmdtool, you can use the termcap description in examples/suncmd.termcap. Set the TERMCAP variable to the terminal description contained in that file, i.e.
TERMCAP='Mu|sun-cmd:am:bs:km:pt:li#34:co#80:cl=^L:ce=\E[K:cd=\E[J:rs=\E[s:'
Then export TERMCAP and start a new cmdtool window from that shell. The bash command-line editing should behave better in the new cmdtool. If this works, you can put the assignment to TERMCAP in your bashrc file.
completion chop off the first few characters of each filename?
This is the consequence of building bash on SunOS 5 and linking with the libraries in /usr/ucblib, but using the definitions and structures from files in /usr/include.
The actual conflict is between the dirent structure in /usr/include/dirent.h and the struct returned by the version of `readdir' in libucb.a (a 4.3-BSD style `struct direct').
Make sure you've got /usr/ccs/bin ahead of /usr/ucb in your $PATH when configuring and building bash. This will ensure that you use /usr/ccs/bin/cc or acc instead of /usr/ucb/cc and that you link with libc before libucb.
If you have installed the Sun C compiler, you may also need to put /usr/ccs/bin and /opt/SUNWspro/bin into your $PATH before /usr/ucb.
` user' tilde expansion on a machine running NIS?
This is a famous and long-standing bug in the SunOS YP (sorry, NIS) client library, which is part of libc.
The YP library code keeps static state -- a pointer into the data returned from the server. When YP initializes itself (setpwent), it looks at this pointer and calls free on it if it's non-null. So far, so good.
If one of the YP functions is interrupted during getpwent (the exact function is interpretwithsave()), and returns NULL, the pointer is freed without being reset to NULL, and the function returns. The next time getpwent is called, it sees that this pointer is non-null, calls free, and the bash free() blows up because it's being asked to free freed memory.
The traditional Unix mallocs allow memory to be freed multiple times; that's probably why this has never been fixed. You can run configure with the `--without-gnu-malloc' option to use the C library malloc and avoid the problem.
The `@' character is the default `line kill' character in most versions of System V, including SVR4.2. You can change this character to whatever you want using `stty'. For example, to change the line kill character to control-u, type
stty kill ^U
redirection before a subshell command?
The actual command in question is something like
< file ( command )
According to the grammar given in the POSIX.2 standard, this construct is, in fact, a syntax error. Redirections may only precede `simple commands'. A subshell construct such as the above is one of the shell's `compound commands'. A redirection may only follow a compound command.
This affects the mechanical transformation of commands that use `cat' to pipe a file into a command (a favorite Useless-Use-Of-Cat topic on comp.unix.shell). While most commands of the form
cat file | command
The file CWRU/sh-redir-hack in the bash-2.04 distribution is an (unofficial) patch to parse.y that will modify the grammar to support this construct. It will not apply with `patch'; you must modify parse.y by hand. Note that if you apply this, you must recompile with -DREDIRECTION_HACK. This introduces a large number of reduce/reduce conflicts into the shell grammar.
The short answer is that Red Hat screwed up.
The long answer is that they shipped an /etc/inputrc that only works for emacs mode editing, and then screwed all the vi users by setting INPUTRC to /etc/inputrc in /etc/profile.
The short fix is to do one of the following: remove or rename /etc/inputrc, set INPUTRC= /.inputrc in /.bashrc (or .bash_profile, but make sure you export it if you do), remove the assignment to INPUTRC from /etc/profile, add
set keymap emacs
to the beginning of /etc/inputrc, or bracket the key bindings in /etc/inputrc with these lines
$if mode=emacs
[...]
$endif