Cygwin: environ problem

Cygwin: environ problem

[Andrej Borsenkow]

Tests for dynamic loading choke almost immediately. The reason is static
libc and environ variable. It is contained in libc.a that is statically
linked so every DLL gets it's own copy.

BUT it looks, that exactly in case of Cygwin this test does not matter.
If I understand correctly, what happens:

- every DLL has control block, that contains pointer to "environ" for
this DLL; this is of type 'char ***' intialised to point to "extern char
**environ", that is a local varible: "user_data->envp = &environ".

- main program has __cygwin_environ that points to actual "true"
environment

- every time environment changes (via setenv()/putnev()) and, of course,
when loading DLL,  cygwin updates local environ to point to
__cygwin_environ, like "*(user_data->envp) = __cygwin_environ"

In other words, every copy of environ is forced to point to the same
location, even if addresses of variables itself are different.

This implies that direct manipulation of environ is not possible (or,
better said, make no sense). Zsh does exactly this - it directly assigns
pointer to new environment block in createparamtable(). This needs to be
fixed for Cygwin.

It just occured to me, that it may be one reason for these misterious
cores on Cygwin.

It looks, like libc.a is actually nothing more than stub library for
cygwin.dll. That is, we can ignore the above test on Cygwin.

We _could_try_ to directly manipulate __cygwin_environ, but I do not
like it - who knows, where and how it is used. BTW comments imply, that
DLLs should actually refer to __cygwin_environ :-)

-andrej

Have a nice DOS!
B >>

Re: Cygwin: environ problem

[Peter Stephenson]

I'll reply to both cygwin-related messages in one go:

Andrej wrote:
> We _could_try_ to directly manipulate __cygwin_environ, but I do not
> like it - who knows, where and how it is used. BTW comments imply, that
> DLLs should actually refer to __cygwin_environ :-)

Without some major rewriting, we may have to: the export-related machinery
assumes it has direct control of the (new) environment's memory.  This is
certainly a contender for the problems people have been seeing.  Strange it
usually works, though.

>> I have English Win2k with Russian locale set, and russian
>> characters are
>> shown as ? in ls output. While this is definitely Cygwin problem, Zsh
>> (often) completely hangs when completing such name ... sorry, it just
>> takes hours (well, a bit less :-) to give listing. It is so
>> slow, that I
>> really had impression it was hung.
> 
> While figuring out environ problem, I got a look at locale
> implementation in Cygwin. There is no :-) setlocale() is just a stub
> function that accepts "C" as locale name and nothing more. It does
> nothing :-))) And locale table contains only ASCII support. So, I
> wonder, how can it work correclty even for ISO-8859-1 charset.

Is there any chance this could be network-related?  My desktop PC has lots
of Samba-mounted drives in various paths, and completion is an absolute
pig, at least until things are cached.  I installed cygwin and zsh onto
someone's notebook this week, with no network dependencies, obviously, and
it's as fast as `normal', whatever normal means for a UNIX porting layer on
top of NT.  There are no serious network problems here which could cause
the difference if everything's running properly.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

RE: Cygwin: environ problem

[Andrej Borsenkow]

> Andrej wrote:
> > We _could_try_ to directly manipulate __cygwin_environ, but I do not
> > like it - who knows, where and how it is used. BTW comments
> imply, that
> > DLLs should actually refer to __cygwin_environ :-)
>
> Without some major rewriting, we may have to: the
> export-related machinery
> assumes it has direct control of the (new) environment's
> memory.  This is
> certainly a contender for the problems people have been
> seeing.  Strange it
> usually works, though.
>

Can you garantee, that no internal libc function and no module will ever
use putenv()? In this case it will happily realloc() environment, thus
getting it out of zsh control again. Oh, even worse, it will try to
realloc() memory, allocated by Zsh. Oops.

BTW the same argument holds for Unix as well.

What's wrong with using "standard" environment?

>
> Is there any chance this could be network-related?

You mean completion speed? Very probable. But in this case my primary
concern is that I cannot see russian filenames :-) I can live with
completion as is.

-andrej

RE: Cygwin: environ problem

[Andrej Borsenkow]

>
> Andrej wrote:
> > We _could_try_ to directly manipulate __cygwin_environ, but I do not
> > like it - who knows, where and how it is used. BTW comments
> imply, that
> > DLLs should actually refer to __cygwin_environ :-)
>
> Without some major rewriting, we may have to: the
> export-related machinery
> assumes it has direct control of the (new) environment's
> memory.


There is unfortunately one more problem. Even if we play with
__cygwin_environ, we need to keep local environ's in sync. This is done
inside of cygwin.dll with update_envptrs() function. This function is
local and is not exported (strictly speaking, it does not appear in any
stub library that is installed with cygwin). The private per-DLL user
structures are hidden as well. So, we have no official way to inform
cygwin about changed environment location.

Please, note - that is currently true even without dynamic loading! But
in this case we at least know, that there is single environ variable, so
we can just update both environ and __cygwin_environ.

-andrej

Environ handling broken on Cygwin RE: Cygwin: environ problem

[Andrej Borsenkow]

>
> There is unfortunately one more problem.

And one more. Cygwin maintains "shadow" Win32 environment, that deals
with Unix<->Win32 name conversion. Now I understand, why calling gvim
(win32 version) out of Zsh never worked - it never got correct filename.

That means, that irrespectively of dynamic loading current environment
handling is broken on Cygwin and needs rewrite.

As I understand, the sole requirement of current code is to be able to
unset environment variable. Cygwin provides unsetenv() function. So, we
could retain current code on Unix and use native Cygwin function there.

Any suggestions before I start hacking? :-)

-andrej

Re: Environ handling broken on Cygwin RE: Cygwin: environ problem

[Peter Stephenson]

Andrej wrote:
> As I understand, the sole requirement of current code is to be able to
> unset environment variable. Cygwin provides unsetenv() function. So, we
> could retain current code on Unix and use native Cygwin function there.
> 
> Any suggestions before I start hacking? :-)

Feel free.  Obviously the best solution would be the minimal changes to use
putenv, getenv and unsetenv where zsh digs around directly in environ with
#ifdef __CYGWIN__.  If this works, we can start adding configure checks to
see if we can do it elsewhere, since anything that reduces the number of
assumptions about the system is good.  However, `if this works' may not be
a particularly well-defined test.

Let me know if you want sourceforge developer stuff adding.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

RE: Environ handling broken on Cygwin RE: Cygwin: environ problem

[Andrej Borsenkow]

>
> Let me know if you want sourceforge developer stuff adding.
>

Probably, not. It needs ssh and I am behind a firewall ... and making
ssh to work with SOCKS is too much currently.

BTW could anybody send me a manual page for setenv()? Our system does
not have it and I'd like to know, if Cygwin version corresponds to Unix.

The patch does not look very hard (actually, it is ready) but it showed
memory leak in environment handling in Cygwin. putenv() allocates it's
own memory and nobody ever frees it. We can write configure checks for
that, but there is no way reliably free memory. So, we could currently
use just free() under #ifdef __CYGWIN__.

I got an answer from Cygwin developers that they probably change it in
future version tp more closely match Unix that adds to even more
confusion :-)

-andrej

Sourceforge development account

[Andrej Borsenkow]

>
> Let me know if you want sourceforge developer stuff adding.
>

I managed to compile OpenSSH with SOCKS and get connection to
zsh.sourceforge.net (I do not care, if sshd really works in this case).

So a couple of questions:

- can anybody add me to list of developers? Account on SourceForge is `bor',
id  64334
- is there any procedure to generate ChangeLog entry? Without emacs that I do
not use (Vim is welcome :-)
- can I login to zsh.sourceforge.net under my normal SourceForge account? Do I
use password authentication or public key? The same, of course, for CVS?

-andrej

Re: Sourceforge development account

[Thomas Köhler]

[-- Attachment #1: Type: text/plain, Size: 674 bytes --]

On Wed, Aug 16, 2000 at 03:30:19PM +0200,
Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru> wrote:
> So a couple of questions:
[...]
> - is there any procedure to generate ChangeLog entry? Without emacs that I do
> not use (Vim is welcome :-)

Some of the sourceforge people happen to use vim, so it shouldn't be a
problem to get vim installed...

> -andrej

CU,
Thomas

-- 
 Thomas Köhler Email:   jean-luc@picard.franken.de     | LCARS - Linux
     <><        WWW:     http://jeanluc-picard.de      | for Computers
                IRC:             jeanluc               | on All Real
               PGP public key available from Homepage! | Starships

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: Sourceforge development account

[Peter Stephenson]

> I managed to compile OpenSSH with SOCKS and get connection to
> zsh.sourceforge.net (I do not care, if sshd really works in this case).
> 
> So a couple of questions:
> 
> - can anybody add me to list of developers? Account on SourceForge is `bor',
> id  64334

OK

> - can I login to zsh.sourceforge.net under my normal SourceForge account? Do 
> I
> use password authentication or public key? The same, of course, for CVS?

You can use the password you requested when setting up your account, just
so long as you use ssh to login.  You can arrange to turn on public key
encryption in the usual ssh way, if you prefer.  Authentication will be
performed identically for CVS, since they're both going the same route.

-- 
Peter Stephenson <pws@csr.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: Sourceforge development account

[Chmouel Boudjnah]

"Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru> writes:

> - is there any procedure to generate ChangeLog entry? Without emacs that I do
> not use (Vim is welcome :-)

something like that ?:

map _ch ggO<C-j><Up><C-R>=strftime("%Y-%m-%d")<C-m> Chmouel Boudjnah <chmouel@mandrakesoft.com><C-m><C-j><TAB>* 

i believe you may need some tweaks....

-- 
MandrakeSoft Inc                http://www.mandrakesoft.com
San-Francisco, CA USA                             --Chmouel