Since I made my adages post last year, I've had a few afterthoughts, so here's a second instalment of things I seem to find myself saying a lot. ( seven more short pontifications )
And I guess I'll reflexively make my traditional adage-response of pouncing on the first thing on the list and saying "Wherever you stand in the kitchen, it'll always be where someone needs to be next, I bet you could make some sort of interstellar FTL communication device out of that" :)
"His ambitious plans to use his discovery to send messages, involving the careful rearranging of a small kitchen in order to modulate the signal, were never fully expounded because, at that point, the bar closed."
Fictional blowhards always seem curiously resistant to shouting loudly at each other in the middle of the street, neither willing to go home without being sure the other understands their new theory: in real life, I haven't found "the bar closing" such a sure-fire conversation ender. Maybe I just know unusually stubborn people :)
Although, if we put "caveat lector" on any advice you should make sure you understand before blindly following (ie. basically everything in the world), what warning do we put on the necronomicon? :)
Or, come to think of it, if you don't want someone to read the book maybe it should say "Health and Safety Manual" or "How to Get Things Done in a Timely Fashion"... :)
if you always have to remember to specify the ‘work properly’ option, something is wrong with the design
Yes, I'm always so annoyed by this. I remember the photocopier in the Trinity library had a mode: automatically copy whatever you put in, the same size, on the same size paper. What I couldn't figure out is why that mode wasn't the default!
To be fair, this often happens when originally there was some reason to do it a way other than "work properly", or beginners and experts have opposite expectations for "work properly", and you get stuck with the wrong default. But yes, you should be able to make it better somehow.
Yes. I think git commit -a (another classic example of a "work sensibly" option that you nearly always want to add) is a good example of both your reasons - it made sense when the git UI was intended to be used by porcelains rather than people, and also one could argue that power users are more likely to take advantage of the ability to not commit everything in one go.
(Though, on the other hand, I am enough of a git power user to constantly take advantage of partial committing, and even I still find I nearly always have to remember to add -a - to the point that on the occasions I don't want to commit everything, I still find my fingers have reflexively added the -a and then I wonder what went wrong...)
I have configured a `git ci` alias and occasionally use it incorrectly in exactly the way you describe :-) Typical failure mode is: prepare partial commit, then type `git ci -m ...`, swear, and spend twice as long unpicking the error.
Mmm. In fact I find myself thinking that since git commit -a modifies your index in a way that can wipe out carefully prepared stuff in it, you'd actually quite like it to have the side effect of leaving the prior index state somewhere easily recoverable, in cases where the index was modified.
Perhaps a handy approach would be for it to generate a second commit consisting of exactly what it would have done if you hadn't said -a, and pointed an ephemeral ref at it similar to FETCH_HEAD. Then you could trivially recover from an accidental -a by saying git reset NO_THE_OTHER_ONE, or some such.
I'd agree with everything… except your example of a wrong-defaults command.
While, sure, I'll often do find -print0 | xargs -0 I'll just as frequently be piping a file into xargs, or viewing find's output on-screen. If you want things to Just Work, I fear many other common Unix utilities would have to be re-vamped to work on files with entries delimited by nulls rather than newlines - things like less, sed, etc.
Either that, or make xargs line-oriented by default and prohibit newlines in filenames.
Realistically, I think the best one could hope for, rather than it just working, is an easier way to spell that. My preference would be a -xargs option to find.
I'm not really sure you're contradicting me - where did I say that if you constantly had to specify the 'work properly' option to find, something was necessarily wrong with find?
Well, a command where one always ends up some specific optionis, I agree, a command that should have better defaults. But both find and xargs, I sometimes use with those options, sometimes without. So I'm not sure what you feel should be improved about the situation, or how.
The reductio ad absurdam would be for the shell to have just one command: dwim (-8
Well, I haven't exactly worked out all the details either, as I'm sure you know perfectly well.
But it seems to me that it ought not to be beyond the wit of humankind to devise a system whereby the list of filenames output by find does not need to be explicitly specified every single time as being in one or another particular serialised representation, when that selection could in principle be automatically inferred by knowing the consumer of the data. Programming languages, for example, have a range of perfectly good mechanisms whereby you can return one type and also provide a default conversion to one or more other types for clients who would have preferred those, and then you don't have to write the conversions out longhand at every call site.
Comments 27
Reply
Reply
Reply
Although, if we put "caveat lector" on any advice you should make sure you understand before blindly following (ie. basically everything in the world), what warning do we put on the necronomicon? :)
Reply
Reply
Reply
Yes! Although it took you to point out that that was a reason to do them, not a reason not to do them! :)
Reply
Yes, I'm always so annoyed by this. I remember the photocopier in the Trinity library had a mode: automatically copy whatever you put in, the same size, on the same size paper. What I couldn't figure out is why that mode wasn't the default!
To be fair, this often happens when originally there was some reason to do it a way other than "work properly", or beginners and experts have opposite expectations for "work properly", and you get stuck with the wrong default. But yes, you should be able to make it better somehow.
Reply
(Though, on the other hand, I am enough of a git power user to constantly take advantage of partial committing, and even I still find I nearly always have to remember to add -a - to the point that on the occasions I don't want to commit everything, I still find my fingers have reflexively added the -a and then I wonder what went wrong...)
Reply
Reply
Perhaps a handy approach would be for it to generate a second commit consisting of exactly what it would have done if you hadn't said -a, and pointed an ephemeral ref at it similar to FETCH_HEAD. Then you could trivially recover from an accidental -a by saying git reset NO_THE_OTHER_ONE, or some such.
Reply
While, sure, I'll often do find -print0 | xargs -0 I'll just as frequently be piping a file into xargs, or viewing find's output on-screen. If you want things to Just Work, I fear many other common Unix utilities would have to be re-vamped to work on files with entries delimited by nulls rather than newlines - things like less, sed, etc.
Either that, or make xargs line-oriented by default and prohibit newlines in filenames.
Realistically, I think the best one could hope for, rather than it just working, is an easier way to spell that. My preference would be a -xargs option to find.
Reply
Reply
The reductio ad absurdam would be for the shell to have just one command: dwim (-8
Reply
But it seems to me that it ought not to be beyond the wit of humankind to devise a system whereby the list of filenames output by find does not need to be explicitly specified every single time as being in one or another particular serialised representation, when that selection could in principle be automatically inferred by knowing the consumer of the data. Programming languages, for example, have a range of perfectly good mechanisms whereby you can return one type and also provide a default conversion to one or more other types for clients who would have preferred those, and then you don't have to write the conversions out longhand at every call site.
Reply
Leave a comment