counsel-grep shows no results on OS X

[jmccarrell]

Summary

It appears to me that the counsel functions that invoke external processes do not reliably report the
results of those process invocations on Mac OS X. This behavior is shown on a minimally configured emacs via
emacs -Q. The reproducible sequence does not show the bug behavior on 3 tested ubuntu-based releases of emacs.

Issues Searching with counsel

I seem to be having issues searching with counsel. Specifically, running counsel-grep gathers the
inputs, but generates no results: no results buffer. I see the same behavior with other counsel file
searching functions as well.

Steps to Reproduce

1. start the emacs under test with no initialization, eg:
   • emacs -Q
2. Load counsel
   • M-x eval-buffer on this

     (require 'package)
     (unless (assoc-default "melpa" package-archives)
       (add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t))
     (package-initialize)
     (package-refresh-contents)
   
     (unless (package-installed-p 'counsel)
       (package-install 'counsel))
   
     (require 'counsel)
     (ivy-mode)
   
     (find-library "counsel")
   

 ```

3. Do a search
   • M-x counsel-grep
   • NB that counsel is working; see how M-x runs counsel-M-x
   • search for counsel which should result in many matches in the file counsel.el
4. Expected vs Actual Results
   • I expect to see a result buffer full of matches
   • The results I actually see are essentially nothing; no search appears to be performed, no results appear.

Versions of Emacs Tested

Shows the bug

1. Emacs for Mac OS X running as a Cocoa window
   • version
     • GNU Emacs 26.1 (build 1, x86_64-apple-darwin14.5.0, NS appkit-1348.17 Version 10.10.5 (Build 14F2511)) of 2018-05-30
   • invoked as
     • /Applications/Emacs.app/Contents/MacOS/Emacs -Q
2. homebrew installed emacs running in the terminal
   • version
     • GNU Emacs 26.2 (build 1, x86_64-apple-darwin18.5.0) of 2019-04-13
   • invoked as
     • /usr/local/Cellar/emacs/26.2/bin/emacs-26.2 -Q

Works as Expected

• ubuntu 16.04 LTS

GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9) of 2017-09-20 on lcy01-07, modified by Debian

• ubuntu 18.04 LTS

jmccarrell@jeff-test-1:~$ emacs --version
GNU Emacs 25.2.2

• ubuntu 19.04

jmccarrell@jeff-test-2:~$ emacs --version
GNU Emacs 26.1

[abo-abo]

Looks like you need to set up your PATH. Use getenv and setenv for that.

Also check:

(executable-find "grep")
;; => "/bin/grep"

[jmccarrell]

Hey Oleh. Thanks for responding.

I don't think it is a path issue. I got here by trying to migrate from helm; helm search commands: grep, ag, rg etc work as expected.

Also here is what executable-find reports:

(executable-find "grep")
;; => "/usr/bin/grep"

Also, M-x grep from the test case above works just fine.

[abo-abo]

How about counsel-git? Does that work?

[jmccarrell]

Yes it does. Running M-x counsel-git, I was able to select a file from the repo. It seems to work as expected.

[abo-abo]

OK, so the path to git is not the problem.

I don't have access to OSX. But I assume other OSX users don't have this problem, so it's likely a config issue. What's your shell-file-name and shell-command-switch?

[jmccarrell]

In the test case above, ie, from emacs -Q I see the following:

shell-file-name  => "/usr/local/bin/zsh"
shell-command-switch => "-c"

[jmccarrell]

Ok, nice. After I

chsh -s /usr/local/bin/bash

and re-execute the test above, counsel-grep works as expected.

In this case I have:

shell-file-name => "/usr/local/bin/bash"
shell-command-switch => "-c"

[abo-abo]

OK, so now we have a workaround. Let's investigate it further. Please try to grep with your default zsh setup.

Then post here the value of counsel--async-last-command. That's the shell command we run to get the output. You can check if that shell command works in your Emacs.

[jmccarrell]

Ok, here is the command that gets executed

counsel--async-last-command => "grep -E -n -e counsel counsel.el"

Running that in eshell does give a hint that my environment may be an issue; which may be related to how the shell is executed. However, when I first cd to the appropriate directory, the grep runs fine

eshell output

Welcome to the Emacs shell

~ $ grep -E -n -e counsel counsel.el
#<buffer *grep*>
~ $ cd .emacs.d/elpa
~/.emacs.d/elpa $ cd counsel-20190803.1121
~/.emacs.d/elpa/counsel-20190803.1121 $ grep -E -n -e counsel counsel.el
#<buffer *grep*>
~/.emacs.d/elpa/counsel-20190803.1121 $ 

results of grep in the counsel dir: buffer *grep*

-*- mode: grep; default-directory: "~/.emacs.d/elpa/counsel-20190803.1121/" -*-
Grep started at Fri Aug 23 20:32:46

grep -n -E -n -e counsel counsel.el
1:;;; counsel.el --- Various completion functions using Ivy -*- lexical-binding: t -*-
48:(defgroup counsel nil
51:  :prefix "counsel-")
54:(define-obsolete-variable-alias 'counsel-more-chars-alist 'ivy-more-chars-alist "0.10.0")
56:(define-obsolete-function-alias 'counsel-more-chars 'ivy-more-chars "0.10.0")

[abo-abo]

Running that in eshell

You should not run it in eshell. counsel-rg runs it in shell-file-name, which is zsh for you. Try to run it in M-x shell. Or even outside Emacs.

[jmccarrell]

M-x shell results

Ok, running grep from M-x shell "works", modulo the color output that my terminal settings and my zsh aliases that presume every terminal supports color conflict with. At least, that is what I presume those escape sequences are doing

�]133;A�% �]133;B�grep -l counsel counsel*.el
grep -l counsel counsel*.el
�]133;C;�counsel-autoloads.el
counsel-pkg.el
counsel.el
�]133;A�% �]133;B�

outside emacs from zsh

Here is the exact output I get from zsh. NB, my zsh config emits the git branch (master here) and the current working directory as part of its prompt. This is a multi-line prompt; $pwd is printed on a separate line.

❯ cd ~/.emacs.d/elpa/counsel-20190803.1121                                                 master

~/.emacs.d/elpa/counsel-20190803.1121
❯ grep -l counsel counsel*.el
counsel-autoloads.el
counsel-pkg.el
counsel.el

outside emacs from bash

The bash prompt is also multi line.

jeff at vega in ~/.emacs.d/elpa/counsel-20190803.1121
$ grep -l counsel counsel*.el
counsel-autoloads.el
counsel-pkg.el
counsel.el
jeff at vega in ~/.emacs.d/elpa/counsel-20190803.1121
$

colorized

Both shell prompts presume a color-capable terminal; ie they are both colorized. I'm not sure if that is relevant to this exploration or not.

[abo-abo]

Can you grep for something, confirm there's no result (although there should be). Then eval (shell-command-to-string counsel--async-last-command).

[mookid]

Going meta: should we consider non POSIX compliant shell commands as bugs?

[abo-abo]

@mookid If Emacs built-ins like shell-quote-argument or start-file-process-shell-command support the shell, even though it's not POSIX, we can support it too, since we get the support for free. Otherwise, I see no reason to do it.

[mookid]

The reason would be to avoid issues with users that prefer some shell that is not the default one.