Remove "access denied" console print

No, this is a little more complex than removing this specific print or adding a toggle for it, and is rather a sign of a broader issue (client command output is still printed to the server console in addition to being printed to the invoking client, which is desirable for some cases but less desirable for other cases), and has various possible solutions including a generic ‘suppress output by channel’ feature and prefixing client commands with this channel, potentially adding multiple routing outputs for different spew channels.

Again, we don’t do half-measures. Removing the print in itself would be confusing in cases where it is desired as part of user diagnostics, and ‘adding an option’ would be silly since now there’s yet another option for yet another tiny thing that has to be maintained for all eternity, potentially leading to users again being confused about cases where it doesn’t show this output and then you find out ‘oh yeah it got disabled by some script I installed/someone suggested it/…’ which also doesn’t help.

How does this output make the subsystem printing said output ‘a pain’ in itself? You’re likely expecting to see something else in the console output, which is ‘a pain’ due to any ‘unwanted’ output, which in your case just happens to be this, but it could just as well be anything else.

This sounds way more easily resolved for your use case by e.g. grep -v’ing console output depending on what else you’re trying to see in there that becomes ‘a pain’ as a result of this, since again the issue of ‘console output is hard to parse for only significant things’ is a way more broader concern than just this print.

I just checked this, by the way, and running FXServer +exec blah | grep -v "Access denied for command" does correctly suppress this output from showing in the console, so if this request were that urgent for you to need to bump it, you’d be able to mitigate it fairly easily yourself as well. :confused:

(by the way, on Windows you can easily get grep and other utilities using MSYS2)


Finally, you bumping a low-priority and fairly complex feature request after a little over a week with just ‘any update?’ is a little bit hostile, if you’d check the GitHub commits you’d see there’s barely any ‘update’ on anything this past week, even on way higher-priority things that have been in the backlog for way longer, in fact the only commits have been for super trivial things which this is not, or blocker bugs/regressions.

Vaguely bumping something this low-priority is only going to get your request covered with fear of even looking at it, especially since neither ‘removing’ it nor ‘adding a toggle’ is going to happen, and now the more complex implementation is also covered in random fear.

1 Like