Talk:Walk a directory/Recursively: Difference between revisions
→Be Careful: Not Here Only
| (9 intermediate revisions by 3 users not shown) | |||
Line 31:
fi</lang>
::::will say it is a directory, and you can do globbing on it just like normal dirs. You'd have to specifically remember to check if it's a symlink. --[[User:Ledrug|Ledrug]] 20:53, 13 June 2011 (UTC)
:::::Ok, yes, bash is very inconsistent about how it handles symlinks. I remember talking with the bash maintainer about this, a number of years ago, and felt unsatisfied afterwards. In particular, <code>cd ../example</code> can fail, while <code>cd -P .; cd ../example</code> can succeed, because bash implements its own rules for about what directories are in the context of symbolic links, which conflicts with that of the underlying operating system. But that's a bash issue -- I do not know of any other language which suffers from that design. (And bash can rely on <code>find</code> or <code>ls</code> which implement sane treatment of symbolic links.) --[[User:Rdm|Rdm]] 23:37, 13 June 2011 (UTC)
::::::Eh, not really a bash specific problem. E.g. <pre>perl -e 'print "is a dir\n" if -d "/some/symlink/dir"</pre> or zsh <pre>if [[ -d /some/symlink/dir ]]; then echo "is a dir"; fi</pre> basically <lang C>#include <stdio.h>
#include <sys/types.h>
#include <dirent.h>
int main() {
DIR * x = opendir("/symlink/dir");
if (x) {
printf("open ok\n");
closedir(x);
} else {
printf("open not ok\n");
}
return 0;
}
</lang> will succeed on openning a symlinked dir (it makes sense), and that's the thing one needs to check for. --[[User:Ledrug|Ledrug]] 00:53, 14 June 2011 (UTC)
:::::::Ok, you are right that -d under perl does the wrong thing for a terminating recursive traversal. That said, the perl implementation does not seem to be using -d for that purpose. Similarly, the C implementation uses stat, and not opendir, to recognize directories. Even the zsh implementation is doing the right thing. But now I am wondering: does zsh also have the issue where paths such as ../foo are manipulated by the shell before being passed to the operating system? --[[User:Rdm|Rdm]] 12:22, 14 June 2011 (UTC)
::::::: This script<lang bash>#!/usr/bin/zsh
cd /tmp
mkdir dir1 dir2
ln -s dir1 symlink
cd dir1; pwd
cd ../dir2; pwd
cd ..; pwd
cd symlink; pwd
cd ../dir2; pwd</lang>says: <lang>/tmp/dir1
/tmp/dir2
/tmp
/tmp/symlink
/tmp/dir2</lang>
Which doesn't seem to do anything unexpected. --[[User:Ledrug|Ledrug]] 17:20, 14 June 2011 (UTC)
::::::: I was thinking more like this: <lang bash>#!/usr/bin/bash
mkdir dir1 dir2
cd dir2
ln -s ../dir1
mkdir dir2
cd dir1
(cd -P .; cd ../dir2; pwd -P)
(cd .; cd ../dir2; pwd -P)
</lang> When I run that in the directory /tmp/t, I get: <lang>/tmp/t/dir2
/tmp/t/dir2/dir2</lang> That said, the behavior now is much better than what it used to be. If I remove the second mkdir line, and delete the directories and run that again, I get <lang>/tmp/t/dir2
/tmp/t/dir2</lang> where once upon a time if I did not use cd -P . I would get an error trying to <code>cd ../dir2</code>. --[[User:Rdm|Rdm]] 20:14, 14 June 2011 (UTC)
::::::: Tested your script in zsh, result was exactly the same. --[[User:Ledrug|Ledrug]] 20:32, 14 June 2011 (UTC)
== Be Careful: Not Here Only ==
Regarding ''"Note: Please be careful when running any code examples found here"'': that applies to pretty much every problem page you see on Rosetta!!! Any program that is not completely trivial and transparent (to your eyes) can be hiding something unsavory.--[[User:Kazinator|Kazinator]] ([[User talk:Kazinator|talk]]) 21:11, 19 June 2017 (UTC)
: Generally speaking, you should try to comprehend what the code is doing. That said, I have not noticed any abusive code here, yet. I have seen quite a lot of abusive users but mostly they are trying for search engine pollution (which we delete, of course) rather than investing their time into getting developers run bad code. Still, the whole point of this site is to understand what's going on in a variety of contexts, so putting some effort into that is good practice for a variety of reasons. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 21:30, 19 June 2017 (UTC)
| |||