quite relevant: http://www.commandlinefu.com a great collection of cli uses and ...

morsch · on July 24, 2012

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.

hntester123 · on July 24, 2012

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.

morsch · on July 24, 2012

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.

shabble · on July 24, 2012

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.

codeinthehole · on July 24, 2012

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.

hntester123 · on July 24, 2012

Thanks to all who answered.

pyre · on July 24, 2012

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.

gavinlynch · on July 24, 2012

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