On 9/6/2020 2:43 PM, David Dyck via Cygwin wrote:
This command triggers an assertion failure "ag" is from the_silver_searcher$ ag 2 <(echo 2) assertion "p >= path" failed: file "/home/corinna/src/cygwin/cygwin-3.1.7/cygwin-3.1.7-1.x86_64/src/newlib-cygwin/winsup/cygwin/path.cc", line 3065, function: int symlink_info::check(char*, const suffix_info*, fs_info&, path_conv_handle&) Aborted (core dumped) 3473k 2020/08/22 C:\cygwin64\bin\cygwin1.dll Cygwin DLL version info: DLL version: 3.1.7 bash 4.4.12-3 OK the_silver_searcher 2.2.0-1 OK Wrapping in "bash -c" gives identical results ( see above) $ /usr/bin/bash -c '/usr/bin/ag 2 <(echo 2)' Turning on some "ag" debugging reveals worker threads and the "special" /dev/fd/63 file handle creation ( used with bash "Process Substitution" ) $ /usr/bin/bash -c '/usr/bin/ag -D 2 <(echo 2)' .... DEBUG: Query is 2 DEBUG: PCRE Version: 8.44 2020-02-12 DEBUG: Using 7 workers DEBUG: Thread 0 set to CPU 0 DEBUG: Thread 1 set to CPU 1 DEBUG: Worker 1 started DEBUG: Worker 0 started ... DEBUG: searching path /dev/fd/63 for 2 assertion "p >= path" failed: file "/home/corinna/src/cygwin/cygwin-3.1.7/cygwin-3.1.7-1.x86_64/src/newlib-cygwin/winsup/cygwin/path.cc", line 3065, function: int symlink_info::check(char*, const suffix_info*, fs_info&, path_conv_handle&) Aborted (core dumped) I expected behaviour like ack $ ack 2 <(echo 2) 2 Noticed that input from pipe works $ echo 2 | ag 2 2 I've reported this on github as an "ag" bug, but I think it is a bug in cygwin https://github.com/ggreer/the_silver_searcher/issues/1408 I would appreciate hearing if someone else can reproduce this issue in 3.1.7 or later dll ( 3.1.6 seems to hang ) Attached cygcheck.out UserName and HostName substituted into cygcheck.out one environment variable deleted
I just tried this: grep 2 <(echo 2) on cygwin 3.1.7 and it worked fine. I am not familiar with Silver Searcher, but it would seem that the problem is more idiosyncratic to that program than to Cygwin more generally. I am _not_ saying the problem is not in Cygwin - only that ag must be doing something somewhat different from what grep does with <( ) command input. Perhaps ag is testing what sort of "thing" (device, etc.) the input file is, while grep does not - something like that might give different behavior. Now I have CYGWIN=winsymlinks:native, which may (almost certainly does) affect what path.cc is doing (the error message is concerned about symlinks; presumably Cygwin is trying to check whether /dev/fd/63 is a symlink. Well, those are the clues I can offer :-) ... EM -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
