XYplorer Beta Club

Yep, fine new scripting bug!

Fix comes.

admin wrote:Yep, fine new scripting bug!

Fix comes.

That's it: already is gone!

Thanks a lot!

PeterH wrote:

PeterH wrote:ScriptStrictSyntay=1 a small problem

I always use ScriptStrictSyntax=1 (Usually very helpful :-) )

Now, defining a User Defined Function, I forgot the starting {
=> no error shown.
But: the terminating } of an If inside of this function physically terminated the whole function body.

Like (just to demonstrate - $p may be 0, positive or other ):

Code: Select all

Function Func($p)   // here the missing {
 If ($p == 0) {
   text "hallo";
 }
// the previous } cuts off all of the following text!
// script works just up to this line.
 ElseIf ($p > 0) {
   text "Never executed...";
 }
 Else {
   text 'Else';
 }

 Text 'Never reached, too';

I'd say:
either the function should work without the embedding {} - as a normal script does,
or the missing { should be reported.

No

This error is too complex for my modest homegrown parser. A minimum of user smartness is needed in scripting.

TheQwerty wrote:Okay.. opinions on whether this is a bug or not:

Code: Select all

function test() {
  perm $value = rand(0,1000);
  echo "Test set value to $value";
}

test();echo "Script sees value of $value";

First execution main script does not find $value in scope. (Assuming you didn't have a $value PV which I just blew away for you. )
On the second execution it will pick it up correctly.

In other words the calling script is not made aware of permanent variables created by functions.


This can be resolved by bringing the PV into scope before using it (before or after calling test() makes no difference) so it's no big deal, but may need pause for thought.

I think it is a bug. Well, I fixed it, so that kind of makes it a bug by reverse logic.

admin wrote:This error is too complex for my modest homegrown parser. A minimum of user smartness is needed in scripting.

OK: I don't plan to make the same mistake. But you never know

Hm - is it really hard to test, that the first non-comment character after Function Func($p) is {

(Yes: this doesn't test for the ending } - but that's a mistake I didn't make till now )

SC swapnames generates a success status message even if the operation failed (say, the items were UAC protected).

foreach aborts unexpectedly after handling a token containing an odd number of quotes: Separator makes no difference - I ran into it parsing output from GetSectionList with its default CRLF.

TheQwerty wrote:an odd number of quotes:

Apparently only double-quotes.

Interesting to change the 1st line to
$test = 'a|b"c|d|e"|f|g';

For sure "foreach" should handle double-quotes as any other character.
(Like it does with single quotes, as Sammay said.)

PeterH wrote:Interesting to change the 1st line to
$test = 'a|b"c|d|e"|f|g';

For sure "foreach" should handle double-quotes as any other character.
(Like it does with single quotes, as Sammay said.)

Indeed and this shows my description of the bug is incorrect.

Maybe.. foreach incorrectly prioritizes double-quotes over the specified separator causing unexpected behavior, especially when handling unmatched quotes.

I think special handling of double-quotes *would* only make sense, if a pair of them *could* include separators. For me this *would* be the only reason for special handling. But I don't think this would make sense.

If it doesn't make sense, any double-quote should just be handled as any other character. (As is for single quotes.) And as such there's no difference if it's only one ore a pair of them.

PeterH wrote:I think special handling of double-quotes *would* only make sense, if a pair of them *could* include separators.

any double-quote should just be handled as any other character. (As is for single quotes.) And as such there's no difference if it's only one ore a pair of them.

Exactly. There shouldn't be absolutely any difference at all between single and double quotes, outside of (1) variable interpretation, and (2) escaped internal quoting, both cases just require looking at which quotes are enclosing the string.

There's something fishy about double-quotes handling. IIRC, there was another scrpting issue with double quotes very recently.

PeterH wrote:I think special handling of double-quotes *would* only make sense, if a pair of them *could* include separators.

If what you're trying to get at is a way to escape the separator then I don't think quoting is a good method.

Though, I'm not sure there is a good solution either - at least not one which matches the flexibility of specifying the separator.

Doubling the separator would at least be consistent with quoting but the years have shown that to also be extremely confusing to most and it interferes with empty tokens.

Specifying a separate escape pattern could work but at that point we might as well just perform the escaping ourselves rather than have Don cram another argument into every function with a separator.

SammaySarkar wrote:There's something fishy about double-quotes handling. IIRC, there was another scrpting issue with double quotes very recently.

I had the same feeling but the only issue coming to mind was klownboy's quoted-separators become gotos issue which was apparently introduced after 16.40. This bug however appears in that version as well so it's unlikely to be related. (Plus multiple people can recreate this one. )

...but I hope you both didn't get me wrong - I said:

PeterH wrote:But I don't think this would make sense.

So it seems we all think that a double-quote should be handled here as any other character.

SammaySarkar wrote:SC swapnames generates a success status message even if the operation failed (say, the items were UAC protected).

Thanks. Same bug in File | File Special | Swap Names.