squeak.sh appears unable to allow specifying a project/file

We briefly touched on this at the last board meeting and I just got egg on my face trying to demonstrate how easy it was to run a Squeak commandline job.

The immediate problem is that the squeak.sh script included in the current linux-x64 package does not let us run things in the form -
./squeak.sh my.image my.st
because sometihng is making the VM see 'my.image my.st' as a single (bad) filename.
With the shell debugging turned on it seems the last line of the script
exec "${VM}" "${IMAGE}"
is resulting in the eventual command being
exec /home/tim/Squeak/{blah=blah}/bin/squeak 'my.image my.st'
If I manually run that line without the quotes around the image & st filenames it runs properly. I imagine the must be some magic tweak to the script that would solve this? Any suggestions anyone?

The equivalent script included in the development build VMs is completely different, doing interesting things related to GDB and LLDPATH and ... other stuff I don't understand. That also appears to wrap the image & st files in ' '.

The equivalent script in the all-in-one is again different and does some working out of which VM to run per the platform but doesn't look like it would handle the st file any better.

The matter discussed at the SOB was that none of them actually do anything akin to a 'proper unix install', which is in itself a can of parasitic brain worms I'd prefer to leave to other people.

tl;dr -
a) what magic would make the final command not have ' ' wrapped around the image & st filenames?
b) can we try to make a less confusing system of scripts and have it/them do better? Cue dtl to rant a little on this...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: CDC: Clear Disks and Crash

On 18/07/20 3:18 am, tim Rowledge wrote:
> The immediate problem is that the squeak.sh script included in the
> current linux-x64 package does not let us run things in the form -
> ./squeak.sh my.image my.st
Tim,

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

HTH .. Subbu

Hi Subbu,

On 7/18/20 6:57 AM, K K Subbu wrote:
> On 18/07/20 3:18 am, tim Rowledge wrote:
>> The immediate problem is that the squeak.sh script included in the
>> current linux-x64 package does not let us run things in the form -
>> ./squeak.sh my.image my.st
> Tim,
>
> 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.

Kindly,
rabbit

>
> HTH .. Subbu
>

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.

You can force a dialog by removing the if check in ensure_image function
in the script. or, move the *.image/*.changes file out of shared/ directory.

If you are developing an GUI app around Squeak, it is better to use XDG
*.desktop/*.mime files. Then you can either drag/drop an image onto the
app icon or open an image file through the file manager. They are very
easy to create. Let me know if you need examples.

Regards .. Subbu

> On 2020-07-18, at 4:32 AM, K K Subbu <[hidden email]> wrote:
> Let me know if you need examples.

I'd love some examples so that the info is 'on the record' in a place likely to get searched. Getting all this in the swiki would be a boon too.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- QUIP PRO QUO - A fast retort

Yes, it does. Good news!


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Aio, quantitas magna frumentorum est. = Yes, that is a very large amount of corn.

On 18/07/20 11:19 pm, tim Rowledge wrote:
>> On 2020-07-18, at 4:32 AM, K K Subbu<[hidden email]>  wrote:
>> Let me know if you need examples.
> I'd love some examples so that the info is 'on the record' in a place
> likely to get searched. Getting all this in the swiki would be a boon
> too.

The XDG files depend on the package manager and desktop manager which is
why I didn't add them to swiki.

Here are the files I use for Ubuntu 16.04 (64bit). I store squeak
related launchers in /opt/share/bin to keep the OS and my apps on
separate volumes, so I have to modify .xsessionrc to include this path.
bashrc is not sufficient because GUI programs may not start a shell.
----- .xsessionrc ------
case "$PATH" in
        */opt/share/bin:*) ;;
        *) PATH=/opt/share/bin:$PATH ;;
esac
------------------------
(Logout and login to read this .rc file)

I then copy squeak5.png icon into /usr/share/pixmaps and then install
the desktop file with:

----- squeak-vm.desktop ----
[Desktop Entry]
Type=Application
Name=Squeak VM
Exec=run %F
Icon=squeak
Categories=Development;
MimeType=application/spur-image;application/cog-image;application/stack-image;application/squeak-image;application/cog64-image;application/spur64-image;application/squeak64-image
--------------------------
$ xdg-desktop install squeak-vm.desktop

The mimes are generated as explained in the thread:

  http://forum.world.st/magic-decode-for-image-files-td4941712.html

HTH .. Subbu

Hi Subbu & all,

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

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

On 20/07/20 1:00 am, Tim Johnson wrote:
> 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.

Nice catch! squeak-app is a GUI launcher while the squeak.sh in
unix/config is meant for shell sessions. The GUI launcher picks its env
variables from xsession rc files while the script squeak.sh picks them
from shell rc files. Using SQUEAK_IMAGE in xsessions is very rare. It is
more likely in shells.

The launcher script is just that - a launcher. It is meant to detect and
use options specific to a Linux distro. The two launchers you list above
are used in different contexts - xsession and bash.

> 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.

1) is an good suggestion. Please propose a patch to the repo or this
list. 2) does not help in xsession. If an image file is not specified,
it is better to use a file dialog to get one.

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

I am glad you posted your observation. I too was confused about the
multiple squeak.sh files. I really wish we could converge them into a
single one, but the diversity in *ix deployments is too large to be
captured in a single script.

Regards .. Subbu