configured FZF call fails since update from Cygwin 3.0.7 to 3.1.2

configured FZF call fails since update from Cygwin 3.0.7 to 3.1.2

[Trosi, Marco]

Hello everyone and a happy new year,

I updated recently Cygwin from 3.0.7 to 3.1.2, and now when I run "fzf" the following happens.

--- commandline call that fails --------------------------------------------
~ >> fzf
Traceback (most recent call last):
        4: from /usr/bin/fzf:1347:in `<main>'
        3: from /usr/bin/fzf:309:in `start'
        2: from /usr/bin/fzf:1157:in `start_loop'
        1: from /usr/bin/fzf:929:in `get_input'
/usr/bin/fzf:929:in `getc': No such process @ io_fillbuf - fd:11 /dev/tty (Errno::ESRCH)
--- end of commandline call that fails -------------------------------------

But it is important to understand that I don't use the default "find" for FZF.

Initially I wanted to use "fd", but "fd" is not available on Cygwin, so I use the Windows version of "fd".
I changed the FZF settings to ...

export FZF_DEFAULT_COMMAND='fd --type f'

... which works fine, still today.

But as I didn't like the Windows path format, I had the idea to run the "fd" output through "cygpath".
So I wrote a little wrapper script, named "fdc", to get Cygwin paths.

--- script named fdc -------------------------------------------------------
#!/usr/bin/bash
fd "$@" -X $(cygpath -aw $(which cygpath))
--- end of script named fdc ------------------------------------------------

and I changed my FZF settings in my bashrc accordingly ...

export FZF_DEFAULT_COMMAND='fdc --type f'

The "-X" executes a command, in this case "cygpath", for every found file.

Everything worked until I updated to Cygwin 3.1.2.


So I started to investigate to narrow down the problem.

FZF works with "fd" and with "find", so I thought it's connected to my "fdc" script.

I ran the command directly on commandline and it still works as usual.
Then I tried different variants in the script and directly on commandline.
Here the variants I tried.

--- script named fdc -------------------------------------------------------
#!/usr/bin/bash
fd "$@" -X $(cygpath -aw $(which cygpath))
#fd "$@" -X 'D:\Tools\cygwin\bin\cygpath.exe'
#fd "$@"
#fd -X 'D:\Tools\cygwin\bin\cygpath.exe'
--- end of script named fdc ------------------------------------------------

Still fails with "fdc".

Then I thought it could be the parameter passed to "fd" through "fdc",
so I also removed "--type f" from the settings.

--- FZF settings in bashrc -------------------------------------------------
export FZF_DEFAULT_COMMAND='fdc --type f' # fails
#export FZF_DEFAULT_COMMAND='fdc'         # fails
#export FZF_DEFAULT_COMMAND='fd'          # works
--- end of FZF settings in bashrc ------------------------------------------


Conclusion is that everything works on it's own (fd, fdc, unconfigured FZF, FZF configured with "fd"),
but when I configure FZF to use my "fdc" script it fails since the update, which wasn't the case with Cygwin 3.0.7.

For a brief moment the output is visible on screen, but it's so fast that I can't see if it is still with Windows paths
or Cygwin paths. I think it's the output due to the length on screen.


Unfortunately I can't give you the "cygcheck" output, but here some tool versions.
If you need specific information from the "cygcheck" output, then I can check them and decide if I can give them out.

--- tool versions ----------------------------------------------------------
~ >> fzf --version
fzf 0.8.9 (Dec 24, 2014)

~ >> fd --version
fd 7.3.0

~ >> mintty --version
mintty 3.1.0 (x86_64-pc-cygwin)
© 2013/2019 Andy Koppe / Thomas Wolff
License GPLv3+: GNU GPL version 3 or later
There is no warranty, to the extent permitted by law.

~ >> uname -a
CYGWIN_NT-10.0 NUL7231W 3.1.2(0.340/5/3) 2019-12-21 15:25 x86_64 Cygwin
--- end of tool versions ---------------------------------------------------


Have a great day,

Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: configured FZF call fails since update from Cygwin 3.0.7 to 3.1.2

[Adam Dinwoodie]

Hi Marco,

On Fri, 17 Jan 2020 at 09:43, Trosi, Marco wrote:
>
> Hello everyone and a happy new year,
>
> I updated recently Cygwin from 3.0.7 to 3.1.2, and now when I run "fzf" the following happens.
>
> <snip>

While I'm nominally the Cygwin maintainer for fzf, the upstream source
has stopped supporting the version Cygwin uses, which means there's
incredibly little help I can offer.

I vaguely intended to create a supported fork of the Ruby fzf version
that Cygwin runs, but never managed to make any useful progress on it.
At this point, it's unlikely I'm ever going to, either.

If you're interested in taking over the maintainership and working out
your problems yourself, that's something I'm definitely willing to
help with insofar as I can, but otherwise I'm afraid you're on your
own here.

(For context: the version of fzf that Cygwin uses is written in Ruby,
but some time ago the upstream fzf project switched from a Ruby-based
version to a Go-based version. Cygwin doesn't have a native Go
compiler, and getting a working Cygwin-packaged version of fzf using a
non-Cygwin Go compiler was beyond what I could achieve with the time
available to me.)

Adam

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: configured FZF call fails since update from Cygwin 3.0.7 to 3.1.2

[Adam Dinwoodie]

Hi Marco,

On Wed, 22 Jan 2020 at 08:56, Trosi, Marco wrote:
> > Hi Marco,
> >
> > On Fri, 17 Jan 2020 at 09:43, Trosi, Marco wrote:
> > >
> > > Hello everyone and a happy new year,
> > >
> > > I updated recently Cygwin from 3.0.7 to 3.1.2, and now when I run "fzf" the following happens.
> > >
> > > <snip>
> >
> > While I'm nominally the Cygwin maintainer for fzf, the upstream
> > source has stopped supporting the version Cygwin uses, which means
> > there's incredibly little help I can offer.
> >
> > I vaguely intended to create a supported fork of the Ruby fzf
> > version that Cygwin runs, but never managed to make any useful
> > progress on it.  At this point, it's unlikely I'm ever going to,
> > either.
> >
> > If you're interested in taking over the maintainership and working
> > out your problems yourself, that's something I'm definitely willing
> > to help with insofar as I can, but otherwise I'm afraid you're on
> > your own here.
> >
> > (For context: the version of fzf that Cygwin uses is written in
> > Ruby, but some time ago the upstream fzf project switched from a
> > Ruby-based version to a Go-based version. Cygwin doesn't have a
> > native Go compiler, and getting a working Cygwin-packaged version of
> > fzf using a non-Cygwin Go compiler was beyond what I could achieve
> > with the time available to me.)
> >
> > Adam
>
> Hi,
>
> Thanks for the offer.
>
> Do you really think it has something to do with FZF?
> FZF is working perfectly.
> The issue occurs only when I use my "fdc" wrapper script and since update to Cygwin 3.1.2.
> Currently it feels to me like some kind of Cygwin internal string/pipe/stream handling thing.
> Okay maybe Cygwin changed something on purpose and FZF needs to be updated accordingly, is that what you think is happening here?

I think it's unlikely that the problem is with FZF, however given that's
where you're spotting the problem, someone needs to narrow down what's
going on, and that'll require either digging into what FZF is doing, or
otherwise coming up with a simple test case that doesn't involve FZF.

As is more-or-less always the case with open source projects, someone
has to do that work.  That might be me, as FZF maintainer, but as above,
I simply don't have the bandwidth to do that.  It could be someone else
involved in the Cygwin project, but given nobody else has replied to
this thread on the Cygwin mailing list, I don't think you're likely to
have much luck waiting on that.  Which, I'm afraid, leaves you.

If you can get a simple test case that shows the problem and doesn't
involve FZF, I expect other people on the list will be much better
placed to help.  Until and unless that simple test case exists, however,
I think there's unlikely to be any more progress unless someone else
happens to discover the same problems by chance.

Adam

PS: Convention on this list, per the links in the email footer, is to
reply to the list, not to individuals, as it means everyone on the list
can help rather than requiring one person to do all the labour.  We also
prefer to reply in-line below the text (as I'm doing here) and to not
quote raw email addresses, since otherwise they get harvested by
spammers from the email archives.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple