Hi

I'm trying to use xcall cgiutl, 2

It works ok from the stdin:
xcall cgiutl, 2, "name", STR1, TMP
and returns the paramval for "name" in STR1 fine!

But adding the optional final string containing the parameter list
xcall cgiutl, 2, "name", STR1, TMP, BIGSTR
where BIGSTR = "name=FRED@town=LONDON"
fails to find "name" and returns -1 in TMP

Is anyone using this successfully?

I'm not sure how to explain this disconnect between the documentation and the actual code. In looking at the source code, I don't see any indication of having ever implemented the optional {,string} parameter. (Perhaps it occurred to me while writing the documentation, but I never got around to implementing it, or maybe it was lost somewhere along the line.)

In any case, I'm all set to implement it as documented, right now in fact, but the $64 question is: are you able to update to the latest version in order to get the fix? (Or are you running on 4.x?) Also, which platform (Windows or Linux)?

Wait, I take that back. The code works, as documented (at least in A-Shell 5.0 - there have been some enhancements over the 4.9 development cycle that may or may not have affected it).

The reason I was confused, and why your test program doesn't work, is that it ONLY works if you previously used XCALL CGIUTL, 1, BIGSTR, STATUS to retrieve the actual CGI stdin. It does not work if you initialze BIGSTR yourself and then pass it along to CGIUTL,2. (So it's not so simple to test.)

So in addition to my previous questions:

Are you trying to use it independent of actual CGI mode and CGIUTL,1?

If so, should I implement the capability? (It might be best to use another opcode, to avoid confusion in the case where both techniques might be used together.)

Hi Jack

Yes you're right we're running behind as usual 4.9.something (still working on the "if it ain't broke don't fix it" premiss).

I can obviously work arround this by scanning the string myself but would make use of cgiutl when we finally get to 5.x.

As to platform - both I'm afraid.

We have installed a 5.x Ashell on a pc but hasn't been finished or tested yet.

I am trying to use it in cgi mode but haven't called cgiutl, 1.

I was trying to use it to seperate out the parameters from the query string from a FORM GET not POST. The string to be scanned comes from the environment variable QUERY_STRING.

Would it work if I called cgiutl, 1 even if I knew there was nothing in it?

No, you can't just get away with a dummy call to CGIUTL,1. The implementation here could stand some improvement, but what happens is that CGIUTL,1 copies the stdin into a holding area and then decodes it (mainly just a matter of replacing special HTML-encoded characters). The CGIUTL,2 then reads the input from the holding area, regardless of whether you specify the {,string} parameter. (So I was partly wrong when I said it worked as documented.)

If I understand you correctly, you want to use the routine to decode something independent of the stdin string, in which case it really ought to work as advertised (meaning that you could pass it essentially any string provided it was properly formatted.)

There's a further complication though - the stdin string uses "&" as a delimiter, and CGIUTL,2 counts on this to identify the end of each value. I take it from your example that the QUERY_STRING uses "@". So perhaps a new opcode which was like CGIUTL,2 but which allowed you to specify the delimiter would be good? (Assuming of course you want to get up to date.)

Another approach might be to use XCALL STRTOK. You could call it once to tokenize the QUERY_STRING into a bunch of "name=value" pairs. Then you'd still need to use a string comparison on each one to find the name in question, but I suspect that your typical case might involve retrieving all the "name=value" pairs anyway, in which case this might be an efficient approach.

(As an enticement to update to 5.0, the new SWITCH construct works nicely in conjunction with STRTOK for this kind of thing. Not to mention the user-defined functions, which would allow you to create a function that worked like you expected CGUITL,2 to work.)

Sorry, that was my typo the example should have been "&" not "@". The QUERY_STRING is the string you would see in a browser Page Address (Navigation) field.

QUERY_STRING also contains the same special HTML-encoded characters as the stdin so I was hoping it would translate those as it does from stdin. The FORM GET & POST return the same info in the same format but it just comes from a different source - QUERY_STRING instead of stdin.

If cgiutl worked as documented with the added advantage of translating the special HTML-encoded characters in the same way as if from stdin it would be perfect! From your description of strtok I assume it wouldn't perform this translation?

About strtok, that's correct - it doesn't have any decoding/translation of the HTML-encoded characters.

Thanks for the clarification on QUERY_STRING - I wasn't quite sure about the details there.

I take it that you have some reason to prefer GET over POST. Unless it's a trade secret, it might provide some insight to know what the reasoning is.

As a somewhat coincidental aside, which may or may not relate to your interests, our Portuguese "Powerhouse" (Firmaware) has just in the last week figured out how to adapt the A-Shell/Windows CGI interface to the ASPX model. We hope to document the details of that sometime in the near future.

I'll proceed to implement the CGIUTL,2 function as documented, and/or as necessary to accommodate what you are doing. As I'm not quite sure about the ideal test environment, can we start with one platform, ideally A-Shell/Windows 5.0, and then once you verify that it works as expected, replicated to the others?

We use both GET & POST - no preference.
GET is easier to embed in HTML documents for short links with few additional parameters and no user interaction. As we do use both GET & POST thats why it would be useful to have cgiutl which works the same on either.

I don't know much about aspx, never had any reason to look at it - but would be interested in any extension to the cgi interface.

If I get a vote on the first platform it would be Linux as thats my development system, for windows I have to commandeer a system...

OK, Linux it is. I'll have something for you to test by Monday. (By the way, which Linux distribution/version are you using?)

I retrofitted the patch (to make CGIUTL,2 work as documented) into the latest 4.8 legacy versions (on the assumption that that's where you really want to test it. I'd certainly prefer to get you to update to 5.0, and although I'm not above using a bug fix to accomplish that, it would seem a bit underhanded when the bug in question contradicts the documentation so clearly as in this case.)

Anyway, the updated executables can be found at:

http://www.microsabio.net/dist/48rel/ash-4.8.845.4-rh8x-upd.tz (RH 8 dynamic link version)
http://www.microsabio.net/dist/48rel/ash-4.8.845.4-lnx-upd.tz (Generic / Static link version)

Also: The Release Notes

Let me know if that resolves the issue and I'll proceed to include the same patch in the 5.0 release.

Is there a reason you've gone back as far as ashell 4.8?

When you asked me what version we were using I said 4.9.something (it is in fact 4.9(923)-2). I'm afraid we may start hitting other problems if I go back to 4.8.

Good point, I was confused, think that you weren't keen on going to 5.0, and thus assumed that the only alternative for going back in time to make a fix was to the prior stable version, 4.8. And I do agree with you, going back to 4.8 is likely to be more traumatic than moving forward to 5.0.

I'm not sure we can go back to the vicinity of 4.9(923). I have pretty extensive backups, but the system is based around one active development version (which changes frequently) and the stable version, for which a snapshot of the entire development environment is maintained for years, to support the ability to go back and apply a patch to a version what people are still running years later (presumably because stability is paramount to them).

Although I have a series of incremental backups of the development version, the purpose is to allow me to review the changes in a particular module, in order to understand bugs that development along the way, or to roll back some change. But the scheme is not intended to support the ability to go back to an arbitrary point several months ago. Instead, with the development version, we just keep moving forward. That is, if you discover a bug in 4.9(xxx), it gets fixed in the next 4.9 patch, even if that means you have to jump forward a hundred edits or so. (Being on the development version requires acceptance of the idea that you can always update to the latest version.)

Officially, 4.8 is the retired stable version, having been replaced by 5.0. 4.9 was interim development version which eventually got renamed to 5.0 when we decided (prematurely as it turns out) that has reached a state where it would be most useful if remained fixed (with new development starting with 5.1 version).

So, at this point, can I interest you in updating to 5.0? I can apply the patch in 5.0.992.4 and release it today.

In any case, I've posted 5.0.992.4 updates of A-Shell/Linux, in rh8x and generix linux flavors, and in complete install (bin), executable only (tz) and Update Center (ashupd.lit) packages, if you'd can be lured into taking the bait.

The A-Shell/Windows versions are also posted, and the other flavors should come along in due time.

(Note that you can test the CGIUTL,2 function with the STRING argument without evening being in CGI mode.)

For manual downloading, the packages can be found in the various subdirectories of:

http://www.microsabio.net/dist/50rel/