5 ms·

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 "$@" mean

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.

shabble 14y ago
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 14y ago
  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 14y ago
  Thanks to all who answered.
pyre 14y ago
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.
morsch 14y ago
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 14y ago

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 14y ago
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 14y ago
Thanks to all who answered.

pyre 14y ago

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.

morsch 14y ago

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.