Add a New Comment (Rich Markup)
Comment Type & Canned Response: None None > Multiple Canned Responses Fixed in CVS Is it reproducible? Fixed in alpha release, please test Fixed in current release
( Jump to the original submission )
Maybe similar to what GNU coreutils' ls?
https://www.gnu.org/software/coreutils/ls
‘-L’ ‘--dereference’ When showing file information for a symbolic link, show information for the file the link references rather than the link itself. However, even with this option, ls still prints the name of the link itself, not the name of the file that the link points to.
Obviously, this has to be extended for find(1) because also the tests like -size act on the de-referenced file (if it is a resolvable file).
Yes, I think we should fix the description of -L. Thanks, Andreas.
Incidentally our interpretation of {} is consistent with that in, for example, Solaris:
$ find -L . -ls -print -exec echo {} \; 176544 2 drwxr-xr-x 2 james other 4 Jun 13 23:56 . . . 176545 1 -rw-r--r-- 1 james other 6 Jun 14 00:02 ./b ./b ./b 176545 1 -rw-r--r-- 1 james other 6 Jun 14 00:02 ./a ./a ./a
Bernhard Voelker wrote:
> I'm trying to find the documentation which would make you as a our user think that -L would let -print or "-exec ... {}' +" use the resolved path name.
I think the description of -L very clearly states this:
-L Follow symbolic links. When find examines or prints information about files, [...]
The filename is "information about files". The real behavior of -L is more complicated than what this sentence says.
We're always interested in improving things, so thanks again for reporting an issue like this.
The implementation of -L is correct - or at least we don't have a proven example where it wouldn't be -; (only) the search, i.e., the tests, are based on the file referenced by the file a symbolic link points to. Or in the words of POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html
Cause the file information and file type evaluated for each symbolic link encountered as a path operand on the command line or encountered during the traversal of a file hierarchy to be those of the file referenced by the link, and not the link itself.
I'm trying to find the documentation which would make you as a our user think that -L would let -print or "-exec ... {}' +" use the resolved path name. Would you point us to such unclear passage, or even better provide a clearer phrasing as a matter for discussion?
Thanks & have a nice day, Berny
OK. This is your product, and you can do with it whatever you want(or don't do). But the manual doesn't describe correct beahviour of -L option. I'm not developer, i'm just a user. And from user's point of view this option works wrong
The information is a bit spread in the documentation. There is:
‘-print’ ‘-fprint’ [...] is handled in the same way as for the ‘%p’ directive of ‘-printf’ and ‘-fprintf’.
and:
%p File’s name (not the absolute path name, but the name of the file as it was encountered by find - that is, as a relative path from one of the starting points).
Is that sufficient?
Thank's for workaround, Berny! BUT! The key point of this option according to manual: When find examines or prints information about files, the information used shall be taken from the properties of the file to which the link points, not from the link itself
Many of my coleagues read manual of find, and understood it just like me. And were surprised by current find behaviour. I mean, why do you need this option if "GNU find will always pass the original name of the file found, regardless whether -L is in place or not"?
At my point of view, change is needed. Either in manual page of find or in its behaviour.
Thanks again for workaround!
While find(1) act on the de-referenced file with -L, the called file(1) does not - per default. GNU find will always pass the original name of the file found, regardless whether -L is in place or not. I think you simply want also file(1) to work on the de-referenced file, so this can easily be done by passing the -L option to file(1).
$ find -L ... -exec file -L '{}' +
Have a nice day, Berny
OK, i'm trying to say, that according to find manual page:
--- -L Follow symbolic links. When find examines or prints information about files, the information used shall be taken from the properties of the file to which the link points, not from the link itself (unless it is a broken symbolic link or find is unable to examine the file to which the link points). Use of this option implies -noleaf. If you later use the -P option, -noleaf will still be in effect. If -L is in effect and find discovers a symbolic link to a subdirectory during its search, the subdirectory pointed to by the symbolic link will be searched. ---
after executing "find -L temp2/ -type f" we should receive following output: temp/file0.txt
As i think after reading manual find should follow symlink and give me info about text file, but not symlink itself.
> So that i didn't do anything with found files and not using {}. But still with -L option it shows me symlink instead of text file.
I don't understand what you are trying to say there. What part of the output of your script do you think is wrong? What output did you expect instead?
I've modified your script a little:
#!/bin/bash set -u if ! top="$(mktemp -d)"; then echo "Failed to create a temporary directory" >&2; exit 1; fi ( set -eCu cd "${top}" mkdir temp temp2 echo "test" >| temp/file0.txt ( cd temp2 && ln -s ../temp/file0.txt file ) if ! wc -c < temp2/file >/dev/null ; then exit 1; fi echo echo with -L find -L temp2/ -type f echo "(ends)" echo echo without -L find temp2/ -type f echo "(ends)" echo echo with -L ... -exec file find -L temp2/ -type f -exec file '{}' \; echo "(ends)" echo ) rv=$? ls -ltR "${top}" rm -rf "${top}" exit $rv
So that i didn't do anything with found files and not using {}. But still with -L option it shows me symlink instead of text file. Here's output script produced:
root@ubuntu1804x64:~# bash test.sh
with -L temp2/file (ends)
without -L (ends)
with -L ... -exec file temp2/file: symbolic link to ../temp/file0.txt (ends)
/tmp/tmp.ap8ae5weXs: total 8 drwxr-xr-x 2 root root 4096 May 30 09:52 temp drwxr-xr-x 2 root root 4096 May 30 09:52 temp2
/tmp/tmp.ap8ae5weXs/temp: total 4 -rw-r--r-- 1 root root 5 May 30 09:52 file0.txt
/tmp/tmp.ap8ae5weXs/temp2: total 0 lrwxrwxrwx 1 root root 17 May 30 09:52 file -> ../temp/file0.txt
No, {} always expands to the file being considered, whether or not file properties are examined with stat (find -L) or lstat (find -P). This mostly makes a difference for the final file name component, since find follows directory symlinks when descending through the file system.
Correct me if i'm wrong, but with -L you should receive temp/file0.txt, not temp2/file.
The output I get looks like this:
$ sh sv56410.sh
with -L 3152508 4 -rw-r--r-- 1 youngman primarygroup 5 May 29 11:41 temp2/file (ends)
/tmp/tmp.jbIJfW8mse: total 8 drwxr-xr-x 2 youngman primarygroup 4096 May 29 11:41 temp drwxr-xr-x 2 youngman primarygroup 4096 May 29 11:41 temp2
/tmp/tmp.jbIJfW8mse/temp: total 4 -rw-r--r-- 1 youngman primarygroup 5 May 29 11:41 file0.txt
/tmp/tmp.jbIJfW8mse/temp2: total 0 lrwxrwxrwx 1 youngman primarygroup 17 May 29 11:41 file -> ../temp/file0.txt
Oops, here is a corrected script (the previous one had a missing "!" in the if.
#!/bin/bash
set -u
if ! top="$(mktemp -d)"; then echo "Failed to create a temporary directory" >&2; exit 1; fi
( set -eCu cd "${top}" mkdir temp temp2 echo "test" >| temp/file0.txt ( cd temp2 && ln -s ../temp/file0.txt file ) if ! wc -c < temp2/file >/dev/null ; then exit 1; fi echo echo with -L find -L temp2/ -type f -ls echo "(ends)" echo echo without -L find temp2/ -type f -ls echo "(ends)" echo echo with -L ... -exec file find -L temp2/ -type f -exec file '{}' \; echo "(ends)" echo ) rv=$? ls -ltR "${top}" rm -rf "${top}" exit $rv
The -L option affects the way that "find" treats symbolic links. But it has no effect on the "file" program run by -exec. {} expands to the file that "find" is currently considering, which is in this case is a symbolic link. Tests made by find on properties will reflect the properties of the file pointed to by find, but {} will expand to the name of the symbolic link (and not its target).
Here is a shell script which I think demonstrates the point you were trying to make, but without requiring root privileges.
if ! top="$(mktemp -d)"; then echo "Failed to create a temporary directory" >&2 exit 1 fi
( set -eCux cd "${top}" mkdir temp temp2 echo "test" >| temp/file0.txt ( cd temp2 && ln -s ../temp/file0.txt file ) if wc -c < temp2/file >/dev/null ; then exit 1 fi find -L temp2/ -type f -exec file '{}' \; ) rv=$? ls -ltR "${top}" rm -rf "${top}" exit $rv
Please provide a specific example, including detailed setup instructions, that reproduces your problem.
Hello!
I was trying to find files from directory full of symlinks and exec file on them, but wasn't able to do so. Find just show info about symlinks, instead of files they lead to, despite option -L was specified
Here is an example:
root@ubuntu1804x64:~# find --version find (GNU findutils) 4.7.0-git Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
Written by Eric B. Decker, James Youngman, and Kevin Dalley. Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS(FTS_CWDFD) CBO(level=2) root@ubuntu1804x64:~# mkdir /temp root@ubuntu1804x64:~# mkdir /temp2 root@ubuntu1804x64:~# echo "test" > /temp/file0.txt root@ubuntu1804x64:~# ln -s /temp/file0.txt /temp2/file root@ubuntu1804x64:~# find -L /temp2/ -type f -exec file '{}' \; /temp2/file: symbolic link to /temp/file0.txt
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Only logged-in users can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 3 latest changes.
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.10