Hi,

We have found what we believe is an issue in xcall TRIM. It looks like it is trimming non-printable characters even if the second parameter is not specified.



EL7: 7.0.1756.2

Credit goes to our friend Kyle for this find and example program.

Thanks,
John

I thought that bug was fixed in 1754.1, but apparently not (or not completely). I'm on the road today but will get to the bottom of it tonight or tomorrow.

OK, thanks Jack

Either I had been out in the sun too long before my response earlier today, or I've been on the road too long now. But if I'm not mistaken, isn't it working the way it is documented . The output for the test program is:

So in other words, with a string consisting of two control characters (chr(20) plus a chr(30))...

XCALL TRIM, build'string$ leaves it alone (since in that mode, it should only remove spaces).
XCALL TRIM, build'string, 1 however teats the control characters the same as if they were spaces, i.e. removes them.

Note that in 1754.0, the rewrite of STRIP and TRIM did result in a bug like the one you describe. But I think it was fixed in 1754.1. Perhaps there was some mixup and it crept back in to 1756.2, but it seems to be working as documented in the latest, 7.0.1757.1, which you can download from the following:

ash-7.0.1757.1-el7-upd.tz
ash70notes.txt

Hi Jack,

OK, thanks for checking into it. We will try the latest and verify it fixes it for us.

Thanks,
John

Hi Jack,

Looks like we have another issue related to this. It looks like XCALL TRIM is now removing tabs as if they were spaces in 7.0.1760.0. In 6.5.1739.2, it did not do this.

Output on 6.5.1739.2:
X=1 / 9
X=2 / 84
X=3 / 69
X=4 / 83
X=5 / 84
X=6 / 9

Output on 7.0.1760.0:
X=1 / 84
X=2 / 69
X=3 / 83
X=4 / 84

I did notice that the A-Shell docs currently state that XCALL TRIM "removes leading spaces, trailing spaces, and tabs". So, not sure if what the proper behavior is.

Right. Unfortunately the specification was never quite clear about whether TABs were to be treated like spaces within the STRIP and TRIM operation, and the in the course of some housekeeping (cleaning, consolidating, optimizing, reconciling the code with the documentation) I made the apparently misguided decision that removing TABs along with spaces was the intent all along. (The older documentation wasn't very explicit about it one way or the other, and the one function that explicitly mentions both spaces as tabs -- EDIT$() -- treats them the same way.)

But I guess we shouldn't be shocked that any change is going to affect someone eventually (although the hope here was that the effect would be a positive one!) Oh well.

The question now is what to do about it. It seems crazy to have independent implementations of the XCALL and function versions of SLEEP and TRIM with slightly different behavior, so I'm not keep on rolling the code back to the way it was. But we can perhaps add another configurable option.

First though, on the assumption that the situation you encountered is at least somewhat rare (i.e. where you want to get rid of spaces but preserve tabs), one alternative would be to use XCALL XSTRIP in place of TRIM...

Unfortunately, even though XSTRIP is considerably more powerful than STRIP or TRIM, it doesn't have a combined option to work on both the leading and trailing ends of the string. (That could be easily rectified though, assuming you are willing to deal with an update, which is going to be the case for almost any other workaround.)

Another possibility, which requires changing your code but doesn't require an update, would be to use REGEX2 for these problematic cases. (It will be left as an exercise for the intrepid reader to come up with the necessary regex patterns.)

A global configurable option, perhaps similar to TRIMCTL would have the advantage of only requiring a single edit to the miame.ini file.

Somewhere in between would be to support additional flags in the optional second argument of XCALL TRIM.

I'm open to any of these.

I may no longer have a proxy vote but if so i would vote to continue the behaviour of the current documentation which indeed DOES state leading and trailing spaces and tabs.

After discussing, we can't find a good example of a situation where you would want to use TRIM and preserve leading/trailing TAB characters if they exist. This came up in some code that is producing a TAB delimited file and was trimming the entire string each time it added a field. The code was easily fixed by using edit$ on only the additional field that was added at each position. So, I am not sure we would vote for a change it this point.

Well at least that seems to reinforce the my perception that in the context of leading and trailing spaces, it was highly unlikely that anyone wouldn't want to include TABs. But I think we may want to at the very least add some kind of warning/clarification to the doc, and point out or add some relatively easy way to remove just the spaces or just the TABs.

Thanks for the follow-up.

FWIW, to make it easier to pivot from TRIM to XSTRIP if you just want to remove spaces (but not TABs), or want to remove some other character(s), 7.0.1760.1 supports a new XSTRIP opcode 9 which combines the actions of 4 (strip leading) and 5 (strip trailing). So to remove all leading and trailing spaces (but not TABs)...

OK, thanks