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: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Date: Mon, 7 May 2001 17:13:32 +0400
From: egor duda <deo AT logos-m DOT ru>
X-Mailer: The Bat! (v1.45) Personal
Reply-To: egor duda <cygwin-apps AT cygwin DOT com>
Organization: deo
X-Priority: 3 (Normal)
Message-ID: <95604040263.20010507171332@logos-m.ru>
To: Corinna Vinschen <cygwin-apps AT cygwin DOT com>
Subject: Re: Forcing SYSTEMROOT (opinions needed)
In-reply-To: <20010507130501.Z24200@cygbert.vinschen.de>
References: 
 <E94FF01DFF6CD31186F4080009DC361501F8C39D AT nttwr2 DOT tower DOT bldgs DOT butlermfg DOT org>
 <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>
 <20010507114813 DOT V24200 AT cygbert DOT vinschen DOT de>
 <77593264899 DOT 20010507141357 AT logos-m DOT ru>
 <20010507130501 DOT Z24200 AT cygbert DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi!

Monday, 07 May, 2001 Corinna Vinschen cygwin-apps AT cygwin DOT com wrote:

CV> On Mon, May 07, 2001 at 02:13:57PM +0400, egor duda wrote:
>> Monday, 07 May, 2001 Corinna Vinschen cygwin-apps AT cygwin DOT com wrote:
>> 
>> CV> Shouldn't we add a generalized interface to be able to set or
>> CV> unset "settings" in an application?
>> 
>> CV>     int cygwin_get (const char *setting, char *value, size_t *size);
>> CV>     int cygwin_set (const char *setting, const char *value);
>> 
>> CV> The settings could influence for example our current problem.
>> CV> Adding a CYGWIN option called "[no]addsyspath" which cares for
>> CV> SYSTEMROOT and SYSTEMDRIVE in the environment, a savvy programmer
>> CV> could then use the interface like that:
>> 
>> CV>     cygwin_set ("addsyspath", "no");
>> 
>> CV> or similar. The settings should get inherited by child processes.
>> 
>> the question here is "when this new setting should have effect?". if
>> the answer is "immediately" then i don't know how we can implement
>> this. some cygwin options (like 'tty') can't be easily switched in the
>> middle of the game.

CV> Sure. While it's easy to switch eg. ntsec on and off it's impossible
CV> to do that for tty. I didn't mean that as a generalized interface to
CV> enable technical nonsense but just as far as it makes sense. "tty"
CV> for example would need to be blocked in a way.

>> if the answer is "they should affect process'
>> children", then savvy programmer already has the means to do what he
>> (she) wants:
>>   str = getenv ("CYGWIN");
>>   add_desired_option_at_the_end_of_string (str, new_str);
>>   putenv (new_str);

CV> What I think is, we are not at the end of the process of adding
CV> options to Cygwin. As Chris I would like to restrict the length
CV> of the CYGWIN variable but in contrast to Chris I don't want to
CV> restrict the number of settings at all.

CV> I don't think that the above example to change CYGWIN could be
CV> denoted as an "interface". It works, but it's ugly, as you say.

i mean here that as far, as i know, no application yet uses such
method to change CYGWIN options. so, probably, we're inventing
something that nobody really needs?

CV> My goal is simply to add a generalized interface to set options
CV> to Cygwin. That's it. The basic settings are provided by an
CV> environment variable, better a file in future, and a per application
CV> registry setting.

CV> If a programmer really wants to change settings in Cygwin, (s)he
CV> needs an interface. But I don't like the idea to add one interface
CV> per setting like

CV>     cygwin_set_systempaths(TRUE);

CV> or so. Why not adding settings in future in an always equal way:
CV> The setting has a name and a value, setting is possible by
CV> changing CYGWIN, the CYGWIN settings file and the registry setting
CV> per application. And now they are overridable by a programmer (as
CV> long as it makes sense) by using the generalized setting API as well!

the problem here is: first 3 things doesn't require program
recompilation if some setting is obsoleted or changes its meaning.
Fourth thing do.

>> more to say, such generalized api will make a set of $CYGWIN options
>> (in some sense) part of the api. we won't be able to change them easily,
>> if some application is known to call cygwin_set ("addsyspath", "no");

CV> But adding an interface to allow the application to set it was
CV> exactly what was part of the discussion. I don't understand the
CV> point here. Chris asked for an interface so that the programmer
CV> of the application can do what (s)he wants with the setting and
CV> that is provided by these kind of interface. With one difference:
CV> It's always part of an interface system which allows these settings
CV> additionally without changing the application as well. See above.

the point is, if we export 'cygwin_set' and 'cygwin_get' functions,
we'll need to bump CYGWIN_VERSION_API_* every time we introduce a new
option or change the meaning of an old one. that's certainly doable,
but i doubt it's worth an effort.

Egor.            mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19