bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#33125: the destrustive and non predent behavior of ALL UNIX commands


From: francky . leyn
Subject: bug#33125: the destrustive and non predent behavior of ALL UNIX commands
Date: Tue, 23 Oct 2018 11:46:13 +0200 (CEST)

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:address@hidden ] 

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 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]