|Anonymous | Login | Signup for a new account||2014-11-27 00:10 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000131||OCaml||OCaml general||public||2000-06-06 15:29||2000-06-06 15:51|
|Status||closed||Resolution||no change required|
|Target Version||Fixed in Version|
|Summary||0000131: threads, terminals & bash|
some months ago (November last year) you fixed a bug concerning the setting
of non-blocking mode on standard channels that messed up the terminal on my
machine (a Sparc running Solaris).
You had mentioned that there might still be problems if the program gets a
(deadly) signal, in which case it will not necessarily terminate leaving a
"sane" terminal state.
I kept indeed experiencing problems from time to time, but only now got
annoyed enough to look into it:
Now, it seems that it is really rather a bash bug that causes my grief. It
should actually be the duty of the shell to guarantee that the terminal is
restored to a sane state after the termination of programs, but our version
(bash-2.00.0(1) - a very (?) encouraging version number) obviously did not
In case anybode else complains about "vanishing lines", CPU-eating bash
sessions and whatever, I recommend taking a look at the version of the
shell and upgrading to a new one if necessary (bash-2.04 works fine).
I just wanted to tell you so that you do not look for problems in your
sources if it is another program which is the cause of the bug...
Markus Mottl, firstname.lastname@example.org, http://miss.wu-wien.ac.at/~mottl [^]
|Tags||No tags attached.|
|2005-11-18 10:13||administrator||New Issue|
|Copyright © 2000 - 2011 MantisBT Group|