-
-
Notifications
You must be signed in to change notification settings - Fork 13
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
from: fallback to command for non-existent files #51
Conversation
Could you perhaps make this part of/adjacent to the |
Like that? |
I think putting it in the |
I mean, resolve is currently only used in xbps. Do you want me to add it to every other PM? |
to be clear,
what's this meant to do? |
Rename this PR and make it both update |
Example: I want to know what package provides
This function resolves symlinks in paths so that this does not happen. You can just add this functionality to it. |
Oh, the next line makes it work yeah i'm never gonna look at those lines again, it hurts |
dab6921
to
dab69c3
Compare
@willeccles You might wanna link the issue to this PR in this PR's sidebar btw. |
You'll never guess who I got them from. |
Does this actually work with more than one argument? |
honestly the natural leadon from that is that I did it? Fairly sure I didn't, and I didn't even know that -P existed.
Yeah. |
At least xbps only allows one argument, and I can't imagine a use-case for multiple anyway. I'd change all the |
Oh, wait, it did work but i think i broke it. |
Heavily disagree. Even if some PMs only support one, others support more, and the ones that don't support >1 will have an error message. |
The xbps error message is literally just printing the usage information. I also can't imagine why you'd want to do |
So you don't have to run multiple commands..? The whole reason cpm exists is for laziness. If this was |
At any rate, like we do for other things, PMs which only support one argument should only be given one. |
oh, that explains it resolve() is broken anyway |
What is |
I assume that's more clear. |
no thoughts, head empty |
|
pain honestly, i'd just not bother resolving symlinks at all. It doesn't work, and there's no good solution, especially not a short & understandable one. Also, half the reason I caved into splitting f/F was because you wanted relative paths, which resolve() doesn't even support..... |
I have fixed the resolve function. Also, xbps does not work with symlinks, and other PMs may also not work with symlinks. Here's a fixed version, I think: resolve() {
p="${1%/*}"
[ -f "$p" ] && p="."
cd -P "$p" 2>/dev/null || PWD="$p"
printf '%s\n' "${PWD}/${1##*/}"
} |
oh, i was just going to go back to the original code because it is literally much better |
The |
|
Just don't support multiple arguments. |
No. |
Actually, I think we can improve my fixed version: resolve() {
p="${1%/*}"
[ "$p" = "$1" ] && p="."
cd -P "$p" 2>/dev/null || PWD="$p"
printf '%s\n' "${PWD}/${1##*/}"
} |
I'll even commit this myself to save you the trouble. |
👍 Unless it's a complete rewrite of it, I would much prefer never touching resolve() again. |
Your fix is a pretty trivial one-line addition to the resolve function, and adding it to all PMs is quite simple. |
But, adding resolve() to all PMs is a downgrade. |
How? |
|
I only created it for xbps, but I have no idea if other package managers require it as well. Not to mention, your current patch doesn't even support your multiple arguments stance. |
Difference is, that's for one scenario, and not a constant thing. |
Inconsistently handling multiple arguments is much worse than consistently allowing only one argument. |
Heavily disagree. I'd prefer sometimes being shit (but that time also has a different improvement) over always being shit (even when not using the addition). |
I don't think it's always bad in either case. If you want to lookup multiple files at once and your PM allows it, you can use the PM directly if you'd prefer not to write two commands. If you moved your change to the resolve function and then applied that to all PMs, every package manager benefits from both symlink resolution and your patch. If you also want to make it work for multiple arguments, you can do that, too. Just don't do it for PMs which only support one. |
like... no? It's just xbps that needs it.
Does in this patch too, just without it being a constant downgrade.
It's literally a feature that cpm already supports, why are you suggesting "don't use cpm for something that it supports which doesn't go against its philosophy so i can downgrade it for no sane reason"
I have no idea what you mean with this, but tbh I'm done, it's clear that you just want to downgrade it. |
Some package managers may return the "wrong" package if the target file is a symlink. While it may point to a file installed by another package (and which you are almost certainly looking for), you will get the package that installed the symlink, which may not be the same. It's a very rare case that you'd be interested in which package installed the symlink.
If you want to allow multiple arguments, at least make your patch actually handle this case. If you added it to the resolve function and used that for every PM, you could make it support multiple arguments there, too, if you wanted. Just don't use |
I'd be willing to merge even if you didn't use resolve for everything, but at the very least make your fix work for all arguments rather than just the first one. |
example (From a dir without that filename):
cpm f test
will be replaced withcpm f /bin/test
, which will probably be coreutils.