by golly part2

Neven Has haski at sezampro.yu
Wed Jan 3 06:08:42 PST 2001

On Wed, Jan 03, 2001 at 02:06:56AM +0000, Bryan Dumm wrote:
> I'll have to try that out then. I was reading up on Q and E, do you
> think we would have any problems using Q&E? It didn't look like 
> it but the explanations I read were long for Q&E, looking for other
> details, opinions...

>From the docs, I think this is what we need. I also did a lot of testing
with some weird and could_cause_problems characters and everything went ok.

> > Yes, I noticed that too. IIRC, with XML::Parser alone I didn't have any
> > problems. So it's probably something with Twig (a bug?). I didn't find
> > anything in the docs.
> > For now, we can translate whose few "special chars" ourselves in the
> > backend.
> Yea I am still looking, and if you can verify the XML::Parser info being
> right, maybe we have found a bug(?). Would seem to be a silly one 
> though.....

Yes, I verified it with XML::Parser and there is no problem with it.
It translate all of those predefined entities right.
Maybe we should write to the author of Twig?

> Yes agreed we need a tag. As for implementation, I dunno yet either. 
> Here is some fodder from the camel book on chroot...
> 3.2.17 chroot
> chroot FILENAME
> This function does the same operation as the chroot system call - see 
> chroot(2). If successful, FILENAME becomes the new root directory for the 
> current process - the starting point for pathnames beginning with "/". This 
> directory is inherited across exec calls and by all subprocesses. There is no 
> way to undo a chroot. Only the superuser can use this function.

chroot won't be easy. We would definitely have to do some forking and then
use "chroot" in the child process. Then, when chroot tag ends, we would kill 
the child and the parent could continue from </chroot> (or some 
value/mark/whatever passed by the child process).
I'll try writing something that works. :)


More information about the alfs-discuss mailing list