Using Run to open files/Applications
mark stephens (181) 125 posts |
I have an obey script which I run on startup to login to CloudFS. I am also trying to get it to automatically open and run !Fireworkz and !Organizer, loading in my data. Cloud Filer_OpenDir Cloud::PCloud.$.daily | open Dir with my files Run Cloud::PCloud.$.daily.current | open Fireworkz file Run Cloud::PCloud.$.daily.OrgData | open Organiser file My issues is that only the first Run will be executed (regardless of order). Is there a way to open multiple files like this? |
Stuart Swales (8827) 1357 posts |
Filer_Run? |
Steve Pampling (1551) 8172 posts |
Curiosity gets the better of me here: Under what circumstances is it a good idea to use Run rather than Filer_Run ? |
Rick Murray (539) 13850 posts |
Nothing wrong with that.
Not really relevant here. In both cases, FileSwitch will determine that it’s an Obey file and will pass the file to Obey, as defined by
Run happens immediately. Normally you don’t notice any difference, however if you want things to happen in a certain way (say, during Boot or running an app from the command line), then Filer_Run is the way to do. For instance, ensure PrivateEye has been seen (this is likely to be in $.Utilities). If you don’t have it, use any app that isn’t one of the built in ones. F12 to command line and then… *Run <PrivateEye$Dir>.!Run Window Manager is in use Postmortem requested 60258 in function main Arg2: 0x0000878c 34700 -> [0xe1a0c00d 0xe92dd80f 0xe24cb004 0xebfffe3a] Arg1: 0x00078448 492616 -> [0x6972503c 0x65746176 0x24657945 0x3e726944] fc16b63c in shared library function 877c in function ___init * This happens because it tries to do it right away, right there. You can’t run desktop apps in the command line (or a TaskWindow). However: Filer_Run <PrivateEye$Dir>.!Run Appears to do nothing if you’re in the command line, but once you’re back in the desktop, the application will load as expected. In this way you can start desktop apps from the command line. It’s a useful trick to remember if you have an app that you know has been ‘seen’ but it’s buried in the directories somewhere. Doing a quick PS: Remember the |
Steve Pampling (1551) 8172 posts |
That’s just one aspect of the fact when people echo the statement that “computers are stupid fast” they haven’t looked at the statement in quite as much detail as is needed. |
Rick Murray (539) 13850 posts |
Hmmm… *Explode With The Power Of A Supernova File 'Explode' not found *Wipe Out Life On Earth Command option not known *Blow My Brains Out File 'Blow' not found *Do Whatever You Want Then File 'Whatever' not found *Go Away Internal error: abort on instruction fetch at &0000000A * Um. I guess I need an upgrade. |
Steve Pampling (1551) 8172 posts |
I bet the responses to the stupid instructions were fast though. |
mark stephens (181) 125 posts |
Filer_Run did the trick! |
nemo (145) 2556 posts |
Late response. FTR *Run passes control of the computer entirely to the file. If it is one of the two filetypes that FileSwitch understands (Absolute and Utility) then it will be executed (in the appslot or RMA respectively). So if the caller was in the appslot and the file is an Absolute, the caller is killed. Otherwise a *@RunType_### is passed to OS_CLI and literally anything can happen including reformatting your hard disc. If the RunType uses *Obey, then it used to be the case that the file would be opened and commands executed one line at a time, but these days the whole file gets cached whether you want it to or not, so there’s no open file (and the old -c switch is silently ignored). Also note that since 1994 *Obey runs through VProtect via an alias. An Obey file that Runs an application will therefore stall until the application quits, at which point the rest of the Obey file will be executed. !Run files sometimes make use of this, which is why you shouldn’t “*RMReinit Obey”. There are a variety of commands available to cause a file (or app) to be run once multitasking is available and they all do slightly different things: *WimpTask (and Wimp_StartTask) take any *command and ensures that the caller is not destroyed by a new Absolute, but can only be called from inside the desktop, or strangeness will occur. If you have a sufficiently modern TaskManager you can *StartDesktopTask (and TaskManager_StartTask) outside the desktop as well as inside, and again it takes a *command. If you have the official TaskModule or the Cerilica clone you can TaskModule_StartTask (no CLI equivalent) to register a function callback once the desktop is available (from where you can do anything). And then there’s Filer_Run (no SWI equivalent) which can only take a file not a *command, but which has a number of options depending on your Filer including -shift, -noshift, -type and -newfile. There’s probably more I’ve forgotten. [bleedin Textile. Does somebody want to put a Textile reference on this site so that clicking the link for help doesn’t say “nah, you’re on your own mate”] |
Steve Pampling (1551) 8172 posts |
Interestingly,1 it looks like the Wayback machine hasn’t got a sensible answer since last year, but that scan does give a meaningful set of info that might work if the Beast/Textile combo likes you at the instant you post. 1 Much like the alleged Chinese curse “interesting” is in the eye of the beholder, or their warped humour – whichever. |