Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!ncar!gatech!ukma!usenet.ins.cwru.edu!news
From: news@usenet.ins.cwru.edu
Newsgroups: comp.unix.programmer
Subject: Re: The shell should handle tty modes along with job control
Message-ID: <1990Nov13.163951.7201@usenet.ins.cwru.edu>
Date: 13 Nov 90 16:39:51 GMT
References: <20651:Nov409:46:3090@kramden.acf.nyu.edu> <108290@convex.convex.com>
Reply-To: chet@po.CWRU.Edu
Organization: Case Western Reserve Univ. Cleveland, Ohio, (USA)
Lines: 34
Nntp-Posting-Host: thor.ins.cwru.edu

In article <108290@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes:

>The (t)csh I've used for the last 5 years or so has always 
>done pretty much the right thing with modes.  That is, it restores
>your tty to the state it was in before calling the program.  It
>does seem to know to do the right thing with stty changes, although
>I haven't looked to see how it does that.

Bash uses the exit status of commands to decide whether or not to restore
the terminal modes.  If a command exits successfully (that is, it does not
exit with a status indicating that it was killed by a signal), bash saves
the tty settings; if one exits via a signal or stops, the tty state is set
back to the saved settings.  This takes care of stty, for instance.

For the morbidly curious, here's the code :-)

  if (job != NO_JOB && interactive)
    {
      if (WIFSIGNALED (child->status) || WIFSTOPPED (child->status))
        set_tty_state ();
      else
        get_tty_state ();

      notify_and_cleanup ();
    }


Chet
-- 
Chet Ramey				``I die, Horatio''
Network Services Group, Case Western Reserve University
chet@ins.CWRU.Edu
                My opinions are just those, and mine alone.