Always fun to see people with limited understanding of ACLs struggle with filesystems that apply them. Look at this like a chance to learn!
Windows has a lot of features built in to prevent users (and malware) from breaking their system, such as the “system” and “read only” flags. I suppose explorer could’ve asked you to elevate, unset any flags, alter ownership, and delete anyway, but that’s doing a lot of work you don’t necessarily intend to do when you click “delete”.
Linux has this too; try the following:
mkdir -p /tmp/test/deleteme;
touch /tmp/test/deleteme/deleteme.txt;
chattr +i /tmp/test/deleteme /tmp/test/deleteme/deleteme.txt
# If you want to apply the "drive from different system" equivalence
sudo chown -R 12345:12345 /tmp/test/deleteme
Now try deleting the folder /tmp/test/deleteme from your file explorer:
Frustrated, you may try to force the issue by forcefully removing the file through the terminal:
user@box /tmp/test $ sudo rm -rf deleteme
Place your finger on the fingerprint reader
rm: cannot remove 'deleteme/deleteme.txt': Operation not permitted
user@box /tmp/test $
Alright, what if I…
user@box /tmp/test $ sudo -i
Place your finger on the fingerprint reader
root@box ~ # cd /tmp/test
root@box /tmp/test # rm -rf deletemerm: cannot remove 'deleteme/deleteme.txt': Operationnot permitted
root@box /tmp/test # whoami
root
root@box /tmp/test #
No dice! Even root can’t remove these files!
The only way to get rid of these files, is to set/unset the right flags:
Linux is so cool, but boggles my mind. I just simply don’t have enough time to really get a good grasp on the terminal and commands associated with it. It took me 3 days worth of attempts from 8am when my fiance leaves for work to 5pm to finally get a pi-hole set up in tandem with a self hosted VPN with wireguard. I just got it up and working on Wednesday this week. I know there’s a tutorial on the pi-hole website, but with no Linux terminology experience it was tough to know what I was supposed to be typing into the terminal. Several times I was typing:
sudo -i
cd /etc/wireguard
umask 077
name="client_name"echo [interface] > "name"
I thought the name= line would tell the terminal that I wanted to replace all the following lines that “name” appeared in with “client_name” automatically. Then I figured out that they were just telling me that I needed to replace “name” in their terminal commands with what I wanted to name the associated files I was creating lol. It was a real man…I’m a fucking moron moment.
That makes total sense. I never really considered that I have been learning Windows over the past 20 years. It was just learning “computer”. And I really appreciate the compliment to my dedication on it! I’m really happy with the result and I learned more about linux/networking/LePotato/Pi-hole than I would have guessed at the beginning of this whole project. From battling with Wireguard server configuration…ufw and portforwarding…client configuration…back to ufw…IP configuration…keys…etc. Troubleshooting was a maze sometimes 😂. One more thing before I go.
About the name thing. Say I type:
name="Gerald"
wg genkey > ${name}.key
Would my output then be a key generated by Wireguard and named “Gerald.key”? Or would it need to be:
wg genkey > "${name}.key"
Or like in your example:
wg genkey > $name.key
I think I’m mostly getting caught up in when the quotations are necessary and when they’re not.
Would my output then be a key generated by Wireguard and named “Gerald.key”?
Yes, assuming the user you’re logged in as has access to write files in the current directory. In /etc/wireguard, that’s usually only possible if you’re logged in as root (or using an interactive sudo shell). Adding sudo to your prompt doesn’t help in that case, because sudo only works up to the redirection character (>).
HOWEVER: if $name is supposed to contain John Cena you’ll need to use wg genkey > "$name" or wg genkey > "${name}". Otherwise, your private key will appear in a file named John, and the key contents would be followed by the word Cena! Spaces mess up the shell and for that quotes are very very useful.
I think I’m mostly getting caught up in when the quotations are necessary and when they’re not.
The exact rules differ per shell. The default on Ubuntu is bash, the rules for which I’ll add below. macOS and some other distros use zsh as a default, which is mostly bash compatible but includes some “most people probably mean to type this other command” style fixes.
In general:
Double quotes are used for when a variable can contain spaces (like a file name)
Single quotes don’t expand variables; '$name' contains the literal string $name, not Eve Johnson
Omitting quotes will lead to variables being expanded in place. If the contents of the variable are a single word, that effectively works the same as if you use double quotes
Suppose you have a directory with these files:
file
file with spaces
readme.txt
Suppose you want to remove some files with this script, using rm to delete them:
myFile="file with spaces"# first quote optionrm$myFile# second quote option rm'$myFile'# third quote optionrm"$myFile"
The first rm call will try to remove the files file, with, and spaces. It will delete the file named file and give you two errors for the missing other two files. It’s as if you typed rm file with spaces. rm takes a long list of files that need to be deleted, so it’ll think you want to delete three files!
The second rm call will give you an error, telling you that there is no file called $myFile. It’s as if you typed rm'$myFile'. You can create a file with that name, though; touch \$myFile or touch'$myFile' will create a file starting with a dollar sign. Many tools forget that this is a possibility (just like * and ? are perfectly valid file names!) and scripting based tools can easily fail or crash or even get exploited by hackers if you place a file with special characters on the system!
The third rm call will remove the file file with spaces and leave the rest alone. It’s as if you typed rm"file with spaces". It’ll remove the one file.
Using ${variable} is a bit safer and clearer, because you indicate exactly where the name of the variable starts and where it ends. Quotes and such are still necessary, following the conventions above. This is useful when you try to create a string like backup_$date_morning_$user.bak; are you referring to a variable $date_morning_ or to a variable called $date? backup_${date}_morning_${user}.bak makes things a lot clearer!
For my own sanity and to make sure I know what to expect, I generally use double quotes and preferably ${} style expansion ("$name") for strings I want variables to be expanded in and single quotes around strings I definitely do not want variables to mess with.
Wow! You absolutely know what you’re talking about! You did an amazing job clearing that up for me. I’ll save this comment in case I need to come back to it. Thank you!
It won’t always take you an entire day to get anything done in Linux. That’s just the pace you’re at as a beginner. As your knowledge expands you move faster.
It’s not very commonly used though. I have seen this command only a few times. I don’t feel like Linux users are missing stuff like this, so they dont use it.
But thanks for the long comment, was a nice read. :)
It’s not commonly used (on the usual popular systems) but for “simple” systems (like Ubuntu) it should probably be used more. There are reasons to remove /usr or ~, but I think requiring a special command to prevent accidents would solve more problems than it causes.
sudo would do nothing. Changing the (effective) user and group IDs does not magically make rm aware of the immutable bit, nor does it alter the behaviour of rm’s code to unset that bit before trying to remove it.
In the example I gave above, I did use sudo. sudo -i started an interactive shell with root permissions, and rm failed to remove the directory and file inside it.
Always fun to see people with limited understanding of ACLs struggle with filesystems that apply them. Look at this like a chance to learn!
Windows has a lot of features built in to prevent users (and malware) from breaking their system, such as the “system” and “read only” flags. I suppose explorer could’ve asked you to elevate, unset any flags, alter ownership, and delete anyway, but that’s doing a lot of work you don’t necessarily intend to do when you click “delete”.
Linux has this too; try the following:
mkdir -p /tmp/test/deleteme; touch /tmp/test/deleteme/deleteme.txt; chattr +i /tmp/test/deleteme /tmp/test/deleteme/deleteme.txt # If you want to apply the "drive from different system" equivalence sudo chown -R 12345:12345 /tmp/test/deletemeNow try deleting the folder /tmp/test/deleteme from your file explorer:
Frustrated, you may try to force the issue by forcefully removing the file through the terminal:
user@box /tmp/test $ sudo rm -rf deleteme Place your finger on the fingerprint reader rm: cannot remove 'deleteme/deleteme.txt': Operation not permitted user@box /tmp/test $Alright, what if I…
user@box /tmp/test $ sudo -i Place your finger on the fingerprint reader root@box ~ # cd /tmp/test root@box /tmp/test # rm -rf deleteme rm: cannot remove 'deleteme/deleteme.txt': Operation not permitted root@box /tmp/test # whoami root root@box /tmp/test #No dice! Even root can’t remove these files!
The only way to get rid of these files, is to set/unset the right flags:
user@box /tmp/test $ chattr -i deleteme deleteme/deleteme.txt user@box /tmp/test $ rm -rf deletemeLinux is so cool, but boggles my mind. I just simply don’t have enough time to really get a good grasp on the terminal and commands associated with it. It took me 3 days worth of attempts from 8am when my fiance leaves for work to 5pm to finally get a pi-hole set up in tandem with a self hosted VPN with wireguard. I just got it up and working on Wednesday this week. I know there’s a tutorial on the pi-hole website, but with no Linux terminology experience it was tough to know what I was supposed to be typing into the terminal. Several times I was typing:
sudo -i cd /etc/wireguard umask 077 name="client_name" echo [interface] > "name"I thought the
name=line would tell the terminal that I wanted to replace all the following lines that “name” appeared in with “client_name” automatically. Then I figured out that they were just telling me that I needed to replace “name” in their terminal commands with what I wanted to name the associated files I was creating lol. It was a real man…I’m a fucking moron moment.deleted by creator
That makes total sense. I never really considered that I have been learning Windows over the past 20 years. It was just learning “computer”. And I really appreciate the compliment to my dedication on it! I’m really happy with the result and I learned more about linux/networking/LePotato/Pi-hole than I would have guessed at the beginning of this whole project. From battling with Wireguard server configuration…ufw and portforwarding…client configuration…back to ufw…IP configuration…keys…etc. Troubleshooting was a maze sometimes 😂. One more thing before I go.
About the name thing. Say I type:
name="Gerald" wg genkey > ${name}.keyWould my output then be a key generated by Wireguard and named “Gerald.key”? Or would it need to be:
wg genkey > "${name}.key"Or like in your example:
wg genkey > $name.keyI think I’m mostly getting caught up in when the quotations are necessary and when they’re not.
Yes, assuming the user you’re logged in as has access to write files in the current directory. In
/etc/wireguard, that’s usually only possible if you’re logged in as root (or using an interactive sudo shell). Addingsudoto your prompt doesn’t help in that case, becausesudoonly works up to the redirection character (>).HOWEVER: if
$nameis supposed to containJohn Cenayou’ll need to usewg genkey > "$name"orwg genkey > "${name}". Otherwise, your private key will appear in a file namedJohn, and the key contents would be followed by the wordCena! Spaces mess up the shell and for that quotes are very very useful.The exact rules differ per shell. The default on Ubuntu is bash, the rules for which I’ll add below. macOS and some other distros use
zshas a default, which is mostly bash compatible but includes some “most people probably mean to type this other command” style fixes.In general:
'$name'contains the literal string$name, notEve JohnsonSuppose you have a directory with these files:
filefile with spacesreadme.txtSuppose you want to remove some files with this script, using
rmto delete them:myFile="file with spaces" # first quote option rm $myFile # second quote option rm '$myFile' # third quote option rm "$myFile"The first
rmcall will try to remove the filesfile,with, andspaces. It will delete the file namedfileand give you two errors for the missing other two files. It’s as if you typedrm file with spaces.rmtakes a long list of files that need to be deleted, so it’ll think you want to delete three files!The second
rmcall will give you an error, telling you that there is no file called$myFile. It’s as if you typedrm '$myFile'. You can create a file with that name, though;touch \$myFileortouch '$myFile'will create a file starting with a dollar sign. Many tools forget that this is a possibility (just like*and?are perfectly valid file names!) and scripting based tools can easily fail or crash or even get exploited by hackers if you place a file with special characters on the system!The third
rmcall will remove the filefile with spacesand leave the rest alone. It’s as if you typedrm "file with spaces". It’ll remove the one file.Using
${variable}is a bit safer and clearer, because you indicate exactly where the name of the variable starts and where it ends. Quotes and such are still necessary, following the conventions above. This is useful when you try to create a string likebackup_$date_morning_$user.bak; are you referring to a variable$date_morning_or to a variable called$date?backup_${date}_morning_${user}.bakmakes things a lot clearer!For my own sanity and to make sure I know what to expect, I generally use double quotes and preferably
${}style expansion ("$name") for strings I want variables to be expanded in and single quotes around strings I definitely do not want variables to mess with.Wow! You absolutely know what you’re talking about! You did an amazing job clearing that up for me. I’ll save this comment in case I need to come back to it. Thank you!
I think Lemmy stripped the $ from your bash commands?
It didn’t for me in the web interface, maybe check if it’s a bug with the app you’re using?
The first progress is always the slowest.
It won’t always take you an entire day to get anything done in Linux. That’s just the pace you’re at as a beginner. As your knowledge expands you move faster.
It’s not very commonly used though. I have seen this command only a few times. I don’t feel like Linux users are missing stuff like this, so they dont use it.
But thanks for the long comment, was a nice read. :)
It’s not commonly used (on the usual popular systems) but for “simple” systems (like Ubuntu) it should probably be used more. There are reasons to remove /usr or ~, but I think requiring a special command to prevent accidents would solve more problems than it causes.
sudosudowould do nothing. Changing the (effective) user and group IDs does not magically makermaware of the immutable bit, nor does it alter the behaviour ofrm’s code to unset that bit before trying to remove it.In the example I gave above, I did use
sudo.sudo -istarted an interactive shell with root permissions, andrmfailed to remove the directory and file inside it.