lychee
lychee copied to clipboard
Don't show progress bar when waiting for user input
Running lychee - (or cargo run -) shows the progress bar without ever finishing. This should not happen.
This doesn't seem to be new. It also happens on v0.10.0 from 3 years ago.
That's expected behavior. Other UNIX tools like cat and grep also block on stdin if no file paths are given.
curl does the same.
curl -d@- # waits forever
(The -d@- option tells curl to read the data from stdin. Source)
The "-" is a convention as well.
Ken Thompson (designer and implementer of the original Unix operating system) modified sort in Version 5 Unix to accept "-" as representing standard input, which spread to other utilities and became a part of the operating system as a special file in Version 8. -- (Source: Wikipedia)
So unless I'm missing something, I'd keep it that way. 😅
Oh, okay I see 😄 I totally agree with you. I realise it was the progress bar that caused my confusion.
Using lychee -v - interestingly enough behaves like I would expect.
Typing lychee - means you can now enter URLs to check and "run" it with Ctrl+D. This is congruent with sort, cat and curl @-. (curl -d@- seems to not behave this way)
So I would suggest to just remove the endlessly spinning progress bar with lychee - because this seems like a bug to me. lychee is not checking links while waiting for user input so no progress bar should be visible. Do you agree?
Ah, yes, let's do that.
why these two produce different outputs?
➜ lychee git:(master) ✗ cargo run https://github.com/lycheeverse/lychee/issues/1736
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.52s
Running `target/debug/lychee 'https://github.com/lycheeverse/lychee/issues/1736'`
103/103 ━━━━━━━━━━━━━━━━━━━━ Finished extracting links Issues found in 1 input. Find details below.
[https://github.com/lycheeverse/lychee/issues/1736]:
[406] https://github.com/lycheeverse/lychee/sponsor_button | Rejected status code (this depends on your "accept" configuration): Not Acceptable
[404] https://github.com/search/custom_scopes/check_name | Rejected status code (this depends on your "accept" configuration): Not Found
[404] https://github.com/search/feedback | Rejected status code (this depends on your "accept" configuration): Not Found
[404] https://github.githubassets.com/ | Rejected status code (this depends on your "accept" configuration): Not Found
🔍 103 Total (in 4s) ✅ 99 OK 🚫 4 Errors
[WARN ] There were issues with GitHub URLs. You could try setting a GitHub token and running lychee again.
➜ lychee git:(master) ✗ cargo run -
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.45s
Running `target/debug/lychee -`
https://github.com/lycheeverse/lychee/issues/1736
🔍 1 Total (in 8s) ✅ 1 OK 🚫 0 Errors
as for the progress bar, I think we could overwrite no_progress when loading the config, if the input is Stdin
if let Ok(inputs) = opts.inputs() {
if inputs
.iter()
.any(|input| input.source == InputSource::Stdin)
{
opts.config.no_progress = true;
}
}
Thank you @rodic for your suggestion. But I'm not quite sure if your code snippet makes sense. I assume this is more of a timing/ordering issue. I think the progress bar is shown too early. It shouldn't be shown before any actual link checking. If there are any inputs from stdin then we still want to show a progress bar.
why these two produce different outputs?
The commands do two totally different things. lychee https://example.com checks links in the HTML of the content served on https://example.com whereas any input from stdin is treated as file input.
So think of lychee https://example.com as curl https://example.com | lychee -
@thomas-zahner @mre here's an attempt to consolidate the current logic before we fix the issue. If you can please give it a look when you find time - https://github.com/lycheeverse/lychee/pull/1835
See https://github.com/lycheeverse/lychee/pull/1914#issuecomment-3532526933. In summary the progress bar is still shown when waiting for user input. But it is no longer ticked while waiting for user input, making it way less obstructive as shown in the recording.