Hi All,

I use GoldED+ to read and edit messages, and Squish to process them. After Squish runs, I end up with two tearlines in the outgoing .PKT, the one that GoldED+ adds, followed by a blank line, followed by the one Squish adds. Is this the expected/desired behavior?

I've been through squish.doc and don't see a way to turn tearlines off altogether. I'd like to have GoldED+ add the tearline, and let Squish add the origin line.

Thanks for any help, hope this echo isn't totally dead...

Daniel

... Vermont USA: 9 months of winter, 3 months of damned poor skiiing

--- Squish v1.11
* Origin: ò Almost At The Top Of The Hill ò Newfane, VT USA ò (1:132/505)

Hello Daniel,

On Sat 2012-Dec-22 07:17, Daniel Torrey (1:132/505) wrote to All:

I use GoldED+ to read and edit messages, and Squish to process them.
After Squish runs, I end up with two tearlines in the outgoing .PKT,
the one that GoldED+ adds, followed by a blank line, followed by the
one Squish adds. Is this the expected/desired behavior?

Which version of Squish, which operating system?

I've been through squish.doc and don't see a way to turn tearlines
off altogether. I'd like to have GoldED+ add the tearline, and let
Squish add the origin line.

Don't think there is, according to docs squish will only add tear and origin if
it doesn't see valid tear and origin in
the message when it's processed.

FIrst thing I note is your squish is using the undersc ore
character, ascii 95 instead of the regular dash character,
ascii 45.

A valid tear should be three dashes, or three ascii 45. I'm seeing a group of 3 ascii 95 chars in the tear line your
squish appended, no golded tear line though.




Regards,
Richard
---
* Origin: (1:116/901)

Hi Richard,

Which version of Squish, which operating system?

It's Squish/386 version 1.11, running on DOS. Well, actually, running in a DOXBox window, which is running in a Windows 7 VM, which is running in Parallels Desktop on a Macbook Pro, which is running OS X 10.8.2. Why do it the
easy way? :-)

FIrst thing I note is your squish is using the undersc ore
character, ascii 95 instead of the regular dash character,
ascii 45.

Interesting. Squish is putting in whatever it wants to by default; I'm not defining a tearline anywhere, just an origin line. If Squish thinks that ASCII 95 is the correct character to use in the tear, that would explain why it's adding one even if there's a previous (ASCII 45) tear in the message, added buy
GOldED+ - if Squish is looking for three 95 chars and what's there is 3 45 chars.

There's no GoldED+ tear in the messages I'm sending out because I've configured
GoldED+ to not add one - I don't want to end up with two, which is what was happening when I was testing.

Thanks for your help, I'll see what I can figure out.

Daniel

... Vermont USA: 18th-century charm, 19th-century conveniences

--- Squish/386 v1.11
* Origin: ò Almost At The Top Of The Hill ò Newfane, VT USA ò (1:132/505)

@REPLY: 1:116/901.0 0d7a4410
@MSGID: 1:132/505 50d856e4
@PID: GED+386 1.1.4.7
@CHRS: IBMPC 2

Squish thinks that ASCII 95 is the correct character to use in the
tear, that would explain why it's adding one even if there's a
previous (ASCII 45) tear in the message, added buy GOldED+ - if
Squish is looking for three 95 chars and what's there is 3 45
chars.

FWIW: here's all your control lines above and below so you can see exactly what
is getting out here to the rest of the network ;)

There's no GoldED+ tear in the messages I'm sending out because
I've configured GoldED+ to not add one - I don't want to end up
with two, which is what was happening when I was testing.

two tearlines, while not "pretty" is not bad, either... but your GoldED is using the PID since you've turned off the tearline stuff... PIDs and tearlines with text are a nono according to the PID/TID spec...

Thanks for your help, I'll see what I can figure out.

might need the squish sources and apply some code fixing so it'll either recognize the PID and add an empty tearline or it'll use the TIP instead and have an empty tearline... then one might also add the option to specify stripping the tearline since they are not required by the spec ;)

Daniel

... Vermont USA: 18th-century charm, 19th-century conveniences

___ Squish/386 v1.11
- Origin: ò Almost At The Top Of The Hill ò Newfane, VT USA ò
(1:132/505)

the above modified automatically when quoted... the tearline is now three underscores instead of dashes... the asterisk in the origin line is now a single dash... my editor, TimED, does this automatically so that brain dead tossers don't get confused...

@EEN-BY: 10/1 11/201 331 18/0 19/33 34/999 103/105 109/500 112/0
114/487
@EEN-BY: 116/18 116 901 123/0 52 57 140 500 789 880 1025 128/2 187 @EEN-BY: 132/174 505 135/364 137/10 140/1 154/10 222/2 226/0 600 229/426 @EEN-BY: 230/150 249/303 250/100 306 261/38 100 1406 1466 266/420
@EEN-BY: 266/1413 267/155 280/1027 292/908 298/5 311/2 320/101 119 @EEN-BY: 320/219 322/320 759 340/400 387/22 396/45 633/260 712/848 @EEN-BY: 801/161 189 2320/105 303 3634/12 22 50 5030/1256
@ATH: 132/505 174 320/119 261/38 123/500 3634/12

)\/(ark

---
* Origin: (1:3634/12.42)

Hello Daniel,

On Mon 2012-Dec-24 08:15, Daniel Torrey (1:132/505) wrote to Richard Webb:

It's Squish/386 version 1.11, running on DOS. Well, actually,
running in a DOXBox window, which is running in a Windows 7 VM,
which is running in Parallels Desktop on a Macbook Pro, which is
running OS X 10.8.2. Why do it the easy way? :-)

<hmmm> Wonder if the mac os might be translating things
funny, lots of things strange there. I run same version,
under dos itself. Others do under various win flavors as
well, so that might have something to do with the problem of wrong character.

FIrst thing I note is your squish is using the undersc ore
character, ascii 95 instead of the regular dash character,
ascii 45.

Interesting. Squish is putting in whatever it wants to by default;
I'm not defining a tearline anywhere, just an origin line. If Squish
thinks that ASCII 95 is the correct character to use in the tear,
that would explain why it's adding one even if there's a previous
(ASCII 45) tear in the message, added buy GOldED+ - if Squish is
looking for three 95 chars and what's there is 3 45 chars.

Hmmm, our mac guys could probably address that one, don't
know where to go for that one, and doubt many of them are
here.

There's no GoldED+ tear in the messages I'm sending out because I've configured GoldED+ to not add one - I don't want to end up with two,
which is what was happening when I was testing.

I'm wondering if through all the vm stuff and then the mac
os that ascii 45 might be interpreted as ascii 95.

Thanks for your help, I'll see what I can figure out.

This one's a new one on me. I know that if squish sees a
msg without an origin line, it will place the one you define at the end of the message, and of course a tear line at that point.

Regards,
Richard
---
* Origin: (1:116/901)

Hello Daniel,

following up a message from Richard Webb to Daniel Torrey:

<hmmm> Wonder if the mac os might be translating things
funny, lots of things strange there. I run same version,
under dos itself. Others do under various win flavors as
well, so that might have something to do with the problem of wrong character.

IS no wrong char, Timed did that so that no message would,
in case it was quoted, show two tear lines, etc. My bad.

I recall having the opposite problem with another creates a
msg from a text file thingy when used in echo areas. That
ver of squish didn't place a tear and origin properly on
messages to echo areas in the manner I tried to use it, so I went with something elseto post echomail.

Sorry about sending you down the garden path re tear line
character. When I look at your message without editing for
a reply your tear line character is correct.

Thanks ML for pointing that out to me btw.


Regards,
Richard
---
* Origin: (1:116/901)