Serious shell compatibility issue introduced by update 4

[saimo]

I don't have much time/energies, so I'll be very short.

Before update 4, a script like:

Code: Select all

.key FLAG/S

If <FLAG>
   Dir
EndIf

would execute the Dir command when the script was called with the FLAG parameter. Now, it doesn't happen anymore. Using .bra and .ket doesn't change anything.
It would be great if a fix to this made it to update 5. Thanks in advance

[tonyw]

We've been through this before. Your syntax "if <flag>" is undefined and thus liable to change. The "If" statement demands a comparison, not a single value to test.

I think you mean 'if <flag> NE "" '

[saimo]

We've been through this before. Your syntax "if <flag>" is undefined and thus liable to change. The "If" statement demands a comparison, not a single value to test.

I think you mean 'if <flag> NE "" '

I did not know this had already been discussed before.
The point is that previously that statement was handled in a certain way. The change now breaks all the pre-existing scripts relying on that syntax. Please note that I'm not saying that such scripts do a good thing, nor that it is impossible to fix them: just that, as a matter of fact, those scripts don't work anymore and could cause headaches, especially to less experienced users. Unless there is a superior reason that justifies the change, it would be wise to restore the old behaviour.

[xenic]

@tonyw
As of update4 there is no "NE" argument to the "IF" command. There is a "NOT EQ" argument but that doesn't work either. I suggest you try to find a statement that does determine if the FLAG switch is given. I could only find one way to detect the switch and it works in reverse. Please tell us the correct way to detect if the FLAG switch was used. If you can't then I'd say saimo is right and something is seriously wrong.

EDIT: O.K I guess I was wrong too. The shell docs indicate that the correct test is:
IF <FLAG> EQ FLAG (True if the FLAG keyword was entered)

[Hypex]

[quote="saimo"][/quote]

I found the same as well. I linked a hot-key to a script with FKey and found it wasn't working for some reason. It was a shortcut that would copy text into the clipboard for pasting. Suddenly the clipboard was always blank and I didn't know why. Until I tracked it down.

Looks like I'm not t he only one who used this "illegal" trick. Wish I knew years ago it wasn't meant to be.

[tonyw]

I'm sorry, but I can't find the earlier discussion about this problem. It may even have been on the betatesters' mailing list, but I'm pretty sure it was here somewhere.

I don't use scripts myself so forgive me if I remember incorrectly. IIRC the problem appeared with the release of Update 4. Something was changed (in the Shell or DOS?) to fix a bug, and as a result, some side effect that was not described in the docs was changed.

Programmers and users must not rely on undocumented side effects. Because they are undocumented, they are probably unknown to the developers, not part of the specification and are likely to change accidentally at any time.

In this case, the correct syntax is clearly described in the Shell docs. If someone uses a different syntax, it might produce an error, it might do something exciting and useful, but the fact remains that it could change at any time. This is one of those times.

[ssolie]

EDIT: O.K I guess I was wrong too. The shell docs indicate that the correct test is:
IF <FLAG> EQ FLAG (True if the FLAG keyword was entered)

The shell docs have always been correct.

So far there has only been a couple of bad scripts that are now broken that I know of. Unless this number increases dramatically I don't think it is worth re-introducing the bug.

[saimo]

@tonyw & ssolie

While I fully agree with you that undocumented features should not be relied upon, I beg you to consider that breaking something that used to work consistently, with potentially dangerous effects, in absence of a superior and important reason, is simply not wise. Just, f.ex., imagine if a user has a custom script that deletes file according to a commandline flag (not, it didn't happen to me).
Here the safest and most logical solution is simply restoring the old behaviour and, at the same time, extending the grammar officially to support also the mono-argument test (which, by the way, is also more elegant) - this preserves compatibility and also eliminates all concerns about conformity to documentation.

[samo79]

@saimo

I have to agree ...

[ssolie]

Thank you for your concern but the change will stay until told otherwise.