Tue 21 Feb 2017 09:38:02 AM UTC, comment #13:
Hi Eric,
would you mind to prepare the test cases (plus the expected output)
for "-printf %h" for cases with /, //, /./, //foo, etc. which you'd
like to have changed?
BTW: I'm not sure the current behavior for a single '/' is correct;
it doesn't seem to be documented at least:
$ find / -maxdepth 0 -printf "'%h'\n"
''
Thanks & have a nice day,
Berny
|
Mon 20 Feb 2017 07:48:25 PM UTC, comment #12:
Thanks for your concern.
I think that's a different story:
$ ./find / // /// -maxdepth 0 -printf "'%h'\n"
''
'/'
'//'
$ /usr/bin/find / // /// -maxdepth 0 -printf "'%h'\n"
''
'/'
'//'
The commit didn't change this - it just fixed the issue with the trailing slash(es) without changing anything else.
|
Mon 20 Feb 2017 07:06:39 PM UTC, comment #11:
You need to make sure 'find // -printf %h' does not corrupt leading // (which POSIX allows to be distinct from /).
|
Mon 20 Feb 2017 05:57:39 PM UTC, comment #10:
No comment, so I pushed - with a slightly better NEWS entry
and commit message at:
https://git.sv.gnu.org/cgit/findutils.git/commit/?id=2a6129bfcc
|
Fri 17 Feb 2017 12:46:46 AM UTC, comment #9:
It turned out to become clearer code when stripping off
all trailing directory separators is done first.
Patch v2 attached.
(file #39769)
|
Tue 14 Feb 2017 07:07:12 AM UTC, comment #8:
Hmm, also the other case, i.e., for multi-dir pathnames has
the same bug:
$ find foo//bar// -printf "%%p=%p, %%h=%h, %%f=%f -> %%h/%%f=%h/%f\n"
%p=foo//bar//, %h=foo//bar/, %f=bar/ -> %h/%f=foo//bar//bar/
I'll fix that, too.
|
Mon 13 Feb 2017 06:48:32 AM UTC, comment #7:
You're right, I missed the following test case:
$ ./find foo// -printf "%p,%h,%f\n"
foo//,foo/,foo/
foo//bar,foo/,bar
I'll send an update soon.
Thanks & have a nice day,
Berny
|
Mon 13 Feb 2017 02:29:42 AM UTC, comment #6:
Great! Why limit it to a single trailing slash though?
|
Sun 12 Feb 2017 01:27:07 PM UTC, comment #5:
With that patch, you can also have a look on what's changed
compared to the installed version with the following snippet:
$ mkdir -p foo/bar
$ ln -snf foo foolink
$ for opt in '' -H -L -P ; do
printf "\n=== Differences for option: '%s' ===\n" "$opt"
diff -u0 \
<( /usr/bin/find $opt {,./}{/,.,foo,foolink}{,/,/.} -maxdepth 1 -printf "%h/%f,%%p=%p,%%h='%h',%%f='%f'\n" ) \
<( ./find $opt {,./}{/,.,foo,foolink}{,/,/.} -maxdepth 1 -printf "%h/%f,%%p=%p,%%h='%h',%%f='%f'\n" )
done | column -t -s,
|
Sun 12 Feb 2017 01:15:42 PM UTC, comment #4:
The attached patch fixes this. I also added some more test
cases for "%h".
Have a nice day,
Berny
(file #39733)
|
Sat 11 Feb 2017 07:50:00 PM UTC, comment #3:
Yes, you're right, I think one is needed. From your example:
$ find foo/ -printf '%h/%f\n'
foo/foo/
foo/bar
I assume that (in your test case) foo/foo does not actually exist. That isn't really the intended behavour (rather the current behaviour is an unintended consequence of the functionality described in the documentation).
|
Fri 10 Feb 2017 07:21:30 PM UTC, comment #2:
> If the file's name contains no slashes (for example because it was named on the command line and is in the current working directory), then “%h” expands to “.”. This prevents “%h/%f” expanding to “/foo”, which would be surprising and probably not desirable.
This looks to me like the intention was for "%h/%f" to be a valid path to the file (otherwise, why have the special case at all?).
But I realise that it does exactly document the current behaviour. Consider this a feature request then?
|
Fri 10 Feb 2017 05:05:07 PM UTC, comment #1:
The behaviour might be strange, but it's documented and explained:
https://www.gnu.org/software/findutils/manual/html_mono/find.html#Name-Directives
|
Thu 09 Feb 2017 01:12:01 AM UTC, original submission:
If the root path has a trailing slash, %h doesn't replace it with '.', resulting in this strange behaviour:
$ mkdir -p foo/bar
$ find foo -printf '%h/%f\n'
./foo
foo/bar
$ find foo/ -printf '%h/%f\n'
foo/foo/
foo/bar
|