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.
It is listed here, with and example like what you want to do, if I understood it correctly.
If Format: If NOT/S WARN/S ERROR/S FAIL/S EQ/K GT/K GE/K VAL/S EXISTS/K
Purpose: If condition is true execute following commands until an ELSE or ENDIF occurs.
Example: IF WARN, IF $count GT 10, IF EXISTS C:List
While waiting to hear if I've overlooked something, I wrote such a command using PortablE:
/* SetError.e */
MODULE 'std/pShellParameters'
PROC main() RETURNS errorCode
errorCode := 20 ->default to Fail if no valid param given
IF ParseParams('OK/S, Warn/S, Error/S, Fail/S, ErrorCode/N')
IF GetParam(0) ->OK
errorCode := 0
ELSE IF GetParam(1) ->Warn
errorCode := 5
ELSE IF GetParam(2) ->Error
errorCode := 10
ELSE IF GetParam(3) ->Fail
errorCode := 20
ELSE IF GetParam(4) ->ErrorCode
errorCode := Val(GetParam(4))
ELSE
Print('No parameters were supplied.\n')
ENDIF
ENDIF
ENDPROC
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:
;some command has just been run by the script
IF ERROR
SKIP Error
ENDIF
Set ErrorCode OK
SKIP Finish
LAB Error
Set ErrorCode ERROR
LAB Finish
SetError $ErrorCode
Thus the script can notify whether it succeeded or not.
Edited by ChrisH on 2010/11/13 12:47:15 Edited by ChrisH on 2010/11/13 12:47:50 Edited by ChrisH on 2010/11/13 13:10:04 Edited by ChrisH on 2010/11/13 13:14:21
@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.
Elwood wrote: 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
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:
EDIT: Strangely I got "Quit" to return an error code (5) by misstyping the argument; i.e. "Quit (5".
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.
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.
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.
Yes, we'll need a complete shell replacement at some point. This includes "Execute" as well.
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.
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?
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
