Yay: Running incorrect commands quietly exits with exit code 0.

[DL6AKU]

Affected Version

yay v5.608.r8.g42b7df4

Issue

yay should complain if a wrong/bogus command is entered. For example yay --asdkjlasjglaj quietly exits with an exit code of 0

[Morganamilo]

This came up before, I find it totally overboard and not worth the effort to implement this fully, there's so many different Pacman options and each option may only apply to certain operations. There's also conflicts, we don't allow multiple operators to be used at a time such as -S and -Q but lots of other stuff conflicts like -Sis.

We could implement a huge array of valid flags and just check against that without doing per operation checking which would help a little but in your example #306 --stats would be a valid flag so it still wouldn't error even though it should.

I think it would be possible to implement something like this #173 but on a larger scale than just one command. That way we don't check for invalid commands but instead if the current command leads somewhere. For example yay --stats leads nowhere but yay -S xterm --invalidflag would lead somewhere.

Perhaps that could be combines with the flag array idea but my main issue with that is missing potential flags and if Pacman ever updates and comes out with a new flag Yay would not work with that flag until fixed.

[DL6AKU]

100% honest: It is your project, it is ultimately your decision to make. Personally, I think it is a huge problem for any program to not exit with a non-zero exit code on a bogus command. But I come from a IT security background, I might be overly cautious here.

Still, I think it is a non-trivial problem for a myriad of reasons, not the very least that it is both confusing and not consistent with standard unixoid tooling, including pacman itself.

I am open to dive into Go and try to patch the issue myself so it won't be a workload issue for you. If it is an ideological thing though, I of course would like to know before, so I don't invest time to fix something that is not wanted.

EDIT: I read some of the parser code today when I wrote the -Syu patch, and now to me it does not seem an insurmountable obstacle to just exit -1 or 1 on a false command. Of course I am not fluent in Go, might have overlooked something.

[Morganamilo]

I don't think adding the check for invalid commands would be to hard and I'm not against it. The reason I closed #173 was because it only applied to some commands which was inconstant.

Checking for invalid flags I don't know if it's a good idea for the reasons mentioned above.

Another thing I have not attempted to deal with at all nor really plan to is that Pacman actually has it's own autocomplete thing. --noconfirm --noconf --noc all work but --no doesn't work because it's ambiguous. This can possibly cause problems because Yay passes flags to Pacman as well as reading them. So you could do yay -S foo --noconfwhich would get passed to Pacman and run in no confirm mode but Yay would not realise and run itself in confirm mode.

So yeah my current plan on that is don't think about it.

Also technically it's @Jguer's project, I just dump a bunch of code here and we tend to agree on things.

[Jguer]

Yes, we should exit with an exit code != 0 on a wrong command, but I agree with @Morganamilo on the implementation side.

I think we should start by the easy and simple, return an error code on no OP provided but flags provided and on false OP provided. Implementation wise it should fix the biggest problems on a low code overhead

[Morganamilo]

one slight caveat is that yay --devel --save is a valid no-op, shouldn't be too hard to catch though.

[samuelhnrq]

Wait what? Illuminate me, but cant we just forward whatever exit code pacman gives us as our exit code? What part of the implementation is am I missing here that doesn't make that possible?

[Morganamilo]

Yay doesn't just pass everything to pacman. For example yay -Ps doesn't use pacman at all. If there is an error along the way Yay will exit non 0 but if you add a non existing flag yay will ignore it.