On Fri, 15 May 2015 01:59 am, Chris Angelico wrote: > On Fri, May 15, 2015 at 1:49 AM, Grant Edwards <invalid@invalid.invalid> > wrote: >> On 2015-05-14, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> >> wrote: >> >>> I'd like to do a little survey, and get a quick show of hands. >>> >>> How many people have written GUI or text-based applications or >>> scripts where a "Move file to trash" function would be useful? [...] > I have never used such a feature, and generally found them to be more > annoying than useful. The times when I want to mark a file for > deletion either now or at some undefined time in the future (at the > file system's discretion) are approximately zero; either I want the > file, or I can delete it immediately. Given that actually-removed > files can usually be undeleted if their disk space hasn't been > reclaimed, I don't think trash cans really help much.
If you're relying on the ability to undelete, you're already in trouble, you just don't know it. As I understand it, you can't undelete from SSDs. Or maybe it's the opposite, you can't securely delete from SSDs? I forget. In any case, undelete is *unreliable* -- if you're relying on it for "Oh, I changed my mind", then you're in trouble. The primary purpose of trash cans is to protect users who are, um, let's say, less than comfortable with computers, or careless, or both. But even experienced users can make mistakes, or change my mind, and I find myself recovering files from the trash, oh, once or twice a year. I think every person who deletes files from the command line has accidentally deleted the wrong file *more than once*. (And again, I hold my hand up sheepishly here too: been there, done that.) If we were sensible, we'd give ourselves a safety net just like the desktop guys, but there's a machismo associated with command line use than makes us tough it out. No matter how many times we delete the wrong file and have to recover it from backups (or recreate it from scratch because the backups aren't working), we tell ourselves it will be the very last time and it will never happen again. At least many Linux distros alias mv to mv -i by default, which is a start, and use rm -i for root. Anyway, this isn't meant to be a critical look at sys admin psychology :-) > Plus, I think it's a UI insanity when a console program dumps > something in the trash, which to me has always felt like a GUI file > manager tool. I'm not sure why you should feel that way. Every other file manager function is more or less unified between GUI and CLIs. There's only one file manager, and I think you would be annoyed if (say) renaming a file via a CLI only showed the new name at the CLI, not from the GUI. If I was writing a file manager tool, it shouldn't matter whether it used a GUI or CLI, or a rich Curses text-based interface. I'd want to offer both delete immediately and move to trash. > That said, though, I think a standardized API for trashing files is > not a bad thing; and it's not something that will need huge API > changes, so the costs of feature-freeze would be low. Indeed. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
