Arch Linux

allan@kamala ~
> pacman -T glibc

allan@kamala ~
> echo $?
0

allan@kamala ~
> pacman -T doesnotexist
doesnotexist

allan@kamala ~
> echo $?
127

Your problem is that your bash script is incorrect, it falls prey to a common, dangerous pitfall.

https://mywiki.wooledge.org/BashPitfalls#cmd1_.26.26_cmd2_.7C.7C_cmd3

Do not use cmd1 && cmd1 || cmd3

Your lack of knowledge about the incredibly important difference between that and proper coding logic as represented by `if`, does not constitute a reason on its own to add new functionality to pacman.

Additionally as allan pointed out, pacman -Qi is a very inefficient way to check if the package is installed. -T exists and is far superior. Using -Qi is slower to consult metadata you don't use, and prints out a ton of information you don't silence using >/dev/null 2>&1 (though -T still needs to silence stdout in order to prevent *one* line being printed, you don't need to silence both and the consequences of forgetting are one line, not many).

I'm aware of the difference between && && || and if. in fact the version I settled on uses an if.

its very common for deletion operations to not return errors when there actually isn't anything to delete,
because in essence the goal was achieved.

The request is for a convenience feature, not because alternatives solutions don't exist.

I'm also not the first to request that pacman have switches to suppress missing package errors as they tend to
make life harder.

is pacman opposed on principle to the switch or just not interested in implementing it personally?

if the issue is the principle of the switch then we're done and we can all move on.
if the issue is the work, well that I might be able to help with.

Your feature request as stated described itself with the rationale "however this doesn't really work because I can't tell if the uninstall failed or if the package was just missing."

I pointed out that this is factually incorrect; it can, in principle, be scripted around, and thus tell if the uninstall failed or if the package was just missing... but your proposed script has an elementary mistake that prevents it from even beginning to approach validity. I can't read your mind and know about the scripts you didn't propose but were always intending to use.

Now you completely changed your entire tune, turned around 180 degrees, and insist you knew what I was going to respond and still aren't happy because $REASON.

I don't believe you. But it doesn't matter -- whatever, you wasted our time at first with complete non-issues, and you currently claim you *deliberately* wasted that time, which is annoying, but let's move on.

> I'm also not the first to request that pacman have switches to suppress missing package errors as they tend to

So did you consider what was said there, and maybe submit reopen requests instead of opening new tickets? If it's been previously discussed, what was the resolution there?

This is relevant information, and it's unfair to everyone to try to pretend that those discussions never happened, because then we will waste time rehashing old rationales that don't suddenly *not* apply, and everyone gets frustrated. Let's build on the knowledge we already have.

I'm sorry my toy example code was interpreted as a request for help with a problem, it was meant as a use case example where having this feature would make life (slightly) easier for users.

I, personally, like to ground feature requests around concrete examples of additional work that the end user had to do to get a desired result. clearly that was a mistake.

the issue I mentioned had no useful discussion in it. it was 2 comments in addition to the request itself and from 10 years ago.

so yeah, I thought it might be worth asking about. here is the issue in question for you to use it as further proof of how horrible a human I am - https://bugs.archlinux.org/task/18306

would it be nice if I didn't have to pull out bash every time I try to:
- remove a set of packages and I happened to removed one in the middle of the set earlier?
- remove a package unconditionally regardless of the state of the system I'm on?

yeah, yeah it would. and this also happens to be the behavior of other package management cli tools. apt in particular, I assume yum as well, just don't have an RPM system handy to confirm that.
I also assume others might appreciate this feature as well. I could be wrong though!

am I willing to do some of the heavy lifting implementing this? sure, I might be.

but I'd like to know if I would be wasting my time because the feature is just going to be rejected on the principle that one can script around it.

which again is entirely okay. I'm not going to argue with maintainers about their own project, and going forward hopefully this issue will have
enough information so you guys are not asked this question for 20 years this time.

Eli, I'm sorry I offended you by opening a feature request after:

1. reading the man page for relevant options that might solve my problem.
2. searching the web for related information, and coming up with overly complex scripts.
3. searching here for related issues and only discovering 1 that was 10 years old, and had 0 useful discussion around the feature itself.
4. attempting to explain the use case with a shitty off the cuff example of extra work I had to do to achieve a result which, frankly, other package managers handle themselves directly.

I did attempt to be a good citizen. I am sorry I upset you.

Hell I even just went to check the bug reporting wiki page after seeing your response to make sure
I didn't make a complete ass of myself by not reading that page first prior to submitting.

At this point, if you have further questions about why I think this would be a small, but nice to have enhancement to pacman. then great. ask away.

otherwise, just feel free to close the request with any further chastening you wish to give me and we'll call it done. =)