2

Is it true that find is not supposed to be doing even the most simple path unification/simplifications operations, such as coalescing multiple successive slashes together (which would be equivalent to the original form)?

For example the output of find ./// is:

.///
.///somefile
[…]

(tested with find from GNU and busybox)

If so then why is that? Is there any sensible use case I'm missing? Perhaps for the case that someone is grepping the output of find inside scripts?

BTW, Also interesting is the output of GNU's find for find ./// -maxdepth 0 -printf '%h\n' (%h is supposed to be "Leading directories of file's name (all but the last element and the slash before it)"): .// (simply one fewer /)

Community
  • 1
phk
  • 5,953
  • 7
  • 42
  • 71
  • 3
    Related: http://unix.stackexchange.com/questions/256497/on-what-systems-is-foo-bar-different-from-foo-bar – Jeff Schaller Dec 30 '16 at 23:06
  • @JeffSchaller This is about the special case with leading slashes, it's true that this might theoretically make a difference but IMHO it would not justify never merging. – phk Dec 30 '16 at 23:12
  • 1
    POSIX simply says that the path operand is concatenated with the results, without saying that the concatenation could be simplified. I used that in a previous answer (this is probably a duplicate). – Thomas Dickey Dec 30 '16 at 23:15
  • Interesting question. I guess you could reverse the question: why would find merge multiple slashes? If, say, I got a script that uses find and it parses a string with multiple strokes / slashes then that may point to a bug in the script. In that case hiding the bug wouldn't be helpful. – rkhff Dec 30 '16 at 23:15
  • @rkhff I feel like it should do so because it acts on paths, has to understand them and it seems to me like it's always good to work with the most simple and clear representation, makes things possibly easier and less buggy. – phk Dec 30 '16 at 23:25
  • @rkhff But now that I think of, it might not be always easy to reach the most simple and unified representation, in that case you would have to define the exact process in the standard and this might be complex. And in the case of e.g. busybox code size might also play a role. – phk Dec 30 '16 at 23:27
  • 2
    Related: Is it ok that find displays double forward-slash? (where the applicable POSIX rule is quoted) – Gilles 'SO- stop being evil' Dec 30 '16 at 23:56
  • 2
    I probably had this (earlier) one in mind: 301570. – Thomas Dickey Dec 31 '16 at 00:06
  • 1
    You ask what is the usecase, like why did they write some code to do that. They did not. They just did not write extra code to do some thing else e.g. convert //// to /, or /./././ to / or foo/bar/.. to foo. Oh wait, that would be a bug, if bar say a symlink. So we would have to collapse in some cases and not in others. So I will restate the question, why does it not have more complex code to handle with special cases that don't need handling. – ctrl-alt-delor Jan 06 '17 at 16:57

1 Answers1

6

If you don't have utilities that can understand NUL characters, then this historical behavior can be used to distinguish between files. The output of find will never contain two slashes in a row unless they are provided as part of the initial path. This means that output like

.//path/to/file
./name/more

tells you that there is a directory called file\n. rather than there is a sub-directory of the current directory called name if you invoke find with

find .// -print
icarus
  • 17,920