xtod vs: lponlcr

Jeff Hyman

unread,

Nov 27, 2002, 12:46:23 PM11/27/02

to SCO Mailing List

Hello all,

I have a customer that is having a stair-stepping output issue
to the printer. I am not new to this problem and even have a FAQ
on the topic. My question has to do with command '/usr/lib/lponlcr'
which I am not familar with. I have no 'man' pages on this command.
I am most interested in finding out how it compares to what 'xtod' does...
if they are even comparable commands.

Best Regards,
Jeffrey Hyman, President
.--.
___________________________ .-. | | _____________________________________
Lone Star Software Corp. | | | | .-. Home of World Famous LONE-TAR(tm)
Cactus International, Inc. | |_| | | | Backup Software for UNIX and LINUX
Sales: 800.525.8649 _ |___ |_| | 24x7 Support Available
Support: 301.829.1622 _| ~- | ___| RESCUE-RANGER(tm) and AIR-BAG(tm)
http://www.LONE-TAR.com \, _} | | Disaster Recovery Software
-------------------------- \( -- | | --------------------------------------
| |

Bela Lubkin

unread,

Nov 27, 2002, 1:11:37 PM11/27/02

to sco...@xenitec.on.ca

Jeff Hyman wrote:

> I have a customer that is having a stair-stepping output issue
> to the printer. I am not new to this problem and even have a FAQ
> on the topic. My question has to do with command '/usr/lib/lponlcr'
> which I am not familar with. I have no 'man' pages on this command.
> I am most interested in finding out how it compares to what 'xtod' does...
> if they are even comparable commands.
>
> # lp -dprinter_name ascii_file
> # cat ascii_file | lp -dprinter_name
> # cat ascii_file | xtod | lp -dprinter_name
> # cat ascii_file | /usr/lib/lponlcr | lp -dprinter_name

`xtod` and `lponlcr` are very similar. xtod's source is more
complicated because it responds to the name you run it under (xtod or
dtox). lponlcr is _really_ simple. Aside from a ridiculous copyright
statement about how holy and confidential this stuff is, it's just:

#include <stdio.h>

main()
{
register int c;

while ((c=getchar()) != EOF) {
if (c == '\n')
putchar('\r');
putchar(c);
}
}

xtod also: takes an optional single filename to read from instead of
stdin; and appends a control-Z (DOS EOF marker) to the end of the
output.

I believe DOS Merge comes with another set of these utilities, and VP/ix
probably did, and quite a number of utilities have an embedded ability
to do CRLF translation along with something else they're doing (e.g.
`ftp`). It's a very frequent problem for Unix users, so the wheel has
been reinvented many times.

>Bela<

Tony Lawrence

unread,

Nov 27, 2002, 1:18:12 PM11/27/02

to

Jeff Hyman wrote:
> Hello all,
>
> I have a customer that is having a stair-stepping output issue
> to the printer. I am not new to this problem and even have a FAQ
> on the topic. My question has to do with command '/usr/lib/lponlcr'
> which I am not familar with. I have no 'man' pages on this command.
> I am most interested in finding out how it compares to what 'xtod' does...
> if they are even comparable commands.
>
> # lp -dprinter_name ascii_file
> # cat ascii_file | lp -dprinter_name
> # cat ascii_file | xtod | lp -dprinter_name
> # cat ascii_file | /usr/lib/lponlcr | lp -dprinter_name

xtod adds a CTRL-Z and lponlcr does not.

--

Please note new phone number: (781) 784-7547

Tony Lawrence
Unix/Linux Support Tips, How-To's, Tests and more: http://aplawrence.com
Free Unix/Linux Consultants list: http://aplawrence.com/consultants.html

Tom Parsons

unread,

Nov 27, 2002, 1:20:27 PM11/27/02

to sco...@xenitec.on.ca

Jeff Hyman enscribed:

/usr/lib/lponlcr adds a carriage return to every newline

xtod add a carriage return to every newline AND appends a ^Z, which
is supposed to be the ms-dos end of file character.
--
==========================================================================
Tom Parsons t...@tegan.com
==========================================================================

Tony Lawrence

unread,

Nov 27, 2002, 1:36:54 PM11/27/02

to

Bela Lubkin wrote:
> Jeff Hyman wrote:
>
>
>> I have a customer that is having a stair-stepping output issue
>>to the printer. I am not new to this problem and even have a FAQ
>>on the topic. My question has to do with command '/usr/lib/lponlcr'
>>which I am not familar with. I have no 'man' pages on this command.
>>I am most interested in finding out how it compares to what 'xtod' does...
>>if they are even comparable commands.
>>
>># lp -dprinter_name ascii_file
>># cat ascii_file | lp -dprinter_name
>># cat ascii_file | xtod | lp -dprinter_name
>># cat ascii_file | /usr/lib/lponlcr | lp -dprinter_name
>
>
> `xtod` and `lponlcr` are very similar. xtod's source is more
> complicated because it responds to the name you run it under (xtod or
> dtox). lponlcr is _really_ simple. Aside from a ridiculous copyright
> statement about how holy and confidential this stuff is, it's just:
>
> #include <stdio.h>
>
> main()
> {
> register int c;
>
> while ((c=getchar()) != EOF) {
> if (c == '\n')
> putchar('\r');
> putchar(c);
> }
> }
>

Uh-oh. Disclosing intellectual property :-)

You'd think (given it's intended use) that it would be smart enoufgh to
see if the file really is text before munging the output. If it did
that minor little thing, it could be safely included anywhere and
everywhere as extra \r's are harmless.

Jean-Pierre Radley

unread,

Nov 27, 2002, 1:38:34 PM11/27/02

to ScoMisc [c.u.s.m]

Jeff Hyman typed (on Wed, Nov 27, 2002 at 05:46:23PM +0000):

None of those 'cat' commands are needed, Jeff!

My experience is that xtod adds a ^Z at the end of the file, lponlcr does
not.

--
JP

Tony Lawrence

unread,

Nov 27, 2002, 1:56:54 PM11/27/02

to

For lponlcr cat (or something) is necessary - that's a filter only,
takes no Args.

Jeff Hyman

unread,

Nov 27, 2002, 2:11:18 PM11/27/02

to SCO Mailing List

^^^
JP,
I wonder if I am subliminally attracted to cat.
Ever since my wife Crissy has allowed cats in the house,
I have dreams where I take a pipe '|' and clobber the cat.
Unfortunately I cannot get away with 'rm cat'.
I cannot relocate cat outside to '/dev/null'.
I can't even get away with putting an arrow in the cat ... '> cat'

You just got married. I'm sure you'll have (if not already)
some fantastic war/bedtime stories about cat. :-)

- Jeff

>
> My experience is that xtod adds a ^Z at the end of the file, lponlcr does
> not.

PS: Thanks to all for the informative answers. It was very helpful.

> --
> JP

Jean-Pierre Radley

unread,

Nov 27, 2002, 2:23:32 PM11/27/02

to ScoMisc [c.u.s.m]

Tony Lawrence typed (on Wed, Nov 27, 2002 at 01:56:54PM -0500):

Input redirection is just fine; 'cat' is not needed.

--
JP

Scott McMillan

unread,

Nov 27, 2002, 2:28:57 PM11/27/02

to

On Wed, 27 Nov 2002 17:46:23 GMT, Jeff Hyman <sco...@cactus.com>
wrote:

lponlcr appears to do what the stty onlcr option does - Maps NL to
CR(/LF?) Found Jeff Liebermann posting about it here:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=ie38isgar0kiohlgg74i6aqsdnrp8odovt%404ax.com

How it differs from dtox I do not know. Maybe Jeff would like to
tackle that one ?

Scott McMillan

Bela Lubkin

unread,

Nov 27, 2002, 5:16:29 PM11/27/02

to sco...@xenitec.on.ca

Tony Lawrence wrote:

> >># cat ascii_file | /usr/lib/lponlcr | lp -dprinter_name

> You'd think (given it's intended use) that it would be smart enoufgh to

> see if the file really is text before munging the output. If it did
> that minor little thing, it could be safely included anywhere and
> everywhere as extra \r's are harmless.

Sounds simple, but... accurately detecting "text" isn't really all that
easy. If you define it as US-ASCII text (chars 20-7E hex + CR LF TAB
and maybe a couple of others), sure, it's easy. Throw in a couple of
diacriticals and it gets worse. Throw in full ISO8859 and it's a lot
worse. And there are even more character sets. The simple 10-line
program is suddenly 350 lines of analysis + 10 lines of work -- and the
analysis is only right 98% of the time.

Do you really want that?

>Bela<

Tony Lawrence

unread,

Nov 28, 2002, 6:05:57 AM11/28/02

to

I've needed it now and then, and have used "file" to decide whether or
not to use it. Dunno how easy it is to fool "file" but it worked ok for
whatever I needed it for at the time.

Jeff Hyman

unread,

Nov 28, 2002, 12:13:37 PM11/28/02

to SCO Mailing List

Good feedback on the topic. What actually occurs (behind the scene)
to cause one to need to use 'xtod' or any other filtering process?
It is so rare that I see it needed, that I'd be curious as to the
"source" of the problem. IOW: What low-level process is in charge of
how lines end in an ascii file? Why would it occur so infrequently
on a same Ver/Rel of an OS?

-- Jeff Hyman

Jean-Pierre Radley

unread,

Nov 28, 2002, 12:45:21 PM11/28/02

to ScoMisc [c.u.s.m]

Jeff Hyman typed (on Thu, Nov 28, 2002 at 05:13:37PM +0000):

Nothing occurs behind the scenes. Text file line endings in Unix have
always been 0x0a, AKA LF. You don't wnat to send that to a screen
without adding a CR (try 'stty -onlcr' and cat a file...), and you may
or may not want send just an LF to a printer. Many printers allow a
setting to add a CR to an LF, but if they don't, you want to do it in a
software filter before the bytes hit the printer.

--
JP

Bela Lubkin

unread,

Nov 29, 2002, 3:30:58 AM11/29/02

to sco...@xenitec.on.ca

Tony Lawrence wrote:

> Bela Lubkin wrote:
> > Tony Lawrence wrote:
> >
> >
> >>>># cat ascii_file | /usr/lib/lponlcr | lp -dprinter_name
> >
> >
> >>You'd think (given it's intended use) that it would be smart enoufgh to
> >>see if the file really is text before munging the output. If it did
> >>that minor little thing, it could be safely included anywhere and
> >>everywhere as extra \r's are harmless.
> >
> >
> > Sounds simple, but... accurately detecting "text" isn't really all that
> > easy. If you define it as US-ASCII text (chars 20-7E hex + CR LF TAB
> > and maybe a couple of others), sure, it's easy. Throw in a couple of
> > diacriticals and it gets worse. Throw in full ISO8859 and it's a lot
> > worse. And there are even more character sets. The simple 10-line
> > program is suddenly 350 lines of analysis + 10 lines of work -- and the
> > analysis is only right 98% of the time.
> >
> > Do you really want that?
>
> I've needed it now and then, and have used "file" to decide whether or
> not to use it. Dunno how easy it is to fool "file" but it worked ok for
> whatever I needed it for at the time.

A file that starts with text and continues with gibberish will be
labeled text (cat /etc/termcap > /tmp/foo; compress < /etc/termcap >>
/tmp/foo; file /tmp/foo). Files in medium-exotic localized character
sets will probably not show up as text, but would need CR's added to be
printed correctly.

So now you're looking at an override flag ("look you stupid program,
this file _really is_ text, go ahead and add CRs like I told you"). But
then what's the difference between having a program that sometimes adds
CRs, unless you override it and make it always add CRs; and a program
that always adds CRs? You're back to needing to individually decide,
for each file, how to handle it. Instead of "do I pipe through lponlcr
or not", now the question is "do I pipe through lponlcr or through
lponlcr -yesIamsure".

No gain.

No matter how sophisticated you make the decider, there will be corner
cases that break it. Meanwhile, the more sophisticated the behavior,
the more mysterious it will be when it does fail. Suppose you piped
everything through lponlcr, and it generally "worked" on binaries
(didn't trash them). Then one day something got trashed. Would you
suspect lponlcr? Suppose you did. How would you test it? Run some
various binaries through it? It would pass them cleanly, since they
weren't the corner cases. Your debugging process would be painful.

The correct solution is: don't pipe everything through a filter intended
for particular data types! For instance, use an interface script which
takes arguments like "-o raw", meaning "don't do anything weird such as
piping through lponlcr" -- and _use_ that flag when you need to.

>Bela<

Tony Lawrence

unread,

Nov 29, 2002, 6:47:39 AM11/29/02

to

Probably Jeff is still left wondering why it is sometimes needed and
sometimes not. The answer is that in many setups it doesn't matter
because the printer is already doing CR/LF translations itself, or the
data is being sent in a graphic format that doesn't need it, or an
interface script is handling it in another way (example hpnpf and -N
-N). or the script does stty onlcr. And of course you absolutely don't
want it if you are sending Windows jobs to a Visionfs/Samba printer.

Bill Vermillion

unread,

Nov 30, 2002, 12:27:12 PM11/30/02

to

In article <m18H7ag...@cactus.com>,
Jeff Hyman <sco...@cactus.com> wrote:

> I wonder if I am subliminally attracted to cat.
>Ever since my wife Crissy has allowed cats in the house,
>I have dreams where I take a pipe '|' and clobber the cat.
>Unfortunately I cannot get away with 'rm cat'.
>I cannot relocate cat outside to '/dev/null'.
>I can't even get away with putting an arrow in the cat ... '> cat'

They are already dimensioned into an array with a size of 9.

Bill
--
Bill Vermillion - bv @ wjv . com

Bob Meyers

unread,

Nov 30, 2002, 6:55:19 PM11/30/02

to

"Jeff Hyman" <sco...@cactus.com> wrote in message
news:m18H7ag...@cactus.com...

> I wonder if I am subliminally attracted to cat.
> Ever since my wife Crissy has allowed cats in the house,
> I have dreams where I take a pipe '|' and clobber the cat.
> Unfortunately I cannot get away with 'rm cat'.
> I cannot relocate cat outside to '/dev/null'.
> I can't even get away with putting an arrow in the cat ... '> cat'

Try Domination Option Grepper, aka DOG, in Unix tradition, it is called just
plain dog.