pick hangs when piped empty results

[Nebuchadrezzar]

When piping unknown results to pick, e.g.:

ag -l 'foo.*bar' | pick

an empty search result appears to hang pick. Crl-c is the only escape; alternatively, creating a bash function like:

pipe_if_not_empty () {
input=$(cat; echo a);
if [ "x$input" != x"a" ]; then
{ printf %s "${input%a}"; } | "$@"
fi
}
then one can resort to a solution like:

ag -l 'foo.*bar' | pipe_if_not_empty pick

However, pick should handle this itself.

[calleluks]

Hey @Nebuchadrezzar, thanks for reporting!

I'm not sure I understand the issues your having. I tried to recreate what your describing using the following commands:

~$ mkdir empty
~$ cd empty
~/empty$ ag -l 'foo.*bar' | pick
~/empty$ ag -l 'foo.*bar' | pick

~/empty$

When ag doesn't find any results, Pick is started and I can type into the input field. Since there are no available choices, I can't choose one using Enter. What I can do, though, is to interrupt pick using Ctrl-C or choosing whatever I type by pressing Meta-Enter (in my case Alt-Enter). Does this correspond to what you're experiencing? If so, that is the expected behavior.

Note: If I understand this correctly ag -l 'foo.*bar' | pick in this case is the same as printf "" | pick.

[Nebuchadrezzar]

Calle-

All clear. But..control-c becomes a limitation when using pick in the midst of a pipeline:

~$ mkdir empty
~$ cd empty
~/empty$ vim $(ag -l 'foo*bar' | pick)

Pick prevents me from opening vim when ag finds nothing. That’s the problem.

Right now, I work around this problem with a bash function ‘pipe_if_not_empty' that I previously mentioned. Alternatively, one could add a newline to what one sends to pick so as to ensure passing on to the next command in the pipeline — ironically, this is where echo’s "bad behavior" comes in handy since it tacks on an extra newline:

~/empty$ vim $(echo $(ag -l foo*bar) | pick)

But if Pick had a solution for this issue itself that would be preferable. Perhaps a mode could be added to Pick that would exit immediately if nothing was piped to it? Or, if simpler, a newline added to the pickable set? e.g.:

~/empty$ printf ‘’ | pick —e # exit quietly if stdin is empty
~/empty$ printf ‘’ | pick —n # adds a newline to pick set

I hope that clarifies the “issue”? While seemingly nit-picky, it does gunk up integrating Pick into a workflow using wildcards and globs where I don’t know the contents being sent to Pick.

@Nebuchadrezzar https://github.com/Nebuchadrezzar

On Feb 5, 2016, at 4:56 AM, Calle Erlandsson [email protected] wrote:

Hey @Nebuchadrezzar https://github.com/Nebuchadrezzar, thanks for reporting!

I'm not sure I understand the issues your having. I tried to recreate what your describing using the following commands:

~$ mkdir empty
~$ cd empty
~/empty$ ag -l 'foo._bar' | pick
~/empty$ ag -l 'foo._bar' | pick

~/empty$
When ag doesn't find any results, Pick is started and I can type into the input field. Since there are no available choices, I can't choose one using Enter. What I can do, though, is to interrupt pick using Ctrl-C or choosing whatever I type by pressing Meta-Enter (in my case Alt-Enter). Does this correspond to what you're experiencing? If so, that is the expected behavior.

Note: If I understand this correctly ag -l 'foo.*bar' | pick in this case is the same as printf "" | pick.

—
Reply to this email directly or view it on GitHub #98 (comment).

[calleluks]

Thanks, @Nebuchadrezzar.

When running the following in my shell, Pick gets started and piped an empty list of choices. While Pick is open, I press Alt-Enter, Pick exists with a successful status, and prints a newline effectively starting Vim with an empty buffer.

~$ mkdir empty
~$ cd empty
~/empty$ vim $(ag -l 'foo*bar' | pick)

Could you clarify why this feature doesn't solve the issue?

[calleluks]

@Nebuchadrezzar Did pressing Alt-Enter work for you? Can I close this issue?

[calleluks]

Closing due to inactivity.