The Linux Thread - The Autist's OS of Choice

Let's say you have a script to delete a file and you give an unprivileged user permissions to run it

deletelog.sh:
#! /bin/bash
rm /opt/application/log/$1

and you allow "sudo deletelog.sh file"
Well, now the user runs:
sudo deletelog.sh "file /etc/passwd"

Now you've just let the user delete any file on the system.

With $0 you can influence what it is by making symlinks(among other ways), so you can do stuff like:
ln -s /usr/bin/stupid_script.sh "rm -Rf /etc/passwd"
depending on what it's doing with $0
Thank you for the reply, but not gonna lie I don't think I fully understood it. Not your fault, I'm just not used to thinking in this way yet. From what I could understand it helps prevent unintended consequences from happening when users do something dumb? Also, I don't mean to derail the thread into a shell scripting thread, just something I've been trying to learn. I'm still very much in caveman levels of understanding for it though.
 
Sorry if this is a bit of a newbie question, but I am still quite new to this. What do you mean by "whitespace fuckery?" Is it just generally better practice to quote commands?
To add on to what @davids877 said: you may have noticed that whitespace matters in bash commands because the commands use whitespace to separate their arguments.

For example, suppose we've got a file with whitespace in it (Windows-style) called My File.txt. We store the filename in a variable x:
Bash:
x=My\ File.txt

That's all well and good. But say we want to create that file now. What happens when we do touch $x?
Bash:
touch $x
ls
#> File.txt  My
See how it has taken the whitespace in the filename and treated it as if it were whitespace in the command? So in touch's case, it treats it as two arguments, and creates two separate files.

To fix this, we put quotes around the variable recall, i.e. "$x":
Bash:
touch "$x"
ls
#> File.txt   My  'My File.txt'
Now it treats the entire variable x (whitespace and all) as a single filename, and we get our My File.txt file created exactly as we want.
 
Thank you for the reply, but not gonna lie I don't think I fully understood it. Not your fault, I'm just not used to thinking in this way yet. From what I could understand it helps prevent unintended consequences from happening when users do something dumb? Also, I don't mean to derail the thread into a shell scripting thread, just something I've been trying to learn. I'm still very much in caveman levels of understanding for it though.
The shell splits arguments on spaces, unless they're quoted.
Say you want to delete a file called "my file"
rm my file
won't work, it will try and delete "my" and then "file"
rm my\ file
rm 'my file'
rm "my file"
will all work.
Now, replace "my file" with a variable..
X="my file" (trying to do X=my file without the quotes, will also fail)
rm $X
still won't work, it expands the variable first, gets my and file and tries, just like the first case to delete my and then file
rm "$X" tells the shell that everything in X is one argument to "rm" so it now deletes "my file" properly.

Edit: Beat me by that '' much.
 
To add on to what @davids877 said: you may have noticed that whitespace matters in bash commands because the commands use whitespace to separate their arguments.

For example, suppose we've got a file with whitespace in it (Windows-style) called My File.txt. We store the filename in a variable x:
Bash:
x=My\ File.txt

That's all well and good. But say we want to create that file now. What happens when we do touch $x?
Bash:
touch $x
ls
#> File.txt  My
See how it has taken the whitespace in the filename and treated it as if it were whitespace in the command? So in touch's case, it treats it as two arguments, and creates two separate files.

To fix this, we put quotes around the variable recall, i.e. "$x":
Bash:
touch "$x"
ls
#> File.txt   My  'My File.txt'
Now it treats the entire variable x (whitespace and all) as a single filename, and we get our My File.txt file created exactly as we want.
The shell splits arguments on spaces, unless they're quoted.
Say you want to delete a file called "my file"
rm my file
won't work, it will try and delete "my" and then "file"
rm my\ file
rm 'my file'
rm "my file"
will all work.
Now, replace "my file" with a variable..
X="my file" (trying to do X=my file without the quotes, will also fail)
rm $X
still won't work, it expands the variable first, gets my and file and tries, just like the first case to delete my and then file
rm "$X" tells the shell that everything in X is one argument to "rm" so it now deletes "my file" properly.

Edit: Beat me by that '' much.
Ah, I think I get what was meant now. I've known about the whitespace issue with shell commands for a while (since I started using terminals for a lot of my programs a few years back) but I just wasn't quite putting 2 and 2 together on what was meant. Thank you guys for the great explanations! So it is more to help prevent possible issues from arising and. I shall go make the changes now. Very much appreciated for the help.
 
So just to check to see if I actually understood (I now get the feeling I didn't) does this look better or did I put the quotes in completely the wrong spots? I'm starting to suspect I'm at least mildly brain damaged lol

learning_printf_01.png
 
So just to check to see if I actually understood (I now get the feeling I didn't) does this look better or did I put the quotes in completely the wrong spots? I'm starting to suspect I'm at least mildly brain damaged lol

View attachment 3476321
I have no idea what you're trying to do, but:
printf takes one required argument, plus 0 or more optional arguments. The first argument is the format string "Thing:%.2f\n" then the variable(or just a number or a string) for each format string.
so
printf "Terminal: %7s\n" "$TERM"
NUMBER=4.2
STRING="Bob The String"
printf "Two Things: %.2f %3s\n" "$NUMBER" "$STRING"

Yes, if you're sure NUMBER is a NUMBER or STRING has no spaces you wouldn't need quotes, but it's good practice.
 
I have no idea what you're trying to do, but:
printf takes one required argument, plus 0 or more optional arguments. The first argument is the format string "Thing:%.2f\n" then the variable(or just a number or a string) for each format string.
so
printf "Terminal: %7s\n" "$TERM"
NUMBER=4.2
STRING="Bob The String"
printf "Two Things: %.2f %3s\n" "$NUMBER" "$STRING"

Yes, if you're sure NUMBER is a NUMBER or STRING has no spaces you wouldn't need quotes, but it's good practice.
You glorious human being! You just accidentally gave me the answer I've been looking for this whole time! I'm a little annoyed with myself that I couldn't just figure this out on my own because it seems so simple, but let me explain:
learning_printf_02.png
Over on the right I separated out two printf commands to illustrate what I mean. The bottom one (printf "KERNEL:%8s$kernel\n") is what I was doing before to add a number of whitespaces between "KERNEL:" and the output of "$kernel" but I wanted to be able to have the same result with $kernel separate and in quotes. So you giving that example with Terminal inspired me to experiment with it and the OS line above KERNEL is the result. The exact same result but written how I wanted.
I feel like I've been massively overthinking this, but it was annoying me and you help solve that annoyance. Much appreciated to both of you guys for the help! I feel like I learned at least a little more about printf today. I feel I'll learn a lot more the more I continue to tinker around and experiment. That tends to be how I learn best at least.
Also sorry for the likely poor explanation. I'm not great at explaining things sometimes.
 
Slight update, turns out it wasn't exactly what I was looking for. I don't expect you guys to help me figure it out, I'll work it out at some point. Thanks for the help. I think I actually have learned quite a bit more about printf than I knew before. Again, sorry if this was a derailing of the thread.
Learning goes better once you get assistance from various tools. My shell scripts used to be way worse until I installed shellcheck. This might be a little annoying for you on Gentoo, however, since it's written in Haskell and you'll have to pull in GHC. If you do install it, vim will start automatically linting every script you write and it'll save you a lot of headaches down the line.
 
I've also been trying to learn Bourne Shell and BASH, but it's been kinda slow going.
A major impediment to my better understanding of BASH was just the sheer amount of information out there. If I had actually sat down with this material and worked my way through it, I could have saved countless hours of wasted time and frustration. I'm hoping that it will do the same for you and anyone else that is trying to learn.
Advanced Bash-Scripting Guide
An in-depth exploration of the art of shell scripting
Mendel Cooper

This tutorial assumes no previous knowledge of scripting or programming, yet progresses rapidly toward an intermediate/advanced level of instruction . . . all the while sneaking in little nuggets of UNIX® wisdom and lore. It serves as a textbook, a manual for self-study, and as a reference and source of knowledge on shell scripting techniques. The exercises and heavily-commented examples invite active reader participation, under the premise that the only way to really learn scripting is to write scripts.
https://tldp.org/LDP/abs/html/ (https://archive.ph/LdLRI)

Google Shell Style Guide:
https://google.github.io/styleguide/shellguide.html (https://archive.ph/HgT1R)
 
Thanks for the support guys! I'll look up a way to set up Vim to be better suited to scripting with spellchecks and what not. I think the main way I'll learn is trial and error through writing some more scripts to handle some tasks that I've up till now been doing manually that I could just easily write a script for.
A major impediment to my better understanding of BASH was just the sheer amount of information out there. If I had actually sat down with this material and worked my way through it, I could have saved countless hours of wasted time and frustration. I'm hoping that it will do the same for you and anyone else that is trying to learn.

https://tldp.org/LDP/abs/html/ (https://archive.ph/LdLRI)

Google Shell Style Guide:
https://google.github.io/styleguide/shellguide.html (https://archive.ph/HgT1R)
It's funny you linked to that guide, I actually came across that last night before bed and found a pdf of it and downloaded that before calling it a night. Looks like a good source of info that I'll give a shot. Here's the link to that pdf for those interested in it:
 
Last edited:
A major impediment to my better understanding of BASH was just the sheer amount of information out there. If I had actually sat down with this material and worked my way through it, I could have saved countless hours of wasted time and frustration. I'm hoping that it will do the same for you and anyone else that is trying to learn.

https://tldp.org/LDP/abs/html/ (https://archive.ph/LdLRI)
Apparently this guide has a bad reputation for containing outdated or just plain wrong advice. I can't verify that myself since I am a total bash noob, and most of what I've seen about it comes from Reddit so take it with a grain of salt, but I've seen this list of resources recommended instead:
 
Apparently this guide has a bad reputation for containing outdated or just plain wrong advice. I can't verify that myself since I am a total bash noob, and most of what I've seen about it comes from Reddit so take it with a grain of salt,
Yeah I was googling around about it and most of the naysayers are coming from Reddit, use the exact same language to deride the Advanced Bash Scripting guide, and then (typically) immediately shill for GreyCat's shit instead.
Screenshot 2022-07-10 at 19-34-05 r_commandline - Where can I find a REAL course on bash scrip...png

Same fucking guy:
Screenshot 2022-07-10 at 19-28-36 How can I create a select menu in a shell script.png


More GreyCat shilling:
Screenshot 2022-07-10 at 19-28-20 What is the difference between $@ and $ in shell scripts.png

Screenshot 2022-07-10 at 19-32-08 r_linux - Comment by u_pi3832v2 on ”What's a good resource f...png


I mean whatever, they're probably both good resources. Redditors suck, was my point I guess.
 
Yeah I was googling around about it and most of the naysayers are coming from Reddit, use the exact same language to deride the Advanced Bash Scripting guide, and then (typically) immediately shill for GreyCat's shit instead.
View attachment 3478717
Same fucking guy:
View attachment 3478719

More GreyCat shilling:
View attachment 3478718
View attachment 3478720

I mean whatever, they're probably both good resources. Redditors suck, was my point I guess.
They just truly can't help themselves can they? Every single time I see multiple redditors talk about something they always speak in such an eerily similar way. It's like some kind of cult. It doesn't help that signing up to that site seems to somehow remove your capacity to speak in a non-smarmy or condescending way. I used to think my hatred for them was due to my spending way too much time on 4chan in my teen years and that it was all just a meme rivalry or something, but now I see that they truly are just reprehensible and vile hive-mind robots.
Nigger Cattle, if you will.
 
They just truly can't help themselves can they? Every single time I see multiple redditors talk about something they always speak in such an eerily similar way. It's like some kind of cult. It doesn't help that signing up to that site seems to somehow remove your capacity to speak in a non-smarmy or condescending way. I used to think my hatred for them was due to my spending way too much time on 4chan in my teen years and that it was all just a meme rivalry or something, but now I see that they truly are just reprehensible and vile hive-mind robots.
Nigger Cattle, if you will.
I've noticed the same thing about 4chan.
 
Back