Hi Subbu & all,

On Jul 18, 2020, at 4:32 AM, K K Subbu wrote:

> On 18/07/20 4:39 pm, Robert Withers wrote:
>>> This was patched recently. Does the version below solve your  
>>> problem?
>>>
>>> https://github.com/squeak-smalltalk/squeak-app/blob/squeak-trunk/templates/linux/squeak.sh
>> Would there be any chance of modifying the script to open a file  
>> chooser
>> dialog so the user can select the image s/he wants to run? There is a
>> squeak.sh out there somewhere that does this.
>
> The script uses a file dialog only when required. It is skipped if  
> an image file is specified in the command line or a single image is  
> found in the shared/ directory or through SQUEAK_IMAGE env variable.

Are you sure about the SQUEAK_IMAGE environment variable?  My  
experience in the last ~6 months had been that squeak.sh actually  
interfered with the VM's ability to read SQUEAK_IMAGE.  I hadn't  
posted about it because I feared it might only be my environment:   
self-built VM, Ubuntu or Raspbian.  But now I realize there are  
actually two files named squeak.sh, so I need to get my story straight  
before I post.

Let's differentiate the two squeak.sh files:

(a) The squeak.sh which is produced as part of the opensmalltalk-vm  
build process.  It begins life as  'platforms/unix/config/ 
squeak.sh.in' and/or 'platforms/unix/config/bin.squeak.sh.in' in the  
opensmalltalk-vm repo.  Its stated purpose is to "Run the VM, setting  
SQUEAK_PLUGINS if unset to the VM's containing directory if unset, and  
ensuring LD_LIBRARY_PATH includes the VM's containing directory".

(b) The squeak.sh which lives in the 'squeak-smalltalk/squeak-app'  
repo, and which is significantly different.  Its stated purpose is  
"Script to launch Squeak executable from a bundle".

(Is it fair/correct to say that squeak.sh ("b") would invoke the VM on  
Linux/Unix using squeak.sh ("a")?  Or is this not how the all-in-one  
bundle works?)

In any case:

Note that neither script references SQUEAK_IMAGE directly.   This is  
likely because each script anticipates that the VM will read the  
contents of SQUEAK_IMAGE.  But the Unix Squeak VM binary will only  
honor the contents of the SQUEAK_IMAGE environment variable if no  
image is specified on the command line -- see lines 1448-1450 of  
platforms/unix/vm/sqUnixMain.c:

if (documentName)
	strcpy(shortImageName, documentName);
else if ((ev= getenv(IMAGE_ENV_NAME)))

Aaaaanndddd I think it's fair to say that squeak.sh ("a") allows  
SQUEAK_IMAGE to pass through to the VM, whereas squeak.sh ("b") does  
not.   This is because (I think) squeak.sh ("b") tries very hard to  
find images somewhere (see ensure_image()), and then makes sure to  
ultimately pass an image parameter to the VM:
exec ${SOUNDSERVER} "${VM}" ${VMOPTIONS} ${VMARGS} "${IMAGE}" ${STARGS}

Compared to squeak.sh ("a") which doesn't try to pass any image or  
parameters if none were supplied to it:
LD_LIBRARY_PATH="$PLUGINS:$SVMLLP:${LD_LIBRARY_PATH}" exec $GDB "$BIN/ 
squeak" "$@"


My suggestion would be:  if squeak.sh ("b") from the squeak-app repo  
wants to honor the contents of the SQUEAK_IMAGE environment variable  
on Unix, it should either:  (1) adapt ensure_image() to check whether  
SQUEAK_IMAGE is set, and if it is, consider passing it along;  or (2)  
not supply  "${IMAGE}"  to the VM if no image is found.  Otherwise,  
the legend that the Unix Squeak VM will honor SQUEAK_IMAGE needs a big  
caveat: "unless launched by squeak.sh as provided in the app bundle"...

Also:  perhaps also one of the squeak.sh files could be renamed so  
this is less confusing.

Please ignore me or correct me if I'm totally off-base here.

Thanks,
another Tim