@ericmarceau Prompt colors are changed as well but it is very clear to me when I see a particular background color, which system I’m on.
It was simple to do this using different profiles under gnome terminal and even easier under wezTerm.
3 Likes
Did the same thing. My Putty sessions for production boxes are always red background with white text. Danger Will Robinson!!! For dev boxes I use blue with white letters. Only problem is the color aliases that slip in and frequently aren’t friendly with these colors. Added a loop in my login profile to unalias any color aliases. for i in $(alias | grep color); do ## parse the alias and issue the unalias.
3 Likes
@nosugrof, if you have a script or setting that set the FG/BG colours, you can store a custom
- ~/.dircolors
on each of those hosts, that suits each host uniquely. If you want details on what and how, I had a discussion topic, with an example, here:
3 Likes
That sounds pretty interesting. I’ve often thought the highlights could make life simpler but just never invested the time to figure it out. Quite often the default colors don’t work with my session colors so I’ve always just excluded the color option on commands. I’ll make a point of reading this.
Thanks for sharing!
3 Likes
Very interesting that there is so many references and comments about using rm -rf, particularly in the root directory, /!
It’s actually one of my favorite commands to use, but because of it’s power I use it with care and it’s rarely used.
My favorite memory of using rm -rf / was when I was leaving a company where I had been an engineer for many years. I knew that my workstation would be “re-purposed”, reused, and reinstalled by someone who would get it after me, and we were all in an OS organization anyway, so it’d be no problem install either a release, a nightly build, or whatever the person after me might choose, so it was a safe thing.
Given that such behavior is quite destructive, I wanted to see my workstation, which I had named TheMas, one nickname of my youth, and one implementation of rm even had an argument to show the files being removed, so I added that option and watched the system sink into the darkness, then I brought some of my friends to my favorite food and drink spot and we had a celebration that spanned our years of friendship. One guy a few of you may have heard of - famous in some circles as Jon ‘maddog’ Hall. We first met in Merrimack, NH one afternoon at the popcorn maker and remained friends for many years and chatted about Unix and Linux numerous times!
4 Likes
Never run a fork bomb.
Can you explain the following bash code or bash fork() bomb code?
:(){ :|:& };:
The fork bomb is a form of denial-of-service (DoS) attack against a Linux or Unix-based system. It makes use of the fork operation. The :(){ :|:& };: is nothing but a bash function. This function gets executed recursively. It is often used by sysadmin to test user process limitations on server. Linux process limits can be configured via /etc/security/limits.conf and PAM to avoid bash fork() bomb. Once a successful fork bomb has been activated in a system it may not be possible to resume normal operation without rebooting the system as the only solution to a fork bomb is to destroy all instances of it.
4 Likes
Hi Jymm 
Yes,
It starts with a function definition, redefining the command ‘:’
Everything between the braces is executed when the function is called.
Let’s first change the function name from ‘:’ to ‘bomb’ to make it more readable.
The first line is the function definition
bomb()
{
bomb | bomb &
}
bomb
Here is how it works:
Let’s first take a look at the payload of the function ‘bomb()’
what does bomb | bomb & mean or do ?
what it literally means:
- start function ‘bomb’
- pipe the output to another (on the spot created ) instance of the function ‘bomb’
- run this in the background
What it does:
It starts the function bomb and sends the output to another instance of bomb via pipe and puts it in the background, thereby giving it its own process and environment space.
We have now two processes ‘bomb’ running
-
They will never finish because the second instance of bomb is waiting for the first one to send something (i.o.w. read-locked) so they never exit.
-
we now have two functions in a separate process (subshell) which takes up space
-
In the meantime each “bomb” command is calling … itself
Thereby putting new copies of itself in new background processes … in an endless recursive loop.
The last ‘bomb’ command is actually the command that starts it all.
5 Likes
Can you explain the following bash code or bash fork() bomb code?
That wasn’t me, that is how the article was formatted. But thanks for the explanation anyway, it’s a little more detailed than the article.
3 Likes
Ah, thanks for the link. I’ll take a look.
2 Likes