I have a few scripts that interact with wl-copy. Like one that just cats all the files in a directory and pipes it into wl-copy so I can paste it somewhere else. Something like that would've been immensly useful when I was still on windows, but that would've been too much a bother to set up.
not OP, but my current solution is to have a link which says "click to show email", with javascript handler that changes that link's href (and text) to email address, which is somehow computed. For example, by taking page URL and performing some regexp on it. It both avoids storing email in page source in plain text and requires human interaction, so feels good enough.
Another way I've seen elsewhere is to use a human-language explanation of how to build email address, something like this: "To get my email address, combine my first name (John) with my birth year (2000), separated by dash (-), and add email provider (@gmail.com)".
> my current solution is to have a link which says "click to show email"
Yeah was thinking of going down that route, but I like the simplicity of just having it there there as a mailto link when you land. Based on Mike's response I might try it!
not a Linux expert, but I believe that at the very least it's time sensitive: after consumer process reads it, it's gone from the pipe. Unlike env vars and cli argument that stay there.
not OP, but for some it might be availability of latest versions packages (say, you've heard about new major version of Bash or Vim being released today, and wondering how soon it might be available in your distro packages), and, as someone else mentioned, less update stress due to lack of "major version bumps" - just remember to subscribe to https://archlinux.org/news/ and watch out for entries requiring "manual intervention".
i.e. something like this: CREATE INDEX idx_events_type ON events(json_extract(data, '$.type'))?
i guess caveat here is that slight change in json path syntax (can't think of any right now) can cause SQLite to not use this index, while in case of explicitly specified Virtual Generated Columns you're guaranteed to use the index.
Yeah, you can use index on expression and views to ensure the expression matches, like https://github.com/fsaintjacques/recordlite . The view + index approach decouples the convenience of having a column for a given expression and the need to materialise the column for performance.
> slight change in json path syntax (can't think of any right now) can cause SQLite to not use this index
It's pretty fragile...
-- Just changing the quoting
select * from events where json_extract(data, "$.type") = 'click';
-- Changing the syntax
select * from events where data -> '$.type' = 'click';
Basically anything that alters the text of an expression within the where clause
When you write another query against that index a few weeks later and forget about the caveat, that slight change in where clause will ignore that index.
I'm not sure 2015 counts as new, but that's same release that first introduced the JSON extension. There isn't a version of SQLite with JSON expressions but without indexes on expressions. Also, the JSON extension wasn't enabled by default until 2022, so most people using SQLite with JSON have got a version much newer than 2015.
https://man.archlinux.org/man/wl-copy.1
(i was also interested :)
reply