I have recently started working in the Linux environment and I am finding it very useful, especially grep, find and sed utilities.
However, it is a kind of pain to backup every file before 'sed-ing' into it. This is because the regex that I use may not be correct and my file may go for a toss. Slightly better option that I have is to first redirect my output to a temporary file and check whether I am doing it correctly or not.
Nope, if you bugger things in *nix then you're pretty much done.
You can write a script or alias a command to create a copy or backup of a file, though. When I worked at my last job, I created a script that sent files that I rm'd to a trash can, rather than deleting them permanently. It was command-line HP-UX, so we had no GUI, trash etc.
As Duoas says, the feature you are looking for in Linux also does not exist in Windows, Mac, etc. in fact I don't know of any operating system that supports it. You would have to go all-out and start using version control, but most VCS are optimized for code and not general files.
@iHutch who would do that? I always use rm -rf . so that the shell (or lack of shell) doesn't matter.
In all *nix environments I have used so far, "rm -rf *" has behaved differently from "rm -rf ." depending on the shell or lack of shell. The latter always empties the current directory, whereas the prior occasionally leaves dotfiles or if not run from the shell will try to delete a file/directory named *
Someone very careless. It's just a bad habit to get into. Telling a system that has no undo switch to recursively and authoritatively delete is probably going to wind someone up in a world of hurt.
It wasn't uncommon for beginners to do it in my old place. We used Weblogic and a lot of test logs would build up in a directory. People without any good knowledge of the system would go to the directory and type that command to move them all. However, you'd have instances where people accidentally in the wrong directory and obliterated stuff they needed. Coupled with that, you have the risk of accidentally using the command in your command history (easily done) when in another directory.