Hacker News Reader

Comment by abhirag | Hacker News Reader

As long as we are on the topic of Linux shell commands I would like to share a tip which has helped me, whenever you are using wildcards with rm you can first test them with ls and see the files that will be deleted and then replace the ls with rm. This along with -i and -I flags makes rm just a tad bit less scary for me. Kinda basic but hopefully somebody finds it helpful :)

View on HN

As mbrock says, you can also use echo instead of ls for that. And "echo *" serves, in a pinch, as a rudimentary ls, when the ls command has been deleted and you are trying to do some recovery of a Unix system. Similarly dd can be used to cat a file if cat is deleted: dd < file

And in fact whenever you want to do some command like:

cmd some_flags_and_args_and_metacharacters ...

you can just replace cmd with echo first to see what that full command will expand to, before you actually run it, so you know you will get the result you want (or not). This works because the $foo and its many variants and other metacharacters are all expanded by the shell, not by the individual commands. However watch out for > file and >> file which will overwrite or append to the given file with the output of the echo command.

Knowing how to cope with a deleted `ls` and `cat` sounds like a horrible battle scar to carry. How on Earth did you ever get into that situation?

There are a number of accounts of that sort of situation floating around the Internet; it's not necessary to acquire the scars personally. As to how we get into those situations, I suspect that the universal path would be an erroneous 'rm -rf' command affecting the /bin directory.

  http://www.terminalinflection.com/negotiating-a-damaged-linux-filesystem-using-only-shell-builtins/
  http://eusebeia.dyndns.org/bashcp
  https://news.ycombinator.com/item?id=1212051

Just saw your comment now ...

Was not really an issue for me personally, since it was not on my machine. Used to encounter such situations with some regularity when I was a Unix (and general) system engineer in the field, for a large hardware + Unix vendor, early in my career. The job involved solving all sorts of software problems (sometimes involving many levels of the stack) for customers of my employer. Sometimes, less technically savvy customers, like data entry operators or end users of the Unix systems sold by that vendor to them, would end up doing things like that - deleting critical files, losing backups or not taking backups and then the hard disk or OS crashed, corrupting the data on disk, etc. Got to handle many and diverse interesting problems in this area, and learned a lot from it; some of those skills have served me in good stead later in my career too - troubleshooting, Unix fundamentals and skills, interaction of apps with the OS, etc.

As sethrin says, you don't have to acquire the scars personally. And thanks, sethrin, for those links - should make for some good reading, I'm interested in this area though I do not work on it from some time. It can be good fun and mental exercises in problem solving.

You can also use M-? to list all the files.

So typing 'rm foo* ' and pressing Alt-? (on non-OSX computers) will give you a list of what your wildcard would expand to.

M-* does the same thing but actually expands the wildcards, instead of just showing what that expansion would be.

Still works with ESC on OSX

Or echo instead of ls.

Using find to do that is a much better idea. The author shows this as the first examples in #9.

Reply on news.ycombinator.com