RFC: alias tar="tar --backup" ?

[Micah Cowan]

Onno Benschop wrote:
> On 18/05/07 06:18, Micah Cowan wrote:
>> A user, timothy, describing his difficulties at:
> 
>> https://bugs.launchpad.net/ubuntu/+bug/113154
> 
>> describes his frustration as a new user, in discovering the hard way
>> that tar's default is to overwrite existing files, causing him to lose
>> important data.
> 
>> While I'm opposed to fixing the problem in tar itself, as traditional
>> usage frequently relies upon this behavior, I don't see why we couldn't
>> make the experience of using tar interactively a little safer, by
>> providing a default alias for tar in /etc/skel/.bashrc that backs-up
>> existing files.
> 
>> Comments?
> 
> Ironically, I suspect that you're damned if you do and damned if you
> don't. A similar overwriting happens with the mv command. I strongly
> suspect that you can make an argument either way. In the days of yore,
> DOS had similar behaviours with the copy command.

Which is why some distros have root's bashrc alias mv -i, cp -i. But I
think such things happen with mv and cp, only for single files by
default, not with tree moves, whereas tar has the capability of killing
many files with a single command.

> What I see here is a classic example of an expectation mismatch. The
> new user expects the computer to almost "honour" their data, the more
> experienced user expects the computer to do what it is told.

Yes. Well, the user expects the computer to do what it is told, too, but
doesn't realize that without flags like --backup or -k, he has
implicitly told the computer to go ahead and write over anything it sees.

> There is something to be said for your proposal, if we keep in mind
> the "do no harm" approach, but then you would need to do that for all
> such commands. That is a long and slippery slope to head down. Perhaps
> another way of resolving this is that any and all GUI tools should
> warn or not overwrite unless specifically told to, and the command
> line tools should do what their man page says that they will.

I had thought about that as well. Not sure whether that ought to be
sufficient, but that's what this discussion is for :)

After all, I have no vested interest in it, and would probably end up
removing the alias from my own bashrc anyway: I just didn't want to
dismiss the user off-hand with a "that just isn't how tar works; RTFM!"
...that wouldn't seem very Ubuntu-y.

And the user has a valid point: it should generally be considered a
design flaw to "destroy by default". It's just that this design flaw has
the weight of long history behind it.

> Perhaps when a user launches a terminal for the first time, a dialog
> pops up that says something along the lines of:
> 
>     Commands entered within a Terminal screen may not work as you
>     expect. Sometimes a command will overwrite files without warning
>     you. If you are unsure, use the 'man' command to find out.

Too general to be useful, IMO. And, in this specific example, the user
would have to give it a pretty thorough reading to discover this trait.

> Of course a completely different approach would be a file system
> capable of roll-back, and in doing that, a user may well benefit from
> the backup services such a solution offers.
> 
> Finally, you could probably create a "safe" terminal, but personally I
> do not think that this is a good idea because then you would have a
> tar command in a "safe" environment (with a --backup flag) and the
> same tar command in the "unsafe" environment, causing a deferred
> mismatch of expectation with potentially bigger harm down the track.

Yes... but is having a "safe" versus an "unsafe" environment really any
different from having "safe" defaults in .bashrc, that the user can
switch to an "unsafe" environment by removing/editing? :)

And I do mean, of course, that such an alias, if it were approved,
should /not/ be present in /etc/bash.bashrc; only /etc/skel/.bashrc.

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20070517/5323798f/attachment.sig>