The reason it doesn’t work is because you have no access rights to the files in the directory as your normal account, which is needed for the asterisk to compose the list.
PS: You output in the image clearly shows you are using ZSH and not bash, because the error returned is from ZSH 
I have tried escaping it with \ and wrapping it with " " and ’ '. I have also tried adding the glob qualifier (N) at the end and also adding
unsetopt nomatch
at the end of my .zshrc, but nothing has worked for me thus far.
Right, I logged in as su and that changed the shell to bash and then it worked, but not because it worked on zsh.
I know you said, my point was that you shouldn’t try because the globbing is a special meaning and escaping it will make it a normal asterisk.
Of course, nice catch. 
Changing to the root user will make it work in any shell because the root user does have access to those files…
I guess, so but su is set to use bash by default. Anyways, this takes power away from sudo, which is meant to give you those powers. I see it as an inconvenience, since everything else works with sudo.
Try this:
sudo chmod a+rx /var/lib/mysql
After that you should be able to do a normal ls on the mysql dir as normal user…
You are confusing power of sudo and your knowledge about directory permissions…
Nothing is taking away powers of sudo, it’s just you who doesn’t know how permissions work 
Also, yes, but as a normal user, I think it is best practice not to have access to anything but the home directory unless using sudo or an equivalent.
Having access to something as a normal user is completely unrelated to being able to run other commands using sudo…
Your command:
sudo rm /var/lib/mysql/*
Does not work because your shell, (which is operating under your normal user), is unable to replace the asterisk with all the files in that directory.
Hence the correct error returned from your shell (ZSH)
You could change that command to this to make it work, because this time the command which is run as root will compose the list it self:
sudo find /var/lib/mysql -mindepth 1 -delete
First run that command without the -delete argument, to show what it finds.
If you want to use sudo and globbing without changing permissions, either of these will work.
sudo bash -c "ls /etc/sudoers.d/*"
sudo zsh -c "ls /etc/sudoers.d/*"
I’ve used another directory that would produce this error as I don’t have the mysql dir and I won’t be the only one. I’ve used ls so it’s safe to try it out, obviously just replace with rm and the proper path.
@Centaro
Next time please dont post screenshots, but use codeblocks to paste command output, see:
I’m changing the topic title to reflect the actual problem…
I am no pro, but I don’t appreciate the snarky remarks @TriMoon.
Anyways, I appreciate you all taking your time to support me and pointing me in the right direction,
I’m not making snarky remarks, im just stating the facts…
Don’t be offended if you lack knowledge about some things, no one can know everything, that’s why we help others…
Stating the fact you don’t understand something is to make it clear to you where you went wrong, to HELP you not to make you feel bad…
Correct me if I am wrong, but I don’t think your title fits the bill, because the issue here was that no user but the mysql user had permissions for this folder. That means that not even the root user had permissions and that is the thing that threw me off. I would say it is a relatively uncommon scenario.
In other words, I never expected the normal user to have access to this folder.
I am not offended by my lack of knowledge. I just think your messages come across as snarky. It is possible to state the facts in a snarky way. They are not mutually exclusive things.
And I understand the fact that you are all taking time and energy answering when I need help. That’s why I have thanked several times.
The root user still has access to it, because it can access everything by definition.
Proof: you can access it when using su which makes you root…
I think the part you are mistaking in is:
Thus your change of the Title is plain wrong and impossible…
The root account means the system itself…, so if the system can’t access it nor will any other user account on your system.
Makes sense. I wonder whether the same would have happened with Bash, though.
I will just su to root when I have to work with it.
Thanks =))
The behavior of permissions stays the same, no matter which shell you use, because that is part of the Unix/Linux operating system way of doing things.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.