Is there an undo command in Linux? If not then why not?

[abhishekm71]

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.

I have checked for 'undo' option but this link says that it deos not exist. http://unix.stackexchange.com/questions/996/do-we-have-an-undo-in-linux

So why isn't undo supported in linux? Is it so difficult to implement (atleast for some functions).

[MrHutch]

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.

The moral of the story is never rm -rf * ;-)

[abhishekm71]

Ok, so seems like I will have to write my own scripts for the 'destructive' functions that I use most often like sed and rm so that a backup is first created automatically before the modification.

[MrHutch]

Yeah. Fortunately script writing in *nix is a doddle. I wrote a lot of shell script (it was korn at the time) which I later converted to Perl.

[Duthomhas]

This isn't a Linux-only issue -- If you booger a file in Windows (or any other OS) you won't be able to get it back (unless you have a pretty advanced journaling file system, maybe).

The moral of the story is to back up your files before you try modifying them.

[LB]

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.

[ne555]

> I always use `rm -rf .' so that the shell (or lack of shell) doesn't matter.
¿ah? ¿what is that supposed to do?

[LB]

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 *

[ne555]

> The latter always empties the current directory

$ touch this
$ ls
this
$ rm -rf .
rm: refusing to remove ‘.’ or ‘..’ directory: skipping ‘.’
$ ls
this

[LB]

Hm, so apparently there is no way to empty the entire directory that works in all environments. I guess I should have expected that.

EDIT: D'oh, I was thinking of git rm -rf . and not rm -rf .

[MrHutch]

LB wrote:

who would do that?

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.