Hacker News Reader

Comment by morsch | Hacker News Reader

I've got something like this in my .bashrc so I can access commandlinefu from within the shell:

  cmdfu(){ wget -qO - "http://www.commandlinefu.com/commands/matching/$@/$(echo -n "$@" | openssl base64)/plaintext"; }

It's like man but for one-liners.

View on HN

Interesting. Can you explain how the command works? I did look at the commandlinefu API page but didn't get it. I know UNIX and also specifically what "$@" means in UNIX but didn't get the meaning of the two uses of it in the commandlinefu URL you show, nor what the openssl part does.

It seems that the API bizarrely expects:

    [URL]/matching/ssh/c3No - Search results for the query
    'ssh' (note that the final segment is a base64-encoding
    of the search query)

So it's passing the command args through 'openssl base64' to encode them as required by the api.

     $ echo -n ssh | openssl base64
     c3No

It's not immediately clear to me why they require both - base64 encoding might be useful to allow non-printable/special-purpose chars in the URL, but we already have a perfectly good URL-encoding scheme for that.

And requiring both (it doesn't seem to work with only one) is just silly.

commandlinefu.com author here. Agreed, the API is odd and needs rewriting - I was trying to work around the idiosyncrasies of CodeIgniter which didn't support query parameters (hilarious) at the time of writing. The first segment (eg 'ssh' in /matching/ssh/c3No') isn't actually used - it's just there for SEO. You can insert junk there if you want - both aren't required. I'll update the docs to make this clearer.

There is a Django-rewrite of commandlinefu on the way including a saner API.

Thanks to all who answered.

The openssl part is just using openssl to base64-encode "$@":

  $ echo 'test' | openssl base64
  dGVzdAo=

Which is the same as:

  $ echo 'test' | base64
  dGVzdAo=

The URL is the same as:

  args="$@"
  b64=$(echo -n "$@" | openssl base64)
  url="http://www.commandlinefu.com/commands/matching/$args/$b64/plaintext"

For these purposes though, "$@" could probably be replaced with "$*". Technically the URL is invalid since "$@" could introduce non-escaped spaces into the URL.

Well, I only copied it myself, but it's not that complicated. From the API docs we learn that we need our search terms both in verbatim and base64 encoded. The first $@ is the verbatim part, and the second one is the one involved in the base64 part.

$(<command>) gets replaced by the output of <command>, in our case that means the output of the openssl base64 call, which takes stdin, applies the base64 encoding and prints it out on stdout. echo -n $@ just serves to translate our parameters into something the openssl base64 call can work with (-n means it won't introduce a superfluous newline). I'm not sure why the script uses openssl base64 instead of just base64 (a GNU coreutils utility).

I agree with the sibling that the API requirement to include both verbatim and base64-encoded search terms are fairly bizarre.

Wow this is so cool, I'm adding this to my .bashrc as well! Thanks for the tip :)

Reply on news.ycombinator.com