display vs video sync vs ^L

[brian at aljex.com]

Quoting Kenneth Brody <kenbrody at bestweb.net>:

> Quoting Brian K. White (Wed, 17 Jan 2007 04:48:57 -0500):
> [...]
> > I'm putting
> > Then: printer "destpr"
> > where destpr is a script that captures stdin to a temp file and then
> > runs an rclerk process
> > rclerk .... -r $tempfile <$tty
> >
> >
> [...]
> > printer "destpr"
> > form "someform"
> > printer reset
> >
> >
> > Except... upon returning from the printer command, the screen is left
> > mostly blank except for the bottom of the screen prompts.
>
> filePro isn't expecting to have the screen cleared when you print
> something.
>
> > I tried putting both display and video sync after the printer reset to
> > no effect.
>
> That's because filePro thinks the screen is already up-to-date and
> doesn't need to display anything to refresh it.  Consider what would
> happen with:
>
>     system noredraw "cls"
>
> > I noticed that pressing Ctrl-L does refresh the screen.
>
> Correct.  That forces filePro to clear the screen and redraw it from
> scratch, rather than simply update the things that have changed.
>
> > I failed to find a definitive list of special codes understuud by
> > pushkey to try and push a Ctrl-L from within filepro.
>
> As you mention below, it's "DRAW".
>
> > I finally figured out pushkey "[DRAW]"  by doing "strings rclerk |less",
> [...]
> > the pushkey actually did cause a refresh like Ctrl-L.
> > (I was prepared to find that ctrl-l worked at the os or shell level as
> > part of the tty line discipline and stty settings, and that trying to
> > pushkey from inside fp wouldn't have the desired effect, that it
> > needs to come from the terminal for real, happy surprise it actually
> > works)
>
> The O/S has no concept of what is on the screen.  Some screen managers,
> like "screen", _may_ keep track of this to enable multiple screens on
> one physical display.
>
> Consider what happens if you press Ctrl-L at the shell prompt.
>
> > My question is, is that really the only way to get the screen to redraw?
> > I never like relying on pushkeys. Just seems too Rube Goldberg.
> > The descriptions for display and video sync both say they will redraw
> > the screen, why don't they?
>
> You could do:
>
>     system "cls"

Ahh right.
I remember now. We used to have code a few places that just did system ":" for
just that reason. Forgot that trick.
I guess in this case the pushkey is better than system for the sake of
efficiency.


> (Note the absense of "noredraw".)  This will force filePro to assume
> that the entire screen is invalid, and redraw it from scratch, just
> as it does on Ctrl-L.  Any command will suffice, of course.
>
> > Btw this is @key processing so a screen command isn't indicated.
> > Besides, I tried that and the screen stayed blank. It went into update
> > mode because the cursor went to the place on the screen where the first
> > field would be if it were visible.
> >
> > Also, it would be super duper if there was some way to control how a sub
> > process like a printer command gets run.
>
> What sort of control are you thinking of?
>
> > In this case, after getting all this working, I think I really can't use
> > it anyways because:
> >
> > The sub process is getting run as user filepro.
> > This, (or something) causes the rclerk process to be unable to read or
> > write the tty the user is on.
>
> I can't see how that is possible, as stdin/out/err are already open,
> and simply passed to the child process.
>
> [...]


heres the trail of crumbs I followed....

initially the destpr script just has an rclerk command in it with no special
redirections. Just:
rclerk ... -r $tmpfile
you use the script by just "destpr filename"
ie: Then: system "destpr" < tmpfile
and that has been working fine for years now on numerous sco and linux boxes, at
the command line and in system commands.
It worked in pfprostprint too, but we had to stop using that since
pfprostprint was firing up in places we didn't expect or want.

Then I add the code to detect missing args and capture stdin to a temp file
before running rclerk.

----------------------------------
[ -n "$1" ] && {
        F="$1"
} || {
        F=/tmp/destpr_$$
        cat >$F
        CAT=true
}

rclerk askrept -sblank -u -xa -z destpr -r "$F"

$CAT && rm -f "$F" >/dev/null 2>&1
----------------------------------


At that point, before trying things like using it as a printer command, just
doing echo this is a test |destpr
the script does it's part ok and rclerk runs and displays ok, but when you try
to press keys, they don't go into rclerk. I don't know exactly what happens to
them, but for example, if you press down arrow, the listbox highlight doesn't
move, and some escape code representations appear near the bottom right corner
of the listbox.

so, `tty` is already being captured in /etc/profile, so in /etc/profile.local i
just also export it, and then in the destpr scrtipt I appended "<$tty" to the
rclerk command line.

After that, keyboard input into rclerk works normally even when doing
echo this is a test |destpr, and it didn't break normal usage either.

Next step, drop the script into a filepro printer command.

when I tried to use that, at first there is almost no way to know what happened
other than nothing seems to happen. I added lots of debugging to the script and
determined that everything in the script is running and working normally except
the rclerk command. even directing all stdout/err from rclerk to a file showed
nothing, because apparently tthe shell itself is what encounters an error
trying to open $tty for reading. I was able eventually to capture that error and
see it by
adding a clear to the top of the script and a read junk to the bottom.

So I look at the permissions of the tty (dynamically generated /dev/pts/##)
$ ls -l `tty`
crw--w---- 1 bkw tty 136, 1 2007-01-17 13:58 /dev/pts/1

So, seems obvious enough, filepro doesn't have permission to read bkw's tty, and
looks like bkw should have permission to chmod the tty, which in fact worked.
(part of the debugging mentioned above showed that the script is running as
filepro)

So, after adding chmod 666 $tty to /etc/profile.local, the destpr script now
works fully even when used as a filepro printer command.

Did I miss anything?

Also, another tty oddness,
now that rclerk is fully working from within a printer command...
within the rclerk thats in the in destpr, there are several system
commands. All but one of them continued to work fine in the new mode without
changes. Only one of them is an interactive app, "less", and it's in a pipeline
too, so the system command is system "blah"<file<"|blah |less".
That one didn't work in the new mode even after rclerk itself was fixed.
I could see the data flash on the screen, but it's as if less is exiting as soon
as the data were finished reading in. (no I don't have the command line option
that specifically does that in effect, yes I'm aware of the less env variables
and config files)
In this case, adding ">$tty" to the system command fixed it.
yes, >, not < this time. And now that works too.

--
bkw


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.