Thanks for the answer.
Fred
>Further empirical tests turned out that the environment in Windows NT
is not limited, at least not up to a tested size of about 800K.
>But there is a big problem in Windows nevertheless. When using ASCII
functions to access the environment, as Cygwin does, the enviro
On Sep 16 21:55, Hommersom, Fred wrote:
>
> >>You can help by running the new snapshot under strace, like you did before.
>
> I have done three tests:
> below the maximum
> exactly the maximum
> over the maximum
Further empirical tests turned out that the environment in Windows NT
is not limited
>>You can help by running the new snapshot under strace, like you did before.
I have done three tests:
below the maximum
exactly the maximum
over the maximum
**
Here are the results of the test below the maximum
***
On Fri, Sep 16, 2005 at 08:04:57PM +0200, Hommersom, Fred wrote:
>Perhaps I do not understand it. I was talking about invoking cygin
>from native. The native environment grows far over 32 k. It just does
>not show up in bash. If I can help by testing the new snapshot: please
>supply some hints.
Perhaps I do not understand it. I was talking about invoking cygin from
native.
The native environment grows far over 32 k. It just does not show up in
bash.
If I can help by testing the new snapshot: please supply some hints.
Fred
>On the other hand, POSIX would claim that this usage should b
> >
> >I don't think all places in Windows have the limitation.
>
> Look at the code. We're inspecting a buffer returned from
> GetEnvironmentStrings. That is a windows function. The very first
> things returned from this are garbage.
OK, I stand corrected.
$ /bin/env | wc -c
34664
$ cmd
bash
On Fri, Sep 16, 2005 at 04:36:00PM +, Eric Blake wrote:
>>>It looks to me as if a buffer or stack is reused if some maximum is
>>>exceeded with effect that the system sometimes works.
>>
>>From your strace output, it looks to me like windows itself is
>>returning garbage when we ask it for the
> >It looks to me as if a buffer or stack is reused if some maximum is
> >exceeded with effect that the system sometimes works.
>
> From your strace output, it looks to me like windows itself is returning
> garbage when we ask it for the list of environment variables.
I don't think all places in
>
> From your strace output, it looks to me like windows itself is
returning garbage when we ask it for the list of environment variables.
>
>If that is the case, we can guard against that but we can't make the
passed in environment useful, unfortunately.
Is it possible that 'asking for the envi
On Fri, Sep 16, 2005 at 03:55:14PM +0200, Hommersom, Fred wrote:
>Yes sure. You can see this in the header of the dump its says:
>DLL version: 1005.19, api: 0.138
>DLL build:20050916 00:00:39SNP
>
>In order to be sure that we are talking about the same things:
>I have all these variables in DO
Yes sure. You can see this in the header of the dump its says:
DLL version: 1005.19, api: 0.138
DLL build:20050916 00:00:39SNP
In order to be sure that we are talking about the same things:
I have all these variables in DOS and start bash from a CMD window with command
c:\cygwin\bin\strace -o
On Sep 16 14:28, Corinna Vinschen wrote:
> I observerd that tcsh doesn't like variables with a length of 31K,
> though. ash, bash, zsh and pdksh could handle that long environment
> varibale just fine, tcsh on the other hand printed this:
>
> $ echo $VERY_LONG_ENV_VAR
> Word too long.
Never
On Sep 16 13:31, Hommersom, Fred wrote:
> No problem. here is a new trace (similar to the original) and the related
> stackdump
>
> Exception: STATUS_ACCESS_VIOLATION at eip=610D6971
> eax= ebx=10010248 ecx=F2FF edx=00245300 esi=0001 edi=00246000
> ebp=0022EE68 esp=0022EE64 progra
No problem. here is a new trace (similar to the original) and the related
stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=610D6971
eax= ebx=10010248 ecx=F2FF edx=00245300 esi=0001 edi=00246000
ebp=0022EE68 esp=0022EE64 program=c:\cygwin\bin\bash.exe, pid 3572, thread main
cs=0
On Sep 16 12:51, Hommersom, Fred wrote:
> The problem can be reproduced with cygwin1-20050916.dll
> The output of strace in the case of a stackdump is below.
>
> **
> Program name: c:\cygwin\bin\bash.exe (pid 2692, ppid 1)
> App version: 1005.18, api: 0
The problem can be reproduced with cygwin1-20050916.dll
The output of strace in the case of a stackdump is below.
**
Program name: c:\cygwin\bin\bash.exe (pid 2692, ppid 1)
App version: 1005.18, api: 0.132
DLL version: 1005.19, api: 0.138
DLL build:
On Sep 16 11:08, Hommersom, Fred wrote:
>
> Thanks for the replies so far. Unfortunately is the best option (set
> variables in bash) not feasable.
> The .bat file is a complex set of bat files with logic inside so that
> would take a lot of effort to convert
> But I have done some experiments wit
Thanks for the replies so far. Unfortunately is the best option (set
variables in bash) not feasable.
The .bat file is a complex set of bat files with logic inside so that
would take a lot of effort to convert
But I have done some experiments with bash without --login option and
the advised export
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Reid Thompson on 9/12/2005 5:15 PM:
> Hommersom, Fred wrote:
>
>>
>> The file bigsetup.bat contains a huge amount environment variables.
>> For a medium number (~ 600) everything works fine
>> For a larger number the output is:
>> bash: /
Hommersom, Fred wrote:
My startup of cygwin is a .bat file with contents
call bigsetup.bat
set HOME=C:\Data\locations\tc50_custy00
c:\cygwin\bin\bash --login -i
The file bigsetup.bat contains a huge amount environment variables.
For a medium number (~ 600) everything works fine
For a larger nu
My startup of cygwin is a .bat file with contents
call bigsetup.bat
set HOME=C:\Data\locations\tc50_custy00
c:\cygwin\bin\bash --login -i
The file bigsetup.bat contains a huge amount environment variables.
For a medium number (~ 600) everything works fine
For a larger number the output is:
bash
21 matches
Mail list logo
