because they are a PITA indeed and it’s easy to promote toxic/savant attitudes, just like lemmy but worse :P

it does not work, it says permission denied. Is there anything I should do ?

[…] there were rumours some French guy got arrested and had his LUKS encryption fail on him, so you never know.

https://xkcd.com/538

Removed by mod

Removed by mod

Removed by mod

can confirm that tuxedo is great if you are in Europe. It has been my daily driver for 3 years with debian sid and it’s great!

also, there is not a “specific default”, I don’t care about debian and even if I’m not using since longtime in this thread stupidity has been expressed :P

I’ll defend your right to edit your comments if you’ll defend my right not to be bothered by u, ciao

Removed by mod

Removed by mod

Removed by mod

which then I mean, if you don’t have an attention span that lasts at least until the end of other people’s comments, what are you doing here :D

Removed by mod

you obviously can’t use sudo visudo if you’re not already in the sudoers file LOL - is the same security, which you also desire, as having a spare set of keys in the bowl at the entrance to your house, where, however, no one comes unless they already have a key to open the door

also let’s be curious about the things we copy-paste in order to prove whatever theory: in literally the first line of your bashrc non-login shells are named. What are those non-login? If we need to defined them like that, do also we have a non-non-login ones? How do they get executed? How do they get initialized? Let’s explore and understand some new stuff (that we should have learned already, but who cares, it’s not our job!)

lol I’m not defensive at all, I swear I don’t need that :D. The theme here is that you keep thinking you don’t have an ass because you’re looking for it on your forehead instead of between your butt cheeks :D

What we can already see:

• sudo is indeed installed, and in path
• bash is running since system is newly installed => /usr/bin is obviously in path (bash lives in /usr/bin/bash)

set | grep ^PATH will show that /usr/bin is indeed in path, also the fact that grep runs tell it path is correct, since grep lives in /usr/bin/grep :)

that said, your user isn’t in the sudoers file because you choose to give login access to root during install (which is strange, because no sudo package get installed if you choose that, so you probably made some other strange not-obvious thing), and no, groupadd can’t be run by the user you keep being after a failed sudo invocation (of course you can invoke it w/ the fully qualified path which is /usr/sbin/groupadd w/ /usr/sbin not in user’s path because the binary here usually require high permissions).

now you have a chance to learn something: where is PATH env var configured? Is it in your home or outside? Why and how it gets parsed?

cmon, let’s explore a bit my good boy, let’s be curious about the world that is not wrong by default and only we are right ;) let’s learn stuff, for real

Removed by mod

beside op’s bashrc fud, it’s a common newbie misconception that testing and sid are not stable like some kind of exotic experimentation would make them so. It is more a stabilization process in respect to the project’s policy/processes and you will definitely find /usr/bin in pathh in either testing and sid rofl

I looked it up and realised that /usr/bin wasn’t on the bashrc path.

lol, no. PEBKAC