This is just a proof of concept script, which I didn't intend to mature to this level. Ideally this would be ported as a standalone webOS app for App Management or included in PreWare and other homebrew app installers.

Revision as of 18:26, 4 October 2009

Contents

A call to port this script to a webOS app

This is just a proof of concept script, which I didn't intend to mature to this level. Ideally this would be ported as a standalone webOS app for App Management or included in PreWare and other homebrew app installers.

Modified the APP variable in the script

Modified the script to changeAPP=$1
toAPP=/var/usr/palm/applications/$1
I'm no script writer, and wouldn't normally change someone else's code, but the script did not work as originally written unless you were already in that directory. I tested it with the changes, and it works properly now.

Changing app directory to .app

I had noticed that with the 1.2 update, all of the graphics on the USB directory were being scanned as if they were photos. This was pretty much a mess, and hand planned on coming back here to suggest that the "app" directory be changed to ".app" so it would be hidden. I noticed the altered code already had that change, but the original intro did not. Assuming this was the intent, I changed that.

Restructured script to use functions

Suggestion for the script

Perhaps in preparation for the "unlink" command, the "link" command can also create a full backup of the app (.tgz) which will contain the full permissions and any symbolic links that will be lost when copying the app to the /media/internal/.apps directory. That way if we find that the app does not run correctly from the linked version on /media/internal/.apps, we can restore it fully to /var with no loss of data.

We talked about this on the PreCentral thread. Doing a backup would nearly double the space to move an app to /media. It would be ideal to restore the attributes cleanly but the recommended way to restore is to completely remove the app and re-install. I may considering adding it as an option in the future.

Versioning

Possibly could those modifying the script start using some sort of versioning, with the version at the front of the script, with information about what the new version does added to the main article page?