Georg Baum wrote:
// FIXME: we should try and replace all calls to RunCommand with
// ForkedCall (if the output is not needed) or the code in ispell.C
// (if the output is needed).
OK. Adapted. Thanks.
Jürgen.
Georg Baum wrote:
> // FIXME: we should try and replace all calls to RunCommand with
> // ForkedCall (if the output is not needed) or the code in ispell.C
> // (if the output is needed).
OK. Adapted. Thanks.
Jürgen.
Georg Baum wrote:
As I understand it, it is not safe to assume that the child process was
executed successfully if errno is ECHILD.
Yes, you're right.
The siginfo struct that can be
obtained with sigwaitinfo() has probably the needed information.
[...]
If we had the value of si_code, we
[EMAIL PROTECTED] (Juergen Spitzmueller) writes:
| Georg Baum wrote:
As I understand it, it is not safe to assume that the child process was
executed successfully if errno is ECHILD.
| Yes, you're right.
The siginfo struct that can be
obtained with sigwaitinfo() has probably the needed
Am Samstag, 3. April 2004 10:31 schrieb Juergen Spitzmueller:
I think instead of working around the error message we rather should
investigate why the error occurs suddenly.
I thought that this was an old bug unrelated to Angus' recent changes, but
this was obviously a misunderstanding.
Juergen Spitzmueller wrote:
Georg Baum wrote:
Why not add a
cmd_ret const Forkedcall::startscript(string const what)
method that replaces cmd_ret const RunCommand(string const cmd)
and implements the piping on top of the forked controller stuff? In
fact, the piping is already
Angus Leeming wrote:
We could probably get rid of all calls
to RunCommand (see below). However, for now, I think that we should
just fix the bug.
OK. I added a FIXME for now.
Could you see if adding this to RunCommand fixes the problem?
It does. Shall I apply the attached?
Thanks,
Jürgen.
Am Samstag, 3. April 2004 18:55 schrieb Juergen Spitzmueller:
Angus Leeming wrote:
We could probably get rid of all calls
to RunCommand (see below). However, for now, I think that we should
just fix the bug.
OK. I added a FIXME for now.
I think it would be good to mention explicitly
Georg Baum wrote:
> As I understand it, it is not safe to assume that the child process was
> executed successfully if errno is ECHILD.
Yes, you're right.
> The siginfo struct that can be
> obtained with sigwaitinfo() has probably the needed information.
[...]
> If we had the value of si_code,
[EMAIL PROTECTED] (Juergen Spitzmueller) writes:
| Georg Baum wrote:
>> As I understand it, it is not safe to assume that the child process was
>> executed successfully if errno is ECHILD.
>
| Yes, you're right.
>
>> The siginfo struct that can be
>> obtained with sigwaitinfo() has probably the
Am Samstag, 3. April 2004 10:31 schrieb Juergen Spitzmueller:
> I think instead of working around the error message we rather should
> investigate why the error occurs suddenly.
I thought that this was an old bug unrelated to Angus' recent changes, but
this was obviously a misunderstanding.
>
Juergen Spitzmueller wrote:
> Georg Baum wrote:
>> Why not add a
>>
>> cmd_ret const Forkedcall::startscript(string const & what)
>>
>> method that replaces cmd_ret const RunCommand(string const & cmd)
>> and implements the piping on top of the forked controller stuff? In
>> fact, the piping is
Angus Leeming wrote:
> We could probably get rid of all calls
> to RunCommand (see below). However, for now, I think that we should
> just fix the bug.
OK. I added a FIXME for now.
> Could you see if adding this to RunCommand fixes the problem?
It does. Shall I apply the attached?
Thanks,
Am Samstag, 3. April 2004 18:55 schrieb Juergen Spitzmueller:
> Angus Leeming wrote:
> > We could probably get rid of all calls
> > to RunCommand (see below). However, for now, I think that we should
> > just fix the bug.
>
> OK. I added a FIXME for now.
I think it would be good to mention
Juergen Spitzmueller wrote:
the citation dialog does not list the contents of a bib file if that file
has been inserted without path (i.e. is in the texmf path). This is not
related to my latest changes.
I tried to spot the bug. This is what I have for now:
InsetBibtex::getFiles calls
Juergen Spitzmueller wrote:
pret must be -1.
It is. Some more print statements showed that:
RunCommand:: ret: /home/juergen/texmf/bibtex/bib/diss/diss.bib
RunCommand:: pret: -1
kpse status = -1
kpse result = `/home/juergen/texmf/bibtex/bib/diss/diss.bib'
Jürgen.
Juergen Spitzmueller wrote:
This means, for the file test.bib, kpsewhich test.bib is called.
Now when running lyx -dbg latex, we get:
kpse status = -1
kpse result = `/usr/share/texmf/bibtex/bib/base/test.bib'
Bibfile:
The question is now: why is kpsestatus=-1, which leeds to an empty
Georg Baum wrote:
man 3 popen answers that:
yes, found that in the meantime. thanks.
A wild guess: maybe pclose() returns -1 because the child did already
terminate when pclose() was called? In this case the failure can of course
be ignored. Maybe reading the errno variable could tell more?
Juergen Spitzmueller wrote:
errno is ECHILD (no child processes)
For what it's worth, I found this statement in popen(3C):
The signal handler for SIGCHLD should be set to default when
using popen(). If the process has established a signal
handler for SIGCHLD, it will be called
Am Freitag, 2. April 2004 19:45 schrieb Juergen Spitzmueller:
errno is ECHILD (no child processes), so your guess is probably right.
OTOH man popen says: If pclose() cannot obtain the child status, errno is
set
to ECHILD, which sounds a bit vague.
Yes, it seems that it does not tell all
Juergen Spitzmueller wrote:
> the citation dialog does not list the contents of a bib file if that file
> has been inserted without path (i.e. is in the texmf path). This is not
> related to my latest changes.
I tried to spot the bug. This is what I have for now:
InsetBibtex::getFiles calls
Juergen Spitzmueller wrote:
> pret must be -1.
It is. Some more print statements showed that:
RunCommand:: ret: /home/juergen/texmf/bibtex/bib/diss/diss.bib
RunCommand:: pret: -1
kpse status = -1
kpse result = `/home/juergen/texmf/bibtex/bib/diss/diss.bib'
Jürgen.
Juergen Spitzmueller wrote:
> This means, for the file test.bib, "kpsewhich test.bib" is called.
> Now when running lyx -dbg latex, we get:
> kpse status = -1
> kpse result = `/usr/share/texmf/bibtex/bib/base/test.bib'
> Bibfile:
>
> The question is now: why is kpsestatus=-1, which leeds to an
Georg Baum wrote:
> man 3 popen answers that:
yes, found that in the meantime. thanks.
> A wild guess: maybe pclose() returns -1 because the child did already
> terminate when pclose() was called? In this case the failure can of course
> be ignored. Maybe reading the errno variable could tell
Juergen Spitzmueller wrote:
> errno is ECHILD (no child processes)
For what it's worth, I found this statement in popen(3C):
The signal handler for SIGCHLD should be set to default when
using popen(). If the process has established a signal
handler for SIGCHLD, it will be called
Am Freitag, 2. April 2004 19:45 schrieb Juergen Spitzmueller:
> errno is ECHILD (no child processes), so your guess is probably right.
> OTOH man popen says: "If pclose() cannot obtain the child status, errno is
set
> to ECHILD", which sounds a bit vague.
Yes, it seems that it does not tell all
the citation dialog does not list the contents of a bib file if that file has
been inserted without path (i.e. is in the texmf path). This is not related
to my latest changes.
Regards,
Jürgen.
the citation dialog does not list the contents of a bib file if that file has
been inserted without path (i.e. is in the texmf path). This is not related
to my latest changes.
Regards,
Jürgen.
Angus Leeming wrote:
On Tuesday 21 August 2001 16:51, Michael Schmitt wrote:
Hi,
I think the following bibtex entry is not read correctly (the year is
50BC in the citation dialog)
@STRING{ ProcOfThe = Proceedings of the }
@ARTICLE{FrinckeTomp96,
AUTHOR = {D. A.
Angus Leeming wrote:
>
> On Tuesday 21 August 2001 16:51, Michael Schmitt wrote:
> > Hi,
> >
> > I think the following bibtex entry is not read correctly (the year is
> > "50BC" in the citation dialog)
> >
> >
> > @STRING{ ProcOfThe = "Proceedings of the " }
> >
> > @ARTICLE{FrinckeTomp96,
> >
30 matches
Mail list logo
