Re: Forcing SYSTEMROOT (opinions needed)

[Corinna Vinschen <cygwin-apps at cygwin dot com>]

On Mon, May 07, 2001 at 02:13:57PM +0400, egor duda wrote:
> Hi!
> 
> 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.

Sure. While it's easy to switch eg. ntsec on and off it's impossible
to do that for tty. I didn't mean that as a generalized interface to
enable technical nonsense but just as far as it makes sense. "tty"
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);

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

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

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

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

    cygwin_set_systempaths(TRUE);

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

> 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");

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

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.