hat this function will return true for a lot fewer inputs
than the macro
+++ var.c
* Check for upper/lowercase 'X' without resorting to ASCII trickery
* Use the ORD() macro so that these subtractions don't inadvertently
become additions
I will be happy to provide f
xedMisc-20130517.tgz
Nice! If it weren't for the big Web-mail providers seeing fit to display
.signatures in variable-width fonts, there would still be a little ASCII
skunk down below ^_^
--Daniel
--
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.
e user base of the application(s) running on the
system. At the same time, there is z/Linux (Linux on the mainframe), and
most organizations that want a modern mainframe Unix environment---and
no EBCDIC goofiness---just go with that. z/Linux is not an option for
me, however, so we have to confront
ings altogether
> ③ another answer message tackling those things, after I ponder this
> some more (it *is* a brave new world you opened!)
>
> The result of #1+#2 follows.
Ready for it!
> Daniel Richard G. dixit:
>
> >> - what about \u20AC? UTF-8? UTF-EBCDIC?
> >
>
On Wed, 2015 Apr 29 15:42+, Thorsten Glaser wrote:
> Daniel Richard G. dixit:
>
> >I'm working from a system with a UTF-8 locale, but as I'm US-based,
> >pretty much everything is ASCII. The conversion layer, however,
>
> OK, I can see that. Though I’m u
ide the actual environment...
> >(Couldn't get uhr to work with R50 on my Debian system, however...
> >lots of "no coprocess" errors...)
>
> Huh.
>
> tg@tglase-eee:~ $ zcat /usr/share/doc/mksh/examples/uhr.gz | mksh
>
> This works OOTB for me. But you do have to install bc(1) first;
> unlike real Unix systems, absolutely-basic-should-be-everywhere
> tools like bc, ed, uudecode are not installed by default on GNU.
Ah, that was it---bc was not installed.
Very nice hack! I do prefer analog clocks myself.
> Now go get some sleep ;-)
Still working on it...
--Daniel
--
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.
On Wed, 2015 May 6 20:22+, Thorsten Glaser wrote:
> Daniel Richard G. dixit:
>
> Unless we convert EBCDIC to Unicode ourselves (as opposed to letting
> the system do it; I’m currently convinced that we really want to do
> this actually, since we don’t support them all anyway).
have the
limitation/advantage of still being one byte per character. (UTF-EBCDIC
is definitely not a thing in IBM mainframe land)
Anyway, if you need any z/OS testing, feel free to drop me a line ;)
--Daniel
--
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.
f you need any z/OS testing, feel free to drop me a line ;)
>
> Thanks!
>
> I hope to be able to get back to that offer eventually. Glad to know
> you’re still interested after two years.
Mainframes are not a platform for the impatient... at least not if one
has to deal with IBM
great! That'll certainly make EBCDIC easier to deal with.
I might suggest looking at Gnulib, specifically lib/c-ctype.h, for
inspiration. I helped them get their ctype implementation in order on
z/OS (and at one point we were even trying to deal with *signed* EBCDIC
chars, where 'A' has a negative value!), and it works solidly now.
They've got a good design for dealing with non-ASCII weirdness; they
were clearly thinking of that from the start.
Happy hacking,
--Daniel
--
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.
t… there’s CUNLCNV, but it looks extremely… IBM. So
> maybe we can or have to make do with etoa and its limitations…
> probably still enough at this point.
Don't forget that ISO 8859-1 is equivalent to the first 256 codepoints
of Unicode ;)
--Daniel
--
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.
ll break.
These odd encodings should be usable in a 3270 terminal session, the
traditional mainframe UI. But the POSIX environment is a special
case of that.
> When does it error out, too?
It's in the doc. Both failure modes (non-SBCS locale, out-of-memory
condition) should be extremel
Apologies again for the delay; this was a busy weekend for me!
On Thu, 2017 Apr 27 12:01+, Thorsten Glaser wrote:
> Daniel Richard G. dixit:
>
> >I played with this some more, and found what was missing: a call to
> >setlocale().
>
> Oh.
I often forget, the LC_* envv
ally needed?) A log of that is also attached.
(Note: Both output files were produced with ">file.txt 2>&1", so nothing
should have been lost.)
> The new -E option is necessary to enable EBCDIC, I chose to not rely
> on autodetection as we will need this in the te
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
.<(+|&
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.
ound trip.
I don't know if there are use cases where this may yield unintuitive
results... perhaps if this "nega-UTF-8" were redirected to a file and
then processed further in z/OS, that may lead to some surprises. But in
terms of doing something sensible when using a "\u&quo
; UTF-8-converted-as-extended-ASCII-to-EBCDIC) makes sense, or, at
> least, more than not doing it?
Yes, I agree with that. I don't see the usefulness of a shell generating
real UTF-8 in the EBCDIC environment, at least not as the default.
Nega-UTF-8 > UTF-8, in other words, and certainly nega-UTF-8 >> error.
--Daniel
--
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.
particular Yoda quote seems applicable: "You must
unlearn, what you have learned." :-)
--Daniel
--
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.
mksh-build.txt.gz
Description: application/gzip
mksh-test.txt.gz
Description: application/gzip
18 matches
Mail list logo
