This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Forcing SYSTEMROOT (opinions needed)


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

something like this is done in winsup/exceptions.cc to prevent
'error_start'ed program from running recursively. yes, this method is
bit ugly, but, afaik, nobody had a need to do things like this yet.
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");

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]