GNU bug report logs - #33125
rm: add --backup option, similar to cp/mv/ln

Previous Next

Package: coreutils;

Reported by: francky.leyn <at> telenet.be

Date: Tue, 23 Oct 2018 09:47:01 UTC

Severity: wishlist

Full log


View this message in rfc822 format

From: francky.leyn <at> telenet.be
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: Francky Leyn <Francky <at> Leyn.eu>, 33125 <33125 <at> debbugs.gnu.org>
Subject: bug#33125: the destrustive and non predent behavior of ALL UNIX commands
Date: Wed, 24 Oct 2018 11:10:14 +0200 (CEST)
[Message part 1 (text/plain, inline)]

----- Op 24 okt 2018 om 8:18 schreef Francky Leyn <francky.leyn <at> telenet.be>: 



On 10/23/18 11:46 AM, francky.leyn <at> telenet.be wrote: 
> Hello, 
> 
> I just destroyed 3 days of scaninng work. This was the command: 
> 
> ls p.*.png | sort -t. -k2 -n | gawk '{ printf("mv '\''%s'\'' '\''p. %d.png'\''\n", $0, NR+6) }' | bash [ mailto:bug-coreutils <at> gnu.org ] 
> 
> The problem was that the sequence of mv command resulted in one .png file: 
> 
> mv 'p. 123.png' 'p. 124.png' 
> mv 'p. 124.png' 'p. 125.png' 
> mv 'p. 126.png' 'p. 127.png' 
> 
> The result is that you end up with one file: 'p. 127.png'. 

outch, sorry for your loss. 

> When you look at the commands (without the trailing bash), you think it's ok because you think declaratively. However, this thing works imperative/procedural. 

As you said, the problem originated from a logic error in the counting 
for the new names of the files. 
Didn't you run that without the executing "| bash" first? 

I did, but my coin hasn't fallen. What I should have done, is after seeing the result when executing without the "| bash", is change the command to: 

ls p.*.png | sort -t. -k2 -n | gawk '{ printf("mv -i '\''%s'\'' '\''p. %d.png'\''\n", $0, NR+6) }' | tac | bash 





What also could have worked, is: 

ls p.*.png | sort -t. -k2 -nr | gawk '{ printf("mv -i '\''%s'\'' '\''p. %d.png'\''\n", $0, NR+6) }' | bash 

Unfortionately, sort doesn't have a reverse option/switch. 


BQ_BEGIN

> I would not have lost all my files if I would have used "mv -i": 
> 
> ls p.*.png | sort -t. -k2 -n | gawk '{ printf("mv -i '\''%s'\'' '\''p. %d.png'\''\n", $0, NR+6) }' | bash 

No, because once you would have confirmed the -i prompt, the same would have happened. 
The point is to recognize that file 123 is first renamed to 124, then 124 is renamed 
to 125, and so on. 

> ============================== 
> 
> With the rm command it is the same. It deletes/removes, and the file is gone forever. No tracing back option like a recycle bin under Windows. 
> 
> In this mail I make a plei for a more protective manner for the coreutils. The "-i" options should dissapear altoghether and being the default. Instead there should be options to force execution without confirmation. 

The GNU coreutils are a low-level tool set which adheres to certain 
standards and provides certain compatibility with other implementations. 
We cannot (and therefore will not) simply change such behavior. 
Furthermore, -i is not effective in scripts without stdin (in this case 
stdin came from the pipe). 
Finally, as written above, -i would *not* have helped you unless you 
would have seen the logical mistake. 

As such, I'm afraid we can not do something at this point. 

> Also: 
> 
> 
> * There should be a recycle bin for rm. 
> * There should be a call back facility to undo the latest action. In Windowds this is ctrl z. 

Different topic. 
I think this has been already discussed. Again, the GNU coreutils as command line 
tools are quite low-level, and things like a recycle bin belongs to desktop apps. 

I once heard about a "trish cli" or something package that implements the rm in the Windows way. I was command line driven. But I was unable to install the package. Do you perhaps know the exact name? 

I'd compare it with using a sharp Japanese kitchen knife: of course one can cut oneself 
into the fingers, but if one uses it as it's designed for, then it can do things 
one can't with a blunt, old steel knife (although the latter may or may not have 
its merits regarding other aspects). 

Do you know a solution to implement the Windows ctrl z feature? 

Have a nice day, 
Berny 
Beantwoorden - Iedereen antwoorden - Doorsturen - Meer a 

BQ_END


[Message part 2 (text/html, inline)]

This bug report was last modified 6 years and 232 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.