« first day (2056 days earlier)   

11:13 AM
I have just read the disscussion you had about a ? matching the /

The whole discussion revolved around the confusing issue of the ROOT slash (/).

But it failed to address the issue of a ? matching an / in a path (not the root), like this:

........... mkdir -p one/two/three; find one -path 'one?two?three'

If it matches, then one ? could match one / in an string that contains slashes.
That means that a find pattern could match slashes.
Can anyone with knowledge on remotely accessing linux help me with a recommendation (sorry for cross posting) softwarerecs.stackexchange.com/questions/32359/…
11:29 AM
@PK-Killer That isn't answereable in its current form. You'll need to edit and explain what features you need and why. As it stands, you're just asking for opinion.
12:14 PM
I don't know what in this question is about programming unix.stackexchange.com/review/close/142184
@Braiam you're right, nothing, I was thinking of serverfault (or is there a better SE site for networking questions?).
12:42 PM
@derobert thanks for that pointer, derobert; I should have looked, rather than assuming
2 hours later…
@Braiam only in unstable and testing for now of course, stable is still safe for a few months...
2:46 PM
@BinaryZebra, all I'm saying is that shell pathname expansion
(aka globbing or filename generation) or the shell's "case"
construct or ksh's [[ x = pattern ]] operator use the same kind
of pattern as used by find's -name or -path, but that is not to
say that find's -name or -path perform shell globbing (or are
case contructs or [[...]]), so calling it as such is misleading.
My objection is on terminology ground. That is *not* pathname
Shell globbing is a special feature of shells. That takes a
pattern and generate a list of files out of that using a complex

For instance from a pattern like /*s*/lib[/e]*/"*"*, the shell will
first split it in parts (*s*, lib[, e]*, "*"*), and work from
there by listing the content of /, exclude the files that start
with "." as *s* doesn't start with ., finding the files of type
directory (or symlink to directory) in there that match *s*, for
each try to open $dir/lib[ if they are of type directory,
list their content, look for dirs that start with e], list
their content, look for files that start with "*".
By contrast "-name" and "-path" are just two out of many find
predicates that can be used to select a file. They don't affect
the way find descend the directory tree. The only predicates
that can do that are -depth, -maxdepth, -mindepth, -prune and
-quit. All they do is match the path (for -path) or basename
(for -name) of the currently considered file and return either
true or false (causing the next predicate (like -print) to be
run or not). They don't "expand", they "match" or "filter" if
you like.
find / -path '???????'
Will descend the entire file system (including hidden ones
except . and ..), and for each of the files being encountered,
print the ones whose path consist of 7 characters.
While the pathname expansion of ??????? will be the list of
files in the current directory whose name doesn't start with "."
and consist of 7 characters.
7 hours later…
9:38 PM
@StéphaneChazelas Where is "pathname generation" defined in the POSIX spec?

And my answer does say (emphasis mine):
"Those characters are used in a **similar** way in the command find."

That sentence does say that "Pathname expansion" and "find patterns" (even if closely related) are NOT equivalent.
The POSIX spec links both shell pathname expansion http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_06

And find's `-name` and `-path` patterns: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html#tag_20_47_05

To the same "Pattern Matching Notation" http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13
So, unless the POSIX spec is wrong, both: find patterns and Shell pathname expansions share the same basic characteristics. And both share the use of ?,* and [ to build patterns. The description of one is valid for the other. My answer is describing that shared characteristic and then explaining why that basic pattern must be quoted to avoid shell interpretation.
But that doesn't even start to cover the fact that a find pattern may match an slash, which a pathname expansion does not. And it has been the source of my comments to you (which you have failed to answer or address).

Again: Does mkdir -p one/two/three; find one -path 'one?two?three'
Print the path?, Then it follows that a ? in find patterns may match one slash (not the root slash but one slash anyway).

« first day (2056 days earlier)