On Mon, Feb 27, 2017 at 12:59 AM, L A Walsh <g...@tlinx.org> wrote: > > > James Youngman wrote: > >> >> Because, typically, -printf is used for output intended for humans rather >> than programs. >> > ---- > Ahh... This is your 1st mistake. Interactive forms, and the > ones used most often are supposed to be the shortest forms. Go back > and look at early unix design docs. The designers of the early > unix tools couldn't touch type. That's why the names were all > short. The most commonly used items were the shortest. Go read a > book on language design (like the 2011 C++ Stroustrup book). He > says the same thing -- you use the shortest forms for the most > common usage. >
I believe you're saying that the shortest form, "find" by itself, is the one used most often and the form intended for use by humans. I agree. Perhaps you've assumed that I was saying that "find -printf" is the only form intended to produce output for humans, but that's not what I was saying. > As far as I can see, it is also unnecessary. That is I don't agree that >> someone would have to modify the output in this way. >> > I find the extra "./" to be a distraction. It slows comprehension. > Every book on comprehension and language will tell you that languages > with short forms for expression are the most powerful. > "./" is part of the output, though, not the input from the user. > >> >> Rather than >> adding protections that the user specifically doesn't want and must >> circumvent, why not give them what they ask for? >> >> What the user is asking for is determined by the behaviour of "find" as >> documented. >> > ---- > ??? How can you say that's what the user wants --- Telling the > user that some complex invocation is "really what the want" is the > height of arrogance. You don't tell users what they want -- you > listen -- something you are refusing to do. You're putting words into my mouth. I am stating that the user interface for find, such as it is, is a "little language" (in the sense coined by Jon Bentley). The user uses this language to indicate their wishes, and the find command line, together with the "specification" of the language, determine how the computer interprets what the user stated that they wanted. To phrase this a bit differently, and I hope more clearly the second time: 1. The only information we have about what the user wants is the find command line that they specified. 2. This means that we cannot reliably determine that the user "specifically doesn't want" something unless they said as much in the find command line. > > > (in the sense that the find command line is a little language with >> specified semantics and the user is communicating their wishes by using >> that language). POSIX specifies no semantics for the case where no path >> name argument is specified, so the current behaviour is compatible with >> POSIX. >> > ==== > POSIX is irrelevant to what users want -- it's what computers want. > Forcing users to adjust to what computers want is the opposite of > "user friendly". > POSIX is a way of ensuring that someone's expectations for how programs behave (given some input, shell, C, or whatever) are reasonably consistent between systems claiming compliance. The relevance, here, of POSIX is that find should behave consistently with POSIX in order to avoid unwelcome surprises for users and changes from previously-compliant behaviours to no-longer-compliant behaviours. Given that the use of "find" without an argument is not specified by POSIX, implementations are free to specify what (their version of) find does in this case. GNU has some long-established behaviour for this usage. I don't think the usefulness of that behaviour is at issue here, though, and my only point was that GNU find's behaviour for "find" by itself is not forbidden by POSIX. > >> POSIX requires path names that _are_ specified on the command line to be >> used un-edited: >> >> """ >> Each /path/ operand shall be evaluated unaltered as it was provided, >> including all trailing <slash> characters; all pathnames for other files >> encountered in the hierarchy shall consist of the concatenation of the >> current /path/ operand, a <slash> if the current /path/ operand did not end >> in one, and the filename relative to the /path/ operand. >> > ---- > Um... > > find tmp2 >> > tmp2 > tmp2/a > tmp2/b > tmp2/c > > Clearly a slash is not appended to the current path operand > in the 1st case. Why should one be forced in the "" case: > > cd tmp2 > find "" > a > b > c > > > >> I don't agree with your assumption that the user should or will remove >> it, though. >> > ---- > You can't disagree that I remove it. I do. I am a user. > Thus your statement that I don't remove it is clearly untrue. > My statement was about users in general. > You can believe I'm the only one in the entire world that does > so if you want, but that would seem to be a rather provincial > view in my opinion. > My claim is not that there is just one user who does this (and I'd say it was pretty obvious I wasn't claiming so). My claim is that the *proportion* of users who routinely remove the "./" is small. My rationale for that claim is that, in the last fifteen years, as far as I can remember, the total number of people asking on the mailing list for "./" to be omitted from the output is 1. If the proportion of users who specifically don't want "./" in the output is indeed small, then the burden of implementing or maintaining the feature isn't justified. But I've not said that you shouldn't remove the "./" or that you can't have the feature. You certainly can, you can change the code of GNU find any way you like. I will even try to help you do it, time allowing. I just won't be including this feature in the released version. James.
