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

Previous Next

To reply to this bug, email your comments to 33125 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: francky.leyn <at> telenet.be
To: bug-coreutils <at> gnu.org
Cc: Francky Leyn <Francky <at> Leyn.eu>
Subject: the destrustive and non predent behavior of ALL UNIX commands
Date: Tue, 23 Oct 2018 11:46:13 +0200 (CEST)

[Message part 1 (text/plain, inline)]

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'. 

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. 

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 

============================== 

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. 

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. 

Ok, this is what I had to say. Hoping it will result in some action. 

Regards, 

Francky 

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

Message #8 received at 33125 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: francky.leyn <at> telenet.be, 33125 <at> debbugs.gnu.org
Cc: Francky Leyn <Francky <at> Leyn.eu>
Subject: Re: bug#33125: the destrustive and non predent behavior of ALL UNIX
 commands
Date: Wed, 24 Oct 2018 00:50:54 +0200

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 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'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).

Have a nice day,
Berny

Message #11 received at 33125 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: francky.leyn <at> telenet.be, 33125 <at> debbugs.gnu.org
Cc: Francky Leyn <Francky <at> Leyn.eu>
Subject: Re: bug#33125: the destrustive and non predent behavior of ALL UNIX
 commands
Date: Tue, 23 Oct 2018 16:44:47 -0700

On 10/23/18 2:46 AM, francky.leyn <at> telenet.be wrote:
> In this mail I make a plei for a more protective manner for the coreutils.

Sorry about the loss of your data, but at this point the behavior of mv 
etc. is relied on by so many people and scripts that we can't 
realistically make the change you requested. You can, if you like, 
create a shell script like this:

#!/bin/sh
exec /usr/bin/mv -i "$@"

call this script "mv", and then put it into your PATH; that way, the 
'mv' command will behave the way you like, for your usage.

Message #14 received at 33125 <at> debbugs.gnu.org (full text, mbox):

From: francky.leyn <at> telenet.be
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: Francky Leyn <Francky <at> Leyn.eu>, 33125 <at> debbugs.gnu.org
Subject: bug#33125: the destrustive and non predent behavior of ALL UNIX
 commands
Date: Wed, 24 Oct 2018 08:18:16 +0200 (CEST)

[Message part 1 (text/plain, inline)]

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 


> 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 

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

Message #17 received at 33125 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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)]

Message #20 received at 33125 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: francky.leyn <at> telenet.be
Cc: Francky Leyn <Francky <at> Leyn.eu>, 33125 <33125 <at> debbugs.gnu.org>
Subject: Re: bug#33125: the destrustive and non predent behavior of ALL UNIX
 commands
Date: Fri, 26 Oct 2018 16:30:22 +0200

On 10/24/18 11:10 AM, francky.leyn <at> telenet.be wrote:
> Do you know a solution to implement the Windows ctrl z feature? 

backups?

Have a nice day,
Berny

Message #23 received at 33125 <at> debbugs.gnu.org (full text, mbox):

From: francky.leyn <at> telenet.be
To: 33125 <33125 <at> debbugs.gnu.org>
Cc: Francky Leyn <Francky <at> Leyn.eu>
Subject: /bin/del
Date: Sat, 27 Oct 2018 16:22:45 +0200 (CEST)

[Message part 1 (text/plain, inline)]

Hello, 

in this message a do a plea to introduce a /bin/del command into the coreutils. 

Deleting is something totally different than removing. It is a mv action and there must be a restore action. 

With the coreutils, removing is the default. This is not wrong, but it can be very anyoing, as I have experiences with the mv command. The current coreutils work like an incinerator. There is no way back. 

There exist file managers with a recycle bin to solve the problem. But I think they all work differently. Switching from file manager therefore is not obvious. If there would be a /bin/del command, these file managers all could do a system call to he SAME routine, with the same functionality. 

How must this del command work? Look, on the net one finds a plethora of tools to do the job in a command line way. 

I ask you, coreutils developers to develop a /bin/del, that combines the best of these tools. 

Regards, 

Francky 

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

Message #26 received at 33125 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: francky.leyn <at> telenet.be, 33125 <33125 <at> debbugs.gnu.org>
Cc: Francky Leyn <Francky <at> Leyn.eu>
Subject: Re: bug#33125: /bin/del
Date: Sun, 28 Oct 2018 14:12:09 -0700

It'd be nice to add a --backup flag to 'rm', which would behave like --backup 
does with cp, mv, and ln. This would have the effect of the 'del' command you're 
suggesting.

Message #29 received at 33125 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, francky.leyn <at> telenet.be,
 33125 <33125 <at> debbugs.gnu.org>
Cc: Francky Leyn <Francky <at> Leyn.eu>
Subject: Re: bug#33125: /bin/del
Date: Mon, 29 Oct 2018 22:08:00 -0600

severity 33125 wishlist
retitle 33125 rm: add --backup option, similar to cp/mv/ln
stop

On 2018-10-28 3:12 p.m., Paul Eggert wrote:
> It'd be nice to add a --backup flag to 'rm', which would behave like 
> --backup does with cp, mv, and ln. This would have the effect of the 
> 'del' command you're suggesting.

The topic of the thread changed, I'm marking this as a "wishlist" item.

-assaf

Previous Next

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