HEADSUP: Intended behavior? "$=" creates a variable - KiXtart.org - official site

You are not logged in. [Log In] KiXtart.org website » Forums » KiXtart » Advanced Scripting » HEADSUP: Intended behavior? "$=" creates a variable

Page 1 of 2

1

Topic Options

#64403 - 2002-04-10 02:54 AM HEADSUP: Intended behavior? "$=" creates a variable
Shawn Shawn Administrator Registered: 1999-08-13 Posts: 8611	Folks, This has been posted on the board already (Brian), but I think Ruud's comments at the end of this thread are worthy of re-reading: Intended behavior? "$=" creates a variable This will have a negative impact on folks that have (incorrectly) encoded single $ sign hidden-share strings, eg: This syntax works today: use m: "\\server\share$" but it's incorrect and it won't work in the next release! Just a headsup ! -Shawn [ 10 April 2002, 02:56: Message edited by: Shawn ]
Top

#64404 - 2002-04-10 03:10 AM Re: HEADSUP: Intended behavior? "$=" creates a variable
Les Les KiX Master Registered: 2001-06-11 Posts: 12734 Loc: fortfrances.on.ca	Well... while I don't endorse that loose format, I don't agree with your "Chicken Little" theory either. To the contrary, the way I read it, $ as a string, to quote Ruud, "won't ever be resolved if used inside a string". That should fix rather than break sloppy coding in the next release. _________________________ Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.
Top

#64405 - 2002-04-10 03:17 AM Re: HEADSUP: Intended behavior? "$=" creates a variable
Shawn Shawn Administrator Registered: 1999-08-13 Posts: 8611	My "Chicken Little Theory" ?!?!?!? (heheh)(rofl) No, I was just meaning that when one upgrades to the next version, and realizes that they aren't getting any hidden share maps - this will probably be the cause. Check your scripts before you upgrade kinda thingy. chicken little theory eh ? -Shawn
Top

#64406 - 2002-04-10 03:24 AM Re: HEADSUP: Intended behavior? "$=" creates a variable
Les Les KiX Master Registered: 2001-06-11 Posts: 12734 Loc: fortfrances.on.ca	I think you're missing it there bud. My read on it is that Ruud is going out of his way to make sure that use m: "\\server\share$" will still work in the next release. In fact, it should even work if $="whatever".Re-read the entire thread and see if you draw the same conclusion. _________________________ Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.
Top

#64407 - 2002-04-10 03:50 AM Re: HEADSUP: Intended behavior? "$=" creates a variable
Shawn Shawn Administrator Registered: 1999-08-13 Posts: 8611	Right you are my friend. I had to re-read that about 5 times before it sunk in. So really, everybody is happy. I'm happy because I can now use $= with impunity (hehehe). And since the single $ variable will never get resolved inside a string, nothing will ever break (in the new release). Yep - ok - I'm going to go crawl back under my rock now. -Shawn
Top

#64408 - 2002-04-10 04:01 AM Re: HEADSUP: Intended behavior? "$=" creates a variable
Les Les KiX Master Registered: 2001-06-11 Posts: 12734 Loc: fortfrances.on.ca	As they say, "the proof is in the pudding". We'll see when that next release is out just how well it works. I'm not sceptical, just have empathy for Ruud having to put in all sorts of "work-arounds" to cover various "loose" coding styles. That, and Murphy-proofing is what keeps me from being a real programmer instead of a hacker. Remember when "hacker" was a good term... _________________________ Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.
Top

#64409 - 2002-04-10 05:04 AM Re: HEADSUP: Intended behavior? "$=" creates a variable
Shawn Shawn Administrator Registered: 1999-08-13 Posts: 8611	You mean back in the good old days when a hacker was "someone that knew computers really well" as opposed to "someone that breaks them". I don't know - I think what Ruud is proposing is a good thing. I've been running a few scenarios through my brain - you know - all the different permutations of $'s and double$'s in strings and I really can't think of how it would break anything. Like you say, it should only validate the "bad syntax" thats already out there. And being one of the biggest "$-in-string" offenders there are, I really can't think of a time I ever used the $ sign itself as a variable in a string. So yeah, a good thing all 'round. -Shawn
Top

#64410 - 2002-04-10 07:15 AM Re: HEADSUP: Intended behavior? "$=" creates a variable
MCA MCA KiX Supporter Registered: 2000-04-28 Posts: 5152 Loc: Netherlands, EU	Dear Shawn, You are right. Manytimes we see all kind of code which aren't strictly confirm Ruud's documentation. it - may introduce unknown errors. - may return all kind of compatibilities problems during upgrading to new release. Some examples of not strictly code SetOption(DisableDebugging,off) instead of SetOption("DisableDebugging","off") Shell 'cmd /c setup.exe ' instead of Shell '%comspec% /c setup.exe ? "Info: @userid - @wksta - $message" instead of ? "Info: "+@userid+" - "+@wksta+" - "+$message With the tools "kixref" and "kixstrip" we try to verify the correctness of scripts. In some situations these tools are more correct than kixtart (f.e. WHILE/LOOP endless loop situation by missing LOOP statement). In some situations Ruud can't cover "bad" code. Normally it may not work, but it did. A nice example in the past was the way "how DIM command in Kixtart 3.6x releases was working". Ruud introduces REDIM as workaround. greetings. _________________________ email scripting@wanadoo.nl homepage scripting@wanadoo.nl \| Links \| Summary of Site Site KiXforms FAQ kixtart.org library collection mirror MCA \| FAQ & UDF help file UDF kixtart.org library collection mirror MCA \| mirror USA \| mirror europe UDF scriptlogic library collection UDFs \| mirror MCA
Top

#64411 - 2002-04-10 07:33 AM Re: HEADSUP: Intended behavior? "$=" creates a variable
Lonkero Lonkero KiX Master Guru Registered: 2001-06-05 Posts: 22346 Loc: OK	to this, ONE (read as lonk) would hope that ruud would work out also other chars like @ this way there wouldn't be need to write email addresses exceptionally... cheers, _________________________ ! download KiXnet
Top

#64412 - 2002-04-10 10:05 AM Re: HEADSUP: Intended behavior? "$=" creates a variable
Richard H. Richard H. Administrator Registered: 2000-01-24 Posts: 4946 Loc: Leatherhead, Surrey, UK	I don't think we will see special handling for other metacharacters such as "@" and "%" inside strings, and that is a good thing. The case of "$" being used for a hidden share is manageable as there is no trailing text to be interpreted as a variable name. Mail addresses specifically would be hard to handle. Here's a simple example of how it would be a problem. Say I had a Linux server which in a moment of madness I had named "LSERVER". Should the email address "root@LSERVER.ACME.COM" refer to my Linux server, or my login server? If a bare "@" is treated as a literal you could of course use "root@" + "LSERVER.ACME.COM" for a literal address and "root@LSERVER.ACME.COM" to expand to the login server. It's more natural however to escape metacharacters, so that if you use "root@@LSERVER.ACME.COM" it is quite clear on your intent.
Top

#64413 - 2002-04-11 12:06 AM Re: HEADSUP: Intended behavior? "$=" creates a variable
Lonkero Lonkero KiX Master Guru Registered: 2001-06-05 Posts: 22346 Loc: OK	richard, wasn't it the case allready (which has been spoken by ruud a year ago) that control characters inside string is not interpreted? like $x="12" ? "$x" would give "$x" to console and so it should be also with other control chars. no special handling on just one of those 'cause it makes it still harder to understand when can and when can't use inside of string. _________________________ ! download KiXnet
Top

#64414 - 2002-04-11 12:38 AM Re: HEADSUP: Intended behavior? "$=" creates a variable
Richard H. Richard H. Administrator Registered: 2000-01-24 Posts: 4946 Loc: Leatherhead, Surrey, UK	The use of variables and macros within a quoted string is deprecated but supported. In other words it is bad programming practice and might not work at some future time, but it works now. The only variables that you can't use in a quoted string are arrays and objects if I recall correctly. I think the idea is that parsing strings for variables is expensive in terms of CPU, so Ruud was keen to drop it. The problem is that it would break just about every script in live use From the latest kix2001.doc manual: quote: A string expression can contain up to 32,000 characters. Any macros, or references to environment strings within a string (e.g.: “String with the macro @USERID in it.”) are resolved before the string is evaluated. For compatibility reasons, references to variables inside strings (e.g.: “String with a $Var in it.”) are also resolved before the string is displayed. The only exceptions to this rule are arrays and object references, which can not be used inside strings. To use arrays or object references in combination with strings, you have to use concatenation.
Top

#64415 - 2002-04-11 12:38 AM Re: HEADSUP: Intended behavior? "$=" creates a variable
Jochen Jochen KiX Supporter Registered: 2000-03-17 Posts: 6380 Loc: Stuttgart, Germany	ok, here are my two cents ... I think this intended behaviour has been prepared a long time now ... So it seems to me when I read this little note in the 3.62 ! documentation : quote: ; Old style use of variables inside a string: "Use of a variable $Var inside a string." New, preferred style to use variables in combination with strings: "Use of a variable " + $Var + " inside a string." J. _________________________
Top

#64416 - 2002-04-10 02:04 PM Re: HEADSUP: Intended behavior? "$=" creates a variable
Shawn Shawn Administrator Registered: 1999-08-13 Posts: 8611	I personally don`t think Ruud should change the handling of $vars inside strings. I mean, how many instances of code like this are there out there: $var = readprofilestring("$filename","$section","$key") there is no difference between this: "$filename" and this: "the file is called $filename don`t you know" plus how many times have we seen this on the board - I do it all the time: $snippet = substr("$string",1,5) I do this to protect myself from undefined variables (if memory serves, substr crashes when using an undefined var) and we all seem to have this impression that wrapping $vars in quotes protects us when using long filename variables (which probably isn`t true). Anyway, my 2 cents. -Shawn
Top

#64417 - 2002-04-10 02:11 PM Re: HEADSUP: Intended behavior? "$=" creates a variable
Lonkero Lonkero KiX Master Guru Registered: 2001-06-05 Posts: 22346 Loc: OK	there is also this 32,000 limitation which isn't the case when not using variable inside quotes. you can try it out yourself with something like shawn's $snippet = substr("$string",1,5) grow the $string to more than 32,000 and you see it's not possible to handle it anymore. but if used as $snippet = substr($string,1,5) it still works. am I right or not? _________________________ ! download KiXnet
Top

#64418 - 2002-04-10 02:18 PM Re: HEADSUP: Intended behavior? "$=" creates a variable
Shawn Shawn Administrator Registered: 1999-08-13 Posts: 8611	Lonkero, yup your right - i just tried it and it bombed. good point! That actually explains a few things. -Shawn
Top

#64419 - 2002-04-10 02:21 PM Re: HEADSUP: Intended behavior? "$=" creates a variable
Richard H. Richard H. Administrator Registered: 2000-01-24 Posts: 4946 Loc: Leatherhead, Surrey, UK	Going a bit OT here, but if $string is undefined code: $snippet = substr("$string",1,5) Will return "$stri", probably not what you are after. A better way of handling it is probably: code: $snippet = substr("" + $string,1,5)
Top

#64420 - 2002-04-10 02:26 PM Re: HEADSUP: Intended behavior? "$=" creates a variable
Lonkero Lonkero KiX Master Guru Registered: 2001-06-05 Posts: 22346 Loc: OK	and still the size is limited. how anyone uses undefined variables anywhere? (as I never do it by mistake ) but the better way, as you pointed, is the way it should be handled. if ppl want to perform numeric to string or some other conversions with this kind of handling your ""+$var is the proper way to do it. _________________________ ! download KiXnet
Top

#64421 - 2002-04-10 02:26 PM Re: HEADSUP: Intended behavior? "$=" creates a variable
Shawn Shawn Administrator Registered: 1999-08-13 Posts: 8611	Richard, sorry, I was referring to it bombing under Kixtart 3.63 and below. Its an old habit I picked-up from long ago you know how these things tend to stick with us. Hey Lonk, another great point. Numeric and string conversions, yeah: $number = 0 + $string $string = "" + $number heheh -Shawn [ 10 April 2002, 14:28: Message edited by: Shawn ]
Top

#64422 - 2002-04-11 09:39 AM Re: HEADSUP: Intended behavior? "$=" creates a variable
cj cj MM club member Registered: 2000-04-06 Posts: 1102 Loc: Brisbane, Australia	I actually consider "" to be a semi-function. It is a function in that it returns the contents as a string. that is $string="$anything" $string will be of type String and $anything can be of any time. So, "" converts variables to strings, just like a function. But it doubles as a command that sends data to std out too. so, it is a semi-function (the only one) in my user manual my AUD0.02 cj
Top

Page 1 of 2

1

Previous Topic

Previous Topic View All Topics

View All Topics

Index Next Topic

Next Topic

Moderator: Glenn Barnas, NTDOC, Arend_, Jochen, Radimus, Allen, ShaneEP, Ruud van Velsen, Mart

Hop to:

Shout Box

Who's Online

0 registered and 657 anonymous users online.

Newest Members

M_Moore, BeeEm, min_seow, Audio, Hoschi
17883 Registered Users

Generated in 0.083 seconds in which 0.035 seconds were spent on a total of 12 queries. Zlib compression enabled.

click tracking