Author |
Topic: Trapping Errors in *Commands (OSCLI statements) (Read 1003 times) |
|
mohsen
New Member
member is offline
Gender: 
Posts: 39
|
 |
Trapping Errors in *Commands (OSCLI statements)
« Thread started on: Nov 19th, 2008, 04:48am » |
|
Is there a better means of trapping errors in OSCLI statements other than by LOCAL ERROR.
i.e. asking the system not to bounce the error back but return a pointer to an error block/message. Something like "XOS_CLI" in RISC-OS?
possibly:
OSCLI <string> [TO <n-var>]
thanks
|
|
 Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Trapping Errors in *Commands (OSCLI statements
« Reply #1 on: Nov 19th, 2008, 08:50am » |
|
Quote:| Is there a better means of trapping errors in OSCLI statements other than by LOCAL ERROR. |
|
Errors generated by OSCLI are treated internally just like all other BASIC errors, the only difference being that (in general) they have error numbers greater than 127.
What is your objection to using ON ERROR LOCAL, just as you would for other BASIC statements? You could reproduce the functionality you mentioned as follows:
Code:
DEF FNoscli(cli$)
ON ERROR LOCAL = ERR
OSCLI cli$
= 0
Of course you're always going to have difficulty detecting a non-existent OS command in your program because COMMAND.COM issues the 'not recognized as an internal or external command, operable program or batch file' error to the console rather than returning an error code.
Richard.
|
|
Logged
|
|
|
|
mohsen
New Member
member is offline
Gender:
Posts: 39
|
|
Re: Trapping Errors in *Commands (OSCLI statements
« Reply #2 on: Nov 19th, 2008, 11:10pm » |
|
on Nov 19th, 2008, 08:50am, Richard Russell wrote:Of course you're always going to have difficulty detecting a non-existent OS command in your program because COMMAND.COM issues the 'not recognized as an internal or external command, operable program or batch file' error to the console rather than returning an error code.
Richard. |
|
Can you please give an example of the above COMMAND.COM untrapped errors when using OSCLI.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Trapping Errors in *Commands (OSCLI statements
« Reply #3 on: Nov 20th, 2008, 08:42am » |
|
Quote:Can you please give an example of the above COMMAND.COM untrapped errors when using OSCLI.
|
|
Any unrecognised command will result in a console window opening briefly and the message 'Bad command or filename' being displayed. For example:
Code:
This is what the BB4W documentation says: "If a star command is mistyped, or does not exist, it will be interpreted as an 'external' command and passed to Windows™ for execution. If it is not the name of a valid Windows™ or MS-DOS™ command, MS-DOS will report the 'Bad command or file name' error. However this may appear on the screen very transitorily and it may not be apparent what has happened. In addition this error cannot be detected or trapped by BBC BASIC for Windows, and execution of the BASIC program will continue".
Richard.
|
|
Logged
|
|
|
|
mohsen
New Member
member is offline
Gender:
Posts: 39
|
|
Re: Trapping Errors in *Commands (OSCLI statements
« Reply #4 on: Nov 20th, 2008, 08:57am » |
|
The reason I asked for an example was that I have tried issuing a junk *Command but there was no resulting console window at all. I did this last night on a Vista-64.
I have tried this just now on another PC running Windows XP-32 and "Yes" there was a brief console window but no text in it and quickly disappears.
Could it be that there are differences between the operating systems?
I have used a slightly modified version of the oscli function as follows as I need to report the error message rather than the number:
Code: DEF FNoscli(cli$)
ON ERROR LOCAL = REPORT$
OSCLI cli$
= ""
It is possible that in the Vista-64 test example, the display was too fast that simply does not show the console window at all.
What is the advantage of the COMMAND.COM reporting an error message in a window that displays for millisconds? and no other means to report a message to the user.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Trapping Errors in *Commands (OSCLI statements
« Reply #5 on: Nov 20th, 2008, 1:40pm » |
|
Quote:| Could it be that there are differences between the operating systems? |
|
Of course there are "differences" but not ones that should affect the COMMAND.COM behaviour significantly. It's more likely that on some PCs the console window is closed so quickly that the display drivers never actually show it.
Quote:| What is the advantage of the COMMAND.COM reporting an error message in a window that displays for millisconds? |
|
I don't think there is an "advantage". The console command processor was written by Microsoft to be used in an interactive way, with the user typing in commands manually. In that context the way it behaves makes sense. It wasn't really designed to be called from an application like BB4W.
The only alternative would be not to allow BB4W to issue 'MS-DOS' (i.e. console) commands like XCOPY at all. That would be a high price to pay for avoiding the 'Bad command or filename' anomaly.
Richard.
|
|
Logged
|
|
|
|
JGHarston
Junior Member
member is offline
Gender:
Posts: 52
|
|
Re: Trapping Errors in *Commands (OSCLI statements
« Reply #6 on: Aug 6th, 2010, 2:57pm » |
|
I've had to get around this sort of thing before way back when on Unix systems. Try this:
Code:
DEFFNwin_cmd(cli$)
LOCAL ch%,err$
OSCLI "cmd /c "+cli$+" 2>"+@tmp$+"err.txt"
ch%=OPENIN(@tmp$+"err.txt"):IF ch%=0:=""
err$=GET$#ch%:CLOSE#ch%
=err$
It redirects the error output to a file, then reads that file to see if anything has been output to it. Bear in mind that if the called command displays its error reports to standard-out instead of standard-error, then it will return an empty string.
A quick test does the following:
Code:
>PRINT FNwin_cmd("junk")
'junk' is not recognised as an internal or external command.
>PRINT FNwin_cmd("dir")
>
|
|
Logged
|
|
|
|
|
