Comment on Every time i have to use windows again my IQ slips a point or two

• skullgiver@popplesburger.hilciferous.nl ⁨1⁩ ⁨year⁩ ago

  Learning to work with any operating systems beyond the most basic apps takes a lot of time. Whatever OS you started out with probably took you a few years to get into, but as a kid you don’t notice that you’re learning anything special. And, to be honest, Linux GUIs lack a lot of quality of life features. At least in Windows you can use the mouse to make files read-only, in many Linux utilities you can’t even see or modify such attributes.

  Getting Wireguard and Pihole working without any prior Linux knowledge is an impressive feat on its own! Putting three days of work into it shows more dedication than I would have, I hope it paid off when you finished!

  Also, you were so close with the name thing. In most shell languages, after typing name=“client_name” you can use the dollar sign to refer to the value you set, i.e. $name.

  If type this:

  name="Eve"
  echo "Hello, $name!"
  

  you would see Hello, Eve!

  This would actually work perfectly:

  user@box ~ $ name="client_name"
  user@box ~ $ echo "[interface]" > $name
  

  This would create a file called client_name that contains the line [interface].

  I see a lot of tutorials online that had special characters removed (i.e. the dollar sings) or had broken script because quotes were turned into fancy quotes that are meaningless to the terminal, often because those guides were shamelessly stolen from other sites without checking if they even worked. It’s easy to miss these things!

  source

  • GiuseppeAndTheYeti@midwest.social ⁨1⁩ ⁨year⁩ ago

    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.

    source

    • skullgiver@popplesburger.hilciferous.nl ⁨1⁩ ⁨year⁩ ago

      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.

      source

      • GiuseppeAndTheYeti@midwest.social ⁨1⁩ ⁨year⁩ ago

        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!

        source
  • anonymoose@lemmy.ca ⁨1⁩ ⁨year⁩ ago

    I think Lemmy stripped the $ from your bash commands?

    source

    • skullgiver@popplesburger.hilciferous.nl ⁨1⁩ ⁨year⁩ ago

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

      source
• intensely_human@lemm.ee ⁨1⁩ ⁨year⁩ ago

  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.

  source