#1091 closed bug (duplicate)
Ctrl-C Quits Terminal after the First Command Has Been Executed
| Reported by: | bonefish | Owned by: | axeld |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | System/Kernel | Version: | R1/pre-alpha1 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
After the first (non-built-in) command has been run, Ctrl-C quits the Terminal. E.g. run "ls" in a fresh Terminal, press Ctrl-C, and *plop* the Terminal is gone.
Tested in vmware.
Change History (6)
comment:1 by , 18 years ago
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
comment:2 by , 18 years ago
I checked #113 before. It also concerns incorrect SIGINT handling, but the bug described there is indeed fixed. Hence I opened a new ticket.
comment:3 by , 18 years ago
comment:4 by , 18 years ago
I didn't read all the #113 comments, figuring they wouldn't apply since the bug was closed. But apparently some do describe the same bug. So, let's continue tracking it there, but adjust the bug description.
comment:5 by , 18 years ago
Using /bin/ftp it might be possible to see what goes wrong.
If you issue just 'ftp' without an IP or domain name it gives you the ftp prompt. There you can ctrl-C without anything happening, until you 'quit' ftp, and Terminal dissappears. Between pressing ctrl-C on the ftp prompt and before quitting ftp, one should be able to inspect the enviroments of ftp, its parent shell and Terminal itself.
comment:6 by , 18 years ago
I don't think the environment of the shell and/or ftp are of much interest. This seems to be simply a problem with our signals implementation. The shell apparently gets a signal it is not supposed to get (likely SIGINT). Its reaction being to wait for all children and then to quit.
Anyway, this bug has been marked a duplicate of #113. Please continue the discussion there.
Duplicate of #113 (was closed before).