Existe-t-il un moyen de faire échouer «mv» en silence?

Une commande telle que mv foo* ~/bar/produit ce message dans stderr si aucun fichier ne correspond foo*.

mv: cannot stat `foo*': No such file or directory

Cependant, dans le scénario sur lequel je travaille, tout irait bien, et j'aimerais supprimer ce message de nos journaux.

Y a-t-il un bon moyen de dire mvde rester silencieux même si rien n'a été déplacé?

Vous cherchez cela?

$ mv  file dir/
mv: cannot stat ‘file’: No such file or directory
$ mv  file dir/ 2>/dev/null
# <---- Silent ----->

En fait, je ne pense pas que la mise en sourdine mvsoit une bonne approche (rappelez-vous que cela pourrait aussi vous rapporter d'autres choses qui pourraient être intéressantes ... par exemple manquantes ~/bar). Vous souhaitez le désactiver uniquement si votre expression globale ne renvoie pas de résultats. En fait plutôt ne pas l'exécuter du tout.

[ -n "$(shopt -s nullglob; echo foo*)" ] && mv foo* ~/bar/

Ne semble pas très attrayant, et ne fonctionne que dans bash.

OU

[ 'foo*' = "$(echo foo*)" ] || mv foo* ~/bar/

sauf que vous êtes bashavec nullglobensemble. Vous payez un prix de 3 fois la répétition du motif glob.

find . -maxdepth 1 -name 'foo*' -type f -print0 | xargs -0r mv -t ~/bar/

- GNU mva une belle option "destination en premier" ( -t) et xargspeut ignorer l'exécution de sa commande s'il n'y a aucune entrée ( -r). L' utilisation de -print0et -0fait en conséquence assurer qu'il n'y aurait pas un gâchis lorsque les noms de fichiers contiennent des espaces et d' autres choses « drôle ».

Il est important de réaliser que c'est en fait le shell qui étend foo*la liste des noms de fichiers correspondants, de sorte que rien ne mvpourrait se faire.

Le problème ici est que, lorsqu'un glob ne correspond pas, certains shell ressemblent bash(et la plupart des autres shell Bourne-like, ce comportement buggy a été introduit par le shell Bourne à la fin des années 70) et transmet le motif à la commande.

Donc ici, quand foo*ne correspond à aucun fichier, au lieu d'abandonner la commande (comme le font les shells pre-Bourne et plusieurs shells modernes), le shell passe un foo*fichier in extenso à mv, demandant donc mvde déplacer le fichier appelé foo*.

Ce fichier n'existe pas. Si c'était le cas, il aurait correspondu au modèle, mvsignale donc une erreur. Si le motif avait été à la foo[xy]place, vous mvauriez pu déplacer accidentellement un fichier appelé à la foo[xy]place des fichiers fooxet fooy.

Maintenant, même dans les obus qui n'ont pas ce problème (pré-Bourne, csh, tcsh, poisson, zsh, bash -O failglob), vous obtiendrez toujours une erreur mv foo* ~/bar, mais cette fois par l'obus.

Si vous voulez considérer que ce n'est pas une erreur s'il n'y a pas de correspondance de fichier foo*et dans ce cas, ne déplacez rien, vous voudriez créer d'abord la liste des fichiers (d'une manière qui ne provoque pas d'erreur, comme en utilisant l' nullgloboption de certains shells), et alors seulement appeler si mvla liste est non vide.

Ce serait mieux que de cacher toutes les erreurs de mv(comme l'ajoutant 2> /dev/null) comme si cela mvéchouait pour une autre raison, vous voudriez probablement encore savoir pourquoi.

en zsh

files=(foo*(N)) # where the N glob qualifier activates nullglob for that glob
(($#files == 0)) || mv -- $files ~/bar/

Ou utilisez une fonction anonyme pour éviter d'utiliser une variable temporaire:

() { (($# == 0)) || mv -- "$@" ~/bar/; } foo*(N)

zshest un de ces shells qui n’a pas le bogue Bourne et rapporte une erreur sans exécuter la commande quand un glob ne correspond pas (et que l’ nullgloboption n’a pas été activée), alors ici, vous pouvez masquer zshl’erreur et restaurer stderr pendant mvsi vous voyez toujours les mverreurs s'il y en a, mais pas l'erreur concernant les globs non correspondants:

(mv 2>&3 foo* ~/bar/) 3>&2 2>&-

Ou vous pourriez utiliser zargsce qui éviterait également les problèmes si le foo*glob devenait trop volumineux.

autoload zargs # best in ~/.zshrc
zargs -r -- foo* -- mv -t ~/bar # here assuming GNU mv for its -t option

En ksh93:

files=(~(N)foo*)
((${#files[#]} == 0)) || mv -- "${files[@]}" ~/bar/

En bash:

bashn'a pas de syntaxe à activer nullglobpour un seul glob, et l' failgloboption est annulée nullglob, vous aurez donc besoin d'éléments comme:

saved=$(shopt -p nullglob failglob) || true
shopt -s nullglob
shopt -u failglob
files=(foo*)
((${#files[@]} == 0)) || mv -- "${files[@]}" ~/bar/
eval "$saved"

ou définissez les options dans un sous-shell pour enregistrer devez les enregistrer avant et les restaurer ensuite.

(
  shopt -s nullglob
  shopt -u failglob
  files=(foo*)
  ((${#files[@]} == 0)) || mv -- "${files[@]}" ~/bar/
)

Dans yash

(
  set -o nullglob
  files=(foo*)
  [ "${#files[@]}" -eq 0 ] || mv -- "${files[@]}" ~/bar/
)

Dans fish

Dans la coquille de poisson, le comportement nullglob est le comportement par défaut de la setcommande, il s'agit donc simplement de:

set files foo*
count $files > /dev/null; and mv -- $files ~/bar/

POSIXly

Il n'y a aucune nullgloboption dans POSIX shet aucun tableau autre que les paramètres de position. Il existe une astuce que vous pouvez utiliser pour détecter si un glob correspond ou non:

set -- foo[*] foo*
if [ "$1$2" != 'foo[*]foo*' ]; then
  shift
  mv -- "$@" ~/bar/
fi

En utilisant a foo[*]et foo*glob, nous pouvons différencier le cas où il n'y a pas de fichier correspondant à celui où il y a un fichier appelé foo*(ce qui set -- foo*n'a pas pu être fait).

Plus de lecture:

• Pourquoi nullglob n'est-il pas par défaut?
• cette discussion connexe sur la liste de diffusion du groupe Austin (le groupe Austin est l'organe qui gère la spécification POSIX)

Ce n'est probablement pas le meilleur, mais vous pouvez utiliser la findcommande pour vérifier si le dossier est vide ou non:

find "foo*" -type f -exec mv {} ~/bar/ \;

Je suppose que vous utilisez bash, car cette erreur dépend du comportement de bash pour développer des globs sans correspondance entre eux. (En comparaison, zsh génère une erreur lorsqu’on tente de développer un glob sans correspondance.)

Alors, qu'en est-il de la solution de contournement suivante?

ls -d foo* >/dev/null 2>&1 && mv foo* ~/bar/

Cela ignorera silencieusement le mvsi ls -d foo*échoue, tout en enregistrant les erreurs si ls foo*réussit mais mvéchoue. (Attention, ls foo*peut échouer pour des raisons autres foo*qu'existantes, par exemple des droits insuffisants, un problème lié au service fixe, etc., de sorte que de telles conditions seraient ignorées en silence par cette solution.)

Vous pouvez faire par exemple

mv 1>/dev/null 2>&1 foo* ~/bar/ ou mv foo* ~/bar/ 1&>2

Pour plus de détails, voir: http://mywiki.wooledge.org/BashFAQ/055

Vous pouvez tricher (portable) avec perl:

perl -e 'system "mv foo* ~/bar/" if glob "foo*"'

Si vous utilisez Perl, vous pouvez aussi bien aller jusqu'au bout:

#!/usr/bin/perl
use strict;
use warnings;
use File::Copy;

my $target = "$ENV{HOME}/bar/";

foreach my $file (<foo*>) {
    move $file, $target  or warn "Error moving $file to $target: $!\n";
}

ou comme one-liner:

perl -MFile::Copy -E 'move $_, "$ENV{HOME}/bar/" or warn "$_: $!\n" for <foo*>'

(Pour plus de détails sur la movecommande, consultez la documentation de File :: Copy .)

Au lieu

mv foo* ~/bar/

tu peux faire

cp foo* ~/bar/
rm foo* 

Simple, lisible :)

mv foo* ~/bar/ 2>/dev/null

Si la commande précédente est réussie ou non, nous pouvons trouver le statut de sortie de la commande précédente

command: echo $?

si sortie de echo $? est différent de 0 signifie que la commande est non fructueuse si la sortie est 0, cela signifie que la commande est réussie