Hello,
Some of the problems faced with the use of lyxpipes are:
1. they must be in a place known to the client
2. they should be in /tmp because their creation in home is not always
allowed
3. they should be "per process" to allow two simultaneously running lyxes
to have clients
4. there should be a way to tell if they are active or if they belonged to
a crashed lyx.
The simplest way to accommodate 2 and 3 is to put them in tempdir,
something like
/tmp/lyx_tmpdir8814Rhtgtj/lyxpipe.{in,out}
This also solves the problem when lyx crashes and don't remove pipes, then
precluding further lyxes to use the pipes unless poor user removes them.
How then 1. could be solved? If the client is being used by an advanced
user, chances are that it is being called by hand. He then can start lyx
with -dbg 1 to know tmpdir and call client as
lyxclient -t /tmp/lyx_tmpdir8814Rhtgtj ...
Normal clients, though, will be spawned by lyx childs (eg. xdvi as with
"inverse dvi search") so the alternative in this case points to set an
environment variable LYXTMP with equal to /tmp/lyx_tmpdir8814Rhtgtj.
Lyxclient reads the environment and then knows how to find the pipes.
Then problem 4. is: user starts lyx and calls preview dvi. Lyx crashes
and, not being aware of this, user calls inverse dvi search. Impatient
because he doesn't see any reaction, he calls inverse dvi search 20 times
more. As a result, he will end up with 21 ugly client processes hanging on
the pipe. The way to solve this problem seems to be to replace pipes by a
local socket:
/tmp/lyx_tmpdir8814Rhtgtj/lyxsocket
so if it is dead and an unwise client tries to connect to it, it will
receive "connection refused" or the like.
So what do you think resurrecting PutEnv()? I could then work in this
migration of lyxpipes to tmpdir and write a compliant client. Further
migration to local sockets could be made in a next step, when inverse
search would be already working.
Regards,
Jo�o.
