oh wow, that's pretty cool and impressive! thanks for sharing.
> ytsearch does not support continuation searches.... Continuation searches occur when a user scrolls to the bottom of a search results page.
true, I never bothered adding "continuation searches" feature to ytsearch
because I very rarely scroll down to the second page of results. usually if what
I'm looking for is not in the first 4-5 results, I just "refine" the search
query.
ytsearch is a quick-and-dirty script that avoids me to open the browser for
simple YouTube searches (I stole the idea from the initial version of ytfzf).
> It only retrieves the first 15 results.
that's not true, I always get more than 20-25 results on average and it's
usually enough for my use:
$ ytsearch foo | sort | uniq | wc -l
37
> 1.sh only uses TLS1.3 so no server certificate is sent in plaintext over the wire. Nor does it send SNI, i.e., plaintext hostnames on the wire.
> 1.sh could be adapted to use curl but how does one disable SNI with curl.
that's pretty cool if you care about this kind of stuff!
> Not to mention curl has a TLS fingerprint that sites may use to try to block requests or treat them with prejudice.
yes I see how this could become a problem.
> ytsearch requires sed, column, awk, jq, fzf, and curl.
> 1.sh requires sed, netcat, stunnel and flex.
what are you implying here? do you think those 6 dependencies are "too much"
for ytsearch compared to those of 1.sh?
anyway, it seems that the 2 tools offer a slightly different user experience out-of-the-box:
- 1.sh dumps json and can be used to continue searches without leaking too much data.
- ytsearch allows to quickly select a few urls and it's meant to be used interactively.
> To convert our line-oriented JSON to TSV, we can use line-oriented UNIX utilities. In general, this will be faster than jq and more robust for large files.
faster yes, but how it will be "more robust for large files" than jq?
I always thought jq is the right tool for the job when dealing with json.