I didn't install and run the code, but this appears to be a wrapper for performing a search across these sites via browser...i.e. you specify a provider and the query, and the browser pops open with the properly formatted URL, rather than it doing the query, scraping the results and streaming into stdout.
Because I was thinking, there's no way it could be this easy to programmatically search Google:
It appears to be officially deprecated as of November 2010, though it is perhaps one of those heavily used APIs (such as static charts API) that Google is in no rush to disable https://developers.google.com/web-search/docs/?hl=en
Except mine, because I started looking for it post-2010 and got stuck on Google's new whatever-it-is that has complexity beyond imagination and a seriously buggy dev panel.
Correct, I am not a fan of listing the results in the terminal itself. I like the flexibility of it loading in a browser so I can click around after the search. It also makes adding additional search providers much much easier.
Yep great project if you want to show results in the terminal itself. Slightly different default behavior, as opening a remote uri in the browser requires additional flags.
Ok, so that's exactly what I thought this program did (display results in the terminal), so I downloaded it and installed it. When I found that it opened a web search I was quite surprised and came to look at the comment thread.
However, should the results appear in the terminal (i.e. do I agree with you)? I am not at all sure that this browser view is a bad thing. The idea of searching from the command line and focus moving to the browser is just not something I was picturing at all, and I kind of like it.
But I definitely do agree 100% that I was and am interested in something that runs these webapps from the command line and makes the terminal a first class interface to say, Google, StackOverflow, etc. I think I may try to tinker with such a thing, and when I thought this project had it, I was really curious to see what method of scraping they used and how they turned web data into meaningful result objects of some sort.
Thinking about it, I feel like noting two things:
1 - I don't see why a single application, like s, can't support both interfaces. Give it an alias, say, r, and r renders search results at the command line instead of the browser. No reason the list of providers has to be the same for both interfaces.
2 - now we're on web like 2.9999999, right? Googlebot indexes JS/dynamic webpages properly, and webapps use a lot of JS to perform their basic functions, it seems. i believe it's time to start taking command line browsers seriously again. we have a few production ready off-the-shelf JS engines to choose from today and browsing from terminal seems like a simple and why-the-hell-not idea. Terminal/shell interfaces, imo, provide a really great way to move around, focusing on text and with the super quick functional input response that only keyboard navigation can provide.
i am positive that if we started aiming for a web development standard supporting JS and HTML5 or whatever well supported but capable standard is out there today and full accessibility from a text-only/terminal web browser (Lynx for 2015's HTTP realities) then we would be helping out people using non-standard input devices (screen readers, etc.). of course im talking out of my ass here, but someone knowledgeable back me up on this point please.
i guess it just didn't completely click until i saw this app, someone else who had the same idea as me (you/your post), and the fact that repo this is useful, but not what i was looking for, that i have decided i feel extremely strongly that now is the time for a fully functional javascript capable cross platform browser that does not render graphics at all and runs happily in the terminal.
On another note: the project README has very simple and well highlighted Installation instructions, if you happen to have Golang installed, which I do. but not sure how easy that would be if you didn't. A suggestion to the author: post Windows/Mac/Linux binaries on https://github.com/zquestz/s/releases .
There is this project : http://weboob.org (Web Outside Of Browsers). It allows the use of certain web apps in the terminal. It's a french project, so it's mostly french apps that have been integrated.
This tool might be helpful if you are regularly searching for the same phrases and make aliases to, for example, `s "what is the weather"`.
For regular interactive usage this would actually hamper your productivity because you type "s", a space, eventually a starting quote, the phrase without autocompletion, and an eventual ending quote, versus switching to a browser window and focusing over its location bar with two key shortcuts.
Since results are displayed in browser window, There should be a "Search on google" in context menu displayed on right click after text selection in terminal.
It will save some clicks like in Google Chrome.
There was one similar package available for earlier versions of ubuntu(http://ubuntuguide.net/ubuntu-13-0412-10-terminal-with-searc...)
When it's compiled, isn't the user just interacting with a nice binary? Among languages that compile to binary and have a nice standard library for http requests, I'm not surprised that somebody choose Go.
And if you want to talk about portable, I think people would rather work with Go than shell.
I started using Go for exactly this reason. It was something that felt slightly too advanced to write in shell, and figured I'd try Go (command line tool). I can't say I'm too much of a fan of the language, but the things it does well (fast compile times, simple portable binaries) it does very well.
This is exactly why I did it in Go. It is just a binary. Has full support for OS X, Windows and Linux. Not to mention I find that Go is far more readable than shell scripts.
Because I was thinking, there's no way it could be this easy to programmatically search Google:
https://github.com/zquestz/s/blob/master/providers/google/go...