Discussion:
bug#33125: the destrustive and non predent behavior of ALL UNIX commands
(too old to reply)
f***@telenet.be
2018-10-23 09:46:13 UTC
Permalink
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-***@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
Bernhard Voelker
2018-10-23 22:50:54 UTC
Permalink
Post by f***@telenet.be
Hello,
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.
Post by f***@telenet.be
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?
Post by f***@telenet.be
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.
Post by f***@telenet.be
==============================
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.
Post by f***@telenet.be
* 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
Paul Eggert
2018-10-23 23:44:47 UTC
Permalink
Post by f***@telenet.be
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.
f***@telenet.be
2018-10-24 06:18:16 UTC
Permalink
Post by f***@telenet.be
Hello,
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.
Post by f***@telenet.be
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
Post by f***@telenet.be
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.
Post by f***@telenet.be
==============================
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.
Post by f***@telenet.be
* 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
f***@telenet.be
2018-10-24 09:10:14 UTC
Permalink
Post by f***@telenet.be
Hello,
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.
Post by f***@telenet.be
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
Post by f***@telenet.be
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.
Post by f***@telenet.be
==============================
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.
Post by f***@telenet.be
* 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
Bernhard Voelker
2018-10-26 14:30:22 UTC
Permalink
Post by f***@telenet.be
Do you know a solution to implement the Windows ctrl z feature?
backups?

Have a nice day,
Berny
f***@telenet.be
2018-10-27 14:22:45 UTC
Permalink
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
Paul Eggert
2018-10-28 21:12:09 UTC
Permalink
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.
Assaf Gordon
2018-10-30 04:08:00 UTC
Permalink
severity 33125 wishlist
retitle 33125 rm: add --backup option, similar to cp/mv/ln
stop
Post by Paul Eggert
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

Loading...