xt-pipes

TLDR: Humane command-line pipe functions.

cat package.json | xt trim each line  | xt add line numbers > mashed_file.txt

Challenges

Challenge 1 - Understand what the sequence below does. Hopefully its self-explanatory (that's the goal of XT).

xt new uuid  | xt uppercase  | xt remove hyphens

Challenge 2 - Perform the above with traditional command-line tooling (ideally, without referencing the manual)

...

How did it go? Did you manage it? Send your answers in to: [email protected]

Purpose

Infrastructure is moving to code (Yay!) - but 'code' needs to be readable, and when your build needs to do a little impromptu data maniupulation - traditional commands are not that readable - IE Can you spot the fake in: bc, renice, xy, mknod, fsck?

(And we've not even mentioned the switches/flags of those commands. Do you use the -s short flag names rather than --long ones? I hope you're using the long form - as it's a step closer to readability!)

There's a tension here - command-line tool names are short because they are designed to be typed... a lot; and as you're typing them a lot, you KNOW what they mean - so short names win. However, in a build we only need to type the commands once, but we want them to be readable for the future.

XT still has all the composable goodness that is the hallmark of the unix command line, but aims to be fully readable and transparent.

TODO 

Stream data through rather than read-all-in, write-all-out.
Current approach should be fine for most uses, but large files / data may not fit in memory.


Formalise injection attack protection (each language keyword must come from a separate 
command line argument - ensuring the meaning of a command can't be changed with parameters).