> Hi, thank you very much for this analysis which should enable me to do
> further investigation; first, I'd like to know whether the two alternative
> codelets for the -D option change anything.
> Anyway, maybe I should simply disable transparency, either at all (but
> people would complain, I'm sure) or at least if mintty is invoked from a
> console.
Hi Thomas,
Let me rephrase/summarize my findings:
Executing 'mintty -D' (i.e. v212)
from a shortcut to bash (i.e. Cygwin console),
will fork itself, where the child will turn itself into a session leader, as
desired.
i.e. the following code will be executed:
#if 1 // Thomas
if (daemonize && !isatty(0)) { // daemonize == true, !isatty(0) == true
if (fork() > 0) exit(0);
setsid(); // executed by child
}
#endif
1. if 'Windows Basic' has been selected (Personalization), the child will crash.
2. if 'Windows 7' has been selected (Personalization), the child will NOT crash,
... and, eventually, fork itself, where the "grandchild" will replace itself
by bash in the end.
@@ ps ax
PID PPID PGID WINPID TTY UID STIME COMMAND
800 2752 800 3684 pty0 1000 00:35:30 /usr/bin/ps
2752 3936 2752 1708 pty0 1000 00:35:25 /usr/bin/bash
<====
I 3252 1 3252 3252 cons0 1000 23:58:38 /usr/bin/bash
3936 1 3936 3936 ? 1000 00:35:25
/usr/bin/mintty-v212 <====
case 1. reveals a bug in update_transparency() (or in the call stack below that)
Henri
Re. 'Anyway, maybe I should simply disable transparency ... if mintty is invoked
from a console, as a workaround.'
Why? As I see it, the code that manages the "advanced features" (eye candy) of
mintty has a bug, that must be solved.
However, in future, it might be wise to restructure mintty in a "classic/basic"
part and an "enhanced part". The advantage would be, that one could request for
the "basic part" (command line option), in case of a bug in the "enhanced part".
=====
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
