Mail Archives: cygwin-apps/2001/05/07/05:48:26
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:<DOS-PATH>"
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.
- Raw text -