[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
- bug#33125: the destrustive and non predent behavior of ALL UNIX commands,
francky . leyn <=