Running Workbench program from CLI (at startup.)

[Pheonix]

I have a nice little program I came across that changes the look of system request boxes. The problem I'm running into is getting it to start automatically. If I double click on the Icon from Workbench, everything is fine. The program runs, stays in the background, and does what it is supposed to do. The problem I'm facing is that if I run it from CLI (such as in User-Startup,) then the CLI window will never close. I've tried using the run command, and even putting it in a script file and doing a run execute. It all results in the CLI window staying open. The system will complete the bootup, without a problem, and I can even shrink the window down and access everything just fine. With Workbench 2+ I would just put it in the WBStartup drawer. But Workbench 1.3 doesn't have that (and it doesn't run under 2+.) Is there any way to make it run detached, or to have LoadWB run it as if it had been double clicked? I don't remember ever having to do something like this, and I'm not having much luck finding information in a search.

[cyberhead97]

It sounds like you need to use WBRun. Readme says it supports Workbench 1.3.

[bubbob42]

Originally Posted by Pheonix

I've tried using the run command, and even putting it in a script file and doing a run execute.

Did you try just "run" or "run <>nil: yourcommand > nil:" ?

[Pheonix]

Originally Posted by cyberhead97

It sounds like you need to use WBRun. Readme says it supports Workbench 1.3.

Heh.... I came here to post that answer Just found it, quite by accident, and finished testing it. Works like a champ. It turns out, I had downloaded it quite a while ago, and didn't know I had it. I'm actually using the one included with CLICon which seems to be a newer version. Though I guess it could also be older.

Originally Posted by bubbob42

Did you try just "run" or "run <>nil: yourcommand > nil:" ?

I've actually never run a program like that. I just used "run command". I usually prefer to see the "startup" messages programs give when you run them during the startup-sequence.

[Amiga1992]

Originally Posted by Pheonix

I've actually never run a program like that. I just used "run command". I usually prefer to see the "startup" messages programs give when you run them during the startup-sequence.

Well if you don't RUN it the shell will be waiting for it to return but it never will until you close it. So your only choice is to run it. I guess WBRun basically just runs the WB app in a new shell.

[Pheonix]

I'm using the run command... Exact command variations:

"run sys:system/newareq"
"run execute s:newareq.s" {one line in script: "run sys:system/newareq"}
"run execute s:newareq.s" {two lines in script: "run sys:system/newareq" & "endcli"}


All 3 in S:Startup-Sequence and in S:User-Startup. Not one variation made a difference except in the "[CLI #]" messages in the boot CLI screen. I tried putting in the re-directors (along with the .bra & .ket lines,) you suggested, but it then just asked for volume ">nil" to be inserted.

[Daedalus]

Was the <> form of redirection supported under 1.3? I don't remember ever using it like that before 3.0... The thing is, that redirection won't make a difference to the command working or not anyway. So does WBRun not work as you need it to?

[idrougge]

Along with the .bra .ket? What .bra .ket lines?

[Amiga1992]

I think redirection is supported under 1.3 but .bra and .ket isn't.
Also I just noticed this was meant to be on 1.3. As far as I know 1.3 cannot multitask in that way, so it won't work.

[idrougge]

Why wouldn't it work?

Also, I think Daedalus is on to something about <> redirection. You probably need to write <NIL: >NIL: instead of <>NIL:

[Amiga1992]

Because it isn't implemented in the same way. Go ahead and try it, I just did because I don't have much experience with 1.x. I wouldn't know of any further explanation, but we all know 1.3 was sort of multitasking and only 2.x brought proper multitasking.

I edited the Workbench 1.3 startup sequence to RUN SYS:PREFS/Preferences before Loadwb did. System "opened" a new CLI (in the same window, [CLI 2]) , then loaded Preferences but did NOT continue running the script until I closed Preferences. Either the system doesn't support multitasking in that way or the 1.3 command doesn't work in the same way as in 2.x

Redirecting to NIL: only redirects the output of the command, it has no effect on whether the script waits for the command to return or not. RUN or RUN >NIL: do the same in 2.x (open command in new process so script in the process it was executed from can keep on running)

[Pheonix]

WBRun works just fine in 1.3, and it solved my problem. I thought I said that in my second post.

.bra & .ket also work in 1.3, and was needed because <> is normally used for variable insertion. .bra .ket replaces those so that the <> would be recognized as an input/output redirection instead of a variable marker. I didn't realize that the suggested run command would look at it that way until I got the error message the first time I tried to use it. I added in the the .bra .ket commands so that it would look at it the way that bubbob42 wanted it to be used instead.

However, 1.3 does not support <>nil: that way. It looked at it as input from volume ">nil" instead of the double redirection that I believe was intended. However, changing it to <nil: >nil: also didn't seem to have an effect on keeping the process separate from the CLI. WBRun does that for me now, so that I can put it in my startup sequence instead of having to manually double-click the icon every time. The only issue is that I have to have it after the loadwb command, so it can't be in my User-Startup (where I like to keep all my changes & additions if I can,) but in the main Startup-Sequence.

[idrougge]

Originally Posted by Akira

Because it isn't implemented in the same way. Go ahead and try it, I just did because I don't have much experience with 1.x. I wouldn't know of any further explanation, but we all know 1.3 was sort of multitasking and only 2.x brought proper multitasking.

I don't know what you intend by multitasking, but 1.3 is just as multitasking as 2.0.

[Daedalus]

Originally Posted by Pheonix

WBRun works just fine in 1.3, and it solved my problem. I thought I said that in my second post.

So you did, I thought I'd missed something else because of the other posts after that

However, 1.3 does not support <>nil: that way. It looked at it as input from volume ">nil" instead of the double redirection that I believe was intended. However, changing it to <nil: >nil: also didn't seem to have an effect on keeping the process separate from the CLI.

Yeah, that's what I thought. And redirection won't normally have any effect on the behaviour of a command, just on what happens to its output. The command itself can't tell that it's been redirected to NIL:

WBRun does that for me now, so that I can put it in my startup sequence instead of having to manually double-click the icon every time. The only issue is that I have to have it after the loadwb command, so it can't be in my User-Startup (where I like to keep all my changes & additions if I can,) but in the main Startup-Sequence.

You could also implement your very own WBStartup script - add an Execute S:WBStartup to your Startup-sequence after LoadWB and then keep all your post-WBStartup modifications in that script instead. You could even cobble together some sort of script that approximates the WBStartup drawer behaviour of later Workbenches...

[Daedalus]

Originally Posted by idrougge

I don't know what you intend by multitasking, but 1.3 is just as multitasking as 2.0.

Yep, true. Perhaps it's a limitation of the old Shell that 1.x uses before NEWCON: is mounted. The default ROM-based CLI in 1.x is pretty limited from memory, so you need to mount NEWCON: to make the updated shell available.

[Pheonix]

Originally Posted by Daedalus

You could also implement your very own WBStartup script - add an Execute S:WBStartup to your Startup-sequence after LoadWB and then keep all your post-WBStartup modifications in that script instead. You could even cobble together some sort of script that approximates the WBStartup drawer behaviour of later Workbenches...

That is actually something I haven't thought of Going to have to look into that. Would make things like this a lot easier.

Basically, I would need to WBRun every icon in the drawer. Easy to build a list of them, but passing them, one at a time, to WBRun could be problematical. I haven't build complex scripts like that on the Amiga before, will have to do some research.

[idrougge]

It's easy with List LFORMAT, assuming that is supported in 1.3.

[Pheonix]

Yes, List will get me a list of all the Icon files. The issue comes with setting it up so that I can do a WBRun on each one individually. That takes a little bit of advanced scripting. If I was just running them, I would just create the list and treat it as a script file (which is what WB 2+ does with the Monitors directory.) However, I need to append "WBRun " at the beginning of each line before running it as a script. I'm not exceptionally familiar with Amiga OS scripting language. All I've rally done (language wise,) so far is basic if else type functions. Have also set up lab & skip activities as well. So, that's what I'm going to have to study, to see if it can be done.

[Pheonix]

OK, it won't let me edit my post for some reason...

lformat looked like it would work after all. But it won't let me strip the .info off of each line. WBLoad is designed to load an icon, and then execute that icon as if it had been double clicked. However, it adds the .info itself, so I need to create the list without the .info, but only for .info files.

I tried switching to WBRun instead, but the parm.library is giving me fits. I found the parm.library (eventually,) on a fred fish disk, but even with it in my libs: directory (and after a reboot as well,) it still throws up a parm.library v1+ required message when I try to use it.

[idrougge]

Try if this works in 1.3:

List LFORMAT "WBRun %M" #?.info