On Mon, 2017 May 1 16:37+0000, Thorsten Glaser wrote:
>
> >The credit is good, thank you! For changes like this I'd request mention
> >in an AUTHORS file or the like, but as mksh doesn't have one, that's a
> >moot point.
>
> Well the sum of all people listed in (c) plus some in the manpage, but…
Wherever is appropriate :)
> >Could you elaborate on which parts need updating? While I know more now
> >than I did then, the comment didn't discuss conversion to/from an "ASCII
> >codepage."
>
> I’m not too clear on that myself. I guess you could just check
> what’s still missing, patch-wise, and resubmit that, or something.
> Or not, if we’re good.
I would change "thankfully tend to agree on the code points..." to
"usually tend to agree..." in light of the square-bracket shenanigans,
but that's about it.
> >The first command shows
> >
> > ==> which compiler seems to be used... xlc
> >
> >but uses "cc" for everything, which doesn't work. (On z/OS, "cc" is a
> >K&R-C-level compiler, only used for building ancient code.)
>
> This is expected, this is a detection of the *type* of compiler.
> I’ll change the verbose string to “which compiler type seems…”.
Note that "cc" isn't even the same type of compiler as xlc. The option
syntax is different/incompatible, for starters.
I saw that you put in a change to use xlc on this platform, however, so
this should no longer be an issue.
> It’s used later on, but it could conceivably be optional.
> My perl-foo is not very good either though… I’ll try something.
I remember seeing somewhere that it's possible to make a "use" fail non-
fatally. I think an eval was involved...
> Now on to the tests themselves:
>
[...]
>
> Conclusion: I guess we’re not quite there yet, but I now have more
> input to work with once I have the more pressing issues out of my
> feet. Thanks!
Glad to help! Let me know if you want another go.
> As for ebcdic-soecial: the testsuite already contains a “duffs-device-faux-
> EBCDIC” check which is used in “faux EBCDIC” mode (basically ASCII
> system running with most of the EBCDIC codepaths enabled), just so you
> can see how they can differ; I’m fairly sure the “got” output for duffs-
> device in your testsuite log can be copy/pasted into a “duffs-device-
> EBCDIC” expected-stdout, as it looks correct. So you can play around
> with the tests if you want (otherwise I’ll just do them in batch,
> after fixing the more obvious bugs like why the hell there are ^L and
> ^G in the shell output).
The test suite is pretty much Greek to me :] But looking at the output
of that test, and the raw bytes therein, I would point out that the file
did go through an EBCDIC->ASCII conversion when I copied it out of the
system. If I view the file in less(1) in z/OS, I see e.g.
\072\073\074\075\076\077
<41><42><43><44><45><46><47><48><49><4A>.<(+|&<51><52>
instead of the
\072\073\074\075\076\077
<A0><E2><E4><E0><E1><E3><E5><E7><F1><A2>.<(+|&<E9><EA>
that you are probably seeing. (You may be taking this into account
already, but I wanted to make sure.)
--Daniel
--
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.
