Relative links including `~` do not work

[mathieuhendey]

When I try to pass a relative link to q it complains that there is no file matching the path. However, if I immediately stat the path it complains about, there is indeed something there:

~
❯ q "select count(*) from ~/dev/lastfm/data/lastfm_scrobbles.csv"

No files matching '~/dev/lastfm/data/lastfm_scrobbles.csv' have been found

~
❯ stat ~/dev/lastfm/data/lastfm_scrobbles.csv
16777220 25789060 -rw-r--r-- 1 mathieu staff 0 7970474 "Jun  3 19:24:48 2019" "Jun  3 19:19:38 2019" "Jun  3 19:19:38 2019" "Jun  3 19:19:38 2019" 4096 15568 0 /Users/mathieu/dev/lastfm/data/lastfm_scrobbles.csv

However, if I then pass the absolute path that q previously complained didn't exist to q it finds it with no issues:

~
❯ q "select count(*) from /Users/mathieu/dev/lastfm/data/lastfm_scrobbles.csv"

45365

I believe something strange is happening with the parsing of relative paths. Perhaps the path parser is somehow treating ~ as part of an absolute path, and looking for a directory named ~ in /Users/mathieu

❯ brew info q
q: stable 1.7.4, HEAD

~
❯ defaults read loginwindow SystemVersionStampAsString
10.14.4

I read up about the docs on os.path.expandUser function and I do indeed have a HOME env var.

~/dev/lastfm master*
❯ env | rg home
<stdin>
HOME=/Users/mathieu

N.B. I am using conda to manage my Python environments, although I don't see how this would affect that.

[bitti]

The ticket rename still doesn't reflect what you mean, because paths starting with ~ are in fact absolute. (They only depend on the user you're logged in, not on what your current $PWD is.) So I would rephrase it as q doesn't do tilde expansion.

I'm not sure though if this is actual bug or rather a feature request, since depending on the shell there are different forms of tilde expansions. So I guess @harelba has to think about how and if to support them.

As a workaround you could use $HOME instead of tilde (which should be preferred in scripts anyway.)