-
Notifications
You must be signed in to change notification settings - Fork 15
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
Ownership check (-Qo) chokes on executable file extension #36
Comments
It is not misleading at all. ntldd and ntldd.exe are two different file and ntldd does not exist.
No, it is the expected behavior. For example,
In the above example, mpv is a shell script whereas mpv.exe is a portable executable.
|
Just to clarify, I'd not want to change the behavior in your example (where there's a wrapper script AND an .exe file). My problem is that when using "pacman -Qo" for commands, I typically don't know or care if they have an .exe extension, and MSYS behavior actively enables and reinforces this in basically all other places:
But this fails hard with I used to believe that Would you at least be willing to consider merging a PR for this? |
I understand your perspective but I am not sure if that pacman behavior need to be changed. Please feel free to create a pull request. Others may share their views. |
I have a fix that is not too ugly! It is modelled after cygwin_spelling in an MSYS2 coreutils patch. If this is acceptable, I could also just PR the necessary changes in MSYS2-packages (because I have those for testing already anyways). Note: Lots of tests fail for pacman right now, but these are currently ignored. Thus I have not looked into adding unit tests for the added .exe suffix checking. |
If I want to check which package an executable is from, then it only works if I fully specify the file extension (e.g. ".exe").
Works
❯ pacman -Qo ntldd.exe
/ucrt64/bin/ntldd.exe is owned by mingw-w64-ucrt-x86_64-ntldd
Fails
❯ pacman -Qo ntldd
error: No package owns /ucrt64/bin/ntldd
Why this should be fixed
This is highly misleading, because it basically pretends that the file in question did not come from a package at all; if it was not intended to work, then it should NOT do the path lookup, because currently it basically acknowledges to the user that the file was found (without the user specifying the full path NOR the extension) and THEN fails if the extension is missing.
TL;DR: It would be non-ideal, but acceptable if
pacman -Qo ntldd
would return "error: No package owns ntldd" in the above example (note: output name is the same as user query).Possible fix
My approach to fixing this would be to add extension awareness (specifically: ".exe" only) to lrealpath (in https://github.com/msys2/msys2-pacman/blob/master/src/pacman/query.c#L101), which does path canonicalization already.
Questions
The text was updated successfully, but these errors were encountered: