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

Buchbinder, Barry (NIH/NIAID) [E] BBuchbinder@niaid.nih.gov
Sat Oct 11 02:49:00 GMT 2008


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/



More information about the Cygwin mailing list