SUMMARY: Annoying Shell/Terminal Problem

From: Crist Clark <Crist.Clark_at_globalstar.com>
Date: Fri Aug 22 2008 - 20:53:54 EDT
Thanks to "francisco roque" for catching this one. He suggested
that a startup script was set to trap(1) INT. Yep. Some /etc/profile
and .profile scripts map INT to a null action with trap(1). Then
at the end of the script either (a) someone forgot to clear the
trap(1) or (b) someone changed it to ksh-specific syntax that sh
doesn't seem to understand (keep /etc/profile sh-clean people)
depending on the system.

Thanks.

On 8/22/2008 at 3:45 PM, "Crist Clark" <Crist.Clark@globalstar.com>
wrote:
> OK. I give up. I'm asking for help. We've got this annoying
> little problem with a number of machines. I'm not sure what
> this sysadmin does differently, but almost all of the boxes
> she builds show this behavior.
> 
> The primary annoyance is that Ctrl-C doesn't work like we
> want and expect. It doesn't actually interrupt a command.
> For example, if I,
> 
>   # tail -f /some/file
> 
> And then ^C to try to break out, it does not work. I can't
> break out. But if I ^Z, it does background it.
> 
> But ^C does do something. If I type,
> 
>   # echo howdy^Cecho doody
>   doody
> 
> The ^C canceled the first echo, but it doesn't cause the shell
> to kick back with a newline and prompt like I usually expect,
> 
>   # echo howdy^C
>   # echo doody
>   doody
> 
> That's the output on system with the glitch and one without for
> the exact same set of keystrokes.
> 
> As a plus, we have systems where the ^C will break out in the
> tail command example, but does still show the weird behavior
> when I run those echo commands from the shell.
> 
> I've looked at the shell environmental variables. I've looked
> at stty(1) settings. It doesn't look like the login shell,
> /sbin/sh and /bin/ksh both seem to do it. I'm stumped. Anyone
> seen this before?


BB<information contained in this e-mail message is confidential, intended
only for the use of the individual or entity named above. If the reader
of this e-mail is not the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient, you are hereby
notified that any review, dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this e-mail
in error, please contact postmaster@globalstar.com 
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Fri Aug 22 20:56:11 2008

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:44:11 EST