<div dir="ltr"><div>There is a solution that can be used meanwhile which seems to work at least back to R15.<br></div><div><br></div><div>filelib:wildcard/2 allows a module that gets information from the filesystem to be passed as second argument. The module only needs to export read_file_info/1 and list_dir/1, as defined here:</div>
<div><br></div><div><a href="https://github.com/erlang/otp/blob/maint/lib/stdlib/src/filelib.erl#L490-L508">https://github.com/erlang/otp/blob/maint/lib/stdlib/src/filelib.erl#L490-L508</a><br></div><div><br></div><div>Given the module defined below:</div>
<div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>-module(file_no_dot_match).</div></div><div><div>-export([read_file_info/1, list_dir/1]).</div></div><div><div><br></div></div>
<div>
<div>read_file_info(File) -></div></div><div><div> file:read_link_info(File).</div></div><div><div><br></div></div><div><div>list_dir(Dir) -></div></div><div><div> case file:list_dir(Dir) of</div></div><div><div>
{ok, Files} -></div>
</div><div><div> {ok, [File || File <- Files, hd(File) /= $.]};</div></div><div><div> Other -></div></div><div><div> Other</div></div><div><div> end.</div></div></blockquote><div><br></div><div>You can now get filelib:wildcard/2 to ignore files starting with dot by passing the module as argument:</div>
<div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>filelib:wildcard(Pattern, file_no_dot_match).</div></blockquote></div><div><br></div><div>I have run some tests locally and this approach seem to initially work fine. *, ** and ? now all ignore dots at the beginning of the file name.</div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div><br></div><div><br></div><div><span style="font-size:13px"><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><b>José Valim</b></span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><div><span style="font-family:verdana,sans-serif;font-size:x-small"><a href="http://www.plataformatec.com.br/" style="color:rgb(42,93,176)" target="_blank">www.plataformatec.com.br</a></span></div>
<div><span style="font-family:verdana,sans-serif;font-size:x-small">Skype: jv.ptec</span></div><div><span style="font-family:verdana,sans-serif;font-size:x-small">Founder and Lead Developer</span></div></span></div></span></div>
</div>
<br><br><div class="gmail_quote">On Tue, Jun 17, 2014 at 3:26 AM, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
While installing rebar today, I ran into a problem.<br>
The problem *happened* to bite me in rebar, but it<br>
is in no way a rebar-specific problem. It's quite<br>
easy to patch around the problem in rebar, but it's<br>
worth discussing whether a more general fix is<br>
appropriate.<br>
<br>
Here's the symptom:<br>
<br>
m% ./bootstrap<br>
Recompile: src/._rebar<br>
src/._rebar.erl:1: unterminated string starting with "l\000\000\016â\000\000\000\230\000\000\000N\000\000\000"<br>
src/._rebar.erl:1: no module definition<br>
Failed to compile rebar files!<br>
<br>
Here's one of the two causes:<br>
<br>
%% Compile all src/*.erl to ebin<br>
case make:files(filelib:wildcard("src/*.erl"),<br>
<br>
The whole setup has<br>
- no problems in Linux<br>
- no problems in Solaris<br>
- no problems in OpenBSD<br>
- no problems in Mac OS X with its native file system<br>
BUT<br>
- is broken in Mac OS X with files accessed over NFS.<br>
<br>
The basic issue is that Mac OS X still wants files to<br>
have "data forks" and "resource forks", which it uses<br>
for "extended attributes". Like these:<br>
<br>
m% ls -l@ rebar-master.zip<br>
-rw-r--r--@ 1 ok csstaff 247237 17 Jun 11:37 rebar-master.zip<br>
com.apple.quarantine 78<br>
com.apple.metadata:kMDItemWhereFroms 132<br>
com.apple.metadata:kMDItemDownloadedDate 53<br>
<br>
This is actually quite handy; using the 'xattr' command I can<br>
discover not just that it was Safari that downloaded the file,<br>
but where it was downloaded from.<br>
<br>
It's also the case that when you unpack downloaded files,<br>
the extracted files get the same 'quarantine' information.<br>
<br>
It's not just downloading.<br>
<br>
This all works smoothly in the Mac's own file system, but when<br>
your home directory is held on a departmental file server and<br>
accessed through NFS, it's handled by giving each file xxx a<br>
a ._xxx shadow. See for example <a href="http://support.grouplogic.com/?p=1496" target="_blank">http://support.grouplogic.com/?p=1496</a><br>
<br>
This is not a problem in shell scripts.<br>
m% cd rebar-master/src; ls *.erl<br>
will not show the AppleDouble dot-underscore files,<br>
because shell wild cards don't match leading dots.<br>
<br>
However, it appears that filelib:wildcard(...) wildcards<br>
DO match leading dots.<br>
<br>
m% mkdir FOO<br>
m% cd FOO<br>
m% touch .foo .barfood .foogol<br>
m% erl<br>
1> filelib:wildcard("*").<br>
[".barfood",".foo",".foogol"]<br>
2> filelib:wildcard("*.foo*").<br>
[".foo",".foogol"]<br>
<br>
This discrepancy between Erlang wildcards and UNIX wildcards<br>
is not a bug waiting to happen. It is a bug that *has* happened.<br>
The documentation for filelib:wildcard/1<br>
<a href="http://www.erlang.org/doc/man/filelib.html#wildcard-1" target="_blank">http://www.erlang.org/doc/man/filelib.html#wildcard-1</a><br>
not only does not mention the problem, it goes out of its way<br>
to present examples that *WILL* go wrong in Mac OS X.<br>
<br>
>From a user perspective, the simplest and by far the best change<br>
would be to make "*" wildcards act like their Unix analogues and<br>
NOT match leading dots, and the same with "?".<br>
<br>
This would immediately fix quite a few programs that are now<br>
broken (like all of the wildcard examples in the documentation).<br>
<br>
The least effort change would alter the documentation:<br>
<br>
wildcard(Wildcard) -> [file:filename()]<br>
<br>
Types:<br>
<br>
Wildcard = filename() | dirname()<br>
<br>
The wildcard/1 function returns a list of all files that match<br>
Unix-style wildcard-string Wildcard.<br>
<br>
The wildcard string looks like an ordinary filename, except that<br>
certain "wildcard characters" are interpreted in a special way.<br>
The following characters are special:<br>
<br>
?<br>
Matches one character.<br>
<br>
*<br>
Matches any number of characters up to the end of the<br>
filename, the next dot, or the next slash.<br>
+++ BEWARE: in the Unix shells, a * wildcard will never<br>
+++ match a leading dot. Thus the file name "._stuff.erl"<br>
+++ won't match "*.erl" in a shell. But in this function<br>
+++ it WILL match.<br>
<br>
....<br>
<br>
[Character1,Character2,...]<br>
^ ^<br>
<br>
*** compile_charset/2 does not in fact require commas or process<br>
*** them specially; remove the commas from the documentation.<br>
<br>
+++ Character classes in ``re'' regular expressions and csh(1)<br>
+++ command lines can be complemented using "^". ksh(1) uses<br>
+++ "!" for complementing. bash(1) allows both "^" and "!".<br>
+++ This function allows neither. You cannot complement a<br>
+++ character class at all.<br>
<br>
To find all .beam files in all applications, the<br>
following line can be used:<br>
<br>
filelib:wildcard("lib/*/ebin/*.beam").<br>
<br>
+++ BEWARE: if you are using Mac OS X and accessing files through<br>
+++ NFS the extended attributes of a snark.beam file will be held<br>
+++ in a ._snark.beam file, *which this pattern will match*.<br>
<br>
Then all the examples need fixing, but unfortunately it's rather<br>
hard to fix them. The simplest patch to the examples would be<br>
to change e.g. "lib/*/ebin/*.beam" to "lib/*/ebin/[^.]*.beam".<br>
<br>
Unfortunately, filelib:wildcard/1 not only does not support<br>
complement character set patterns, it doesn't know (and the<br>
documentation doesn't say) that there is an issue.<br>
<br>
m% touch '^x.foo' '.y.foo'<br>
4> filelib:wildcard("[^.]*.foo").<br>
[".y.foo","^x.foo"]<br>
5> filelib:wildcard("[!.]*.foo").<br>
[".y.foo"]<br>
<br>
The absence of character class complementation means that there<br>
is currently NO easy way for Erlang programmers to write wild-card<br>
patterns that do the right thing, which is why I think that<br>
fixing the semantics is the best thing to do.<br>
<br>
<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div>