Forum unknown
· Amiga at Work
#RUN LocksCLI
27 messages in this thread
Hi All!
I've got a question to ask you. Has anyone had any problem when using the RUN
command?
I've found on occasion that even when RUNning a program I get a
locked-up CLI window. Then when I check with STATUS, I find a task with RUN
next to it. I have yet been able to get BREAK to work.
BREAK 2 all
2 being the task which RUN is using. BTW I've never been able to get BREAK to
work!
If anyone has any info on run having a bug of this sort I'd like to hear about
it and also if 1.3 will fix it. I'd also like to know what break really is
doing when I invoke it. BTW I'm using a B2000 with an additional 2 Meg of RAM.
Thanks, Chris
Chris,
It's funny you should ask that. In the last 2 weeks I've started having
that problem. I RUN a program, terminate the program, yet the CLI isn't
released. Weird. I have no idea what's causing it. I installed ARP 5-6 weeks
ago. Could that be it?
Steve, I've got ARP (latest release from MicroSmiths) and I've been wondering
if that is it too, but there is no RUN command in ARP. I've compared the file
size with run in my original WBench and it's the same size. It is weird because
it does it only occasionally no real pattern to it. I'm gonna pin down the
circumstances somehow though.
Thanks for the reply, Chris
If you do pin it down, please let me know. I've had it happen 3 times in the
last 2-3 weeks. The only changes in my environment has been ARP and the use of
WShell.
OK Steve, I'm gonna try it just happens and when it does I kinda get worked up
and forget what I was doing. But I'm gonna try. Chris
ARP, does have a RUN command, however, it's got a different name. ARP's RUN
command is called ARUN. I've been using it without any problems.
Ray
Ray, I thought ARUN was for Resident commands and programs. So far I haven't
gotten any programs to stay resident too long that weren't made to stay
resident. Chris
ARUN is the ARP replacement for AmigaDOS' RUN. It's just like RUNBACK but
supposedly better (smaller anyway). I think there is something else called RRUN
to handle the resident stuff in ARP.
Ray
ARUN is the ARP replacement for AmigaDOS' RUN. It's just like RUNBACK but
supposedly better (smaller anyway). I think there is something else called RRUN
to handle the resident stuff in ARP.
Ray
Ray, I thought ARUN was for Resident commands and programs. So far I haven't
gotten any programs to stay resident too long that weren't made to stay
resident. Chris
ARP, does have a RUN command, however, it's got a different name. ARP's RUN
command is called ARUN. I've been using it without any problems.
Ray
OK Steve, I'm gonna try it just happens and when it does I kinda get worked up
and forget what I was doing. But I'm gonna try. Chris
If you do pin it down, please let me know. I've had it happen 3 times in the
last 2-3 weeks. The only changes in my environment has been ARP and the use of
WShell.
Steve, I've got ARP (latest release from MicroSmiths) and I've been wondering
if that is it too, but there is no RUN command in ARP. I've compared the file
size with run in my original WBench and it's the same size. It is weird because
it does it only occasionally no real pattern to it. I'm gonna pin down the
circumstances somehow though.
Thanks for the reply, Chris
Steve,
IF you're using FFS and 1.3, there is a strong possibility that you'll
have to put RUN into RAM: to get it to work. I had the same problem until I
did that.
Don
I am not running 1.3. FFS works great. The problem did not surface until
I installed ARP and WShell (is there an echo in here?)
Steve,
Yes, I saw that…but try to put run into RAM: and then add ram: to
your path. See if that works….it may well be the problem.
The combination of WShell, ARP and FFS may act in the same manner as
1.3 and FFS….the symptoms are certainly the same.
Don
No they aren't. It's intermittent. I've seen the problem 2-3 times. When I
ran 1.3 the problem with RUN occured everytime. That's why I don't use it.
No they aren't. It's intermittent. I've seen the problem 2-3 times. When I
ran 1.3 the problem with RUN occured everytime. That's why I don't use it.
Steve,
Yes, I saw that…but try to put run into RAM: and then add ram: to
your path. See if that works….it may well be the problem.
The combination of WShell, ARP and FFS may act in the same manner as
1.3 and FFS….the symptoms are certainly the same.
Don
I am not running 1.3. FFS works great. The problem did not surface until
I installed ARP and WShell (is there an echo in here?)
Steve,
IF you're using FFS and 1.3, there is a strong possibility that you'll
have to put RUN into RAM: to get it to work. I had the same problem until I
did that.
Don
Chris,
It's funny you should ask that. In the last 2 weeks I've started having
that problem. I RUN a program, terminate the program, yet the CLI isn't
released. Weird. I have no idea what's causing it. I installed ARP 5-6 weeks
ago. Could that be it?
Chris,
Certain things grab the spawning CLI for use as Stderr, with some using it
for stdout and stdin as well. As long as they're still running they hold on
to the window. The well-behaved ones detach or open their own windows. Some
will allow themselves to be 'killed' (Snipit being a nice example) so you can
close the window. It's a case of operator beware, or choosing what you intend
to RUN carefully. Sometimes, a redirection to NIL: will help. e.g. RUN >NIL:
thingie >NIL: but not always.
The safest method is never to close the CLI when you've RUN something from it
unless you're sure that it hasn't grabbed the window. A quick check of each
thing will allow you to be sure of how it will behave.
Doug, I didn't do an ENDCLI just used RUN to start something from my CLI so I
could still use it but never got the prompt back! WEIRD Chris
Doug, I didn't do an ENDCLI just used RUN to start something from my CLI so I
could still use it but never got the prompt back! WEIRD Chris
Chris,
Certain things grab the spawning CLI for use as Stderr, with some using it
for stdout and stdin as well. As long as they're still running they hold on
to the window. The well-behaved ones detach or open their own windows. Some
will allow themselves to be 'killed' (Snipit being a nice example) so you can
close the window. It's a case of operator beware, or choosing what you intend
to RUN carefully. Sometimes, a redirection to NIL: will help. e.g. RUN >NIL:
thingie >NIL: but not always.
The safest method is never to close the CLI when you've RUN something from it
unless you're sure that it hasn't grabbed the window. A quick check of each
thing will allow you to be sure of how it will behave.