I'm pretty sure this isn't an AShell issue, but actually an issue with some of our older programs, but I'm putting it out there in case it helps anyone else.

We've got a few older browser-based options that are executed via CGI files, and output via standard print statements, rather than using the CGI flag and standard out.

We've been updating our systems to deal with the Meltdown issue, and these options were generating server errors as it appears the older version of linux we were running was tolerant of the output being preceded by the AShell command line argument being printed before the rest of the output.

We found a fix easy enough (either convert to using the CGI flag, or just offset the output by 1 line), and the CGI option isn't impacted at all, but it had us scratching our heads for a bit until we found the cause, so thought I'd share it in case it saves anyone else some time!

If I understand the situation correctly, you had some old programs that, although being launched in CGI mode by the web server, were not using the -cgi command line flag, and instead were just using ordinary PRINT statements to create the new web page output. (Just to restate what might be obvious here: in A-Shell/UNIX, unlike A-Shell/Windows, ordinary output sent to the screen, i.e. PRINT statements, is in fact stdout.)

The problem which you encountered is that in addition to your explicit PRINT statements, A-Shell also outputs some initial "junk" (such as echoing the startup command line, and maybe some terminal emulation-related ESC sequences). That junk was certainly not respecting the specifications for how the output of CGI process is supposed to begin. Some older web servers weren't really that persnickety about enforcing such rules, but newer ones almost certainly are.

I'm not sure if it should be considered an Ashell issue or not. On the one hand, what might appear as "junk" to the CGI server may be otherwise quite reasonable to a "normal" terminal client. On the other hand, it could be argued that there should be a way to stifle such extraneous initial output, allowing your program to have 100% control over the entirety of the stdout stream. The -cgi switch already provides one method of accomplishing that, but at the cost of forcing you to change all your PRINT statements to CGIUTL calls. And that would seem especially circuitous if the objective, rather than being CGI, was to use an AShell command in a piped series of commands (where any such junk might cause other problems).

After a bit more investigation, I think I've confirmed that you can create a "clean" stdout session by explicitly specifying the "dumb" terminal driver, i.e. -td dumb . (The -q switch will also stifle the initial output, allowing it to be turned back on again by the CMD/DO file :R or :T commands, although you might still have terminal emulation ESC sequences to deal with.)

To create an AShell command that generates "clean" stdout, you would probably have to create a CMD file wrapper for it, mainly to make sure the command gets logged in. So for example:

(In the above example, I'm using VER.LIT to output a simple one-line message; in your case it would have been RUN SOMEPROG.)

Warning: when using the above technique for unattended commands, make sure that AShell is going to exit on its own, i.e. by specifying the -e switch or perhaps we should have added an explicit HOST to the CMD file. Otherwise the session may end up in a sort of limbo, without you being able to see what the problem is.

As you can hopefully see, the ashell command didn't output anything to the screen (the stdout being redirected), and the foo.lst is "clean", i.e. devoid of any initial startup command or other AShell administrative output junk.

So it might have been that you could have worked around the problem by just adding -td dumb, or maybe even just -q to the command line.

But it was probably a good exercise to modernize those old programs anyway!

Thanks for the interesting post.

You're exactly right Jack. It's certainly not an AShell issue, this is very much an artefact of some older programs not doing things the correct way, and being able to get away with it due to less strict older servers.

I wasn't aware of the -td dumb switch, and that would certainly solve it. I'd actually just redirected the output through Tail and cropped the first line of content myself as a quick fix! Modernising the older programs is on our list of things to do, but a quicker fix is more immediately useful.