`rm -rf /*`

 

DONT EVER DO IT!

Before running any command, first do a  'ls -al  path'   command.  That will show exactly what is in the path that you are going to use.  If that path is what you want to operate on, then cut-and-paste it as the path of the command that you are going to use. 

 

Also make sure what the switches are going to do.  Double check and read again to make sure you really understand the implications of that switch.  If you use 'wildcards', again think about what that wildcard will select.

 

Remember that most of the two letter Unix/Linux commands were first written by the computer nerds at Bell Labs back in the day when the computer terminals was teletype machines.  They wanted as little feedback from a command as possible because of the noise and time required to type them out on paper.  So they run "silent" and the only way you knew when they were finish is when the command prompt was generated after the command had completed! 

9 hours ago, Frank1940 said:

Before running any command, first do a  'ls -al  path'   command.  That will show exactly what is in the path that you are going to use.  If that path is what you want to operate on, then cut-and-paste it as the path of the command that you are going to use. 

 

Also make sure what the switches are going to do.  Double check and read again to make sure you really understand the implications of that switch.  If you use 'wildcards', again think about what that wildcard will select.

 

Remember that most of the two letter Unix/Linux commands were first written by the computer nerds at Bell Labs back in the day when the computer terminals was teletype machines.  They wanted as little feedback from a command as possible because of the noise and time required to type them out on paper.  So they run "silent" and the only way you knew when they were finish is when the command prompt was generated after the command had completed! 

 

I was inside the correct directory. I was cd'd into the new share I had just created which after i had `ls -la` and checked its contents had a bunch of incorrectly copied files in.

So I was in the correct directory but that command wiped every mounted drive including the boot USB disk.

 

I am lucky because I had only 1 drive mounted and recovered my data from a windows PC (using a program called Recuva - got my photos from 2012 back :phew)

 

But goddamn is this nuts. Doing `rm -rf /*` on a Mac deletes things inside the pwd and below. The actual stupidity of this command is wild. And how Unraid has NO guardrails is even more wild.

54 minutes ago, qal1h said:

is this nuts. Doing `rm -rf /*` on a Mac deletes things inside the pwd and below. The actual stupidity of this command is wild. And how Unraid has NO guardrails is even more wild.

 

No, in Linux (based on Unix), the beginning forward slash, "/", has always meant the the path begins in the root of the file system!!!!  It allow one to explore (or reference) any directory in the entire file system-- not just one associated with the pwd.  And Mac OS, I believe, was based on BSD Unix which a re-engineered Bell Labs Unix..  

 

By the way, the forward slash is a very tricky beast.  When is the last character in a path that ends in a directory, it can change whether the directory is included or just its contents.  That is another one that can bite one in the butt... 

As a further bit of information, the 'proper' way to pass the pwd to a command is to use period followed by a slash-- 

./  

Showing what I mean:

 

 

Notice that all three of these give the same result.  These types of insights can only come by in-depth study and experience using any OS at the command line level.  While the   ls    command assumes the pwd as the default path, any Command the requires a path will require that the path be fully specific.  I thought I might post up what the    ls -al  /*    would output.  Then I tried it and discovered that the output was everything in the entire file system!  (Give it a try and see what I mean!)

 

Hopefully, your rm command did not get to the /boot or /mnt directory...

 

PS---  I have no knowledge of your level of experience working at the command line level.  But I wrote these responses for a wider audience whose knowledge might be well below yours.  (I will be honest and admit that I didn't remember the ./  shortcut until I walked away for about an hour.  I really don't use the command line that often these days.)

Thanks for the insight @Frank1940. I am certainly more conscious about doing anything in the CLI. And thats because another incident occurred. I deleted an entire folder of 600gb of data oops. Lesson learned, always check you're in the right directory! As well as using `./`

 

Luckily the program I referenced already did a great job and recovered everything.

There are textbooks on using the Linux command line but they are pretty boring reading.  Even if you are conscientious in reading one, only constant use of the command line will really drill home in your brain all of the gotcha's.  (As I like to say, "I know just enough but the command line to make me really dangerous!")   I use the   rsync    command to keep the backup of my 20TB of media up to date.  I have a text file on my desk top with the command to be used and I cut-and-paste the command when I need to run it.  (I use    tmux   if the backup might take longer than an hour.)I did about ten hours of research on rsync switches and paths before I was confident enough to use it the first time.  (tmux allows you to close the terminal session on your desktop and any process in the session will continue to run in the background on the Unraid server.  When you open the terminal later, you can rejoin the tmux session.  tmux is included as a part of Unassigned Devices Preclear plugin.  I is a valuable addition to the Unraid arsenal.  I prefer to use this version as opposed to the one in Nerd Tools because Nerd Tools at the present time is unsupported.  You will need to google 'tmux' for a short-sheet set of instructions. )

 

One more thing you can play with...

ls -al ../

See if you can figure out what the extra 'dot' does.

I'm a software developer so quite familiar with the command line but on Mac. Didnt know there was a difference but now I do!

 

On rsync actually and the Unraid terminal - glad you brought it up (was going to start another thread) - BUT - basically yesterday I must have been timedout of my session to Unraid and thought the rysnc would continue running in the background but it had stopped when I was logged out. So is that what tmux will help resolve or will it just allow you to continue where it left off?

 

31 minutes ago, qal1h said:

So is that what tmux will help resolve or will it just allow you to continue where it left off?

It runs in the background, as long as you detach the session and not close it
 

 

 

Edited July 9, 20241 yr by Mainfrezzer
added example

1 minute ago, qal1h said:

On rsync actually and the Unraid terminal - glad you brought it up (was going to start another thread) - BUT - basically yesterday I must have been timedout of my session to Unraid and thought the rysnc would continue running in the background but it had stopped when I was logged out. So is that what tmux will help resolve or will it just allow you to continue where it left off?

It will continue to run in the background.  That is the reason why folks use it.  (When I did my initial backup, I did it in small pieces-- Usually overnight.  I would start it running and then shutdown my PC.  In the morning, I would start the PC, log onto the GUI, open a GUI terminal session, run the command to attach to the tmux session, then check to see how things went over night.)

 

14 minutes ago, qal1h said:

I'm a software developer so quite familiar with the command line but on Mac. Didnt know there was a difference but now I do!

 

I worked for Western Electric as an Engineer. The guys at Bell Labs who developed UNIX were genius but were a bit egotistical who look down on us mere mortals who had to use it.  They never went back and fixed those gotchas (They were smart and they could avoid them so why couldn't the rest of the world) so we still have them today.  I think the ones who adapted UNIX into BSD UNIX (The distant ancestor of MACOS), took the time to fix some of them.  (Point of disclosure.  I never met any of the developers personally but I did meet some people who had...) 

 

PS: tmux can be a life saver if you get a brain f**t and accidentally close on a running terminal session while cleaning up open windows on your desktop...

2 hours ago, Mainfrezzer said:

 

It runs in the background, as long as you detach the session and not close it
 

 

Brill! So can you run multiple instances? Like multiple tmux new -s transfer1 and tmux new -s transfer2 and detach from both and re-attach to each one? The reattach command seems to have no other arguments to attach to something else, so presumably just 1.

7 minutes ago, qal1h said:

Brill! So can you run multiple instances? Like multiple tmux new -s transfer1 and tmux new -s transfer2 and detach from both and re-attach to each one? The reattach command seems to have no other arguments to attach to something else, so presumably just 1.

Yes, you can run multiple sessions. "tmux a" just re-connects you to the last used session.

"tmux ls" lists all active sessions. "tmux a -t NAMEOFSESSION" will reconnect to the named session.

3 minutes ago, Mainfrezzer said:

Yes, you can run multiple sessions. "tmux a" just re-connects you to the last used session.

"tmux ls" lists all active sessions. "tmux a -t NAMEOFSESSION" will reconnect to the named session.

Amazing thank you, works perfectly as expected. One thing I find weird is the detatch command ctrl+b then d - I suppose it stops you from doing it accidentally!