Hi Tzafrir,

First, a question: Ignoring for a moment refreshd, do you want the
biditext script to support the --r2l-filename option?

On Tue, 11 Sep 2001, Tzafrir Cohen wrote:

> Hi Emil

> No. refreshd_hook.so shouldn't pass argv to r2l_init(). It is always run
> from another process, with an altogether different argv. If you wantto
> preserve to pass some parameters to refreshd_hook you can do it through
> the environment. See BIDITEXT_OPTIONS in biditext.so . The biditext script
> can try translating command-line options to environment vars.

This is exactly what I did. The original biditext script (well, it was not
a script, it was a C program, but I don't think this matters in any way)
initialized r2llib via r2l_init() and then queried r2llib for a serialized
representation which is the absolute pathaname of the .rev file and set
BIDITEXT_FILENAME to that value. If BIDITEXT_FILENAME is not defined
prior to the script invocation, r2llib will be initialized with the
appropriate defaults, and after that BIDITEXT_FILENAME will be set to the
defaults queried from r2llib.

Maybe I should have used another environment variable instead of
BIDITEXT_FILENAME to pass the r2llib serialization to refreshd_hook.so.
But I thought that BIDITEXT_FILENAME after the above trick contains
exactly the right thing and no harm is done to other applications in any

> >
> > In short it is the task of `biditext' to make sure all the variables are
> > set correctly (including BIDITEXT_FILENAME). Only after `biditext' sets
> > the BIDITEXT_FILENAME variable to the serialization string from r2llib,
> > the rest of the code queries the environment. So the situation in which
> > BIDITEXT_FILENAME should not normally happen.
> r2llib has some defaults in case BIDITEXT_FILENAME is not defined. I don't
> want to replicate this code in a shell script, unless there is a good
> reason. In this case refreshd_hook can simply query r2llib.

Of course, you should not duplicate the code. If you think it is better, I
can use another environment variable to pass the r2llib serialization
token to refreshd_hook.so instead of BIDITEXT_FILENAME.

refresh_hook.so does not use r2llib in any way. It only passes the
serialization of the r2llib token to refreshd over a UNIX domain socket.

> There shouldn't be more than one biditext script, otherwise users will be
> confused. Do we want it to have a command-line parameter for
> '--with-refhreshd' [or a better name] ?
A better name: --with-refreshd (no typo:-), or maybe --refresh. Shouldn't
this option be the default, and instead add a --no-refresh option for
operation without refreshd?

> Currently I create the biditext script in the Makefile, and put there the
> full path to which biditext.so will be installed. Can I assume
> refreshd_hook.so will be in the same directory?
I see no reason why not. As of refreshd-0.1.0, refreshd_hook.so has been
separated from biditext.so. Both shared objects are `on their own' (i.e.
loading one does not imply loading the other). So if this simplifies the
packaging, you can put the to .so-s in the same directory. 

> To something slightly different:
> The current biditext script of the biditext package sets LD_PRELOAD to
> '/path/to/biditext.so' Thus it overrides any existing LD_PRELOAD . Is this
> a good idea, or should it preserve the current LD_PRELOAD (and just add
> biditext.so to it)?

The script should preserve the old LD_PRELOAD and add refreshd_hook.so and
biditext.so to it. The components in LD_PRELOAD should be separated by
space characters. You can see this in biditext.c.


> -- 
> Tzafrir Cohen
> http://www.technion.ac.il/~tzafrir



Haifa Linux Club Projects Mailing List (http://linuxclub.il.eu.org)
To unsub send an empty message to [EMAIL PROTECTED]

Reply via email to