beep and garbage with long commands

beep and garbage with long commands

[slumos]

When entering certain long commands, zsh (at least 4.0.7 and 4.2.0 on
at least FreeBSD and Solaris) beeps and echos parts of the command.
Here's a stupid made-up example:

[~]0% ls -la | while read line; do echo $line | awk '{print $1 " " $2 " " $3 " " $4 " " $5 "\n"}'; done >|/dev/null; echo

"}'; done >|/dev/null; echo
[~]0% 

Steve

Re: beep and garbage with long commands

[Dan Nelson]

[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]

In the last episode (Jun 16), slumos@unlv.nevada.edu said:
> When entering certain long commands, zsh (at least 4.0.7 and 4.2.0 on
> at least FreeBSD and Solaris) beeps and echos parts of the command.
> Here's a stupid made-up example:
> 
> [~]0% ls -la | while read line; do echo $line | awk '{print $1 " " $2 " " $3 " " $4 " " $5 "\n"}'; done >|/dev/null; echo
> 
> "}'; done >|/dev/null; echo
> [~]0% 

I bet you have a preexec function that sets your xterm's title bar,
right?  Either the backslashes or the embedded newline is aborting the
escape sequence, you end up with the rest of your command printed
onscreen, plus the ^G that was supposed to end the titlebar escape
string.

I've attached the part of my zshrc file dealing with xterm and screen
titles.  It strips control characters from the commandline before
sending it to xterm.  It also sets the window name in screen, so if you
use the windows or windowlist command, you can see at a glance what is
running in each screen:

 0*&$ ./start  1-$ mutt  2@$ irc_irc.ca  3$ ssh_emssr  4$ ssh_emssr 5$ joe_/e

Note there are raw control characters in the attached file, so you
might not be able to cut'n'paste the text correctly unless you save it.

I also have the following in my screenrc, since screen won't write to
the xterm titlebar unless the termcap entry has the 'hs' capability.

 termcapinfo xterm|xterm-color 'hs:ts=\E]2;:fs=\007:ds=\E]2;screen\007'

--
 
	Dan Nelson
	dnelson@allantgroup.com

[-- Attachment #2: zshrc --]
[-- Type: text/plain, Size: 1217 bytes --]

SHOST=`print -P %m`

# strip control chars and replace with "."
# result is returned in $reply
function _strip()
{
	local i=1
	reply=$1
	while (( i <= $#1 )) ; do
		[[ $reply[i] > "\x1f" && $reply[i] < "\x7f" ]] || reply[i]="."
		(( i ++ ))
	done
}

if [[ $+WINDOW = 1 && $TERM = screen* ]] ; then
	PROMPT="(%n@$SHOST.$WINDOW) %B%/>%(#/#/)%b "
	RPROMPT="%t %D{%m/%d} %l"
	# set window title to first 10 chars of command
	# set hardstatus to hostname and first 100 chars of command
	preexec () { _strip $1 ; echo -En "^[k${reply[1,10]:gs/ /_/}^[\\^[]0;$SHOST: ${reply[1,100]}\a" }
else
	PROMPT="(%n@%m) %B%/>%(#/#/)%b "
	case $TERM in
		cons25-crt|xterm*|screen*)
			# set titlebar to first 100 chars of command
			preexec () { _strip $1 ; echo -En "^[]0;$SHOST: $reply[1,100]\a" } ;;
	esac
fi

# Update titlebar and inform the user of background jobs
precmd () 
{
	if [[ $+WINDOW = 1 && $TERM = screen* ]] ; then
		# Set the window title to $SHELL
		# Set hardstatus to hostname
		print -Pn "^[k${SHELL:t}^[\\\\^[]0;%m\a"
	fi
	case $TERM in
		# set titlebar to hostname
		cons25-crt|xterm*|screen*)
			print -Pn "^[]0;%m\a" ;;
	esac
	
	if [[ -o interactive ]] ; then
		jobs -s
		:
	fi
}

Re: beep and garbage with long commands

[Steven Lumos]

Dan Nelson <dnelson@allantgroup.com>:
>In the last episode (Jun 16), slumos@unlv.nevada.edu said:
>> When entering certain long commands, zsh (at least 4.0.7 and 4.2.0 on
>> at least FreeBSD and Solaris) beeps and echos parts of the command.
>> Here's a stupid made-up example:
>> 
>> [~]0% ls -la | while read line; do echo $line | awk '{print $1 " " $2 " " $3
> " " $4 " " $5 "\n"}'; done >|/dev/null; echo
>> 
>> "}'; done >|/dev/null; echo
>> [~]0% 
>
>I bet you have a preexec function that sets your xterm's title bar,
>right?  Either the backslashes or the embedded newline is aborting the
>escape sequence, you end up with the rest of your command printed
>onscreen, plus the ^G that was supposed to end the titlebar escape
>string.

Of course! I *never* would have guessed that.  Thanks!

Steve