[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-wget] recursive_retrieve()
From: |
Tim Rühsen |
Subject: |
Re: [Bug-wget] recursive_retrieve() |
Date: |
Mon, 06 Mar 2017 21:07:18 +0100 |
User-agent: |
KMail/5.2.3 (Linux/4.9.0-2-amd64; KDE/5.28.0; x86_64; ; ) |
On Montag, 6. März 2017 11:59:43 CET Dale R. Worley wrote:
> Tim Rühsen <address@hidden> writes:
> > Did you try wildcard matching ? (-A "*.pdf*")
>
> That's a bit subtle, though. The -A pattern apparently has to match
> everything in the URL after the final /, *including* the query-part
> ("?..."), which strictly speaking isn't part of the file name. But the
> documentation of -A/-R (in 1.16) describes it as a pattern to match the
> file name:
>
> -A acclist --accept acclist
> -R rejlist --reject rejlist
> Specify comma-separated lists of file name suffixes or patterns
> to accept or reject. Note that if any of the wildcard characters, *, ?, [
> or ], appear in an element of acclist or rejlist, it will be treated as a
> pattern, rather than a suffix. In this case, you have to enclose the
> pattern into quotes to prevent your shell from expanding it, like in -A
> "*.mp3" or -A '*.mp3'.
>
> Then again, what does -A/-R match against in a URL
> "http://example.com/file.pdf?a/b/c"?
>
> It seems like this needs something like "Note that this is matched
> against the entire part of the URL following the final slash; for URLs
> containing queries, it may not be the final component of the path part
> of the URL."
It is matched against the (local) filename (file part of the path), whatever
that contains or looks alike.
Tim
signature.asc
Description: This is a digitally signed message part.