False positives when matching `name` against a regex starting with the `^` anchor about fselect HOT 4 CLOSED

First of all, thank you for reporting this issue! However, it has nothing to do with fselect itself. That's the ^ that makes shell behave "bad". To prevent the issue put the whole query into the quotes like this:

fselect "name where name =~ '^\.'"

You can put quotes only around the regexp itself, but as soon as query starts becoming more complex (using parentheses etc.), it's safer to guard it as the whole.

from fselect.

Thanks for your solution. The command you posted does indeed work.

However, I don’t think the ^ is making my Fish shell behave any differently. The ^ was quoted, and the shell doesn’t seem to be interpreting it:

$ printf '%s' '^\.'
^\.
$ printf '%s' '^\.' | wc -c
       3

From the following experiments, the problem seems more likely to be in fselect’s argument parsing:

$ fselect name where name =~ '^\.'
some-file
$ fselect 'name where name =~ ^\.'
some-file
$ fselect "name where name =~ '^\.'"
$ fselect 'name where name =~ "^\."'
$ fselect name where name =~ '"^\."'
$ 

It looks like fselect requires that the regex argument after =~ be given literal quotes, visible to fselect and not just the shell, if the regex starts with ^.

I would call this behavior a bug in fselect’s internal argument parsing that should be fixed eventually. fselect should have all the information it needs to understand the regex after =~. It shouldn’t need literal quotes, because the shell is already giving the regex as a single argument. At the very least, if quotes are required, fselect should issue an error about it instead of parsing the regex wrong.

However, it’s fine to give this bug low priority, because as you showed me, there is a way to write the query that doesn’t trigger this bug. The bug will only confuse new users, not make a certain type of query impossible.

from fselect.

Oh, yes, please forgive me the previous answer. I was wrong in deciding what is faulting there.

When you pass the query like this:

fselect name where name =~ '^\.'

the last argument is being received not as a string with quotes, but without them. Simply ^\.. I suppose this is the intended shell behavior to allow passing strings with spaces. That ^\. should suffice for a regexp parsing, sure, but next lexer treats that string like it has escapes inside. So it throws \ away, and we finally get ^., that goes to query parser.

What could be done there is probably to narrow down the escape sequences to \ and \\.

What are they for after all? To allow queries like that:

fselect name from some\ dir\ with\ spaces

And escaping logic doesn't work for regular string with quotes (for now, at least), and on Windows as well (to be more usable with PowerShell).

from fselect.

Removed escaping behavior as it confuses users.

from fselect.