From: Andrew F. <an...@bl...> - 2004-05-28 14:21:24
|
Hi, For something I've been playing with, I've had the need to be able to run one AppDir and have it set a variable which can be read by another - specifically the location of the first AppDir. I've uploaded a patch to the tracker which gives support to an <AppDirVar> tag in AppInfo.xml. This should contain the name of an environment variable to be set with the path to the AppDir when the AppDir is run; however since the variable is set by the Filer's PID, it's also available to any later children of the Filer. eg: testtty: #!/bin/sh tty -s || exec xterm -e "$0" "$@" echo $LOCALE_DIR read WAIT Locale/AppInfo.xml: <?xml version="1.0"?> <AppInfo> <Summary>Localisation information for WIMP OS</Summary> <AppDirVar>LOCALE_DIR</AppDirVar> </AppInfo> Then, once "Locale" has been run, "testtty" can be run to show that LOCALE_DIR has indeed been set. The patch is in the tracker at: http://sf.net/tracker/?func=detail&aid=962231&group_id=7023&atid=307023 I wasn't really sure of the best place for the filer_boot() function. Better suggestions welcome. There perhaps should also be a SOAP method for telling the filer to filer_boot() an AppDir without having to actually run it. For more RISC OS-like behavior (ie. just opening a Filer dir containing Locale will set LOCALE_DIR *if it is currently unset*) then in diritem.c->examine_dir() the following lines can be added: item->flags |= ITEM_FLAG_APPDIR; + /* Try to boot the appdir... */ + filer_boot(path, item, 0); /* Try to load AppIcon.xpm... */ One advantage of this method is that the existing 'rox -x' will filer_boot an item (if the var's not already set), without needing a new SOAP method. Perhaps it'd be worth having the overwrite == 0 version check whether or not the path in the var is valid, if not then switch overwrite to 1. That's lowering the security even more of course, but the number of possible attacks is probably fairly low. The most obvious one would be to change LD_LIBRARY_PATH, I suppose? Cheers, Andrew -- Andrew Flegg -- mailto:an...@bl... | http://www.bleb.org/ |