Make scripts a bit more safe

[ludat]

While trying to run the vm I found some issues with the script and then reading them I updated some more things:

Fixes

• There are are a couple of hardocded paths which only break if you have a binary in a non common directory (like in the linux distro I use: nixos) so using the name and letting the shell find the right binary is usually the better approach

Improvements

• The syntax using backticks is deprecated in most shell and not recommended anymore, so I changed some to use the more standard $() instead
• Also leaving variables unquoted is very dangerous because it can lead to word splitting by the shell, this is particularly dangerous in rm. For example the script rm -rf $FILE if the file has the path ./something/and/more / will remove every file in the system while rm -rf "$FILE" will fail with rm: cannot remove './something/and/more /': No such file or directory

Questions

Also there are some script the get downloaded from the current release to ./image/sqcogspur64linuxht/squeak that also have absolute paths for some binaries but I'm not sure how to modify those.

Recomendations

I'd recommend running shellcheck on the files which usually catches most of these mistakes and can be done automatically

[eliotmiranda]

Would you be willing to edit all the Linux mvm scripts under building?
find building/linux* -name mvm
That would be great. It’s much better that the scripts be consistent.
Also take a look at the launch script “squeak” which you should find by
find platforms/unix -name squeak -o -name squeak.sh -o -name squeak.sh.in

[ludat]

There, I think I fixed all of the mvm scripts, there are A LOT of them. I had to script it since there are so many (over 100 I think)

I think there were some bugs that I fixed and everything is a bit safer now.

On a side note, I don't think having so many scripts that are mostly the same makes any sense, any change is a massive task for little gain.

[eliotmiranda]

Hi @ludat,

"On a side note, I don't think having so many scripts that are mostly the same makes any sense, any change is a massive task for little gain."

Agreed. If you look in the Windows and Mac builds you'll see the scripts are strict duplicates (which saves adding a directory to a path but is also dubious). The real problem on lunar us the generated Makefiles which are
- generated from templates in platforms/unix/config
- require autoconf to be run once per build rather than once per unix platform (wasting lots of time)
- require running a complex configuration process when making changes to the templates
- do not generate dependency information (see the use of DEPFLAGS = -MMD -MT in the macOS and Windows makefiles) and hence do not necessarily remake objects when headers are changed
- require that platform specific flags be introduced in mvm scripts rather than in sub makefiles as is the case on macOS and windows (e.g. see macos64ARMv8/squeak.*.spur/Makefile)

Others have expressed interest in replacing the Unix/linux platforms/unix/config crap/mess/whatever with static Makefiles similar to the macOS and windows ones. I would love to see this. I also don't object to e.g. having a script directory that one must add to one's path to e.g. find common scripts in a single place, e.g. building//bin. If you have energy here do not hesitate. I will help by answering any and all questions you have. It's high time we got rid of the awful mess that is the unix/linux build system. Autoconf is fine for generating a config.h which specifies what facilities are available on the platform. But platforms/unix/config/mkmf is awful and a two-stage build process to modify Makefiles painful.

[ludat]

I'm sorry but I've already spent more time than I'd like on this (at least for free) so this is as far as I'll go.

[stormwatch]

• There are are a couple of hardocded paths which only break if you have a binary in a non common directory (like in the linux distro I use: nixos) so using the name and letting the shell find the right binary is usually the better approach

This will also help Guix users. See Add script to run on Guix