Missing AmigaDOS command?

I'm converting some MS-DOS scripts I wrote into AmigaDOS ones, and I realised AmigaDOS is missing a really useful command (unless I am mistaken) :

I can do "IF ERROR" or "IF WARN" in an AmigaDOS script, to detect if a program returned an error code, but I don't think that AmigaDOS has any command that specifically generate such errors codes, so a script cannot intentionally return an error code, which seems a glaring lack of symmetry.

I did wonder if Execute cleared any error code set by the last command in the script, but a quick test shows that this isn't the case, so the lack of a "SetError" (or similar) command is quite puzzling.


Of course I can write such a command very easily, but all the more puzzling for it not being present in AmigaDOS.

EDIT: Tweaked post to be clearer.

@ChrisH

It is listed here, with and example like what you want to do, if I understood it correctly.

While waiting to hear if I've overlooked something, I wrote such a command using PortablE:

BTW, it will work just as well on Windows as AmigaOS, although Windows already has a similar command of course...

EDIT: Oh, and if anyone is wondering how you'd use such a command, here's the end of an AmigaDOS script:

Thus the script can notify whether it succeeded or not.

@emeck
No, you misunderstood me, so I have edited my first post to try to be clearer. I know that AmigaDOS has "IF ERROR"/etc! The problem is the lack of any way to generate such an error in the first place.

@ChrisH

Ah, ok. I get what you mean now. Thanks.

@ChrisH

Quote:

quit [error code]

@Elwood

Yep - "quit [RC]" is the one. The error code can be translated with "fault [RC]" then...

@Elwood
That doesn't work here :( . Also, "Quit ?" doesn't show anything.

@ChrisH

I did a script with:

quit 5
echo ok

when I run it, "ok" is not displayed and when I do "set", it shows RC = 5


But yes, "quit ?" displays nothing. I'll report that.

@ChrisH

If you have a standard OS4.1 installation a "help quit" in the shell should - ehem - help.

@Elwood
Quote:
You do get a return code to the shell but Chris is right, it doesn't work when you call a script from another script. Try making a script that calls your test script listed above. When your second script calls the above script it will immediately return to the command line of the shell. For example:

Warning generating script named "doerr":

; generate warning
echo "Testing quit"
QUIT 5

Script named "testerr" that calls "doerr":

; check for warning
echo "Executing doerr"
FAILAT 30
doerr
IF WARN
echo "warned"
ELSE
echo "nothing"
ENDIF

The "testerr" script immediately exits back to the command line after it calls the "doerr" script. However, this behavior is documented in the book "Mastering AmigaDOS 3" dated 1994. It's not anything new in OS4. I think Chris is right about it being a serious shortcoming. There should be a command to return an error code from a script without aborting the entire chain of calling scripts. Maybe we need a new command like "EXIT" or "RETURN" that will return an error code without aborting the calling script.

@ChrisH
I think some people misunderstood the fact that you are calling a script from another script. "Quit" does set a return code if you are just executing a single script (no sub-scripts) from the shell command line. However, as I mentioned in my previous post the "Quit" behavior when executed in a sub-script (script called by another script) is documented for old AmigaDOS too. The explanation is that "Quit" returns a result code directly to the "Execute" command that is running the scripts and causes it to abort.
I agree that we need a new command that would set the return code and return to a calling script. Since I know that the ARexx command "EXIT" works as you would expect when executing ARexx sub-scripts, I tried a cludge that seems to work:
rx "EXIT 5" *>NIL:
When I substitue the above line for "QUIT 5" in my test scripts it seems to work. The "IF WARN" in the calling script works as expected.
EDIT: The above doesn't terminate the called script so you still need to place it at the bottom of the script with a label so you can jump there to exit as you do in your example. The advantage is that you can use "IF WARN" in you main script.
EDIT: Strangely I got "Quit" to return an error code (5) by misstyping the argument; i.e. "Quit (5".

@xenic
Well done on spotting that Quit actually quits all scripts. Not a very useful command, at least for the way that I use scripts.

Quote:
Quit doesn't seem to display anything, in any situation, but I guess it happened to set return code 5 if it has any problems parsing it's parameters. I imagine "Quit foobar" would also set return code 5.

Your ARexx kludge is handy for cases (such as publically released scripts) where I can't easily rely my own SetError command.

@thread

I reported both bugs: "Quit ?" not using ReadArgs() and the RC being cleared in the calling script.

But don't expect bug fixes soon as the Shell doesn't seem an easy thing to fix.

@Elwood
Quote:
I'm not sure that the behavior of "Quit" is a bug. Based on all the old AmigaDOS documentation, it is intended to be a way to abort script execution and return to the command line. Changing it might break some existing scripts. As Chris has suggested, we need a command (like "exit" or "return") that will return the error code (RC) to a calling script without completely aborting the execution of nested scripts. Maybe the report should be a bug report for "Quit ?" not using ReadArgs() and a feature request for a new AmigaDOS command that sets the error code (RC) and returns to the caller; rather that be another script or the shell command line.

@ChrisH
While researching your "Quit" problem, I discovered a better explanation of why "Quit" behaves the way it does. In "The Amiga Guru Book", Ralph Babel explains that the "Execute" command creates only one temporary file when executing a script. When it encounters a sub-script, the temporary file is changed to contain the called script (sub-script) and the remainder of the calling script. The beginning of the calling script is essentially discarded. That also means that your calling script cannot "SKIP BACK" to any part of the calling script that precedes the execution of the sub-script. Basically, AmigaDOS loops based on the "SKIP BACK" command will not work if the loop contains a call to another script (sub-script). Another side affect of the above info is that setting the "FAILAT" level in a sub-script will alter the failure level (FAILAT) of the calling script.
Based of the above information and other weaknesses of AmigaDOS scripting you might be better off converting your MS-DOS scripts into ARexx or Python scripts.

@xenic

Yes, we'll need a complete shell replacement at some point. This includes "Execute" as well.

@Elwood
Quote:
The main problem with the shell is the window (console) that it uses. Most people would just like to see scrollbars added; like KingCon has. The problems mentioned in this thread appear to be a result of the way "Execute" works. One of the problems with changing shell, console, or Execute is backward compatability. We need a new OS4 AmigaDOS "Execute" and protection bits. The protection bits are already expanded to 32bits and it might be a good idea to devote some of those bits to script identification, i.e. a bit for old AmigaDOS scripts, a bit for new AmigaDOS scripts (executed by new Execute), a bit for ARExx scripts and one for Python scripts. The current method of identifying the script type by the comment at the beginning (/* comment */ for ARexx) is a little crude in my view.

@xenic

Forgive me for being a bit overly-explanatorial but let me brain-dump somewhat...

On Windows, there is no execute bit you need to set. The operating system looks at the file extensions specified in the PATHEXT environment variable. It makes things easier for the user but forces regular binaries to have a .exe extension and is rather brain-dead.

On OS4 we have the datatype system. Perhaps the method of determining if a file is executable should be looking to that? Perhaps the protection bits could also be used to mark a file as NOT executable?

In other words, executable bits could flag as file as:
- executable
- not executable
- unknown (fall back to datatypes)

The trick is determining what script files are executable. I am guessing the order could be:
- look at executable flag
- look to datatypes (file extension)
- look to datatypes (file content - i.e. something like "#!/bin/sh" on UNIX)

Here are my thoughts on the "is this file executable" logic:

1. Is the file tagged as NOT executable? Ignore it
2. Is the file tagged as executable? Run it. Look to datatypes for how to run, i.e. if a script which interpreter.
3. Test via datatypes:
- executable binary?
- executable script?

@gregthecanuck

So how do you initialize the datatypes when the datatypes are needed to run the programs needed to inititialize the datatypes?

Seriously, this yet another non-issue that doesn't need any clever solution.