BBC BASIC for Windows: Trapping Errors in *Commands (OSCLI statements)

BBC BASIC for Windows
Programming >> Operating System >> Trapping Errors in *Commands (OSCLI statements)
http://bb4w.conforums.com/index.cgi?board=os&action=display&num=1227073708

Trapping Errors in *Commands (OSCLI statements)
Post by mohsen on Nov 19^th, 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

Re: Trapping Errors in *Commands (OSCLI statements
Post by admin on Nov 19^th, 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.

Re: Trapping Errors in *Commands (OSCLI statements
Post by mohsen on Nov 19^th, 2008, 11:10pm

on Nov 19^th, 2008, 08:50am, Richard Russell wrote:

Can you please give an example of the above COMMAND.COM untrapped errors when using OSCLI.

Re: Trapping Errors in *Commands (OSCLI statements
Post by admin on Nov 20^th, 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:

OSCLI "JUNK"

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.

Re: Trapping Errors in *Commands (OSCLI statements
Post by mohsen on Nov 20^th, 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.

Re: Trapping Errors in *Commands (OSCLI statements
Post by admin on Nov 20^th, 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.

Re: Trapping Errors in *Commands (OSCLI statements
Post by JGHarston on Aug 6^th, 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")

>