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
-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: /
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
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
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 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
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 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
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
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 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
>
> 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
> >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
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
> >
> >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
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
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.
>>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 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
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
20 matches
Mail list logo
