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”?

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 option
rm $myFile
# second quote option  
rm '$myFile'
# third quote option
rm "$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.

It didn’t for me in the web interface, maybe check if it’s a bug with the app you’re using?

Certainly not without using sudo right? It’s the same in the windows land, the UAC dialog is windows’ equivalent of sudo.

chmod -R 777 ./, baby!!!

Back up the folders and format the disk. If you’re deleting system files and folders, you’re clearly not running the OS from this other disk. Why waste the space on unneeded system files?

You do realize that in this very post they explain that if you mount an old linux drive with another user, you can’t delete stuff either until you remove the flags or change the owner of the old drives’ files?

You can do the same in windows, too.

They are not trying to access their own Windows folder, but that of an old drive.

The drive doesn’t have a say. The permissions surrounding the TrustedInstaller account have a say. The account existed on your first Windows install and also on your new one hence the permissions and associated restrictions persevere. This is expected behavior.

Then why does it matter that your an admin if the drive should have no say?

Lol, you’ve got such a good sens of humour. Hope you have a good day today.

File system ACLs.

you cant say it doesnt do exactly what you want.

As someone (a different guy than whom you’re replying to) who has primarily used Linux-based systems in personal settings for about 15 years or so, I can and will say that.

For the most part, Linux-based systems tend to do exactly what you tell them to do. Whether or not this is exactly what you want, however, is a slightly different point.

Nearly 30 years of LINUX experience. I can definitely say on a regular basis that LINUX doesn’t do exactly what I want.

I want it to play rocket league. Without using wine or proton.

There are some things that Linux won’t allow you to do natively. I understand it’s better because it’s open, but come on.

Linux does exactly what you tell it to, not exactly what you want. There’s a big difference.

If you know exactly what you want and how to do it.

I spent countless hours trying to make my display driver working in Linux years ago. I knew what I wanted, but it was impossible. For me at least. I know many who has similar experiences.

So you’re just using the root account 24/7?