> That's because numbers look better when they are right justified.
They don't look better to a computer though. And that's what I don't get. Why are the defaults geared towards typesetting (human consumption) while cut/sort/join friendly output is so painful to produce?
This is a very common scenario when processing log files: line numbering, then sorting on another field followed by join/grep/head to grab a subset of interest, then recovering the original line numbers for the subset of interest.
Honestly half the time I end up doing this, just because it's the shortest invocation that comes to mind:
Comments
> That's because numbers look better when they are right justified.
They don't look better to a computer though. And that's what I don't get. Why are the defaults geared towards typesetting (human consumption) while cut/sort/join friendly output is so painful to produce?
This is a very common scenario when processing log files: line numbering, then sorting on another field followed by join/grep/head to grab a subset of interest, then recovering the original line numbers for the subset of interest.
Honestly half the time I end up doing this, just because it's the shortest invocation that comes to mind:
I've never heard of your use case before--that is interesting.
Though I'm not sure I see why the "%5d" method is hard to parse...
seems to work ok. "cut -f 2" and "cut -c 8-" also seem to work well in this case.