On Tue, May 24, 2011 at 09:19:08AM +0200, Corinna Vinschen wrote: >On May 23 15:33, Christopher Faylor wrote: >> On Mon, May 23, 2011 at 08:21:20PM +0200, Corinna Vinschen wrote: >> >On May 23 13:25, Christopher Faylor wrote: >> >> On Mon, May 23, 2011 at 06:04:37PM +0200, Corinna Vinschen wrote: >> >> >On May 23 11:33, Charles Wilson wrote: >> >> >> as-is. What if you really WANT to use cmdbox? How else can a >> >> >> cygwin-shell-in-cmdbox be started, other than a .bat file of some kind? >> >> >> And since that's the only real way to do so, we ought to provide the >> >> >> file. >> >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> > Huh? >> >> > >> >> >You can simple create a Windows shortcut to bash.exe, edit it to >> >> >add a --login option, and that's all you really need. >> >> >> >> I agree, except for people who "need" to set the CYGWIN environment >> >> variable for some reason. You have to do that before running bash. >> >> >> >> Maybe we should be looking into introducing a way to set the CYGWIN >> >> environment variable in the global environment and adding c:\cygwin\bin >> >> (or whatever) to the global PATH as well. >> > >> >I would really like to avoid that. The question is, which CYGWIN >> >settings are really needed before an application starts? Apart from the >> >"debugging the Cygwin DLL" scenario, the only one I can think of is the >> >"tty" setting, and that's about to go away. >> > >> >IMHO it would be quite helpful if a setenv ("CYGWIN", ...) or putenv >> >("CYGWIN=...") would change the CYGWIN settings for the calling process >> >as well. >> >> Well, unless you make that change, all of the other Cygwin environment >> variables (not just "tty") need to be set before the first Cygwin >> process in a tree is started. Parsing the CYGWIN environment variable >> on the fly is trivial but I don't know for sure if there are some >> settings which only work right when set during program initialization. > >I had a quick look: > > "dosfilewarning" Sets a bool. Has immediate effect. > "envcache" Ditto. > "error_start" Sets a string. Has immediate effect. > "export" Sets a bool. Has effect on exec'ed child processes. > "glob" Sets two bools. Has effect on exec'ed child processes. > "proc_retry" Sets number. Has immediate effect. > "reset_com" Sets bool. Has immediate effect. > However, per the comment in fhandler_serial::open this > works around a problem in Windows 9x! Maybe we should > kill the setting?
Yep. It's always fun to nuke those. > "strip_title" and > "display_title" set bools. Has effect on exec'ed child processes. > "tty" Well... > "upcaseenv" Sets bool. Has effect on exec'ed child processes. > "winsymlinks" Sets bool. Has immediate effect. > >So, as far as I can tell, except for the "tty" setting everything else >would work nicely if set via setenv/putenv. Ok. No objections here. Do you want to do it or should I? It looks like a fairly simple change to _addenv. cgf