Kile cannot create symliks to lyxpipe; in this way collaboration with jabref is not possible

Bug #324722 reported by Katsudon
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
kile (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: kile

Kubuntu 8.04 with all upgrades.
The same problem concerns Kubuntu 8.10 with all upgrades.
In both cases: clean install, but the /home was on a separate partition so the user configuration files are from the older versions of Ubuntu.

When starting kile from the command line, it starts fine, but generates the following message:

kile: ERROR: Could not create symlink: /home/user/.lyx/lyxpipe.in --> /tmp/kde-user/kileuKrtjO/.lyx/lyxpipe.in
kile: ERROR: Could not create symlink: /home/user/.lyx/lyxpipe.out --> /tmp/kde-user/kileuKrtjO/.lyx/lyxpipe.out

And indeed, the symlinks are not created. In this way it is not possible to collaborate directly with jabref since these symlinks are essential for this purpose.

Revision history for this message
Thomas Braun (tbraun1234) wrote : Re: [Bug 324722] [NEW] Kile cannot create symliks to lyxpipe; in this way collaboration with jabref is not possible

Hi,

does creating the directory "~/.lyx" by yourself before starting kile help?

Revision history for this message
Katsudon (katsudon) wrote :

Yes, now it works like a charm. Very good suggestion!

From a perspective of collaboration between kile and jabref I think this is a bug (they simply do not talk to each other out of the box).

However I admit that it might be bizzare if the default behavior of kile would be to create empty .lyx if it does not exist (since LyX is not directly related to kile).

To summarize: I do not know what should be the right behavior.

Revision history for this message
Thomas Braun (tbraun1234) wrote : branches/extragear/kde3/office/kile

SVN commit 922629 by tbraun:

backport r910854

create "~/.lyx" if it does not exist

CCMAIL: <email address hidden>

 M +2 -1 ChangeLog
 M +12 -0 kile/kilelyxserver.cpp

--- branches/extragear/kde3/office/kile/ChangeLog #922628:922629
@@ -1,7 +1,8 @@
 version 2.0.3 -> 2.0.4svn

 Fixes:
- - fix rare crash
+ - fix rare crash
+ - Create "~/.lyx" if it does not exist (Ubuntu bug #324722)

 Syntax:
  - bibtex: add new biblatex types, allow numbers in key names
--- branches/extragear/kde3/office/kile/kile/kilelyxserver.cpp #922628:922629
@@ -107,6 +107,18 @@
  QFile *file;
  struct stat buf;
  struct stat *stats = &buf;
+
+
+ QDir lyxDir(QDir::homeDirPath() + QDir::separator() + ".lyx");
+ if(!lyxDir.exists()){
+ KILE_DEBUG() << "Directory " << lyxDir.absPath() << " does not exist" << endl;
+ if(mkdir(QFile::encodeName( lyxDir.path() ), m_perms | S_IXUSR) == -1){
+ kdError() << "Could not create directory" << endl;
+ }
+ else{
+ KILE_DEBUG() << "Directory created sucessfully" << endl;
+ }
+ }

  for (uint i=0; i < m_pipes.count(); ++i)
  {

Revision history for this message
Jonathan Thomas (echidnaman) wrote :

A KDE4 snapshot of Kile containing this fix has been released to Kubuntu 9.04.

Changed in kile:
status: New → Fix Released
Revision history for this message
nanotube (nanotube) wrote :

This is on Ubuntu Intrepid 32 bit, using the latest jabref (2.4.2), and kile 2.0.1 (from the repos)

I have the same problem, but this fix (creating the .lyx directory) does not solve it. without the .lyx directory, kile starts just fine, and without any error messages, and creates two pipes directly in the home directory:

lrwxrwxrwx 1 dfolkins dfolkins 40 2009-02-18 16:51 .lyxpipe.in -> /tmp/kde-dfolkins/kileJwM0w6/.lyxpipe.in
lrwxrwxrwx 1 dfolkins dfolkins 41 2009-02-18 16:51 .lyxpipe.out -> /tmp/kde-dfolkins/kileJwM0w6/.lyxpipe.out

with the .lyx directory in existence, it creates those two, plus two pipes in the .lyx directory, which look like this:

lrwxrwxrwx 1 dfolkins dfolkins 44 2009-02-18 16:51 lyxpipe.in -> /tmp/kde-dfolkins/kileJwM0w6/.lyx/lyxpipe.in
lrwxrwxrwx 1 dfolkins dfolkins 45 2009-02-18 16:51 lyxpipe.out -> /tmp/kde-dfolkins/kileJwM0w6/.lyx/lyxpipe.out

in either case, pointing jabref to any of the existing lyxpipes by full path, and trying to push a citation to it, fails with the following error in jabref (path changes depending on what's being pointed to):
Error: verify that LyX is running and that the lyxpipe is valid. [/home/dfolkins/.lyxpipe.in]

any suggestions would be appreciated...

Revision history for this message
Thomas Braun (tbraun1234) wrote :

Hi,

maybe Jabref is checking if /home/dfolkins/.lyxpipe.in is a pipe? And because it is not, rather it is a link to a pipe, and then it just complains.

You can try to give Jabref the path /tmp/kde-dfolkins/kileJwM0w6/.lyx/lyxpipe.in (which changes at every kile restart) and then try again. If this is the error we (the kile devs) have to talk to the Jabref peope about a solution.

Hope that helps,
Thomas

Revision history for this message
nanotube (nanotube) wrote :

Hi Thomas,

Thanks for the quick response and the suggestion.

I tried that (checked the current location of the pipe in /tmp, and gave it to jabref in the options), but it gave exactly the same error (with a different path in the [] brackets, of course).

I copy-pasted the full path, so no typos...

So that doesn't appear to be the case. Any other thoughts?

Is there a way i could manually test the pipe (by echoing some sequences into it, maybe?) I tried just echoing random strings into it, but nothing appeared in kile, so I'm not sure if that's because the pipe is bad, or it requires special formatting of input in order to read and post it into the document.

Revision history for this message
nanotube (nanotube) wrote :

another note:

I found a post on the jabref mailing list, claiming that it stopped working since kile 2.0.2:

https://sourceforge.net/mailarchive/forum.php?thread_name=20090207131926.GA10634%40bupt-bcnl.com&forum_name=jabref-users

has anything changed in kile between v 2.0-1 (the hardy version, that appears to work fine when .lyx dir is created) and v 2.0.1 (version that's in intrepid), that might have affected this?

Revision history for this message
nanotube (nanotube) wrote :

ok, so as per the documentation i found here:
http://wiki.lyx.org/LyX/InsertingReferences

i tried manually inserting a citation by echoing the properly formatted lyx citation-insert command, as follows:

echo "LYXCMD:<anything>:citation-insert:<citation key>" >> .lyxpipe.in

This properly created a "\cite{<citation key>}" text in the document.

This worked with both the two different links to the pipe, as well as with the pipe in /tmp/... directly.

Since the pipe created by kile works just fine, this leads me to believe that the bug is not with kile, but with the latest jabref, 2.4.2.

Do you concur? Shall I open a bug with the jabref people?

Revision history for this message
Thomas Braun (tbraun1234) wrote :

> has anything changed in kile between v 2.0-1 (the hardy version, that appears to work fine when .lyx dir is created) and v 2.0.1 (version that's in intrepid), that might have affected this?

No since kile 2.0.0 the lyx stuff has been untouched.

Please file a bug report at the jabref BTS giving this bug here as a link, maybe they have a clue what is going on here.

Revision history for this message
nanotube (nanotube) wrote :

Hi,
Posted a bugreport on jabref here:
https://sourceforge.net/tracker/index.php?func=detail&aid=2614899&group_id=92314&atid=600306

If nobody replies in a few days, I'll try posting to the jabref mailing list.

Revision history for this message
nanotube (nanotube) wrote :

Hi tbraun

Well, i finally got a response on my bugreport:
https://sourceforge.net/tracker2/?func=detail&aid=2614899&group_id=92314&atid=600306

Turns out that jabref actually automatically appends a ".in" to the specified lyxpipe (which seems to be nowhere documented), so when i was specifying a full path to the lyxpipe in options, of course using the full pipe name, including the .in, it was failing. soon as i dropped the .in, it works.

to be honest, i think it's a bug to do that without any documentation to that effect or in any way making it apparent to the user that that is being done... but at least now we know what's going on, and it seems to be not in any way kile's fault. :)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.