Hi Emil
On Tue, 11 Sep 2001, Kohn Emil Dan wrote:
> Hi Tzafrir,
>
> On Tue, 11 Sep 2001, Tzafrir Cohen wrote:
>
> > Hi folks
> >
> > A new version of the complete r2l package is here: 0.1.0
> >
> <snipped>
> > Emil: refreshd fails if BIDITEXT_FILENAME is not set. but you shouldn't
> > query the environment directly: you should ask r2llib what is the token
> > (as I did in the above command).
> >
> <snipped>
>
> Is it refreshd itself or the application (in refreshd_hook.so) who is
> failing ? I suppose it's the latter,
Yes. This is refreshd_hook
> and indeed, this behavior is
> `normal'. Hmm smells like yet another "It's not a bug, it'a a feature"
> thing ;-). But let me try to explain things first.
>
> The idea was that I wanted to support the --r2l-filename command line
> parameter. The code from refreshd_hook.so runs `on foreign ground' (i.e.
> inside a different process which is a descendant of the `biditext'
> application or script). Yes you are right, `biditext' can be a shell
> script. In order to operate properly, refreshd_hook.so needs to know the
> serialization string of the r2l token.
Why can't it ask r2llib?
> I think that the safest way to pass
> this string around is through the environment. The idea was that the
> biditext script creates an r2l token in the usual way, based on either on
> the --r2l-filename command line parameter, the BIDITEXT_FILENAME
> environment variable, ${HOME}/.rev or ./.rev files. After the token is
> created, `biditext' sets the BIDITEXT_FILENAME variable to the r2l token
> serialization (whether the BIDITEXT_FILENAME variable was previously set
> or not) and execs the application. The advantage of this scheme is that
> refreshd_hook.so will see the BIDITEXT_FILENAME variable set correctly, no
> matter how many fork()s and exec??()s took place from the moment the
> application was started and until refreshd_hook.so code gets executed. Of
> course this assumes that exec??()s are never performed with a new
> evironment and that the application does not modify the BIDITEXT_FILENAME
> variable. So the assumption was that `biditext' will always set the
> BIDITEXT_FILENAME variable correctly before exec??()-ing the application,
> as it sets all the rest of the variables (e.g. LD_PRELOAD).
>
> I can see a related problem inside the biditext.so library. This library
> passess NULL,0,NULL to r2l_init(). This means that it does not support the
> --rev-filename parameter. If we use a `good' `biditext' script, then
> everything is OK since a `correct' `biditext' script sets the
> BIDITEXT_FILENAME first before exec??()-ing the application. Note that in
> this case r2l_init(NULL,0,NULL) will create an r2llib_t instance based
> on the contents of BIDITEXT_FILENAME environment varaiable. Thus, support
> for the --r2l-filename option is added, albeit in a quite weird way.
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 want to
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.
>
> 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.
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] ?
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?
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)?
--
Tzafrir Cohen
mailto:[EMAIL PROTECTED]
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]
