Allen
|
| (KiX Supporter) |
| 2006-03-26 10:40 PM |
Erroneous Macro Results
|
Let's say someone accidently mis-types a macro name in their code. If the erroneous macro is not typed in a string, it will return a 0 result. However, if that same erroneous macro is included in a string, with NoMacrosInStrings=off, it returns <unknown:err.
Since some macros (ie @error) return numbers, including 0, I don't think an erroneous macro should return 0 as a result. Shouldn't they all return the "<unknown:macroname"?
Code:
break on
? @kix
$=setoption("nomacrosinstrings","off")
? "@err"
? @err
$=setoption("nomacrosinstrings","on")
? @err
Produces
Code:
4.52 Beta 2
<unknown:err
0
0
| Mart |
| (KiX Supporter) |
| 2006-03-26 11:06 PM |
|
|
Re: Erroneous Macro Results
|
Nice one. Got bitten by this one recently. Was using FTPPut() UDF and the password had an @ in it. FTPPut() writes a FTP command file and the @ character got replaced by your example and the files did not got send to the FTP server. The fact that FTPPut() deletes the command file when it is done made me look at the code for several hours before finding this.
If a @ character is used and it makes an invalid macro whit the characters after the @ imho it would best return something like unknown:macroname.
|
Lonkero
|
| (KiX Master Guru) |
| 2006-03-27 03:28 AM |
Re: Erroneous Macro Results
|
allen, think you have a point.
erreneous macros are "unknown commands" and should always be noted by kixtart.
outside strings, they should halt the execution.
|
NTDOC
|
| (KiX Master) |
| 2006-03-27 06:12 AM |
|
|
Re: Erroneous Macro Results
|
Quote:
outside strings, they should halt the execution
Hmmm not so sure I would agree with that. I'd rather maybe that the macro come back without data then just halt the entire script. Then I could maybe look at what might be causing the blank data.
Perhaps not urgent or pressing but maybe Ruud can look at this further for upcoming versions.
|
Richard H.
|
| (KiX Supporter) |
| 2006-03-27 09:52 AM |
|
Re: Erroneous Macro Results
|
Quote:
I'd rather maybe that the macro come back without data then just halt the entire script.
That's a horrible idea, even if it is the current state of play.
If you've mis-typed a macro name why wouldn't you want the interpreter to halt and identify the line the first time that the script runs rather than having to debug the strange effects that it may cause?
While the failure of some macros would be pretty easy to spot, many are used in situations where a null or zero return would fit the use and you'd never know that you had a problem. Consider these:
Code:
If @LOGINMODE
; Map drives only during logon
EndIf
If @INWINN<>2
; Don't process for Win9x
EndIf
If @PRODUTSUITE & 16
; Terminal server processing
EndIf
If @PASSWORDAGE < 7
; Issue password warning
EndIf
If the interpreter returns null or 0 then these will all work, however the will all work incorrectly and they will not necessarily be obvious failures.
|
NTDOC
|
| (KiX Master) |
| 2006-03-27 10:38 AM |
|
|
|
Re: Erroneous Macro Results
|
Well perhaps I mis-read this entire discussion. I was thinking along the lines where the macro for some reason did not return data - I certainly would not want it killing the whole script because a client didn't return data.
Something that would not come up in testing because your client is returning data.
I was not thinking of a mis-spelled macro.
| Mart |
| (KiX Supporter) |
| 2006-03-27 12:24 PM |
|
|
|
Re: Erroneous Macro Results
|
Miss spelled macros should stop the script imho just like miss spelled commands do.
Unknown command gives:
Quote:
ERROR : unknown command [copppy]!
Unknown macros should imho return something like this:
Quote:
ERROR : unknown macro [the used macro goes here just like in the above example]!
Depending on NoMacrosInString settings it should or should not error on @ characters used in strings.
| Mart |
| (KiX Supporter) |
| 2006-03-27 12:35 PM |
|
|
|
Re: Erroneous Macro Results
|
Maybe this can be integrated into the NoMacrosInString option as an optional parameter? This way it will not break all currently running scripts that have the @ character in a string.
|
Lonkero
|
| (KiX Master Guru) |
| 2006-04-17 12:19 AM |
|
Re: Erroneous Macro Results
|
fixing the original unknown-issue should have no affect whatsoever on present scripts.
I haven't seen a single script that purposely uses mistyped macros and their produced unknown texts for anything.
| Ruud van Velsen |
| (Hey THIS is FUN) |
| 2006-04-17 12:12 PM |
|
Re: Erroneous Macro Results
|
Good discussion! Not sure of the best way to address this, though. I think throwing an error only when 'NoMacrosInStrings' is used may be the way forward.
Any thoughts on this?
Ruud
|
Lonkero
|
| (KiX Master Guru) |
| 2006-04-17 02:09 PM |
|
Re: Erroneous Macro Results
|
well, if macro's are used outside strings, throwing error on mistype is obvious.
regardless is noMacrosInStrings on or not.
but, inside strings the behavior can differ.
when the noMacros-switch is on, the mistyped macros should be skipped.
but, then the only hard one, what to do with mistyped macros in strings without the switch.
I think there one can take the example from variables.
variables are either interpreted but if there is no such var, the whole varname is printed on the string.
shouldn't that be the easiest "fix"?
so, 2 conclusions:
1) inside strings, if mistyped macro occurs, print the written string instead of the unknown text.
2) if mistyped macro occurs outside strings, error should be thrown.
noMacrosInStrings does not affect either of these.
|
Allen
|
| (KiX Supporter) |
| 2006-08-20 09:06 AM |
|
Re: Erroneous Macro Results
|
Since Ruud is working on a Beta... just thought I might bump this thread to get his thoughts about it.
| Mart |
| (KiX Supporter) |
| 2006-08-20 11:07 PM |
|
|
|
Re: Erroneous Macro Results
|
Quote:
....
so, 2 conclusions:
1) inside strings, if mistyped macro occurs, print the written string instead of the unknown text.
2) if mistyped macro occurs outside strings, error should be thrown.
....
I agree with Jooel on this unless it throws a "real" error when an unknown macro is used outside a string. Like when using an unknown command.
|
Richard H.
|
| (KiX Supporter) |
| 2006-08-21 09:56 AM |
|
Re: Erroneous Macro Results
|
I disagree. If you've mis-typed a macro inside a string that it is still an error, isn't it? And you would want it trapped wouldn't you?
$-variables in strings don't throw an exception if they are undeclared and changing this behaviour will break existing scripts so probably will have to remain as-is for backwards compatibility. I don't think that because this is how $-variables work it is a good reason to apply the same behaviour to macros.
Example:
Code:
$sMyLogFile="\\$sServer\$sShare\@LOGONID.txt"
Personally I think it is much better for this to error rather than populate the string and continue.
To turn the question on it's head, why would you not want a mistyped macro to throw an exception?
|
NTDOC
|
| (KiX Master) |
| 2006-08-21 11:16 AM |
|
|
|
Re: Erroneous Macro Results
|
Quote:
why would you not want a mistyped macro
Well let's not go overboard either.
@USERDI shouldn't do any error, or are you saying RUDD should take the time to make sure every single thing typed into a script MUST be a macro if it has an @ sign in it and it must conform to those listed?
I'm just not so sure it's really worth the time to control it to that level, but if others feel it is and Ruud wants to that's okay too.
Working on some of our other requests that so far have not come to light would be much higher on the list for me.
|
Richard H.
|
| (KiX Supporter) |
| 2006-08-21 11:58 AM |
|
Re: Erroneous Macro Results
|
Quote:
@USERDI shouldn't do any error
It already does in current versions.
Quote:
or are you saying RUDD should take the time to make sure every single thing typed into a script MUST be a macro if it has an @ sign in it and it must conform to those listed?
The KiXtart interpreter already checks that the macro is valid, so there is no additional work required except to change the action when an invalid macro name is detected.
At present if you used @USERDI in a string the interpreter returns "<unknown:USERDI", which is not a very useful way to signal an error condition.
| Witto |
| (MM club member) |
| 2006-08-21 02:29 PM |
|
|
Re: Erroneous Macro Results
|
Code:
$ = SetOption("NoMacrosInStrings","Off")
? @KXI
? CStr(@ERROR)+": "+@SERROR
? '@KXI'
? CStr(@ERROR)+": "+@SERROR
I would expect the same messages and errors. The message "<unknown:KXI" is IMHO unexpected. Throwing an error would be nice. But as NoMacrosInStrings is Off, the error should be the same, just as the return value should be the same.
| Ruud van Velsen |
| (Hey THIS is FUN) |
| 2006-08-21 02:49 PM |
|
Re: Erroneous Macro Results
|
Hmm, good discussion, difficult to determine the best way forward. I will investigate the options and let you know what I come up with.
Ruud
|
Lonkero
|
| (KiX Master Guru) |
| 2006-08-21 06:40 PM |
|
Re: Erroneous Macro Results
|
ruud, I think concensus was reached at least with one case.
mistyped macro's outside strings should always throw an error.
| Witto |
| (MM club member) |
| 2006-08-21 11:43 PM |
|
|
|
Re: Erroneous Macro Results
|
I hope you did not count my answer in the conclusion.
If NoMacrosInStrings is Off, I hope to get the same return value. Or both "<unknown:KXI", or both 0. "<unknown:KXI" seems to have the lessest logic to me. On second place, I thought it would be nice if an error could be thrown. An error for a macro outside quotes and not within is as confusing as the different return values. NoMacrosInStrings is Off, so macros are allowed between quotes. So please no error for me if it would not be the same.
|
Lonkero
|
| (KiX Master Guru) |
| 2006-08-22 12:05 AM |
|
Re: Erroneous Macro Results
|
syntax error is a error and then it's obvious for it to throw an error.
not sure why you would want it to misbehave like it now does...
and if the current behavior is not confusing, I don't know what is.
as currently, one needs to re-read the whole script to find mistyped macro without even knowing that he has one.
there is no excuse to leave it like it is.
| Les |
| (KiX Master) |
| 2006-08-22 12:10 AM |
|
Re: Erroneous Macro Results
|
Invalid macros inside strings regardless of SetOption() should simply be taken as literal text. It is unreasonable to expect KiX to determine invalid macros embedded within strings, period. So that leaves only macros outside of strings which should IMHO throw an error. In my opinion, KiX is too forgiving on unquoted (space or non-quote character delimited) strings but that argument is for another day.
|
Richard H.
|
| (KiX Supporter) |
| 2006-08-22 09:05 AM |
|
Re: Erroneous Macro Results
|
Quote:
Invalid macros inside strings regardless of SetOption() should simply be taken as literal text. It is unreasonable to expect KiX to determine invalid macros embedded within strings, period.
As I said in an earlier post, KiXtart already determines invalid macros embedded in strings, "period". So how can you possibly consider that unreasonable?
|
Lonkero
|
| (KiX Master Guru) |
| 2006-08-22 10:22 AM |
|
Re: Erroneous Macro Results
|
lol.
| Witto |
| (MM club member) |
| 2006-08-22 11:53 AM |
|
|
|
Re: Erroneous Macro Results
|
I think, what Jooel and Les want, is that something between quotes, starting with an @-sign, but definitely no macro, just is a part of a string. Only existing macros in strings should be recognised. This is of course when NoMacrosInStrings is Off.
I do understand that point of view. Maybe it would be better than it works now. But why is KiXtart so forgiving p.e. for
Code:
Break On
+Blablabla
And should it not help recognising a mistyped macro between quotes?
Once again, as long as NoMacrosInStrings is Off.
|
Richard H.
|
| (KiX Supporter) |
| 2006-08-22 01:55 PM |
|
Re: Erroneous Macro Results
|
Quote:
I think, what Jooel and Les want, is that something between quotes, starting with an @-sign, but definitely no macro, just is a part of a string.
I understand that, but why bring the handling of invalid macros down to the lowest common denominator? If the processing is to be changed why not take the opportunity to change it so that macros both inside and outside strings will generate an error if they are mistyped?
Consider this bit of code:
Code:
$sMailAddress="helpdesk@service.acme.com"
This is a coding error. If the "@" symbol is intended to be present in the string it should be doubled up "helpdesk@@service.acme.com" - that is the KiXtart syntax.
If the parser is changed to ignore the error then this code will work. But what happens in KiXtart release 4.xx when Ruud introduces the new @SERVICE macro to indicate when a script is running as a service? Oops. It would be better if the programmer had been notified the very first time he tested the script that the string contained an invalid macro. He would have doubled up the "@" and there would be no chance of a namespace clash in the future.
Quote:
But why is KiXtart so forgiving
Backwards compatibility. When KiXtart first appeared it was a fairly simple beast designed to replace BATch files so the syntax was designed to be simple and accomodating. If the parser was made more pedantic now it would break too many existing scripts. Personally I'd be happy with a "Strict" option which disallows some of the easy-coder things like bare strings, multi-line strings and so-on.
| Les |
| (KiX Master) |
| 2006-08-22 03:19 PM |
|
Re: Erroneous Macro Results
|
Well... if there is a single @ within quotes and the chars that follow do not represent a valid macro, KiX should just eat the @ and treat the rest as text if NoMacrosInStrings is OFF. If NoMacrosInStrings is ON, then the @ is part of the string but in either case there should be no validation of the macro and no error thrown. Now outside of quotes with proper concatenation, that is another story.
I agree with the "Strict" principle but it should be on by default and sloppy coders should have to explicitly turn it off. That is how most of the SetOption() switches should be, most strict by default.
|
Richard H.
|
| (KiX Supporter) |
| 2006-08-22 03:48 PM |
|
Re: Erroneous Macro Results
|
I guess I'm missing something. Why do you think that KiXtart should not throw an error on a coding error? With NoMacrosInStrings off a single @ in a string is an introduction to a macro. If you're using it for anything else you've made a typo. As I've demonstrated in the somewhat contrived example in the previous post doing anything other than raising an exception is creating the potential for failures in the future.
The only possible problem that I can imagine that erroring on invalid macros might cause is if anyone has added code to check for macro support, something like:
Code:
If "@FOO" = "<unknown:FOO"
"Sorry, your version of KiXtart does not support the @@FOO macro - please upgrade" ?
Exit 1
EndIf
| Les |
| (KiX Master) |
| 2006-08-22 04:34 PM |
|
Re: Erroneous Macro Results
|
I guess what I am saying is that if you want good error checking, you should be forced to use "Strict" coding, meaning concatenation and no embedding crap in strings. If old school embedding is used them old school forgiving code (as in no error thrown) should accompany it.
It's like the old addage... Good, Fast, Cheap... pick any two.
|
Richard H.
|
| (KiX Supporter) |
| 2006-08-22 04:44 PM |
|
Re: Erroneous Macro Results
|
Ok, but what is the down-side to throwing an error for an invalid macro name? I can't see one.
The script is going to fail either way, but throwing an error is far easier to diagnose than a script which continues to run but does something odd.
Considering the majority of macros-in-strings scripters are likely to be newbies and Shawn I think that something that's in your face saying "you've typed something wrong here" is much more preferable.
|
Shawn
|
| (KiX Supporter) |
| 2006-08-22 04:54 PM |
|
|
Re: Erroneous Macro Results
|
roflmao...
|
Shawn
|
| (KiX Supporter) |
| 2006-08-22 05:02 PM |
|
|
|
Re: Erroneous Macro Results
|
You guys should be very proud of me ... I am getting better ... check-out this script bit:
Re: Map drive by user id.
-Shawn
| Les |
| (KiX Master) |
| 2006-08-22 10:08 PM |
|
Re: Erroneous Macro Results
|
LOL
He uses concatenation on a "temporary" marker line to be used to debug and then throw away.
I was going to reprimand him for going off topic in the beta forum but he's as cute as a lamb and I couldn't bring myself to do it.
Just shoot him, damnit... shoot him!
|
Allen
|
| (KiX Supporter) |
| 2006-09-30 07:40 AM |
|
Re: Erroneous Macro Results
|
I'm not sure how practical this is... but here is a stab at making the script exit on a macro error... Maybe in Version 5 there will be no macros as they are now but are accessed through a Macro(Lookup) function.
Code:
break on
$=setoption("Novarsinstrings","on")
? macro("KIX")
? macro("err")
function macro($name)
dim $ms,$,$colors
$ms=setoption("NoMacrosinstrings","off")
$=execute("$" + "macro='@@" + $name + "'")
if instr($macro,"<unknown:")
$colors=split(@color,"/")
color $colors[0]+ / $colors[1]
"ERROR : Unknown Macro [" + $name + "]" + "!"
color $colors[0] / $colors[1]
quit
endif
$ms=setoption("NoMacrosinstrings",$ms)
endfunction
Produces:
Code:
4.52
ERROR : Unknown Macro [err]!
|
Richard H.
|
| (KiX Supporter) |
| 2006-10-02 09:21 AM |
|
Re: Erroneous Macro Results
|
That would be better as "Quit nn" where nn is an appropriate error code.
KiXtart uses error "1" (Incorrect function.) for an unknown command which would be fine.