Re: XYENC/XYDEC programs - and a curiosity

[wbass@xxxxxxxx]

Carl Distefano wrote on Wed, Jan 7 2009

>One change to XYENC I urge you to consider is to have it
>format its output into lines no longer than 60 or 65
>characters. As it is now, if you paste XYENC output, as is,
>into the body of an email message, the mail program may
>insert CrLf's at arbitrary points in long lines. This foils
>decoding if any of the CrLf's fall within multicharacter
>encodings.

I agree that something needs to be done in this area, particularly since
XYDEC chokes when whitespace is inserted within a multicharacter encoding.
But, since requirements vary a lot as to how a user might want a given
file to be split, I had been thinking that XyWrite XPL programs would be a
better place to put the splitting function. However, I think you're right
-- even if XYDEC adds CRLFs in 'undesired' places, it's a pretty trivial
XyWrite editing exercise to remove them, and not having any if the purpose
of the encoding is strictly email is something of a disaster. So I'll look
at it.

Are the line lengths of 60 and 65 "special"? I think I've heard that over
65 is the length were some email programs will start mangling things -- is
65 a known "magic number" of that description?

In XYENC, it would be far easier to emit the line breaks BEFORE knowing
how big the next packet is going to be. Other than the timestamp packet,
which is 20 bytes but is at the start of the file, the longest unsplitable
packet is four chars ("~ddd" encodings) -- it's okay to split either an
"!" packet (length 3), or a ":" or ";", on a separate line from
whatever
they modify. So I'm thinking I'd split after emitting if the length is 60
or more, which means the longest line would be 63 (a packet of length 4
after a line of length 59), and the shortest (other than the last line)
would be 60.

On another note, I was just playing, but here's an interesting curiousity.
I created the following text file

--------------- clip ---------------
~
~)~>
~~>
'BC~'GT~~M~J~Z
--------------- clip ----------------

and ran it though XYDEC to create test.pm. Then I did

 ldpm test.pm,&z

executed it with a key bound to '&Z'

Now, what does this do? Well remember that XYDEC ignores whitespace, which
includes the CRLF, so the above translates to

)>>

and then goes on with a with a BC, to put the length of S/G A
onto the command line (where the <>s are guillemets).

The curious thing is that the string loaded into S/G A has two
"problematic" characters in it -- a nul (00h) and a 1Ah (EOF). (XYDEC will
of course happily create a file with an EOF in the middle, if told to do
so.)

Anyway, running the test puts '32' on the command line, which is the
entire string, including the nul, the EOF, and the chars after the EOF.
Which means that (a) ldpm did NOT terminate loading the test.pm file at
the EOF in the middle of the string, and (b) the SV embedded command also
did not terminate defining the string (or terminate the program) at the
EOF in the middle of the string. Both are surprises to me.

Even though S/G A has all 32 characters, trying to display them with the
SK primitive doesn't work -- that display terminates at the EOF char.

I'm really rather surprised at being able to introduce an EOF char in the
middle of a S/G string this way, I must admit.

(I already have and use an XPL program that has a SV command with a nul
character in the string that it defines. So I already knew that the LDPM
would preserve such a nul, and that the SV command would accomodated it.
However, using them in an XPL program this way is hazardous, because they
are destroyed when you CALL/EDIT the XPL program (in XY III+, at least).
Keeping the source file in some XYENC format and only producing a working
copy via XYDEC looked promising to me as a way to avoid the risk/problem
of destroying the nul accidentally via editing. Even the XyWrite SAVE
command preserves nuls -- it's only the CALL/EDIT command that destroys
them (in III+).)

This is, of course, is all XyWrite III+. I'd be curious if you get the
same results with XyWrite IV.

Wally Bass