Re: Forcing SYSTEMROOT (opinions needed)

[egor duda <deo at logos-m dot ru>]

Hi!

Monday, 07 May, 2001 Corinna Vinschen cygwin-apps@cygwin.com wrote:

CV> On Mon, May 07, 2001 at 02:13:57PM +0400, egor duda wrote:
>> Monday, 07 May, 2001 Corinna Vinschen cygwin-apps@cygwin.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@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19