Problem to open big selfextracting Zip files from bash - starting from scratch :-)

Dirk Napierala Dirk.Napierala@oracle.com
Tue Oct 14 13:01:00 GMT 2008


Buchbinder, Barry (NIH/NIAID) [E] schrieb:
> 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?
>   
The workaround would be to continue using the old one. But as part of a 
lot of other software release updates, the version currently in
use was also a candidate to be updated to the latest release. And with 
this new one we discovered the problem. Thats where it all started :-)
>   
>>> 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.
>
>   
Something we have to check out. Maybe this is an option. I have to 
discuss this internally.
>   
>> 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.
>   
Yes, that is true, but hopefully not the reason, cause that means we 
will never be able to update to the latest under the current circumstances.
So I keep my fingers crossed, that we will be able to fix it somehow :-)
> ____
>
> 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.)
>   
That was done as part of troubleshooting using the regtool mentioned in 
"Changing Cygwin's Maximum Memory"
The result was checked manually by using regedit navigating to the key 
and rebooting the system after the key was verified.
>   - Might a bigger swap file help?
>   
No. Unfortunately not.
>   - Might your antivirus selectively* block loading such a humongous executable.  (* selectively = when launching from cygwin but not cmd.)
>   
Good point. I tested it with having Norton AV Autoprotect disabled. 
Guess what. the problem remains the same :-)
> 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.)
>   
Me too ;-)
> 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.
>   
We tried that during testing. The latest (and the old) cygwin was 
installed on another system (my laptop) but with the same test result.
Also no different if  you use win2000 or xp as the base OS. This issue 
appears on all systems.
>   - 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.)
>   
ash also gives you an error message about memory (cant remember the 
correct output)
>   - If you've been doing this from inside X, does running from a non-X console work?
>   
We are going to try this using non-X console.
>   - 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.
>
>   
Thanks for your your efforts.
Regards Dirk
> - 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/



More information about the Cygwin mailing list