Skip to content
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

PKGMAN_DownloadURL mixes stdout and stderr #77

Closed
lgoettgens opened this issue Sep 14, 2021 · 4 comments
Closed

PKGMAN_DownloadURL mixes stdout and stderr #77

lgoettgens opened this issue Sep 14, 2021 · 4 comments
Labels
feature request New feature

Comments

@lgoettgens
Copy link

lgoettgens commented Sep 14, 2021

When during the download of a file something gets written to stderr by the downloading program, the current implementation interleaves the two outputs, i.e. the error message appears somewhere inside the file. This leads to unexpected behavior when parsing the contents.
This is currently happening as wget 1.21.2 prints SSL_INIT to stderr at the beginning of each download (cf. wget mailing list).

The easy solution would be to remove the interleaving behavior in

fullcmd := Concatenation(fullcmd, " ", args, " 2>&1");

However, this is currently the only way to extract stderr from Process (cf. gap-system/gap#4657).

@mtorpey mtorpey added the feature request New feature label Sep 30, 2021
@mtorpey
Copy link
Collaborator

mtorpey commented Sep 30, 2021

Thanks for suggesting this! It may be a good idea to un-interleave these, but I'm not sure what we would then do with the stderr output. Perhaps writing to two different logs would be useful, but I'm not sure. Open to suggestions! :)

@lgoettgens
Copy link
Author

Right now, it doesn't get written to any files at all, so your idea doesn't work that easily, as everything is handled by a Process instance. The easiest way, in my opinion, would be to add that feature (keep both stdout and stderr) there and then use it here. Then, interleaving would no longer be needed.
This has already been proposed in gap-system/gap#4657

@mtorpey
Copy link
Collaborator

mtorpey commented Oct 1, 2021

Ah, I see! Sounds good to me – we can wait for the corresponding changes in GAP.

@mtorpey
Copy link
Collaborator

mtorpey commented Aug 30, 2024

I believe this is captured by #104.

@mtorpey mtorpey closed this as completed Aug 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature
Projects
None yet
Development

No branches or pull requests

2 participants