Here is how such tools should really be done: https://github.com/rupa/z
And if you want to talk about portable, I think people would rather work with Go than shell.
Maybe it is in the general case, but this... really isn't "the general case".
function gs() { open http://www.google.com/search?q="$*" ;}
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...
func (p *GoogleProvider) BuildURI(q string) string {
return fmt.Sprintf("https://www.google.com/search?q=%s", url.QueryEscape(q))
}>Web search from the terminal. Just opens your default browser.
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 .
License file says MIT.
function gs() { open http://www.google.com/search?q="$*" ;}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.