Lembre-se de que há mais de uma implementação de mv . O mv que você usa no Linux não é exatamente da mesma fonte que o do OSX ou do Solaris, etc. Mas é desejável que todos eles se comportem da mesma forma - essa é a ponto de padrões . É concebível que uma implementação de mv possa adicionar uma opção para este propósito, embora seja tão simples de lidar, provavelmente não valeria a pena porque o benefício muito menor é influenciado por uma conseqüência negativa mais significativa: Código escrito que explorou tal opção não padrão de uma implementação não seria portável / comportar-se constantemente em outro sistema usando uma implementação padrão.
mv é padronizado pelo POSIX e isso vincula explicitamente seu comportamento ao rename() chamada do sistema . Na ISO C, o comportamento de rename() não é muito específico e muito é deixado para a implementação, mas sob POSIX você notará o potencial ENOENT erro, indicando "um componente do prefixo de caminho de novo não existe ", descrevendo o comportamento esperado em termos explícitos. Isso é melhor do que a ambigüidade e deixar tais detalhes à altura da implementação, porque fazer isso prejudica a portabilidade.
Em defesa do design, em um contexto de script, provavelmente é melhor falhar por padrão em um caminho de destino inválido do que assumir que precisa ser criado. Isso ocorre porque o caminho em si pode frequentemente vir da entrada ou configuração do usuário e pode incluir um erro de digitação; Nesse caso, o script deve falhar nesse ponto e indicar ao usuário que ele digitou um caminho inválido. É claro que há a opção para a pessoa que escreveu o código implementar comportamentos diferentes e criar diretórios que não existem, mas é melhor que você seja responsável por fazer isso do que pelo contrário (sendo responsável por garantir uma chamada mv ). não criará diretórios anteriormente inexistentes).