Skip to content

Update --accept behaviour #1661

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Tracked by #664
naher94 opened this issue Mar 8, 2025 · 5 comments
Open
Tracked by #664

Update --accept behaviour #1661

naher94 opened this issue Mar 8, 2025 · 5 comments
Labels
help wanted Extra attention is needed question Further information is requested triage waiting-for-feedback

Comments

@naher94
Copy link

naher94 commented Mar 8, 2025

Another question. Is there a way to skip certain error codes? I notice there is an include (--accept) but didn't see an exclude for codes.

@mre
Copy link
Member

mre commented Mar 8, 2025

Nope, there's just --accept. What should the new parameter be called? Would it take preference over --accept?

@naher94
Copy link
Author

naher94 commented Mar 8, 2025

Could be called --deny and seems reasonable to follow the same logic of --include "Has preference over all excludes". In this case --accept would take preference, if specified, over --deny

--include
URLs to check (supports regex). Has preference over all excludes

What do we think?

@mre
Copy link
Member

mre commented Mar 9, 2025

Yeah, makes sense to me. I will let this cook for a while to see what other people are thinking. Anyone else who's interested in this, please add a comment.

@mre mre transferred this issue from lycheeverse/lychee-action Mar 20, 2025
@mre mre added help wanted Extra attention is needed question Further information is requested waiting-for-feedback labels Mar 20, 2025
@thomas-zahner
Copy link
Member

Had some thoughts about this. The documentation and help message read the following:

  -a, --accept <ACCEPT>
          A List of accepted status codes for valid links

          The following accept range syntax is supported: [start]..[=]end|code. Some valid
          examples are:

          - 200..=204
          - 200..204
          - ..=204
          - ..204
          - 200

          Use "lychee --accept '200..=204, 429, 500' <inputs>..." to provide a comma-
          separated list of accepted status codes. This example will accept 200, 201,
          202, 203, 204, 429, and 500 as valid status codes.

          [default: 100..=103,200..=299]

At the end we can see the default value for this argument. Also its not possible to specify the argument multiple times. (error: the argument '--accept <ACCEPT>' cannot be used multiple times) Personally, when I read this documentation I would expect to overwrite the default values when specifying --accept. I think --accept should simply list all accepted status codes and overwrite the default values. At the moment the default doesn't seem to be overwritten.

So currently:

lychee --accept 123
Accepts the default values 100..=103,200..=299 plus 123

However it would be simpler if lychee would now only accept the status code 123 and deny any others. The drawback of this would be that we break compatibility (probably quite a few people depend on this flag) and it might be less ergonomic for most use cases. If we think these disadvantages are to great I would agree on adding a --deny flag.

@mre
Copy link
Member

mre commented Mar 28, 2025

You're probably right. It is odd, that --accept does not overwrite the default. I'd be okay with changing that. It follows the principle of least surprise.

@mre mre added the triage label Mar 28, 2025
@thomas-zahner thomas-zahner changed the title Question: Excluding error codes Update --accept behaviour Apr 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed question Further information is requested triage waiting-for-feedback
Projects
None yet
Development

No branches or pull requests

3 participants