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
{{ message }}
This repository was archived by the owner on Mar 5, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 5, 2022. It is now read-only.
$ googler hello --debug
[DEBUG] googler version 3.9
[DEBUG] Python version 3.6.8
[DEBUG] Connecting to new host www.google.com
[DEBUG] Fetching URL /search?ie=UTF-8&oe=UTF-8&q=hello&sei=MMvdbA1wEeq7OH1_4X723w
[DEBUG] Cookie: 1P_JAR=2019-11-22-21
[DEBUG] Response body written to '/tmp/googler-response-_sjb5zc5.html'.
No results.
googler (? for help)
The patch provided by @zmwangx works for vanilla searches. Can you also please provide the patch for retrieving news (-N argument) results? It gives the same "No results" error.
Is there a way to auto-detect if the results are in markup?
Looks like we are detecting whether the results are in new markup or earlier.
If you're talking about the if h3 conditional: both layouts could appear in a modern UA response.
Yeah, we can possibly maintain compatibility with the older layout we were targeting, but since the older layout appears to be gone, there's no point.
Note that we used this googler (like MSIE) user agent with the assumption that Google would serve a classic, stable layout to that UA, instead of frequently doing A/B testing on modern browsers. However, that assumption seems broken beyond repair now, so no point in using a non-modern UA now.
we use the FF user agent
I propose we use a Chrome UA. It is said that FF is more likely to be reCAPTCHA'ed than Chrome (although it's not clear whether that's based on UA detection).
@ajithkumar-natarajan I did test my patch with -N and it was working for me, and it still does. Please use --debug and share the markup like OP did.
Hi, I know I opened this ticket but I will not have access to my affected workstation until late in the week. Just want to make sure you don't wait on me for testing! :-D
Turns out I have more pressing matters and didn't have time to refine and test the patch... Instead of delaying the fix further, I just pushed the patch to #307.
I'll refine it and rewrite our currently useless testing system later, but let's have a working release first...
Activity
jarun commentedon Nov 22, 2019
@zmwangx I've been noticing this today too.
webctrl commentedon Nov 23, 2019
I'm having the same results.
zmwangx commentedon Nov 23, 2019
This is in fact the same problem as #299, and it's getting a bit ridiculous. The markup is pretty damn hard to parse as discussed before.
Again, we wait for maybe 48hrs. If things don't go back to normal by then, we move to a modern UA, and update the parser.
Until then, here's a patch (with modern UA) that works:
If it doesn't work, show me the markup and I'll fix it.
jarun commentedon Nov 23, 2019
The patch works fine for me. Is there a way to auto-detect if the results are in markup?
What if we use the FF user agent and this patch. Looks like we are detecting whether the results are in new markup or earlier.
ajithkumar-natarajan commentedon Nov 25, 2019
The patch provided by @zmwangx works for vanilla searches. Can you also please provide the patch for retrieving news (-N argument) results? It gives the same "No results" error.
Thank you.
zmwangx commentedon Nov 25, 2019
Problem still not resolved. I'll turn the patch into a PR soonish and we'll probably need to cut a release.
@jarun
If you're talking about the
if h3conditional: both layouts could appear in a modern UA response.Yeah, we can possibly maintain compatibility with the older layout we were targeting, but since the older layout appears to be gone, there's no point.
Note that we used this
googler (like MSIE)user agent with the assumption that Google would serve a classic, stable layout to that UA, instead of frequently doing A/B testing on modern browsers. However, that assumption seems broken beyond repair now, so no point in using a non-modern UA now.I propose we use a Chrome UA. It is said that FF is more likely to be reCAPTCHA'ed than Chrome (although it's not clear whether that's based on UA detection).
@ajithkumar-natarajan I did test my patch with
-Nand it was working for me, and it still does. Please use--debugand share the markup like OP did.jarun commentedon Nov 25, 2019
Please go ahead. The Chrome UA sounds good.
jarun commentedon Nov 25, 2019
I'll make a release this evening if things are good.
jarun commentedon Nov 25, 2019
Tracking update: the patch works for me so far.
amitai commentedon Nov 25, 2019
Hi, I know I opened this ticket but I will not have access to my affected workstation until late in the week. Just want to make sure you don't wait on me for testing! :-D
jarun commentedon Nov 25, 2019
No problem! Looks like it's reproducible globally. Just came across a post on HN that google is no longer working on Lynx.
bpalmer7440 commentedon Nov 25, 2019
Just FYI, but the patch works for me too running OSX.
Thanks!
mikeaich commentedon Nov 26, 2019
The patch works here on Ubuntu 18.04 as well.
Switch to modern UA and fix parser
Switch to modern UA and fix parser
zmwangx commentedon Nov 26, 2019
Turns out I have more pressing matters and didn't have time to refine and test the patch... Instead of delaying the fix further, I just pushed the patch to #307.
I'll refine it and rewrite our currently useless testing system later, but let's have a working release first...
jarun commentedon Nov 26, 2019
I'll make a release today.