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.
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 explic
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ürge
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 al
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 implemented in src/ispell.C, so
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.
> A
[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
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,
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:
> 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 w
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 mor
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 em
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:
> 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
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,
> >
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)
>
> Michael
>
> PS: I am running LyX each day with Purify and I must confess it is
> _really_ stable. There are still a few an
16 matches
Mail list logo
