You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the regexp passed to ack matches the empty string, this is much more likely to be a mistake than intentional. Rather than print the complete contents of every file, ack should stop with a diagnostic.
% ack ''
The regular expression matches the empty string, so would find all lines.
(If there's really a use for it, then maybe an --allow-empty flag similar to what you have in git to allow empty commits. And of course, having detected that the regexp matches the empty string, ack could go a bit faster by not bothering to match it.)
(For example I mistyped (joe|jim)? when I had meant to search for (joe|jim)@. Just to give a random example.)
The text was updated successfully, but these errors were encountered:
This makes a lot of sense. Let me ponder if we need an --allow-empty. I'm trying to imagine a case where you would want it. Maybe someone searches for .*whatever just so they get every line, even those that don't match whatever? Like they're emulating the --passthru option.
Yes, I don't think --allow-empty would be needed in practice but I mentioned it because you sometimes get people who furiously defend the current behaviour, whatever it may be.
When the regexp passed to ack matches the empty string, this is much more likely to be a mistake than intentional. Rather than print the complete contents of every file, ack should stop with a diagnostic.
(If there's really a use for it, then maybe an
--allow-empty
flag similar to what you have in git to allow empty commits. And of course, having detected that the regexp matches the empty string, ack could go a bit faster by not bothering to match it.)(For example I mistyped
(joe|jim)?
when I had meant to search for(joe|jim)@
. Just to give a random example.)The text was updated successfully, but these errors were encountered: