Use *[path]/ so the PDF recipe follows nested directory indexes

*[file] cannot cross a slash, so *[file]/ only admits a single directory level and
silently drops PDFs linked under nested paths (dated archives, doc trees). *[path]/
spans slashes and follows directory-index pages at any depth, with no over-admission
(only trailing-slash URLs match, never files).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Xavier Roche <roche@httrack.com>

.github/workflows/ci.yml

@@ -618,31 +618,3 @@ jobs:
               echo "Fix locally with: git clang-format --binary clang-format-19 $base"
               exit 1 ;;
           esac
-
-  man-page-sync:
-    name: man page / html in sync
-    if: github.event_name == 'pull_request'
-    runs-on: ubuntu-24.04
-    steps:
-      - uses: actions/checkout@v6
-        with:
-          fetch-depth: 0
-
-      # html/httrack.man.html is groff-rendered from man/httrack.1 and committed.
-      # Rendering needs the full groff html device, so CI can't regenerate it;
-      # instead require the two to move together: a PR that touches httrack.1
-      # must also touch the html, catching the "regenerated roff, forgot html".
-      - name: httrack.1 changes must include html/httrack.man.html
-        run: |
-          set -euo pipefail
-          git fetch --no-tags origin \
-            "+refs/heads/${{ github.base_ref }}:refs/remotes/origin/${{ github.base_ref }}"
-          base="origin/${{ github.base_ref }}"
-          changed="$(git diff --name-only "$base"...HEAD)"
-          has() { printf '%s\n' "$changed" | grep -qx "$1"; }
-          if has man/httrack.1 && ! has html/httrack.man.html; then
-            echo "::error::man/httrack.1 changed but html/httrack.man.html did not."
-            echo "Regenerate it with: make -C man regen-man-html (needs the full groff package)."
-            exit 1
-          fi
-          echo "man/html sync OK."

html/abuse.html

@@ -217,7 +217,7 @@ school or
 shows. They might do that because they are connected through expensive modem connection,
 or because they would like to consult pages while travelling, or archive sites that may be
 removed
-one day, make some data mining, compiling information ("if only I could find this
+one day, make some data mining, comiling information ("if only I could find this
 website I saw one day..&quot;). <br>
 There are many good reasons to mirror websites, and this helps many good people.<br>
 As a webmaster, you might be interested to use such tools, too: test broken links, move a
@@ -229,7 +229,7 @@ test the webserver response and performances, index it..<br>
 Anyway, bandwidth abuse can be a problem. If your site is regularly &quot;clobbered&quot;
 by evil downloaders, you have <br>
 various solutions. You have radical solutions, and intermediate solutions. I strongly
-recommend not to use<br>
+recomment not to use<br>
 radical solutions, because of the previous remarks (good people often mirror websites).<br>
 <br>
 In general, for all solutions,<br>
@@ -244,7 +244,7 @@ or, to be extreme: if you unplug the wire, there will be no bandwidth abuse<br>
 Good: Will work with good people. Many good people just don't KNOW that they can slow down
 a network.<br>
 Bad: Will **only** work with good people<br>
-How to do: Obvious - place a note, a warning, an article, a draw, a poem or whatever you
+How to do: Obvious - place a note, a warning, an article, a draw, a poeme or whatever you
 want<br>
 <br>
 </li><li>Use &quot;robots.txt&quot; file<br>
@@ -266,7 +266,7 @@ Good: Efficient<br>
 Bad: Multiple users behind proxies will be slow down, not really easy to setup<br>
 How to do: Depends on webserver. Might be done with low-level IP rules (QoS)<br>
 <br>
-</li><li>Prioritize small files, against large files<br>
+</li><li>Priorize small files, against large files<br>
 Good: Efficient if large files are the cause of abuse<br>
 Bad: Not always efficient<br>
 How to do: Depends on the webserver<br>
@@ -283,7 +283,7 @@ How to do: Use routine QoS (fair queuing), or webserver options<br>
 <br>
 </li><li>Use technical tricks (like javascript) to hide URLs<br>
 Good: Efficient<br>
-Bad: The most efficient tricks will also cause your website to be heavy, and not
+Bad: The most efficient tricks will also cause your website to he heavy, and not
 user-friendly (and therefore less attractive, even for surfing users). Remember: clients
 or visitors might want to consult offline your website. Advanced users will also be still
 able to note the URLs and catch them. Will not work on non-javascript browsers. It will
@@ -335,7 +335,7 @@ Example: Use things like
 </li><li>Use technical tricks to temporarily ban IPs<br>
 Good: Efficient<br>
 Bad: Radical (your site will only be available online for all users), not easy to setup<br>
-How to do: Create fake links with &quot;killing&quot; targets<br>
+How to to: Create fake links with &quot;killing&quot; targets<br>
 Example: Use things like &lt;a href=&quot;killme.cgi&quot;&gt;&lt;nothing&gt;&lt;/a&gt;
 (again an example in php:)<br>
 <tt>
@@ -417,7 +417,7 @@ Example:<br>
 </li><li>Another one is to create images of emails<br>
 Good: Efficient, does not require javascript<br>
 Bad: There is still the problem of the link (mailto:), images are bigger than text, and it can cause problems for blind people (a good solution is use an ALT attribute with the email written like "smith at mycompany dot com")<br>
-How to do: Not so obvious if you do not want to create images by yourself<br>
+How to do: Not so obvious of you do not want to create images by yourself<br>
 Example: (php, Unix)<br>
 
 <tt>
@@ -491,7 +491,7 @@ echo <br>
 </li><li>You can also create temporary email aliases, each week, for all users<br>
 Good: Efficient, and you can give your real email in your reply-to address<br>
 Bad: Temporary emails<br>
-How to do: Not so hard to do<br>
+How to do: Not so hard todo<br>
 Example: (script &amp; php, Unix)<br>
 
 <tt>

html/cmdguide.html

@@ -219,23 +219,6 @@ that a <tt>403 Forbidden</tt> is a server refusal, not a robots rule: robots
 options will not help there. That is an
 <a href="#identity">identity</a> problem.</p>
 
-<h4>Filter wildcards</h4>
-<p>Inside a filter pattern, <tt>*</tt> matches any run of characters; a few
-bracket forms match narrower sets. The full table, with size and mime rules, is on
-<a href="filters.html">the filters page</a>.</p>
-<table class="tblRegular tableWidth" border="0">
-  <tr class="tblHeaderColor"><td><b>Wildcard</b></td><td><b>Matches</b></td><td><b>Example</b></td></tr>
-  <tr><td><tt>*</tt></td><td>any run of characters</td><td><tt>+*.pdf</tt> &mdash; any URL ending <tt>.pdf</tt></td></tr>
-  <tr><td><tt>*[file]</tt>, <tt>*[name]</tt></td><td>one path segment (any char but <tt>/</tt> and <tt>?</tt>)</td><td><tt>example.com/*[file]/</tt> &mdash; a directory-index page</td></tr>
-  <tr><td><tt>*[path]</tt></td><td>a path, slashes allowed (any char but <tt>?</tt>)</td><td><tt>example.com/*[path].zip</tt></td></tr>
-  <tr><td><tt>*[param]</tt></td><td>an optional query string</td><td><tt>page.html*[param]</tt> matches with or without <tt>?...</tt></td></tr>
-  <tr><td><tt>*[a,b,c]</tt></td><td>any one character in the set</td><td><tt>*[a,b,c].txt</tt></td></tr>
-  <tr><td><tt>*[a-z]</tt></td><td>any one character in the range</td><td><tt>img*[0-9].gif</tt></td></tr>
-  <tr><td><tt>*[\x]</tt></td><td>the literal character x (escapes <tt>* [ ] \</tt>)</td><td><tt>*[\*]</tt> matches a real <tt>*</tt></td></tr>
-  <tr><td><tt>*[&lt;NN]</tt>, <tt>*[&gt;NN]</tt></td><td>file size in KB below / above NN</td><td><tt>-*.gif*[&lt;5]</tt> skips GIFs under 5&nbsp;KB</td></tr>
-  <tr><td><tt>*[]</tt></td><td>end anchor: nothing may follow</td><td><tt>*.html*[]</tt> rejects <tt>i.html?p=1</tt></td></tr>
-</table>
-
 <h3 id="limits">4. Limits and politeness</h3>
 
 <p>HTTrack ships cautious on purpose: it is easy to hammer a small site by

html/filters.html

@@ -111,7 +111,7 @@ See also: The <a href="faq.html#VF1">FAQ</a><br>
     starts links, the default mode is to mirror these links - i.e. if one of your start page is
     www.example.com/test/index.html, all links starting with www.example.com/test/ will be
     accepted. But links directly in www.example.com/.. will not be accepted, however, because
-    they are in a higher structure. This prevent HTTrack from mirroring the whole site. (All
+    they are in a higher strcuture. This prevent HTTrack from mirroring the whole site. (All
     files in structure levels equal or lower than the primary links will be retrieved.)<br>
     </i>
     <br>
@@ -127,15 +127,13 @@ See also: The <a href="faq.html#VF1">FAQ</a><br>
     an authorization filter, like <b><tt>+*.gif</tt></b>. The pattern is a plus (this one: <b><tt>+</tt></b>),
     followed by a pattern composed of letters and wildcards (this one: <b><tt>*</tt></b>). 
     <br><br>
-    To forbid a family of links, define
+    To forbide a family of links, define
     an authorization filter, like <b><tt>-*.gif</tt></b>. The pattern is a dash (this one: <b><tt>-</tt></b>),
     followed by a the same kind of pattern as for the authorization filter.
     <br><br>
     Example: +*.gif will accept all files finished by .gif<br>
     Example: -*.gif will refuse all files finished by .gif<br>
     <br>
-    To see which rule accepted or blocked a given URL, run HTTrack with the <b><tt>--why</tt></b> (<b><tt>-%Y</tt></b>) option, described in <a href="httrack.man.html#OPTIONS">the manual page</a>.<br>
-    <br>
     
 <p>    
     <h4>Scan rules based on size (e.g. accept or refuse files bigger/smaller than a certain size)</h4>
@@ -145,7 +143,7 @@ See also: The <a href="faq.html#VF1">FAQ</a><br>
     size to ensure that you won't reach a defined limit.
     
     Example: You may want to accept all files on the domain www.example.com, using '+www.example.com/*', 
-    including gif files inside this domain and outside (external images), but not take to large images, 
+    including gif files inside this domain and outside (eternal images), but not take to large images, 
     or too small ones (thumbnails)<br>
     Excluding gif images smaller than 5KB and images larger than 100KB is therefore a good option;
     +www.example.com +*.gif -*.gif*[<5] -*.gif*[>100] 

man/Makefile.am

@@ -16,11 +16,6 @@ regen-man: makeman.sh $(top_builddir)/src/httrack$(EXEEXT)
 
 # Render html/httrack.man.html from httrack.1. Needs the groff html device
 # (Debian: full "groff" package, not "groff-base"). Run by hand: make -C man regen-man-html
-# Strip groff's version-stamp and creation-date comments so the committed file
-# doesn't churn across groff versions or rebuilds; the ci man-page-sync guard
-# only requires this file to change whenever httrack.1 does.
 regen-man-html: httrack.1
-	groff -t -man -Thtml $(srcdir)/httrack.1 \
-		| sed -e 's/groff version [0-9][0-9.]*/groff/' -e '/^<!-- CreationDate:/d' \
-		> $(top_srcdir)/html/httrack.man.html
+	groff -t -man -Thtml $(srcdir)/httrack.1 > $(top_srcdir)/html/httrack.man.html
 .PHONY: regen-man-html