Re: [Bug-wget] Bug in processing url query arguments that have '/'

[Giuseppe Scrivano]

Peng Yu pengyu...@gmail.com writes:

 I was looking at the patched version. (See the patch posted in bug
 #31147) So I think that the bug in the patch (see the relevant code
 below, where full_file has the query string). I guess for full_file a
 different 'acceptable' function should be used.

   if (opt.match_query_string) full_file = concat_strings(u-file, ?,
 u-query, (char *) 0);

   if (!acceptable (full_file))
 {
 DEBUGP ((%s (%s) does not match acc/rej rules.\n,
   url, full_file));
 goto out;
 }
   }

I am inclined to don't add more options to the current Accept/Reject
rules, as I think they are not flexible enough and quite tricky.

It is better to support a more generic way to specify these rules.

Cheers,
Giuseppe

Re: [Bug-wget] 'or' and flexible expression of wget options

[Peng Yu]

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