You could improve it by making it not a one-liner! Usually making it a multiple-liner can improve readability. And unless you're typing it into the command line directly everytime you run it (as opposed to putting it in a file that you invoke) it doesn't really matter how many lines it has.
One day the code breaks. For a one liner I have to pick it apart, add logging / diagnostics, fix it, and reassemble. The two most time consuming and error prone parts of that are dealing with the 'one liner'
Comments
You could improve it by making it not a one-liner! Usually making it a multiple-liner can improve readability. And unless you're typing it into the command line directly everytime you run it (as opposed to putting it in a file that you invoke) it doesn't really matter how many lines it has.
It's not just readability.
One day the code breaks. For a one liner I have to pick it apart, add logging / diagnostics, fix it, and reassemble. The two most time consuming and error prone parts of that are dealing with the 'one liner'
I came here to say this. In addition, searching through bash history is a terrible "save and fetch" interface