Hi Giuseppe, Do you have any plan to add this new framework so that more flexible options can be supported in the near future? (I guess this may mean rewritten all the command line options related code, which is a lot of work.)
On Mon, Aug 8, 2011 at 7:51 AM, Giuseppe Scrivano <gscriv...@gnu.org> wrote: > Hi Peng, > > GNU find has to follow POSIX specifications, while wget has not. IMHO, > the best way to expand wget to do such cool things is to support GNU > guile to evaluate expressions, or executing an external process. > > Cheers, > Giuseppe > > > > Peng Yu <pengyu...@gmail.com> writes: > >> Hi, >> >> It seems that all the options checked in download_child_p() are >> AND'ed. In gnu find, options can be and'ed or or'ed much more >> flexibly. I looked at wget source, it is not clear to me that flexible >> expression can be supported by the current wget cmdline option parsing >> framework. >> >> Does anybody know anything about how find does this and if wget can >> adapt the techniques in find to support flexible options? >> >> From man find: >> OPERATORS >> Listed in order of decreasing precedence: >> >> ( expr ) >> Force precedence. Since parentheses are special to >> the shell, you will normally need to quote them. Many of the examples >> in this manual page use backslashes for this purpose: >> `\(...\)' instead of `(...)'. >> >> ! expr True if expr is false. This character will also usually >> need protection from interpretation by the shell. >> >> -not expr >> Same as ! expr, but not POSIX compliant. >> >> expr1 expr2 >> Two expressions in a row are taken to be joined with an >> implied "and"; expr2 is not evaluated if expr1 is false. >> >> expr1 -a expr2 >> Same as expr1 expr2. >> >> expr1 -and expr2 >> Same as expr1 expr2, but not POSIX compliant. >> >> expr1 -o expr2 >> Or; expr2 is not evaluated if expr1 is true. >> >> expr1 -or expr2 >> Same as expr1 -o expr2, but not POSIX compliant. > -- Regards, Peng
