On 10/23/18 11:46 AM, francky.l...@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@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
