Skip to main content
added "mantra" :)
Source Link
syntaxerror
  • 2.4k
  • 2
  • 31
  • 52

I've just lost a small part of my audio collection, by a stupid mistake I made. :-(
GLADLY I had a fairly recent backup, but it was still irritating. Apart from yours truly, the other culprit doing the mischief was mv, which will show as follows:

The audio files had a certain scheme:

ARTIST - Some Title YY.mp3 

where YY is the 2-digit year specification.

mkdir 90<invisible control character> 

(Up to this moment, I did not know that I had actually typed one third excess character which was invisible ...!)
Instead of having all in one directory, I wanted to have all 1990s music in one directory. So I typed:

find . -name '* 9?.mp3' -exec mv {} 90 \; 

Not so hard to get the idea what happened eh? :->
The (disastrous) result was a virgin empty directory called '90 something' (with something being the "invisible" control character) and one single file called '90', overwritten n times.

ALL FILES WERE GONE. :-(( (obviously)

Wish mv would've checked in time whether the signature of the destination "file" (remember on *NIX everything is a "file": Everything Is A File) starts with a d------ (e. g. drwxr-xr-x). And, of course, whether the destination exists at all. There is a variant of the aforementioned scenario, when you simply forgot to mkdir the directory first. (but of course, you assumed that it's there...)

Even our pet-hate OS starting with the capital W DOES DO THIS. You get even prompted to specify the type of destination (file? directory?) if you ask for it.

Hence, I'm wondering if we *NIXers still have to write ourselves a "mv scriptlet" just to avoid these kinds of most unwanted surprises.

I've just lost a small part of my audio collection, by a stupid mistake I made. :-(
GLADLY I had a fairly recent backup, but it was still irritating. Apart from yours truly, the other culprit doing the mischief was mv, which will show as follows:

The audio files had a certain scheme:

ARTIST - Some Title YY.mp3 

where YY is the 2-digit year specification.

mkdir 90<invisible control character> 

(Up to this moment, I did not know that I had actually typed one third excess character which was invisible ...!)
Instead of having all in one directory, I wanted to have all 1990s music in one directory. So I typed:

find . -name '* 9?.mp3' -exec mv {} 90 \; 

Not so hard to get the idea what happened eh? :->
The (disastrous) result was a virgin empty directory called '90 something' (with something being the "invisible" control character) and one single file called '90', overwritten n times.

ALL FILES WERE GONE. :-(( (obviously)

Wish mv would've checked in time whether the signature of the destination "file" (remember on *NIX everything is a "file") starts with a d------ (e. g. drwxr-xr-x). And, of course, whether the destination exists at all. There is a variant of the aforementioned scenario, when you simply forgot to mkdir the directory first. (but of course, you assumed that it's there...)

Even our pet-hate OS starting with the capital W DOES DO THIS. You get even prompted to specify the type of destination (file? directory?) if you ask for it.

Hence, I'm wondering if we *NIXers still have to write ourselves a "mv scriptlet" just to avoid these kinds of most unwanted surprises.

I've just lost a small part of my audio collection, by a stupid mistake I made. :-(
GLADLY I had a fairly recent backup, but it was still irritating. Apart from yours truly, the other culprit doing the mischief was mv, which will show as follows:

The audio files had a certain scheme:

ARTIST - Some Title YY.mp3 

where YY is the 2-digit year specification.

mkdir 90<invisible control character> 

(Up to this moment, I did not know that I had actually typed one third excess character which was invisible ...!)
Instead of having all in one directory, I wanted to have all 1990s music in one directory. So I typed:

find . -name '* 9?.mp3' -exec mv {} 90 \; 

Not so hard to get the idea what happened eh? :->
The (disastrous) result was a virgin empty directory called '90 something' (with something being the "invisible" control character) and one single file called '90', overwritten n times.

ALL FILES WERE GONE. :-(( (obviously)

Wish mv would've checked in time whether the signature of the destination "file" (remember on *NIX: Everything Is A File) starts with a d------ (e. g. drwxr-xr-x). And, of course, whether the destination exists at all. There is a variant of the aforementioned scenario, when you simply forgot to mkdir the directory first. (but of course, you assumed that it's there...)

Even our pet-hate OS starting with the capital W DOES DO THIS. You get even prompted to specify the type of destination (file? directory?) if you ask for it.

Hence, I'm wondering if we *NIXers still have to write ourselves a "mv scriptlet" just to avoid these kinds of most unwanted surprises.

Tweeted twitter.com/#!/StackUnix/status/536309011973677056
deleted 50 characters in body
Source Link
syntaxerror
  • 2.4k
  • 2
  • 31
  • 52

I've just lost a small part of my audio collection, by a stupid mistake I made. :-(
GLADLY I had a fairly recent backup, but it was still irritating. Apart from yours truly, the other culprit doing the mischief was mv, which will show as follows:

The audio files had a certain scheme:

ARTIST - Some Title YY.mp3 

where YY is the 2-digit year specification.

mkdir 90<invisible control character> 

(Up to this moment, I did not know that I had actually typed one third excess character which was invisible ...!)
Instead of having all in one directory, I wanted to have all 1990s music in one directory. So I typed:

find . -name '* 9?.mp3' -exec mv {} 90 \; 

Not so hard to get the idea what happened eh? :->
The (disastrous) result was a virgin empty directory called '90 something' (with something being the "invisible" control character) and one single file called '90', overwritten n times.

ALL FILES WERE GONE. :-(( (obviously)

But this would not have happened ifWish mv hadwould've checked in time whether the signature of the destination "file" (remember on *NIX everything is a "file") starts with a d------ (e. g. drwxr-xr-x). And, of course, whether the destination exists at all. Because thereThere is also a variant of the aforementioned scenario, when you simply forgot to mkdir the directory first. (but of course, you assumed that it's there...)

Believe it or not, yourEven our pet-hate OS starting with the capital W DOES DO THIS. You get even prompted to specify the type of destination (file? directory?) if you ask for it.

Hence, I just cannot believe thatI'm wondering if we *NIXers still have to write ourselves a "mv scriptlet" just to avoid these kinds of most unwanted surprises.

I've just lost a small part of my audio collection, by a stupid mistake I made. :-(
GLADLY I had a fairly recent backup, but it was still irritating. Apart from yours truly, the other culprit doing the mischief was mv, which will show as follows:

The audio files had a certain scheme:

ARTIST - Some Title YY.mp3 

where YY is the 2-digit year specification.

mkdir 90<invisible control character> 

(Up to this moment, I did not know that I had actually typed one third excess character which was invisible ...!)
Instead of having all in one directory, I wanted to have all 1990s music in one directory. So I typed:

find . -name '* 9?.mp3' -exec mv {} 90 \; 

Not so hard to get the idea what happened eh? :->
The (disastrous) result was a virgin empty directory called '90 something' (with something being the "invisible" control character) and one single file called '90', overwritten n times.

ALL FILES WERE GONE. :-(( (obviously)

But this would not have happened if mv had checked in time whether the signature of the destination "file" (remember on *NIX everything is a "file") starts with a d------ (e. g. drwxr-xr-x). And, of course, whether the destination exists at all. Because there is also a variant of the aforementioned scenario, when you simply forgot to mkdir the directory first. (but of course, you assumed that it's there...)

Believe it or not, your pet-hate OS starting with the capital W DOES DO THIS. You get even prompted to specify the type of destination (file? directory?) if you ask for it.

Hence, I just cannot believe that we *NIXers still have to write ourselves a "mv scriptlet" just to avoid these kinds of surprises.

I've just lost a small part of my audio collection, by a stupid mistake I made. :-(
GLADLY I had a fairly recent backup, but it was still irritating. Apart from yours truly, the other culprit doing the mischief was mv, which will show as follows:

The audio files had a certain scheme:

ARTIST - Some Title YY.mp3 

where YY is the 2-digit year specification.

mkdir 90<invisible control character> 

(Up to this moment, I did not know that I had actually typed one third excess character which was invisible ...!)
Instead of having all in one directory, I wanted to have all 1990s music in one directory. So I typed:

find . -name '* 9?.mp3' -exec mv {} 90 \; 

Not so hard to get the idea what happened eh? :->
The (disastrous) result was a virgin empty directory called '90 something' (with something being the "invisible" control character) and one single file called '90', overwritten n times.

ALL FILES WERE GONE. :-(( (obviously)

Wish mv would've checked in time whether the signature of the destination "file" (remember on *NIX everything is a "file") starts with a d------ (e. g. drwxr-xr-x). And, of course, whether the destination exists at all. There is a variant of the aforementioned scenario, when you simply forgot to mkdir the directory first. (but of course, you assumed that it's there...)

Even our pet-hate OS starting with the capital W DOES DO THIS. You get even prompted to specify the type of destination (file? directory?) if you ask for it.

Hence, I'm wondering if we *NIXers still have to write ourselves a "mv scriptlet" just to avoid these kinds of most unwanted surprises.

edited title
Link
syntaxerror
  • 2.4k
  • 2
  • 31
  • 52

Pass (or add) an option to `mv` How to prevent it`mv` from moving a collection of files into a single regular one?

edited title
Link
syntaxerror
  • 2.4k
  • 2
  • 31
  • 52
Loading
edited title
Link
syntaxerror
  • 2.4k
  • 2
  • 31
  • 52
Loading
Source Link
syntaxerror
  • 2.4k
  • 2
  • 31
  • 52
Loading