[HN Gopher] $ rm Important.txt (uh oh)
___________________________________________________________________
$ rm Important.txt (uh oh)
Author : xenodium
Score : 35 points
Date : 2022-09-17 19:57 UTC (3 hours ago)
(HTM) web link (xenodium.com)
(TXT) w3m dump (xenodium.com)
| renewiltord wrote:
| After over 2 decades of Linux use, the other day I created a
| folder called `~` in my code dir accidentally and then just ran
| `rm -rf ~` like a moron instead of `rm rf ./~` like a smart man.
| Fortunately for me, it didn't get far and I ^C before it got
| anywhere.
| hit8run wrote:
| Can one also enable system bin for terminal (zsh)?
| tectonic wrote:
| I was just thinking that I'd write a command for this if it
| didn't exist already. But it does:
| https://apple.stackexchange.com/a/50852
| cristoperb wrote:
| I use trash-cli which implements the freedesktop trash spec:
|
| https://github.com/andreafrancia/trash-cli
| soheil wrote:
| I have nightmares about doing rm -rf *
|
| in my home dir. With this it's a bit better, but you could still
| do rm -rf .*
|
| in your home dir and lose your hidden .trash dir too.
| naniwaduni wrote:
| I make a habit of rm -fr ../current_dir_name/* when trying to
| delete a broad glob, just to at least make sure to sanity-check
| deleting from the right place.
| jrockway wrote:
| My best backup has always been having a buffer visiting the file
| I'm about to delete. I think that's saved my bacon once or twice,
| but honestly I have 0 paranoia about losing data. For whatever
| reason, I've never accidentally deleted .git and an important
| unpushed change at the same time. As a result I disable swap
| files and backup files in Emacs, and I haven't regretted it.
|
| My biggest data loss incident was like 25 years ago when I ran
| "swapon" on /. Wouldn't recommend it. (And that will trash your
| Trash, probably.)
| ataylor284_ wrote:
| I also tend to have important stuff in a buffer before doing
| anything destructive outside emacs although I definitely keep
| backup files on.
|
| Reminds me of a time a hard drive failed on a computer I had. I
| had an active ssh connection, running terminal display emacs
| remotely, with a very important file -- with no backup copy --
| in a buffer. The computer continued to function, but I couldn't
| access the disk at all, and I figured as soon as I closed the
| ssh connection, it was game over. I managed to salvage the file
| by cutting and pasting through my terminal emulator.
| [deleted]
| kickingvegas wrote:
| While this is good guidance for Emacs users, another, more shell-
| based tactic is to use the "-i" option for "rm" which requests a
| confirmation before deleting the file. Aliasing "rm" to "rm -i"
| in either .bashrc or .zshrc (depending on what shell you use) for
| interactive operations has saved me a countless number of times
| from regret.
| marcosdumay wrote:
| > Aliasing "rm" to "rm -i" in either .bashrc or .zshrc
|
| Or, alternatively, don't. People with that alias learning to
| add -f to every rm invocation are also a large source of
| problems.
|
| Rm should really do something more sensible on the -i switch,
| like displaying a summary or the files and asking for
| confirmation only once. Personally, I like to run "find -name
| file" and once I'm ok with it, I circle the command back and
| add -delete to it. It is much more usable.
| naniwaduni wrote:
| Considering the difference between bare rm and rm -f is that
| interactive rm without -f is required to ask for each _read-
| only_ file (which has approximately nothing whatsoever to
| deal with whether you can or should be deleting it!), I 'm
| pretty sure learning to add -f to every rm invocation causes
| a median of 0 problems per person learning it.
| sshine wrote:
| I've run with alias rm='rm -iv'
|
| for years without adding -f.
|
| Much like I don't prepend 'sudo' until it requires me, at
| which point I stop and think.
|
| Your 'find -delete' trick does the same: it creates time to
| think between expressing yourself and evaluating the outcome.
| This is great.
| kickingvegas wrote:
| For such folks, telling them that invoking the full path of
| the executable will bypass the alias, e.g. "/bin/rm -f" will
| do the right thing. Discoverable? Nah. But we are talking
| about shell command behavior which is pretty arcane anyways.
| bravetraveler wrote:
| Not really something I'd suggest with rigor, but prefacing
| an aliased command with a backslash will also defeat it
| dylan604 wrote:
| TIL. I was unaware of that. so if rm is aliased to "rm
| -i", then \rm will do the normal thing?
| bravetraveler wrote:
| Indeed! I had to use this pretty routinely supporting a
| particular customer at a previous employer.
|
| Their shell profiles were _littered_ with two-letter
| aliases, replacing quite a few common things with their
| proprietary [often unrelated] versions
|
| For example, _mv_ for moving files became _mv_ for Mail
| Volume, or something
| dylan604 wrote:
| dearlordy, that's even worse. aliasing an existing cmd
| with options preset is one thing. aliasing a well known
| cmd to some esoteric cmd is mindboggling
| avnigo wrote:
| You can also do that by prefacing an aliased command with
| "command".
| dylan604 wrote:
| i like the \ vs 7+space additional key presses. that's
| like typing the full path without utilizing tab
| expansion. only noobs do that /s
| avnigo wrote:
| Aliasing "cp" to "cp -i" also prevents you from overwriting
| files without confirmation. It's more of a preference thing
| than a recommendation, but overwriting on copy is something
| that bit me in the past when working a bit mindlessly. I guess
| the proper recommendation would be "don't operate the
| commandline mindlessly"?
| [deleted]
| daptaq wrote:
| delete-by-moving-to-trash is a variable defined in
| 'src/fileio.c'.
|
| Its value is nil
|
| Specifies whether to use the system's trash can. When non-nil,
| certain file deletion commands use the function 'move-file-to-
| trash' instead of deleting files outright. This includes
| interactive calls to 'delete-file' and 'delete-directory' and the
| Dired deletion commands. This variable was
| introduced, or its default value was changed, in version
| 23.1 of Emacs. You can customize this variable.
|
| ---
|
| If this option doesn't work for you, you should report a bug.
| pacifika wrote:
| Alias rm to trash
| mmh0000 wrote:
| I've had this function/alias in my {bash,zsh}rc files file years:
| function rm { for file in $@; do mv -t
| ~/.local/share/Trash/files/ -- "${file}" cat <<FROG >
| ~/.local/share/Trash/info/"$(basename ${file})".trashinfo
| [Trash Info] Path=$(realpath "${file}")
| DeletionDate=$(date "+%FT%T") FROG done }
| BerislavLopac wrote:
| I use trash-cli [0] for that.
|
| [0] https://github.com/andreafrancia/trash-cli
| dmckeon wrote:
| No need for "$@" there? (Not many file names with spaces?)
| knorker wrote:
| You have a bug in your function. You need to use "$@", with the
| quotes, or wildcards expanding to a file with spaces will not
| delete properly.
|
| At least with bash.
| miduil wrote:
| Sounds useful, though I'd advice using a different alias - just
| to avoid surprises when for some reason your function wasn't
| loaded properly.
| cassepipe wrote:
| Seems relevant and not just for emacs :
| https://github.com/rushsteve1/trash-d I have been using it after
| for some time after it was posted to HN. It's a great tool.
| There's a .deb in the releases page.
| goshx wrote:
| This reminds me of myself back in the 90's when I learned the
| hard way that I should probably create an alias called "rm" where
| it just moves the files/directories to a "trash" directory where
| I could purge things later.
| nathants wrote:
| i use git-timemachine for emacs, letting me move backwards or
| forwards through commits in the current file.
|
| i do something similar for uncommitted changes. every time emacs
| saves a file, it saves a copy to a .backups/ folder with a
| timestamp appended, then prunes copies to the latest 50. with
| similar hotkeys to git-timemachine i can travel backwards and
| forwards through saves of the current file.
|
| after that i backup my home folder with git and tar[1].
|
| losing data definitely sucks. it has to happen once, and then one
| has to decide: never again.
|
| 1. https://github.com/nathants/backup
| gerdesj wrote:
| I wipe USB sticks with:
|
| # dd if=/dev/zero of=/dev/sdd (CTRL-C after a few seconds)
|
| It's quick and easy and only a slip away from a wiped hard disc.
| On a SSD, that would probably rip through /boot (EFI) and swap
| and be munching on my / before I stopped it. Oh well I could
| restore the OS and /home should still be intact ... probably.
|
| As I current use Arch and prior to that Gentoo for over a decade,
| it's probably not the worst breakage I've done to a laptop 8)
| gizmo686 wrote:
| I routinly need to dd to a thumbdrive at work. On newer
| computers the internal harddrive tends to be on /dev/nvme*,
| making the usb drive sda. Apart from several months of being
| very nervous when I went to flash a drive, this significantly
| reduced the risk of an accidental destruction of you computer.
|
| Having said that, I have forgotten that I had an ssh session
| open and accidentally destroyed a dev server like that.
| DannyBee wrote:
| Zfs. lots of snapshots.
|
| cd .zfs/whatever the nearest one was, copy it, done
| layer8 wrote:
| On Windows, File History works similarly, once you've set it
| up.
| thom wrote:
| I know we pooh-pooh Dropbox as they try and find some more
| expansive business model than backups, but having been a customer
| for more than a decade, I haven't had a single moment's anxiety
| about losing any version of any file. It's never failed when I
| needed to go back and retrieve something, to the point that my
| OS's trash folder is just that thing I empty if I ever want to
| save some disk space.
| simonblack wrote:
| Dropbox is only useful if you are using it for _just one_
| computer.
|
| I tried using it for syncing the files on several computers at
| one time. Instead of adding files to the computer that was
| lacking them so that both computers matched, it deleted files
| from the computer that had them so that both computers matched.
|
| These days I just use 'rsync' instead.
| [deleted]
| dmd wrote:
| I've been using dropbox across three computers since a few
| months after they were founded and have never once
| encountered this problem - and if I someday do, it's a matter
| of seconds to undo deletions in Dropbox.
| amelius wrote:
| A continuous snapshotting filesystem would be a more rigorous
| approach.
| mnd999 wrote:
| APFS is that, no? That's how Time Machine works.
| DannyBee wrote:
| Kinda. It supports consistent snapshots but they are not easy
| to access or copy or ... except through TM. It ends up closer
| to VSS or LVM in usability, though it doesn't have to be
| since the architecture is better.
|
| ZFS is likely the canonical example of a system that makes
| constant snapshots easy to use and access and deal with.
|
| BTRFS is also not bad
| sph wrote:
| Does ZFS snapshot every single operation you do? That
| sounds pretty cool. Unless you're saying snapshots are
| cheap but you have to create them manually, in that case
| it's not very useful against accidental deletion.
| TheAceOfHearts wrote:
| I have rm aliased to trash for interactive use because it
| prevents me from making mistakes. There's a macOS trash utility
| you can download that lets you put files in the trash properly
| with full Finder support.
|
| The great thing about modern computers is that they have so many
| resources that it's okay to build more forgiving tools.
|
| Time Machine has been a huge lifesaver as well. Ideally you
| should be able to mark certain folders to automatically track all
| file changes over time.
|
| There's still so much room for improving user friendliness and
| accessibility of computer systems, but it feels like we're either
| stuck in the Unix box or we've gone full kiddie lockdown mode
| with mobile platforms.
___________________________________________________________________
(page generated 2022-09-17 23:02 UTC)