Hi Danek,

2016/8/19 Fri 9:26:11 UTC+9 Danek Duvall wrote:
> On Wed, Aug 17, 2016 at 05:24:27PM -0700, Ken Takata wrote:
> 
> > Hi,
> > 
> > 2016/8/18 Thu 5:36:51 UTC+9 Danek Duvall wrote:
> > > On Wed, Aug 17, 2016 at 09:52:12PM +0200, Bram Moolenaar wrote:
> > > 
> > > > Danek Duvall wrote:
> > > > 
> > > > > I'm seeing this.  It's on Solaris, but I'm not sure whether that 
> > > > > matters,
> > > > > or if it does, what aspect does.
> > > > > 
> > > > >     From test_startup_utf8.vim:
> > > > >     Found errors in Test_read_fifo_utf8():
> > > > >     function RunTheTest[9]..Test_read_fifo_utf8 line 24: Expected 
> > > > > ['テスト', '€ÀÈÌÒÙ'] but got []
> > > > > 
> > > > > When I run the RunVim command standalone:
> > > > > 
> > > > >     ../vim -f -u NONE -U NONE --noplugin --not-a-term --cmd "so b" 
> > > > > <(cat Xtestin)
> > > > > 
> > > > > I do in fact get nothing in the buffer, and a warning in the status 
> > > > > line
> > > > > 
> > > > >     "/dev/fd/12" [character special][converted][READ ERRORS] 0 lines, 
> > > > > 0 characters
> > > > > 
> > > > > I get the same thing if I remove cp932 from fencs and add ascii, but 
> > > > > latin1
> > > > > gives me something, at least.  Aren't errors in conversion supposed 
> > > > > to be
> > > > > ignored and move vim on to the next entry in fencs, or am I
> > > > > misunderstanding that whole thing?
> > > > 
> > > > It is supposed to work.  No idea why it fails in your situation.
> > > > Would require debugging (or adding some printf's).
> > > 
> > > Hm.  Any suggestions on where to start?  Am I right that it should try to
> > > convert from cp932, fail, and then try utf8?  Is there anything I can do
> > > with the iconv command that could demonstrate that there's something wrong
> > > with iconv on the system?
> > 
> > Does Solaris have S_ISFIFO()?  If not, it might happen.
> > Could you try the attached patch?
> 
> No, Solaris isn't that backwards.  :)  I tried the patch anyway, just in
> case, but no.
> 
> I spent a bit of time debugging.  The problem is that after the iconv()
> call fails, vim tries to rewind the file and the lseek() fails with ESPIPE.
> The file created by <() ends up being a character device in /dev/fd (for
> both bash and zsh), but the seek fails anyway, probably because the
> underlying mechanism really is a pipe.

No, it's not the expected behavior.  lseek() should not be called when opening
<().  It might happen when failing to detect a pipe.


> As the zsh manpage suggests, this really isn't expected to work:
> 
>     If =(...) is used instead of <(...), then the file passed as an
>     argument will be the name of a temporary file containing the output of
>     the list process.  This may be used instead of the < form for a program
>     that expects to lseek (see lseek(2)) on the input file.
> 
>     [ ... ] In both cases [/dev/fd and FIFO implementations of <()], the
>     shell actually supplies the information using a pipe, so that
>     programmes that expect to lseek (see lseek(2)) on the file will not
>     work.
> 
> So it seems to me that the test is broken (though I'm not sure how to fix
> it).

The test is not broken (at least on Linux and Cygwin.)
Please check the patch 7.4.2189 if you want to know the purpose of the test.

When opening a file, open_buffer() in buffer.c is called.  Then open_buffer()
checks if the file is actually a pipe.  If it is a pipe, open_buffer() calls
readfile() in fileio.c twice; first time with READ_FIFO flag, and second time
with READ_BUFFER flag.  The first time, readfile() just reads the whole data
into a buffer (without encoding detection), and the second time, readfile()
reads the data from the buffer with encoding detection.  If the first encoding
fails, readfile() tries to read the buffer again with next encoding.  lseek()
should not be called here.

So please check that the readfile() is called with READ_FIFO flag first time. 

Regards,
Ken Takata

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui