SEO

Hi,

For many years we've used a little workaround to hold a serial port open, to
allow us to cat large print jobs to a serial printer.

The command is put into /etc/rc.d/8/userdef:

(stty 9600 ixon ixoff -ixany ; while : ; do sleep 3600; done) < /dev/ttya1 &

It runs fine on bootup, but since OS507 (not sure which MP if any first showed
the problem), the sleep command simply stops of its own accord after a time.

On all older versions of SCO OS from 500 upwards, this command stays running for
as long as the system is up.

Any ideas what's causing it to terminate, or another way of doing the same
thing?

thanks
-Rob
robatwork at mail dot com

"Rob S" <robatworkDeleteTheseFourWords@mail.com> wrote in message
news:432a9c89.26582515@giganews.nildram.co.uk...
> Hi,
>
> For many years we've used a little workaround to hold a serial port open, to
> allow us to cat large print jobs to a serial printer.
>
> The command is put into /etc/rc.d/8/userdef:
>
> (stty 9600 ixon ixoff -ixany ; while : ; do sleep 3600; done) < /dev/ttya1 &
>
> It runs fine on bootup, but since OS507 (not sure which MP if any first showed
> the problem), the sleep command simply stops of its own accord after a time.
>
> On all older versions of SCO OS from 500 upwards, this command stays running for
> as long as the system is up.
>
> Any ideas what's causing it to terminate, or another way of doing the same
> thing?

It might be catching a quit or intr signal from the serial port. Try adding a
trap "" 1 2 3
to the subshell, or
-isig
to the stty command.
If that still fails, enclose the whole thing in another while : ; do ( ... ) ; done &
loop.

Bob

Rob S wrote:

> For many years we've used a little workaround to hold a serial port open, to
> allow us to cat large print jobs to a serial printer.
>
> The command is put into /etc/rc.d/8/userdef:
>
> (stty 9600 ixon ixoff -ixany ; while : ; do sleep 3600; done) < /dev/ttya1 &
>
> It runs fine on bootup, but since OS507 (not sure which MP if any first showed
> the problem), the sleep command simply stops of its own accord after a time.
>
> On all older versions of SCO OS from 500 upwards, this command stays running for
> as long as the system is up.
>
> Any ideas what's causing it to terminate, or another way of doing the same
> thing?

It cannot be that the `sleep` command is terminating. If that were the
case, the shell loop would just start another one. It has to be that
the shell loop is somehow terminating.

That script was popular when I started working at SCO Support in 1989.
The reason for the loop was that the `sleep` binary in some old release
of Xenix (old in 1989) only supported sleep arguments up to some limited
number, probably 32767. As I remember it, even in 1989, the then-
current Xenix `sleep` supported a 32-bit argument.

Try changing to:

(stty 9600 ixon ixoff -ixany; sleep 2000000000) < /dev/ttya1 &

2 billion seconds is about 63 years. If the system stays up that long
and someone has to figure out why the ancient serial printer goes wrong,
I'll owe you a nice dinner. ;-}

Taking out the loop simplifies things a lot. The printer's continuing
settings no longer depend on the shell to keep waking up and executing
that loop. In fact, the shell is smart enough in this situation to
"exec" the final sleep -- the shell process disappears, so you have one
less purposeless process (per printer) sitting around in the system.

<deep_background>

Another thing that might not be clear about this sort of holdopen
script: it doesn't really hold the settings you specify. Holding a port
open prevents the driver from resetting its settings back to the driver
defaults. But that initial `stty` command exerts no ongoing force. If
anything else comes along and makes further changes, the holdopen script
holds _those_ settings. That is:

(stty 9600 < /dev/tty123; sleep 10000000) &
# tty123 is now set to 9600 for the next 4 months
# two hours later:
stty 4800 < /dev/tty123
# the `stty 4800` process ends immediately
# but its effects remain: tty123 is now at 4800 for the next 4 months

Most of the OSR5 printer interface scripts do their own `stty` commands,
so the holdopen script is mainly serving to retain _those_ settings from
one printout to the next. Without a holdopen script, the port would sit
at the driver's default settings most of the time, except when a
printout was in progress.

Some versions of the holdopen look more like this:

(while :; do stty 9600 ixon ixoff -ixany; sleep 3600; done) < /dev/ttya1 &

Putting the `stty` inside the loop means that its settings _do_
occasionally get slammed onto the port -- whether or not a print job is
currently active. This could either have no effect (if the interface
script is leaving those settings in effect, or if it's using compatible
ones); or disastrous effect (suppose the interface script -- and the
printer, of course -- is actually using 19200 bps). Or it could have a
mysterious effect (maybe the interface script actually uses hardware
flow control, and the printer has buggy XON/XOFF that sends ^S to
throttle input but forgets to send ^Q to continue it. The print jobs
will usually work OK, but once in a while the hour will be up, the
holdopen will poke in XON/XOFF settings, and the printer will suddenly
lock up...)

Finally, you don't need a separate holdopen script for each printer.
One process can hold open a large number of file descriptors. It's
clumsy to hold more than 7 open in a single shell script, though, so
it's easier to reduce the number of holdopen processes by a factor of 7
than it is to drop all the way down to one system-wide holdopen process.

Change this:

(stty 9600 ixon ixoff -ixany; sleep 2000000000) < /dev/ttya1 &
(stty 4800 ixon ixoff -ixany; sleep 2000000000) < /dev/ttya2 &
(stty 19200 ixon ixoff -ixany; sleep 2000000000) < /dev/ttya3 &

to this:

exec 3</dev/ttya1 4</dev/ttya2 5</dev/ttya3
stty 9600 ixon ixoff -ixany < /dev/ttya1
stty 4800 ixon ixoff -ixany < /dev/ttya2
stty 19200 ixon ixoff -ixany < /dev/ttya3
exec sleep 2000000000

The first line uses Bourne shell syntax to open the three ttys. Those
file descriptors will remain open as long as the shell (or any child it
has passed them to) is running. Then we apply the various initial
settings, knowing that they'll "stick" because we're holding open the
ports. Finally, we go to sleep "forever".

The shell's syntax only allows single-digit file descriptor numbers
here, and it's simpler if we don't mess with fds 0-2. That's why we're
limited to 7 per holdopen script. A trivial C program could do
hundreds.

</deep_background>

>Bela<

On 15 Sep 2005 16:43:00 -0400, Bela Lubkin <filbo@armory.com> wrote:

<lots of fantastic detail snipped>

What can I say other than Wow!

I shall give them a go - thanks very much


-Rob
robatwork at mail dot com

In article <200509151342.aa23956@deepthought.armory.com>,
Bela Lubkin <filbo@armory.com> wrote:


>Finally, you don't need a separate holdopen script for each printer.
>One process can hold open a large number of file descriptors. It's
>clumsy to hold more than 7 open in a single shell script, though, so
>it's easier to reduce the number of holdopen processes by a factor of 7
>than it is to drop all the way down to one system-wide holdopen process.
>
>Change this:

> (stty 9600 ixon ixoff -ixany; sleep 2000000000) < /dev/ttya1 &
> (stty 4800 ixon ixoff -ixany; sleep 2000000000) < /dev/ttya2 &
> (stty 19200 ixon ixoff -ixany; sleep 2000000000) < /dev/ttya3 &

>to this:
>
> exec 3</dev/ttya1 4</dev/ttya2 5</dev/ttya3
> stty 9600 ixon ixoff -ixany < /dev/ttya1
> stty 4800 ixon ixoff -ixany < /dev/ttya2
> stty 19200 ixon ixoff -ixany < /dev/ttya3
> exec sleep 2000000000

When I used to use the scripts a long time ago, I used a separate
sleep value for each instantiation. Thus when I had problems I
knew which 'sleep' task to kill in the ps output as I could
see the different sleep number.

Bill
--
Bill Vermillion - bv @ wjv . com

bv@wjv.com (Bill Vermillion) wrote in news:IMwxny.At3@wjv.com:

> In article <200509151342.aa23956@deepthought.armory.com>,
> Bela Lubkin <filbo@armory.com> wrote:
>
>
>>Finally, you don't need a separate holdopen script for each printer.
>>One process can hold open a large number of file descriptors. It's
>>clumsy to hold more than 7 open in a single shell script, though, so
>>it's easier to reduce the number of holdopen processes by a factor of
>>7 than it is to drop all the way down to one system-wide holdopen
>>process.
>>
>>Change this:
>
>> (stty 9600 ixon ixoff -ixany; sleep 2000000000) < /dev/ttya1 &
>> (stty 4800 ixon ixoff -ixany; sleep 2000000000) < /dev/ttya2 &
>> (stty 19200 ixon ixoff -ixany; sleep 2000000000) < /dev/ttya3 &
>
>>to this:
>>
>> exec 3</dev/ttya1 4</dev/ttya2 5</dev/ttya3
>> stty 9600 ixon ixoff -ixany < /dev/ttya1
>> stty 4800 ixon ixoff -ixany < /dev/ttya2
>> stty 19200 ixon ixoff -ixany < /dev/ttya3
>> exec sleep 2000000000
>
> When I used to use the scripts a long time ago, I used a separate
> sleep value for each instantiation. Thus when I had problems I
> knew which 'sleep' task to kill in the ps output as I could
> see the different sleep number.
>
> Bill


Another way to do it (and it might even be older than '89, I can't
remember!) is to use a process like cat to keep the ports open.

(stty ixon ixoff; cat >/dev/null ) </dev/ttya1 &

We always put these in /etc/rc.d/8/userdef. If a support site
called with garbage on their printers, we always told them that
their cat died

Bela's way with exec sleep 2000000000 is better but I just give
this for some historical context.

Rick

On Fri, 16 Sep 2005 14:29:10 GMT, Rick Palen <rickpalen@hotmail.com> wrote:

-We always put these in /etc/rc.d/8/userdef. If a support site
-called with garbage on their printers, we always told them that
-their cat died

Our customers are notoriously humourless, but I may try that!


-Rob
robatwork at mail dot com

Rick Palen wrote:

> Another way to do it (and it might even be older than '89, I can't
> remember!) is to use a process like cat to keep the ports open.
>
> (stty ixon ixoff; cat >/dev/null ) </dev/ttya1 &
>
> We always put these in /etc/rc.d/8/userdef. If a support site
> called with garbage on their printers, we always told them that
> their cat died
>
> Bela's way with exec sleep 2000000000 is better but I just give
> this for some historical context.

Actually I'd say your way is better. Any length of `sleep` could
eventually time out. Your `cat` has a different termination condition
-- receiving EOF on the tty. Which is highly unlikely if there's
actually a printer attached to it.

It would be even better if there was an input source which the kernel
guaranteed to allow you to open, but which never produced any input.
Similar to /dev/null, but it should never return from read() instead of
always returning EOF.

But for this purpose, one of the printer ports would suffice.

One reason the `cat` might be better is that you can lard it with extra
arguments which will show up in `ps -ef`:

exec </dev/ttya1 3</dev/ttya2 4</dev/ttya3
stty 9600 ixon ixoff -ixany < /dev/ttya1
stty 4800 ixon ixoff -ixany < /dev/ttya2
stty 19200 ixon ixoff -ixany < /dev/ttya3
exec cat - Holdopen script for ttya1, a2, a3

Now I'm using fd 0 (stdin) for the first printer port; shell syntax lets
us use that plus fds 3-9, so now we can do 8 per script. (We could
probably also use fds 1 & 2, but it's safer not to.)

>Bela<

In article <200509161033.aa15294@deepthought.armory.com>, Bela Lubkin <filbo@armory.com> wrote:

>One reason the `cat` might be better is that you can lard it with extra
>arguments which will show up in `ps -ef`:

I seem to recall that in the past you could do the same thing with `sleep`,
until someone 'fixed' it to complain about the extra argument rather than
ignore it.

Bela Lubkin wrote:
> Rick Palen wrote:
>
>
>>Another way to do it (and it might even be older than '89, I can't
>>remember!) is to use a process like cat to keep the ports open.
>>
>> (stty ixon ixoff; cat >/dev/null ) </dev/ttya1 &
>>
>>We always put these in /etc/rc.d/8/userdef. If a support site
>>called with garbage on their printers, we always told them that
>>their cat died
>>
>>Bela's way with exec sleep 2000000000 is better but I just give
>>this for some historical context.
>
>
> Actually I'd say your way is better. Any length of `sleep` could
> eventually time out. Your `cat` has a different termination condition
> -- receiving EOF on the tty. Which is highly unlikely if there's
> actually a printer attached to it.
>
> It would be even better if there was an input source which the kernel
> guaranteed to allow you to open, but which never produced any input.
> Similar to /dev/null, but it should never return from read() instead of
> always returning EOF.
>
> But for this purpose, one of the printer ports would suffice.
>
> One reason the `cat` might be better is that you can lard it with extra
> arguments which will show up in `ps -ef`:
>
> exec </dev/ttya1 3</dev/ttya2 4</dev/ttya3
> stty 9600 ixon ixoff -ixany < /dev/ttya1
> stty 4800 ixon ixoff -ixany < /dev/ttya2
> stty 19200 ixon ixoff -ixany < /dev/ttya3
> exec cat - Holdopen script for ttya1, a2, a3
>
> Now I'm using fd 0 (stdin) for the first printer port; shell syntax lets
> us use that plus fds 3-9, so now we can do 8 per script. (We could
> probably also use fds 1 & 2, but it's safer not to.)
>
>
>>Bela<

I think I'd rather keep 'em separate. If I need to screw with one port,
I can kill its process and not affect the others.

And I think I'd still wrap the whole thing in a "while" - I know the
printer shouldn't send an eof back to me, but sometimes people do go
killing processes they don't recognize, so the "while" would rejuvenate
the cat. Of course they could kill the shell too, but mostly they won't.



--
Tony Lawrence
Unix/Linux/Mac OS X resources: http://aplawrence.com
Geek Yard Sale: http://geekyardsale.com