Dirk Napierala wrote on Friday, October 10, 2008 5:36 AM:
> Buchbinder, Barry (NIH/NIAID) [E] schrieb:
>> From: Dirk Napierala wrote on Thursday, October 09, 2008 11:48 AM
>>
>> I'll presume the following.
>> - You've a "good" reason (company policy?) that you cannot use the
>> simplest solution -- using the cygwin1.dll version that you know
>> works.
Is that true? Please confirm. (Just so I don't keep wondering.) Care to
share the reason?
>> OK. One more try at a work-around.
>>
>> I assume that
>> - the script cannot be changed,
>> - bash actually does the launching, and
>> - company policies allow you to somehow set an alias in the bash
>> shell that launches sfx-file.exe.
>>
>> The idea is that when the script tells bash to run sfx-file.exe, bash
>> actually runs "something else" and that "something else" runs
>> sfx-file.exe successfully.
>>
>> In /etc/profile or .bashrc or your script or somewhere, set up two
>> aliases. (You only need one but I don't know which.)
>>
>> alias sfx-file.exe=/path/sfx-file.sh
>> alias sfx-file=/path/sfx-file.sh
>>
>> Write the following two-line script.
>>
>> #!/bin/sh
>> cygstart /path/sfx-file.exe
>>
>> An alternative three-line script.
>>
>> #!/bin/sh
>> cd /path
>> cmd /c sfx-file.exe
>>
>> Putting the script in the same directory as sfx-file.exe is probably
>> the safest possibility.
>>
>> When your script wants to run sfx-file.exe, it will actually run
>> sfx-file.sh and that will launch sfx-file.exe.
>>
>> Let us know ...
>
> Thanks Barry
> Tested successfully .That works fine. But it is not just about one
> file.
> There are hundreds of them called this way.
> With various names. Also not all sfx files, but also other .exe files.
Assuming that there are no duplicate file names, put the following in .bashrc
(or wherever).
for Dir in list_of_directories_where_the_EXEs_are_located
do
pushd "${DIR}" > /dev/null
for File in *.exe
do
# make sure that File is executable
# and not named "*.exe"
if [ -x "${File}" ]
then
eval alias_or_function
# now get rid of the filename extension.
# if the extension can be either exe or EXE
# you may have check that basename
# does what you want.
File="$(basename "${File}" .exe)"
eval alias_or_function
fi
done
popd > /dev/null
done
"eval alias_or_function" may be one of the following.
eval alias "${File}"="pushd "${DIR}" > /dev/null ; cmd /c "${File}" ;
popd > /dev/null"
# if cmd /c is a problem, use /path_to_non-cygwin_info-zip/unzip
eval alias "${File}"="pushd "${DIR}" > /dev/null ;
/path_to_non-cygwin_info-zip/unzip "${File}" ; popd > /dev/null"
eval alias "${File}"="pushd "${DIR}" > /dev/null ;
/path_to_non-info-zip/unzip "${File}" ; popd > /dev/null"
# The following assumes that there are no spaces in ${DIR} or ${File}.
eval alias "${File}"="cygstart -d ${DIR} ${File}"
# If there are spaces in ${DIR} or ${File}. But I tend to mess up
putting double quotes in double quotes in eval.
eval alias "${File}"="cygstart -d \"${DIR}\" \"${File}\""
Constructions of functions instead of aliases is left as an exercise for the
reader.
Note: None of the above has been tested.
I rarely use eval.
I usually have to experiment to make eval work
See comments, above, regarding quoting.
So YMMV.
> I really appreciate any feedback that is suggesting a workaround, and
> I would like to thank everybody who is so lastingly to follow up
> this, but what I do not understand is that after we found that only
> replacing the dll cause the prob and fix it again when reverted, why
> isn't that enough to troubleshoot the dll now? Also because it does
> not work with the 1.7 version.
You forget a possibility: The ability to load sfx-file.exe may have been a bug
that you used unknowingly as a feature. When the bug was fixed, something
outside of cygwin1.dll that was always "wrong" finally became visible.
If, indeed, your problem occurred because a cygwin1.dll bug was fixed that was
masking a bug on your system, the developers are going to be even less
enthusiastic about working on this.
____
Going back to the error message you originally reported
http://sources.redhat.com/ml/cygwin/2008-09/msg00440.html
bash: ./*selfextracting_zipfile*.exe: Cannot allocate memory
- I, in my ignorance and naïveté, am still sort of surprised that "Changing
Cygwin's Maximum Memory" didn't work. Are you sure that you did the registry
key correctly? Does company policy let the change "stick"? (Around here, only
administrators can use regedit and the only part of the registry that we can
access seems to be HKCU. I periodically thank the Flying Spaghetti Monster for
regtool.)
- Might a bigger swap file help?
- Might your antivirus selectively* block loading such a humongous
executable. (* selectively = when launching from cygwin but not cmd.)
Speaking of "Changing Cygwin's Maximum Memory"
<http://www.cygwin.com/cygwin-ug-net/setup-maxmem.html> ...
Curiously (since I've never played with heap_chunk_in_mb), when I tried
max_memory.exe I got the exact same result as you did.
5fffe000 bytes (1536.0Mb)
So I recompiled it with the much-reviled-and-soon-to-be-eliminated -mno-cygwin
flag. Interestingly, the result was different.
77ffe000 bytes (1920.0Mb)
I confirmed that the first executable is linked to cygwin1.dll and that the
second is not.
> cygcheck /usr/local/bin/max_memory.exe
c:\cygwin\usr\local\bin\max_memory.exe
c:\cygwin\bin\cygwin1.dll
C:\WINDOWS\system32\ADVAPI32.DLL
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\RPCRT4.dll
C:\WINDOWS\system32\Secur32.dll
> cygcheck ./max_memory.exe
.\max_memory.exe
C:\WINDOWS\system32\msvcrt.dll
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
So between both of us getting 1536.0Mb in cygwin and 1536.0Mb being less than
-mno-cygwin gave, I wonder whether 1536.0Mb might possibly have been compiled
into the cygwin1.dll. So I'd suggest that you download and browse the current
source browse looking for a likely culprit. (Disclaimer: My "programming"
abilities are limited to bash, gawk, and below, so I don't know what I'm
talking about.)
And this also contributed to my wondering whether you did "Changing Cygwin's
Maximum Memory" correctly.
Of course, if the 1536.0Mb limit was set as a constant, a developer should have
already remembered it. So I'm almost certainly wasting your time. Note the
word "almost". (Also note the above disclaimer.) Also note the word "almost"
does not remove the word "certainly". But you're desperate, aren't you? ;-)
____
Other data that you might obtain:
- Take sfx-file.exe to a machine (your home machine?) that has cygwin but not
the restrictions of "company policy". See if bash can load it. Maybe the
company machines have other restrictions that only became visible after
cygwin1.dll upgraded.
- Can you run sfx-file.exe from other shells than bash, e.g., ash.exe, where
the shell does not have bash as a parent? (E.g., the shell was started from
the Start Menu's "run" box.)
- If you've been doing this from inside X, does running from a non-X console
work?
- Does playing with consoles change anything? (I'd guess not, but if
everything that's likely to work doesn't its time to try the unlikely.)
- starting bash with cmd as the parent, e.g., from cygwin.bat or as cmd
/c bash.
- starting bash from the Start Menu's "run" box.
- cygwin's rxvt
- cygputty
- etc.
Good luck.
- Barry
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
