Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Date: Mon, 7 May 2001 11:48:13 +0200 From: Corinna Vinschen To: cygapp Subject: Re: Forcing SYSTEMROOT (opinions needed) Message-ID: <20010507114813.V24200@cygbert.vinschen.de> Mail-Followup-To: cygapp References: <20010502222849 DOT A1238 AT redhat DOT com> <20010503111926 DOT Y24200 AT cygbert DOT vinschen DOT de> <20010503133346 DOT A5353 AT redhat DOT com> <147585893249 DOT 20010507121105 AT logos-m DOT ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <147585893249.20010507121105@logos-m.ru>; from deo@logos-m.ru on Mon, May 07, 2001 at 12:11:05PM +0400 On Mon, May 07, 2001 at 12:11:05PM +0400, egor duda wrote: > Thursday, 03 May, 2001 Christopher Faylor cgf AT redhat DOT com wrote: > CF> On Thu, May 03, 2001 at 11:19:26AM +0200, Corinna Vinschen wrote: > >>What about adding a CYGWIN env setting "[no]pamper" with default > >>setting "pamper"? We could add a function to Cygwin which is only [...] > CF> I'm not sure if you're 100% serious but this but I think that the number I am. I thought about a way to support more than just one of these problems which no programmer thinks of by default because they are just wierd Windowisms. Just a thought. > CF> of CYGWIN environment variables is already uncomfortably high. Ok, you are right that the number of settings is high but it's clear that the need for _some_ sort of settings to influence the behaviour of Cygwin is needed, though. And the increasing complexity of Cygwin will not lower the need for such settings. Excuse me but in my opinion it's not reasonable to avoid a possible (and perhaps needful) setting just because the already existing settings are too numerous from a rather subjective point of view. Nevertheless I agree that the setting in an environment variable doesn't fit our needs in the future. Shouldn't we discuss creating a settings file which may override or supplement the CYGWIN environment variable settings? We could add a CYGWIN setting ;-) like "settings_file:" and the file could contain setting=value pairs one per line: binmode=yes check_case=relaxed error_init=C:\Cygwin\bin\gdb.exe ntsec=yes smbntsec=no tty=yes > CF> This doesn't strike me as a CYGWIN setting. It's something that a > CF> programmer wants to be able to set in his own code. If I'm calling > CF> execl and only want four things in my environment, I should be able > CF> to do that without being overridden by a user's environment variable > CF> setting. Shouldn't we add a generalized interface to be able to set or unset "settings" in an application? int cygwin_get (const char *setting, char *value, size_t *size); int cygwin_set (const char *setting, const char *value); The settings could influence for example our current problem. Adding a CYGWIN option called "[no]addsyspath" which cares for SYSTEMROOT and SYSTEMDRIVE in the environment, a savvy programmer could then use the interface like that: cygwin_set ("addsyspath", "no"); or similar. The settings should get inherited by child processes. > CF> That's why I suggested some kind of API to control this behavior that > CF> could be used by a savvy (?) programmer. > so, what's the resolution? i vote for forcing SYSTEMROOT and > SYSTEMDRIVE and adding api. Yep, setting both should be the default. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin AT cygwin DOT com Red Hat, Inc.