Hank Stevens wrote: > Running Mac OS 10.3.5, LyX 1.3.4, JabRef 1.4 (or 1.5?) > > What is my .lyx/lyxpipe? I could not find anything in > When I try to insert a reference directly from JabRef, JabRef gives me > an error mesage saying, > "Error: verify the LyX is running and the the lyxpipe is valid. > [/Users/Hank/.lyx/lyxpipe]" > I went into LyX preferences and change my LyXServer path from > /Users/Hank/.lyx/.lyxpipe to /Users/Hank/.lyx/lyxpipe, but this had no > effect even after restarting JabRef. I have not contacted the JabRef > folks because I don't understand what the lyxpipe or .lyx are.
/Users/Hank/.lyx is a directory containing your customisations of the system wide settings. LyX will interrogate the contents of the system wide directory (/usr/local/share/lyx on 'traditional' unix boxes. Somewhere different on the Mac). Thereafter it will override (some of) these settings using the contents of the /Users/Hank/.lyx directory tree. /Users/Hank/.lyx/lyxpipe.in and /Users/Hank/.lyx/lyxpipe.out are the names given to two FIFOs. A FIFO is a window into the kernel memory that 'looks' like a file. Your app (JabRef) will write to lyxpipe.in and read from lyxpipe.out. If you fire up lyx from the command line you may get some messages displayed about problems creating these FIFOs. If not, then they should be visible when you type 'ls /Users/Hank/.lyx'. It may well be that things just don't work on the Mac. The API to interrogate FIFOs is less than standard. The current code is known to work under linux, f.ex, but not under Digital Unix. Angus $ man fifo NAME fifo - first-in first-out special file, named pipe DESCRIPTION A FIFO special file (a named pipe) is similar to a pipe, except that it is accessed as part of the file system. It can be opened by multiple processes for reading or writing. When processes are exchanging data via the FIFO, the kernel passes all data internally without writing it to the file system. Thus, the FIFO special file has no contents on the file system, the file system entry merely serves as a reference point so that processes can access the pipe using a name in the file system. The kernel maintains exactly one pipe object for each FIFO special file that is opened by at least one process. The FIFO must be opened on both ends (reading and writing) before data can be passed. Normally, opening the FIFO blocks until the other end is opened also. A process can open a FIFO in non-blocking mode. In this case, opening for read only will succeed even if noone has opened on the write side yet; opening for write only will fail with ENXIO (no such device or address) unless the other end has already been opened. Under Linux, opening a FIFO for read and write will succeed both in blocking and non-blocking mode. POSIX leaves this behaviour undefined. This can be used to open a FIFO for writing while there are no readers available. A process that uses both ends of the connection in order to communicate with itself should be very careful to avoid deadlocks. -- Angus
