On Wed, 21 Dec 2022 at 09:33, Robert Sturrock <rob...@sturrock.id.au> wrote: > read(0x4, "/Users/rns/tmp/fortune-cookie.txt\n\n\0", 0x2000) = 35 > 0 > write(0x1, "/Users/rns/tmp/fortune-cookie.txt\n\n\n\0", 0x24) = 36 > 0
That looks pretty much what I would expect vileserv to do: it reads from the socket, and writes to stdout, which is a pipe to the running vile instance. > Any clues as to where the issue might be or how I might be better debug this? > I suspect I’m missing some obvious here! Not quite sure what's going on. You could also trace the vile process, where you should see a corresponding read from the pipe. In addition to that, I'd start putting some print statements into the readfiles subroutine in Vileserv.pm. Anything sent to stdout there should appear in the messages buffer. Make sure to ":set pm" first to cause that buffer to popup. Then just put lines in to see what's going wrong, say adding: print "Entering readfiles\n"; at the start of that subroutine (line 171), then: print "Got file $fileName\n"; after the "chomp $fileName;" statement. Keep adding statements until you find what is not working as expected. About the only thing which springs to mind that may be a problem is that the code uses newlines to delimit lines, and Macs at some point used carriage returns. Probably not the case since OS X though. One unrelated, and slightly annoying thing that I noticed is that printing to the minibuffer now elicits a warning. Must look into what changed in more recent Perl versions. :perl use warnings; print "foo\n"; for example produces a warning about an uninitialised value, almost certainly in the guts of perl.xs. I'll maybe poke at that over Christmas. --bod
