Re: checklink: error (or opportunity for improvement?) in masquerade option and/or checklink.pod

Hello C. M.,

Thanks for the detailed feedback.

On Friday 24 April 2009, C. M. Sperberg-McQueen wrote:

> As noted already results were misleading.  They were obtained using a
> for ... do construction on the bash command line in which I appear to
> have made a character escaping error.  (RFE: perhaps the handling of
> the --masquerade option should check for a first argument which begins
> with a literal quotation mark or a second argument which ends with
> one?)

Hmm... that's a pretty specific tweak, perhaps we should try checking that 
both are well formed URI's instead?  And maybe the URI's should be 
canonicalized and transformed using real URI resolution instead of simple 
"starts with" string matching?

Also, if you happen to have the previous buggy script or another reproducer 
for the perl warnings you got, please send them my way (or this list or the 
W3C Bugzilla) and I'll see what can be done about them.

> Now that I seem to have gotten --masquerade to work, I can suggest
> wording for the man page which I think may be clearer for some
> readers.  The current man page says this about masquerade:
> --masquerade "local remote"
[...]
> I propose two alternative versions: (A), which retains the local /
> remote example, and 9B), which doesn't.

First, both of your alternatives reverse the order of the given URIs 
(previously kind of "to from", your suggestions have "from to").  Is that 
intentional?  While perhaps more intuitive that way, it would be a backwards 
compatibility issue.

I've applied a slightly modified version of your (B) alternative in CVS 
(reversed order of real-prefix and surrogate-prefix, see above) because it's 
more accurate with the current link checker behavior.  More changes will be 
needed if we change from simple "starts with" string replacement to URI 
canonicalization/resolution (see beginning of my reply).  BTW checklink --
help's brief --masquerade entry already uses the base URI term.

Thanks!

Received on Tuesday, 28 April 2009 20:40:36 UTC