Problem With Unknown_Cmd

[Jay Sage]

I have tripped over a defect with how Unknown_Cmd operates. Here is an example with unknown_cmd echoing the problem command:

TCC(17.00.51): C:\commands\bat>alias unknown_cmd=`echo Bad command line = %$`
TCC(17.00.51): C:\commands\bat>*badcmd one two three
Bad command line = badcmd one two three
​

The command tail passed to Unknown_Cmd is not entirely correct; the leading asterisk has been stripped. Resubmitting that command will not try to do the same thing as the original command.

This tripped me up in a case where I tried to execute a command with an asterisk to prevent an alias from running. My actual error-processing script (not the one I listed in another post here, but an earlier version that worked a little differently) thought the command had been changed from "*badcmd" to "badcmd" and ran it, causing an alias with the name "badcmd" to run, even though I had included the leading asterisk specifically to prevent the alias from running.

I would like to suggest that the tail passed to Unknown_Cmd should be the actual tail, or at least should have the actual command verb as entered, with any leading asterisk or @ character.

As currently implemented, what is passed is something later in the parsing process, as illustrated by:

TCC(17.00.51): C:\commands\bat>badcmd %temp
Bad command line = badcmd C:\Users\Jay\AppData\Local\Temp
​

The environment variable has already been expanded. Had I intended to enter %tmp instead of %temp, I can still fix the problem. But if the problem is in the command verb, it is harder:

TCC(17.00.51): C:\commands\bat>set badcmd=verybadcmd
TCC(17.00.51): C:\commands\bat>%badcmd one two three
Bad command line = verybadcmd one two three
​

In all these cases, what I would like to have passed to Unknown_Cmd is the command line that caused the problem exactly as I entered it.

Because I rarely enter multiple commands on a line, and even more rarely enter one with a bad command, I had not noticed another difference between how this works and how error processing was handled in the Z-System (ZCPR) command process that I developed for 8-bit CP/M computers. Here is what happens with TCC when multiple commands are on a line:

TCC(17.00.51): C:\commands\bat>badcmd one two three & echo done
Bad command line = badcmd one two three
done
​

Unknown_Cmd gets only the individual command that has the problem. In Z-System, we passed the entire remaining multiple-command line and cleared the entire command-line buffer. So if the command line with the error looked like this:

echo one & badcmd two & echo three
​

the "echo one" command would run and then "badcmd two & echo three" would be passed to the error handler to allow the line to be edited. One could then decide to cancel the entire command line or change the "echo three" part. With TCC, no matter what one does with "badcmd two" in Unknown_Cmd, the remainder of the line, "echo three" in this case, will run.

This is probably one of the reasons why I learned not to manually enter multiple commands on a line in TCC but to feed them one at a time. Of course, I can well imagine that making the error-handling in TCC like what I had in Z-System might require a substantial rewrite of the parser. So, Rex, feel free to tell me that if I want such a change to submit it as a suggestion for a future version.

 

[rconn]

This is not v17 related.

I'm not going to change 20-year-old behavior at this point in the beta (particularly since I think this will probably screw up other people's UNKNOWN_CMD aliases). If you want it changed, please can submit it on the Feedback forum.

 

[Jay Sage]

Rex, it is hard for me to imagine that the simplest change -- restoring the leading asterisk, if present -- would break anyone else's error processing. And that would have prevented the accidental processing of an alias command that I explicitly indicated that I did not want to run. There is, after all, a real and significant difference between the commands "*command" and "command". That's why you support the asterisk prefix.

I agree that the rest of what I suggested is probably too complicated and quite likely not worth the effort.

 

[rconn]

Rex, it is hard for me to imagine that the simplest change -- restoring the leading asterisk, if present -- would break anyone else's error processing.

It's not hard at all for me to imagine it -- but them, I'm the one that will have to deal with the annoyed users whose UNKNOWN_CMD aliases break. For example, I know of users who use UNKNOWN_CMD like an executable extension preprocessor, and pass the command line to an external app to process. In those cases, a prefixed @ or * would be fatal.

Regardless, it's a new feature request and will not be addressed at the end of a beta.

 

[Jay Sage]

Regardless, it's a new feature request and will not be addressed at the end of a beta.

Fair enough. I'll post the suggestion in Feedback.