Wrong lyxpipe

[sarahstuder]

Hey, thank you for maintaining this add-on!

I just downloaded LyZ and it doesn't seem to work because of the "wrong lyxpipe", as Zotero keeps telling me. When I try to "Cite in LyZ", a pop-up appears saying it's the wrong path and that the server couldn't be contacted. What am I doing wrong? Thanks for the support!

[wshanks]

\\.\pipe\lyxpipe should be the default name for the pipe on Windows. Try checking the setting in Menu→Tools→Preferences→Paths→LyxServer path in LyX to make sure it is set to this value.

The format is: \\. means this computer, \pipe means a pipe, and \lyxpipe can be any name. That last part is the only part that should ever be changed (and needs to be the same in the LyX settings and the LyZ settings). You can see a little more information at https://wiki.lyx.org/LyX/LyXServer and https://msdn.microsoft.com/en-us/library/aa365783(VS.85).aspx.

The messages you see are shown when LyZ can not find the LyX named pipe files. If there isn't a naming problem, then there must be some other issue preventing Zotero and LyX from seeing each other -- maybe a recent change to Zotero or LyX or some security setting on Windows? I have not tried to use LyZ on Windows in a while.

[Cuentacuentos]

Hello everyone,
allmost one year later, I have the same problem as described sarahstuder. I´ve checked and I have no "naming problem", both in zotero and lyx, routes are exactly the same.
Has anyone faced (and solved) the same problem??
I got stucked with this 🈂️
Any help¿

[wshanks]

I would try to confirm that the lyxpipe was working first. I'm not sure how to do this on Windows. On Linux, I would echo a command into the lyxpipe.in file and then cat the lyxpipe.out file. There are probably Windows equivalent commands. Also, it seems like JabRef should work with the lyxpipe files.

[Cuentacuentos]

Thanks @willsALMANJ for your answer. I will try to find out what it is going wrong. Im not an expert either on windows, Im just a medium user. I run zotero perfectly well on Word. I was just... giving lyx a try..

[Gnossos]

I'm having the same problem on a Mac. I updated from LyX 2.2 to 2.3 and, because I was having some other issues with LyZ, uninstalled in and reinstalled 4.0.0. Now when I try to cite, I get the error showing the pathway to the LyX 2.2 pipe: /Users//Library/Application Support/LyX-2.2/.lyxpipe. The error messages say to set the path in LyX Preferences, but the path is correct. Where is the LyX 2.2 path coming from and how to fix it?

ADDED ABOUT 10 HOURS LATER
I found the problem. When the error occurs, four error messages pop up. The second says to set the correct path in LyX. What it should say, is go to LyX Preferences and copy the path; then go the LyZ Settings and paste the path there.

In trying to fix this problem today, I reinstalled LyZ and downloaded 4.0.0. IIRC, the earlier versions didn't have a place for the Lyx server path, but 4.0.0 does. Maybe my recollection is wrong.

I'm wondering. Does LyX have an api or other way of advertising its server path? If it doesn't, this should be fixed. If it does, then either when installed or on start up LyZ should refresh the server path.

[wshanks]

I'm glad you got it working. Perhaps the message should say something like "Ensure that the LyX pipe path is set to the same value in LyX settings and LyZ settings." There should be no outward facing changes in LyZ 4.0.0. I just bumped the version number to signal compatibility changes (3.0: compatible with Zotero 5.0; 4.0: no longer signed/hosted by addons.mozilla.org).

I don't think LyX has a way of discovering the LyX pipe path. I don't see anything documented, but I haven't tried reading through the code or asking on the mailing list. It is a bit of a chicken and egg problem -- the LyX API is provided through the LyX pipe, but you have to know where that is before you can ask LyX anything, like where the LyX pipe is.

One improvement that could be made is to make the default pipe location in LyZ be platform dependent. Right now, it defaults to the default Windows LyX pipe location. So all macOS/Linux users have to set this manually when they start. If LyZ detected the OS and set the path to the default for macOS/Linux on those systems, probably very few users would have to fiddle with the LyX pipe. (Not sure what the issue is with the other two posters to this issue which were both on Windows).

[Gnossos]

Thanks for the reply and explanation. You have my utmost respect for digging into this stuff. Not something I'd welcome. And much props for supporting LyZ. Perhaps a simpler solution would be to recommend (insist?) Mac (all) users locate the pipe in a version-independent place and set both LyX and LyZ accordingly. I work on 4 different computers and was curious why this problem didn't crop up on all of them. Well I looked at one, and I'm keeping the pipe in ~/.lyxpipe. No trouble there, but I'm still running the rc2 version of LyX on that computer. When I upgrade it, LyX apparently will put the pipe back into in /Library/<etc.>, and I'll have to remember to change it. I can see doing this for users who might be running 2 different versions of LyX, although it's odd that the release candidate just kept the previously existing one, so someone running both the production and rc versions would have them using a single, common pipe. One would expect test versions to be more isolated. In any case, unless LyX changes this, my idea of using a version-independent location won't work when a user installs new versions of LyX. It seems the chicken-egg problem could easily be solved by LyX. Since the only way to communicate with LyX is through the pipe, create a standard configuration data file for LyX that holds information regarding the pipe's path (and perhaps other configuration-specific things). Then any plugin developer could have their software read the necessary information from the file, either when installing the plugin or when starting up. In fact, LyX could probably implement a method that would return the necessary information to the plugin. Thanks again.

…

On 3/26/18 8:25 AM, willsALMANJ wrote: I'm glad you got it working. Perhaps the message should say something like "Ensure that the LyX pipe path is set to the same value in LyX settings and LyZ settings." There should be no outward facing changes in LyZ 4.0.0. I just bumped the version number to signal compatibility changes (3.0: compatible with Zotero 5.0; 4.0: no longer signed/hosted by addons.mozilla.org). I don't think LyX has a way of discovering the LyX pipe path. I don't see anything documented, but I haven't tried reading through the code or asking on the mailing list. It is a bit of a chicken and egg problem -- the LyX API is provided through the LyX pipe, but you have to know where that is before you can ask LyX anything, like where the LyX pipe is. One improvement that could be made is to make the default pipe location in LyZ be platform dependent. Right now, it defaults to the default Windows LyX pipe location. So all macOS/Linux users have to set this manually when they start. If LyZ detected the OS and set the path to the default for macOS/Linux on those systems, probably very few users would have to fiddle with the LyX pipe. (Not sure what the issue is with the other two posters to this issue which were both on Windows). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUZ7ptdSlkUpPkP7KsW1BDGGamjrkykks5tiN4rgaJpZM4K8kUO>.

[wshanks]

I'm not sure about Windows/macOS, but on Linux LyX's configuration settings are stored in ~/.lyx. Searching in there, I found that the LyX pipe location is stored in a file named preferences on a line formatted like \serverpipe "/path/to/lyxpipe". So something like you suggest may be possible at least on Linux. Maybe something similar could work on the other systems (maybe you have to search for the different LyX versions if the settings are stored per version).

One other thing that could be checked is to see what JabRef does. It has some kind of LyX support using the LyX pipe as well. I just know this from seeing it up come up in search results. I haven't used JabRef myself. It may have a more robust default than LyZ does now.

[Gnossos]

I did some snooping around on my Mac (10.10.5) and found a file here:
~/Library/Application Support/LyX-2.3/preferences
It seems to have the same information as what you describe.

[sascq]

Hey, thanks so much for making this add-on work! I love it but I got stuck as well.

I need to change my LyZ settings according my LyX preferences, both pipes have to be named ~/.lyxpipe since I'm experiencing the same problem as described above. But I don't know how to access the LyZ preferences. Where do I find them?

Would be great if someone could help... Thanks in advance!

[sascq]

Ok, I did a new search and found the answer here: http://uberstudent.com/phpBB/viewtopic.php?f=5&t=1113 Thanks anyway! :-)

[shahahnshah]

I am having a similar problem. I have "\.\pipe\lyxpipe" set properly both within LyX (2.2.3) and in Zotero Standalone (5.0.52) on Windows 10. When I attempt to add a citation in a LyX document, the error that comes up is

Could not contact server at: \.\pipe\lyxpipe

followed by (after clicking ok)

Could not retrieve document name.

Right after installation of LyX, I tested it out and it was fine. This was last week, and I didn't use it after that until now, when it seems to be having problems.

[wshanks]

@shahahnshah Sorry, I don't have too many ideas for you. It is hard to debug problems I can't reproduce. I suppose you have tried restarting LyX. Like I suggested above, you could try to test JabRef or directly writing to the pipe to see if any communication works. The goal would be to determine if the problem is on LyX's end or LyZ's.

[shahahnshah]

@willsALMANJ

I can confirm that JabRef is able to push citations into LyX.

Other things I tried which did not work: using words other than "lyxpipe" in the pipe name; using versions 3.02 or 3.03 of LyZ (on my older computer, I have the same versions of LyX and Zotero but with LyZ v3.03 and it works fine); reconfigure+restart of LyX (after any change of the pipe name).

[wshanks]

So it seems the problem is with LyZ then.

The LyX communication code in LyZ is completely separate for Windows as for macOS/Linux, probably because the lyxpipe is implemented differently by LyX on the different platforms. This makes it a little hard for me to test because I don't have easy access to a Windows system. I do have access that I could use for focused testing, but the issue right now requires more open-ended testing since we don't have a way to reliably reproduce it right now.

The error message you quoted is generated only at one specific point when LyZ tries to read the name of the currently opened LyX document (lyxGetDoc). The message is generated when the lyxAskServer function returns a null result for server-get-filename. lyxAskServer checks that the lyxpipe exists for reading and writing, so it seems that the path to the lyxpipe is okay. I think a different error would be generated if it could not read or write to the pipe, so that is probably not the problem either. For some reason it is reading an empty string from the pipe.

Some things I can think of to try:

1. Make sure that no other programs that could communicate with LyX are running. The cleanest test would be to restart the computer and then start Zotero and LyX and nothing else. It seems unlikely but perhaps some other program is reading the lyxpipe before LyZ can.

2. Check the error console for any errors related to LyZ. Search for "lyz" after startup. Then clear the history, reproduce the LyZ error message, and then check the console again to see if any new output was generated. See the end of this page for how to access the console: https://www.zotero.org/support/reporting_problems

3. Try creating a new Zotero profile and see if the problem is the same for it. Here are instructions for using a new profile: https://www.zotero.org/support/kb/multiple_profiles

4. You could try running some commands with the "LyX command" option in the LyZ menu to see if anything works that way. Help->LyX functions in LyX lists all the available commands.

5. If you are familiar enough with Javascript, you could try debugging the call to lyxGetDoc. The simplest way would be to edit lyz.js to show some more information at various points with either console.log or window.alert. It is also possible to connect Firefox's remote debugger to Zotero, but that is more involved (you have to rebuild the Zotero client using build.sh from https://github.com/zotero/zotero-standalone-build/ and passing the -t flag to enable the devtools).

[shahahnshah]

Thanks for the detailed investigation. Here is what I find when trying your suggestions:

1. No effect.
2. A few things to report in the error console.
   a. When Zotero starts up, I get the following warning in the console:

Timestamp: 7/7/2018 6:36:02 AM
Warning: unreachable code after return statement
Source File: resource://gre/modules/commonjs/toolkit/loader.js -> resource://zotero/bluebird/util.js
Line: 201, Column: 4
Source Code:
eval(obj);

If I try to get to the source file, I get this error:

Timestamp: 7/7/2018 6:36:26 AM
Error: NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getIntPref]
Source File: chrome://global/content/bindings/findbar.xml
Line: 376

b. If I clear the above warning and try to insert a citation with LyZ:

Timestamp: 7/7/2018 6:27:02 AM
Error: res is null
Source File: chrome://lyz/content/lyz.js
Line: 1369

If I click the link to the source file, I get another error:

Timestamp: 7/7/2018 6:28:46 AM
Error: NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getIntPref]
Source File: chrome://global/content/bindings/findbar.xml
Line: 376

If I click the link to that source file, the exact same error comes up again.

3. No effect.

4. A few commands:
   a. "server-get-filename" first gives a window with header [JavaScript Application] that says "RESPONSE: ". After I click "OK", then I get a window that says "DONE", and that's it.
   b. "statistics" causes LyX to open a window giving the correct statistics of the currently open document (I tried two different documents). When I close that, Zotero gives the same sequence as above.
   c. "drop-layouts-choice" also correctly displays the list of layout choices, and then again causes Zotero to display the same sequence of windows.

5. I don't think I'm familiar enough with this to give it a go right now, but I can give it a shot. I'd like to check your thoughts on the above results first though.

[wshanks]

Thanks for trying the different suggestions. Everything seems consistent with LyZ not being able to read from the LyX pipe and nothing else being wrong.

1. indicates that likely nothing else is interfering with the communication.

The startup errors for 2. don't seem to be related to LyZ. The "res is null" error is related to LyZ reading an empty string for the LyX document file name from the LyX pipe.

3. indicates that there is nothing weird in your Zotero configuration causing the problem. In your new profile, you should try going to Preferences->Advanced->Files and Folders and choosing a non-default location (an empty directory) for the Zotero data directory if you didn't try that. Otherwise it uses the same data directory as your main profile, so that doesn't completely test a clean profile.

4. For b and c, I see the same results as you. This indicates that communication from LyZ to LyX is working. I think that it might be the case that only the functions that begin with server- return a response through the pipe. See what you get for server-get-statistics. That gives me the statistics in the LyZ popup window (a response like this: RESPONSE: INFO:lyz:server-get-statistics:13068 75775 87008).

Perhaps we can figure things out without 5. The most puzzling part to me is that this issue seems to be intermittent. If you have access to another computer, you could try testing there and see if everything works okay initially. I can test on a Windows 8 system. Perhaps something changed in a recent version of Zotero. The way LyZ uses the pipe is fairly old. There might be a newer API that could be used instead.

[shahahnshah]

For 3, I did make a new, empty default location for references, and I created a new reference in there to try to push to LyX, which didn't work.

For 4, I tried server-get-statistics and it gives the same output as server-get-filename described above. On my other computer where the system is functioning properly, the server- type commands work correctly as well.

One other thing is that I did initially change the setting in about:config regarding escaping characters, but I then put it back to FALSE later after deciding against changing it from default. However, I'm not sure how this would be relevant.

[wshanks]

Hmm, so you have a second machine where things work correctly -- as far as you can tell is everything the same for the two systems? Both Windows 10 using the same versions of LyX, LyZ, and Zotero?

[shahahnshah]

Yes, I mentioned it before when I noted trying different versions of LyZ. Both machines have Windows 10 (one is "Pro" and new the other is "Enterprise" and about 1.5 years old), same versions of LyX and Zotero, same pipe name. Right now the broken one is using LyZ 4.0, and the functioning one is using LyZ 3.03, but as I wrote above I did try using LyZ 3.02 and 3.03 on the non-functioning one, and nothing changed.

[wshanks]

There is no significant difference between LyZ 3.03 and 4.0. The change to 4.0 just marks the version where updates come from GitHub instead of addons.mozilla.org.

I hadn't looked into JabRef that much before. It seems that it just pushes citations to LyX. From your testing, it seems that communication from LyZ to LyX is working and just communication back to LyZ is not. Since JabRef only pushes, it doesn't test the communication back. So I think there is still a question of whether LyZ could read the data in a way that would work better or whether there is just something wrong with LyX pushing data back through the pipe.

One thing you could try is running LyX from a command prompt with the -dbg flag. You can run lyx.exe -dbg and it should give you the debug options. For me, it looks like lyx.exe -dbg 4096 should print debug information about the LyX server. You could start LyX in this way and then try running server-get-filename from LyZ to see what debug information is printed. I see something like this:

Server.cpp (935): LyXComm: status:31, read_buffer_:, cmd:LYXCMD:lyz:server-get-filename
Server.cpp (1084): Server: Received: 'LYXCMD:lyz:server-get-filename'
Server.cpp (1128): Server: Client: 'lyz' Command: 'server-get-filename' Argument: ''
Server.cpp (972): LyXComm: Sending 'INFO:lyz:server-get-filename:/usr/share/lyx/examples/splash.lyx
'
Server.cpp (783): LyXComm: Closing connection
Server.cpp (743): LyXComm: Opening connection
Server.cpp (776): LyXComm: Connection established

This could confirm that LyX is trying to send the data back because right now the symptom is that it seems that LyX is not sending anything back. It would be nice to test another LyX client, but I haven't been able to find another one for Windows that reads from the LyX pipe (since JabRef does not seem to). You could try writing to the lyxpipe.in and reading from the lyxpipe.out files directly similar to the example here: https://wiki.lyx.org/LyX/LyXServer if you are familiar with any scripting language. It seems like the named pipes behave like normal files, so you could use something like Python. Perhaps you could even use bash if you used something like Git for Windows.

[shahahnshah]

Somehow on I wasn't able to get the debug mode to work in the way you describe from the windows command line. I was able to find a "progress/debug messages" pane within lyx itself (from view->Messages Pane) and watch it as I try to execute a command via LyZ. Here is the output when I attempt to execute server-get-filename

17:05:39.183: C:/[removed]/tmp.lyxLyXComm: Error sending message:
LyXComm: The operation completed successfully.

I only removed my directory path. For some reason the error message LyXComm: Error sending message: is appended to the file path/name. Perhaps it was intended to be pre-pended, but perhaps this gives a clue as to where in the code it is having a problem. It is also not clear why it ultimately believes the operation completed successfully.

[shahahnshah]

Actually I was able to get the messages pane to be more verbose. Below is the full output (with path details removed again). I believe some of the text is related to the message pane updating the view and scroll bar.

17:17:09.111: C:/[removed]/tmp.lyxServer.cpp (633): LyXComm: nbytes:31, iobuf:, cmd:LYXCMD:lyz:server-get-filename
Server.cpp (1079): Server: Received: 'LYXCMD:lyz:server-get-filename'
Server.cpp (1123): Server: Client: 'lyz' Command: 'server-get-filename' Argument: ''
frontends/qt4/GuiApplication.cpp (1539): cmd: action: 92 [server-get-filename] arg: '' x: 0 y: 0
frontends/qt4/GuiApplication.cpp (1800): FNAME[C:/[removed]/tmp.lyx]
BufferView.cpp (441): BufferView::processUpdateFlags()[fitcursor = 1, forceupdate = 0, singlepar = 0] buffer: 03C058C8
Buffer.cpp (3499): updateMacro of tmp.lyx
frontends/qt4/GuiWorkArea.cpp (489): WorkArea::redraw screen
BufferView.cpp (3034): *** START DRAWING ***
BufferView.cpp (3050): Strategy: NoScreenUpdate
TextMetrics.cpp (2013): main text redraw pit=0 row=0 row_selection=0 full_repaint=1 row_has_changed=1 drawingEnabled=0
BufferView.cpp (3098):
*** END DRAWING ***
BufferView.cpp (526): Updating scrollbar: height: 1 curr par: 0 default height 44
BufferView.cpp (542): storing height for pit 0 : 79
BufferView.cpp (3115): Found new anchor pit = 0 anchor ypos = 49
CoordCache.cpp (45): InsetCache is empty.
frontends/qt4/TocWidget.cpp (366): TocWidget::select(): QModelIndex is invalid!
frontends/qt4/LayoutBox.cpp (563): Already had Standard selected.
frontends/qt4/GuiApplication.cpp (1320): dispatch msg is C:/[removed]/tmp.lyx
Server.cpp (651): LyXComm: Sending 'INFO:lyz:server-get-filename:C:/[removed]/tmp.lyx
'
LyXComm: Error sending message:
LyXComm: The operation completed successfully.

[wshanks]

Interesting. Can you get the same output for your older computer that doesn't have the problem?

I tried playing with the LyX pipes on Windows using Python. I was able to send commands to LyX using something like the following:

f = open('\\\\.\\pipe\\lyxserver.in', 'rb', 0)
msg = 'LYXCMD:lyz:statistics\n'
f.write(msg.encode('ascii'))

However, I haven't figured out how to read back the data from LyX in the .out pipe.

[shahahnshah]

Here is the output on the functioning system (filenames/paths removed as per before).

07:24:01.915: [removed].lyxServer.cpp (633): LyXComm: nbytes:31, iobuf:, cmd:LYXCMD:lyz:server-get-filename
Server.cpp (1079): Server: Received: 'LYXCMD:lyz:server-get-filename'
Server.cpp (1123): Server: Client: 'lyz' Command: 'server-get-filename' Argument: ''
frontends/qt4/GuiApplication.cpp (1539): cmd: action: 92 [server-get-filename] arg: '' x: 0 y: 0
frontends/qt4/GuiApplication.cpp (1800): FNAME[[removed].lyx]
BufferView.cpp (441): BufferView::processUpdateFlags()[fitcursor = 1, forceupdate = 0, singlepar = 0] buffer: 06D9AE78
Buffer.cpp (3499): updateMacro of [removed].lyx
frontends/qt4/GuiWorkArea.cpp (489): WorkArea::redraw screen
BufferView.cpp (3034): *** START DRAWING ***
BufferView.cpp (3050): Strategy: NoScreenUpdate
TextMetrics.cpp (2013): main text redraw pit=17 row=0 row_selection=0 full_repaint=1 row_has_changed=1 drawingEnabled=0
TextMetrics.cpp (2013): main text redraw pit=18 row=0 row_selection=0 full_repaint=1 row_has_changed=1 drawingEnabled=0
TextMetrics.cpp (2013): main text redraw pit=18 row=1 row_selection=0 full_repaint=1 row_has_changed=1 drawingEnabled=0
TextMetrics.cpp (2013): main text redraw pit=19 row=0 row_selection=0 full_repaint=1 row_has_changed=1 drawingEnabled=0
BufferView.cpp (3098):
*** END DRAWING ***
BufferView.cpp (526): Updating scrollbar: height: 20 curr par: 18 default height 24
BufferView.cpp (542): storing height for pit 17 : 22
BufferView.cpp (542): storing height for pit 18 : 115
BufferView.cpp (542): storing height for pit 19 : 42
BufferView.cpp (3115): Found new anchor pit = 17 anchor ypos = -2
CoordCache.cpp (49): InsetCache contains:
CoordCache.cpp (57): Inset 05F72540 has point 742,135
CoordCache.cpp (57): Inset 0709C4B0 has point 52,111
CoordCache.cpp (57): Inset 0709C7D0 has point 649,48
frontends/qt4/LayoutBox.cpp (563): Already had Standard selected.
frontends/qt4/GuiApplication.cpp (1320): dispatch msg is [removed].lyx
Server.cpp (651): LyXComm: Sending 'INFO:lyz:server-get-filename:[removed].lyx
'

[wshanks]

Thanks, I tested on a Windows 8.1 system and saw the same thing. I think the output other than Server.cpp is not relevant to our issue (it seems to be information about drawing the GUI), but I could be wrong. So the difference is that the misbehaving system says

LyXComm: Error sending message:
LyXComm: The operation completed successfully.

and the functioning system does not.

Despite the text of the message, "The operation completed successfully" seems to be a generic error message in Windows that can show up when something is not configured properly and then a system operation is attempted that can not work (see, e.g. https://stackoverflow.com/questions/7524142/what-does-windows-error-0-error-success-mean). Likely the .out pipe is not being opened properly for some reason.

The next thing to investigate is this .out pipe to see if we can see something wrong with it. To start out, you can open \\.\pipe in the file browser and see if you see both the .in and .out pipes. Maybe something about the .out pipe will jump out there. I am not sure how to diagnose Windows named pipes besides this, but that would be the next thing to look into. It might also be worth asking the LyX developers if they know a way to test the pipe for errors.

I wasn't able to figure out how to read from the .out pipe outside of LyZ yet, but I did write to it with Python like I mentioned above and then run a LyX command with LyZ. LyZ read about the responses of the Python command I had done before and the command I entered in LyZ.

[shahahnshah]

I am unable to open \\.\pipe in the file browser. Is there something special I should do to get there?

[wshanks]

Sorry, I misremembered what I had seen. You can go to file://.//pipe// in the Chrome web browser, not in Windows Explorer (see https://stackoverflow.com/a/41487846). It just lists the pipes without extra information as far as I can tell, so not that helpful. It can confirm that the pipes exist, but LyZ already does that (it could give a different error if they did not exist). Maybe you could try some of the suggestions here to check that pipes are functioning properly? https://superuser.com/questions/462443/what-are-reasons-for-local-windows-named-pipes-to-fail

I confirm that -dbg does not seem to work on Windows. Searching around, it seems that there was a lyxc.exe binary distributed at one time that had command line options but it seems to have been dropped.

The problem with the messages pane compared to -dbg is that it seems to default to unselecting all logging at startup. The LyX server pipes are created during startup and not changed even if you change the path in preferences (you have to restart LyX). There could be useful error messages when LyX tries to create the .out if we can figure out how to capture the lyxserver messages at that time.

[shahahnshah]

Ok, I can confirm via Chrome that the pipes (.in and .out) both exist.

I also used the utility pipelist64 at https://live.sysinternals.com/ to check it and it also finds them. One curiosity is that it says there are 10 instances of the pipe, with a maximum number of instances of 10. Do you also see this?

[shahahnshah]

I also tried out the Sysmon utility (see here: https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon). Oddly, I did not see an event for generation or connection of the pipes (event IDs 17 and 18), although I do clearly see when LyX is opened or closed.

[shahahnshah]

Update: I had a chance to try the above checks on the functioning system and got the same results.

[anki-xyz]

So I have exactly the same problem as @shahahnshah but couldn't get it to work either... Wouldn't it be an option just to enable pushing and not asking for retrieving data?

Things I also tried: running it in administrator mode, but this did not helped at all. Using different pipes also did not work, so there is actually a connection, however, just the document name cannot be retrieved. Have currently the BBT workaround, but the direct zotero <-> LyX connection would be great!

[wshanks]

LyZ organizes references per document so it needs to know the document to generate the cite key and bib file. A push only option could be made using some workaround but it would take some development time. My free time is very limited. Just now I finished an email I had started three weeks ago to the LyX mailing list about this issue to see if any LyX expert has an idea about what to do. You can see it here: https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg205894.html

[wshanks]

Enrico Forestieri replied to my post on the mailing list indicating that this issue has been fixed in LyX. Here is the relevant change to LyX: https://www.lyx.org/trac/changeset/cf5f2661dc0a902e541704172ab369ba3e5a54d6/lyxgit/

If either of you has the time, you can try to compile LyX from source and see if the problem is fixed with the latest version. Otherwise, you can wait until a new preview version is built, or you can ask on the mailing list for someone to build the exe (one developer had offered to build an exe with debugging turned on previously).

I am going to close this issue for now. Reopen it if this change doesn't fix the problem for you. I partly want to close this issue because I think there have been three or four different but similar problems brought up here and I want to make sure new similar problems go into their issues.

[shahahnshah]

Thanks for the update. For now I will wait on the next preview version to see if that works. I do have one quick update for you below, in case it is helpful:

I updated to LyX. 2.3.0, and also updated all the MikTex packages on both machines, and now I am unable to insert citations on both machines. However, something that came with that is that in the messages pane, the error message when attempting to insert a citation is as follows:

frontends/qt4/LayoutBox.cpp (563): Already had Standard selected.
frontends/qt4/GuiApplication.cpp (1357): dispatch msg is C:/[path/file.lyx]
Server.cpp (652): LyXComm: Sending 'INFO:lyz:server-get-filename:C:/[path/file.lyx]
'
LyXComm: Error sending message:
LyXComm: The operation completed successfully.

support/os_win32.cpp (321): [//./pipe/lyxpipe.out]->>[\.\pipe\lyxpipe.out]

The new piece is the the last line. Not sure if it provides any useful information, since it seems to successfully correct the the pipe address.

[wshanks]

Interesting. I am not sure what to make of it, but it is probably best to wait and see if the recent fix solves the problem before spending more time diagnosing it.

[g-moralesespana]

I also have the same problem. Two machines and one is working perfectly. I tried downgrading Miktex, Lyx and Zotero in the machine that was not working and anyway the Lyz connection was still broken.
Thanks to @shahahnshah, now I know I should not update or do anything to the pc that is working.
Really hope this issue gets solved soon, so I can continue working smoothly.
Thanks all for your efforts...

[wshanks]

IHmm, perhaps the version of Windows is also important? On the mailing list, the developer mentioned recent versions of Windows.

Regarding solving the issue, here are the steps to build LyX on Windows if anyone wants to test the latest version which should fix the problem: https://wiki.lyx.org/Windows/Compilation

[g-moralesespana]

Both pcs have the same (latest) version of Lyx. The pc that is working run on Windows 10 Enterprise, and the pc where it is not working run Windows 10 Home.
@willsALMANJ what do you mean to build the latest version? one that is even more recent that the one available online LyX-230-Installer-005.exe?

[wshanks]

Yes, LyX 2.3.0 was released in March 2018. A LyX developer said that he fixed the issue last week in this post to the lyx-devel mailing list. Here is the commit to which he refers.

[Rizary]

finally i found this issue. It seems we need to wait for preview version or compile it our self.

[josselex]

Error is indeed fixed in LyX 2.3.1
Error occured in Windows 10.
Soultion: Update to LyX 2.3.1

[shahahnshah]

I can confirm that updating to LyX 2.3.1 fixes the issue on my home machine.