EDIT: This issue identified multiple concerns and split those out into separate issues, as noted with the closing comment below.
When providing a relative path, I wasn't aware at the time the path was invalid (wrong git branch, file did not exist).
- I was testing with
--dump prior, so I was a bit confused why lychee was attempting to make a network request in the first place..
- As a new user
--offline seemed like it might have been a workaround (before I realized the issue was the file not existing, not content).
--skip-missing was the actual option I should have used, although I'm not sure if lychee should have attempted to do such an HTTP request when the file was missing?
- I guess some environments may have single label DNS hostnames other than
localhost if they've got their local resolver appending a search domain(s), so maybe assuming it's a query like example.com/path/localhost/path is correct..
Example:
$ lychee --offline 'path/to/file.md'
Error: Network error
Caused by:
0: error sending request for url (http://path/to/file.md): error trying to connect: dns error: no record found for name: path. type: AAAA class: IN
1: error trying to connect: dns error: no record found for name: path. type: AAAA class: IN
2: dns error: no record found for name: path. type: AAAA class: IN
3: no record found for name: path. type: AAAA class: IN
So that issue probably isn't a bug, and just requires the user to be aware of the difference in --offline (links found) and --skip-missing (files to parse).
I have tested --skip-missing with a local webserver with input arg localhost/index.html. If the server isn't running, nothing is output, and if it is running, it does make the request to process. I haven't set up a local DNS service to view logs, but I assume --skip-missing is still making DNS requests for invalid files based on that, just ignoring the errors?
Is there presently no option of assuming relative file paths for lychee args, avoiding the DNS queries if no file is found? Only making requests when an appropriate scheme for the arg value is present (eg http:///https://?)
A related issue I experienced was when I tried to add a hint to lychee that this really was a relative file path:
$ lychee --skip-missing './path/to/file.md'
⠒ 0/0 [00:00:29] █████████████████████████ Extracting links
# Later times out with output:
🔍 0 Total ✅ 0 OK 🚫 0 Errors
That times out after 30 seconds, but it seems it should have known to skip much earlier? Any ideas why the behaviour differs due to ./? (I guess this is more explicit as a local/relative file path, but perhaps the timeout is an attempt to make a remote request/lookup)
When using --dump, the ./ prefix results in the same behaviour, minus the "Extracting links" line (instead a line with a single "█" is visible).
EDIT: This issue identified multiple concerns and split those out into separate issues, as noted with the closing comment below.
When providing a relative path, I wasn't aware at the time the path was invalid (wrong git branch, file did not exist).
--dumpprior, so I was a bit confused whylycheewas attempting to make a network request in the first place..--offlineseemed like it might have been a workaround (before I realized the issue was the file not existing, not content).--skip-missingwas the actual option I should have used, although I'm not sure iflycheeshould have attempted to do such an HTTP request when the file was missing?localhostif they've got their local resolver appending a search domain(s), so maybe assuming it's a query likeexample.com/path/localhost/pathis correct..Example:
So that issue probably isn't a bug, and just requires the user to be aware of the difference in
--offline(links found) and--skip-missing(files to parse).I have tested
--skip-missingwith a local webserver with input arglocalhost/index.html. If the server isn't running, nothing is output, and if it is running, it does make the request to process. I haven't set up a local DNS service to view logs, but I assume--skip-missingis still making DNS requests for invalid files based on that, just ignoring the errors?Is there presently no option of assuming relative file paths for
lycheeargs, avoiding the DNS queries if no file is found? Only making requests when an appropriate scheme for the arg value is present (eghttp:///https://?)A related issue I experienced was when I tried to add a hint to
lycheethat this really was a relative file path:That times out after 30 seconds, but it seems it should have known to skip much earlier? Any ideas why the behaviour differs due to
./? (I guess this is more explicit as a local/relative file path, but perhaps the timeout is an attempt to make a remote request/lookup)When using
--dump, the./prefix results in the same behaviour, minus the "Extracting links" line (instead a line with a single "█" is visible).