Fetches http://Slashdot.org (`iwr ...`), parses it as an HTML page and extracts all the anchor tags (`.Links`), and selects the href of each anchor tag (`select href`). Since this is the end of the command, the hrefs are returned and printed as an array of strings (so one href on each line).
Well, with just grep and curl, it'd be something like:
curl http://slashdot.org/ | grep -o "href=[\"'][^\"']*" | sed -e "s/href=\"//"
But presumably this is being discounted due to the lack of HTML parsing, so not the same as the Powershell example. Then one somewhat ugly method would be using the html xml utilities provided by the W3C and available on most package managers:
Yes, a naive grep will pick up variables named href in JS, the text content of a div that contains "href", an href attribute on a non-anchor element, etc. so a utility that specifically parses HTML is necessary, but not sufficient.
I'm not sure how robust your hxpipe example is against those.
It's a shell script. If you're architecturing more than that in your shell script, I would suggest that you shouldn't be doing this in a terminal in the first place. And if you're just trying to click links for a quick shell script, why not just do it via wget in the first place, rather than have this intermediate list of strings?
But since you asked, hxpipe assumes that href on a non anchor tag is an error and should be represented as an Ahref... which isn't too bad an assumption to make, tbf. The other situations is dealt with (text content, javascript).
