Scripting Bugs

[bdeshi]

In my view it's a bug.

If a separator is provided, it's inserted between items; one extra separator is not added at the end.

If a separator is not provided, "records are returned one per line"; one extra line added at the end => implies an empty item, or an extra separator: bug in either case.

[Filehero]

Hi Peter,

seems we like discussing.

Maybe, if I didn't understand you wrong, you should just use separator <crlf>

That's exactly why I've chosen my example because it clearly show it's a bug. In this special case it's just by accident that the explicit separator happens to have the same semantic as the default one.
Of course, in simple scripts this all doesn't really matter, on those one/two pagers it's merely trial & error anyway. But with larger ones, perhaps including different script files, we all know things can quickly get nasty. Especially when after a long time a ticket enforces you return to the mess you one created.

FH - dreaming of arrays, hashmaps & user-defined functions

[PeterH]

I would be with you, if the sep operand would specify that the default is <crlf> then empty sep and <crlf> would have to be identical.

But separator says: "If missing records are returned one per line."
This is not "identical <crlf>". And a line, even the last, can be ended by a line ending.
So no: for me no

But at the end: Don must decide (or ignore)

Edit: @FH: from you last post our difference seems to be the interpretation of default?

[Filehero]

Edit: @FH: from you last post our difference seems to be the interpretation of default?

Sort of yes. More correct, it is the fact, that a formatting detail is changing the semantic of the function by adding a ghost entry to a list.

[PeterH]

OK: last try to explain my understanding:

Per default the list is a list of *lines* (each ended by crlf).
If you want a list of *tokens* ('records') you must use the separator operand, which is documented to *separate* the tokens. Here no separator follows the last token.

I think, for a list of lines, possibly used for output, the final crlf can be expected, while for a list of tokens, interpreted by script logic, it should not.

As long as this interpretation is possible, I would at least not call it a bug.
OK: if it *is* meant this way, documentation could be a bit more clear for that - to avoid problems with empty operand when looping.

To your last sentence: is it wrong that a formatting detail distinguishes between lines and tokens? A matter of formatting for output or for automated handling?

[TheQwerty]

! SC Property: No longer opened the Shell Properties dialog.

Neither of these examples works in fresh v15.00:

Code: Select all

property(, "<xypath>\<xyexe>"); //show Properties for XYplorer
property(); //show Properties for current item

[admin]

Confirmed and fixed, thanks.

[bdeshi]

there something weird with angle brackets in comparison expressions:

Code: Select all

 echo <get countselected> > 1; echo (<get countselected>) > 1;
 echo 1 < <get countselected>; echo 1 < (<get countselected>);

 echo <xyver> > "12.00.0000"; echo (<xyver>) > "12.00.0000";
 echo "12.00.0000" < <xyver>; echo "12.00.0000" < (<xyver>);

when the part following a < start with <

ed. @Pete: happy now?

[PeterH]

there something weird with angle brackets in comparison expressions:

Code: Select all

 echo <get countselected> > 1; echo (<get countselected>) > 1;
 echo 1 < <get countselected>; echo 1 < (<get countselected>);

 echo <xyver> > 12.00.0000; echo "<xyver>" > 12.00.0000;
 echo 12.00.0000 < <xyver>; echo 12.00.0000 < "<xyver>";

when the part following a < start with <

Basically you seem right: the 2nd and 4th line show wrong results:

But for the last 2 lines: 12.00.0000 isn't a (valid) number, but a string. So I expect it should be quoted.
<xyver> is a variable - no reason to quote. (But not wrong.)
(Sorry )

[admin]

Comfirmed and fixed. Good find!

[bdeshi]

tab('get', 'term') isn't returning VFs. QS is good.

Code: Select all

::goto "<xypath>?exe"; echo tab('get', 'term');goto "<xypath>|exe"; echo tab('get', 'term');

"term": the path including any Visual Filter or Quick Search (same as menu View | Tab | Copy Location Term).

btw, that Copy Location Term also forgets about VFs.

[admin]

Works fine here. Both.

[bdeshi]

I only get the <curpath> , even in ::fresh!

[admin]

OK, it depended on Configuration | Find Files & Branch View | Visual Filters | Show filter information in tab headers.

Next version will always work.

[TheQwerty]

This old bug seems to still exist...

Self and Caller enter a fugue state when Load displays a menu for multiple labels...

Code: Select all

"A" Text "Myself:<crlf>" . Self('script') . "<crlf 2>Caller:<crlf>" . Caller('script');
"B" Text "Myself:<crlf>" . Self('caption') . "<crlf 2>Caller:<crlf>" . Caller('caption');
-
"Sub - Correct" Sub 'A'; Sub 'B';
"Load A - Correct" Load '*', 'A';
"Load B - Correct" Load '*', 'B';
-
"Load A;B - Confused" Load '*', 'A;B';

The results I expect are these:

That they would more closely resemble the results shown for the scripts marked "Correct".

Myself:
Text "Myself:<crlf>" . Self('script') . "<crlf 2>Caller:<crlf>" . Caller('script');

Caller:
Load '*', 'A;B';

Myself:
B

Caller:
Load A;B - Confused