Nice article, and this is obviously a very specific nitpick from a single point in the article, but ... > ls --full-time | cut -d' ' -f6,7 # WRONG > If two “

Nice article, and this is obviously a very specific nitpick from a single point in the article, but ... > ls --full-time | cut -d' ' -f6,7 # WRONG > If two “fields” have different lengths, ls will add spaces to the name of the smaller one to make the two line up, which will break cut -d' '. And in fact you can’t solve this at all with ls, you have to write stat -c %w. Text streams don’t compose. I mean, ok, I get the point how he's saying Powershell has 'objects', but the example is super-contrived. All it takes to fix the offending 'padding spaces' is to remove them. ls --full-time | tr -s ' ' | cut -d' ' -f6-7 Moreover, that's not even "bash" you're comparing against, but 'coreutils'. If you really wanted to grab the output of 'ls' with pure bash then you'd probably go with something like this instead: ls --full-time | while read -r FIELD{1..8}; do echo "$FIELD6 $FIELD7"; done which isn't exactly complicated either. Otherwise, if the gripe is about the command you're using not being field based, then go ahead and use one that is, on data that supports it. This isn't exactly a language issue. Case in point, if 'stat' is the right command to get that "field" for that "object type", then there you go. Nagging that if you don't use the right tool for the job will leave you with having to work around things, is not exactly the environment's fault. Also, text streams absolutely do compose. It's just that the underlying type will always be a text stream. But composability is 100% the reason behind this in the first place.