Le 28 juin 08 à 19:02, KOENIG Yvan a écrit :
> Bonjour
>
> Les composants de la suite iWork omettent de mettre à "busy" la
> propriété des "disk item" nommée busy status.
> Je ne sais pas si les mêmes composants vérifient l'état de cette
> propriété lors d'une tentative d'ouverture d'un document déjà
> ouvert.
> Si celà conduit l'utilisateur B à ouvrir sur un réseau un fichier
> déjà ouvert par l'utilisateur A, le document est perdu.
>
> Le problème a été signalé à Apple mais en attendant je souhaite
> proposer aux utilisateurs un script leur évitant de commettre
> l'irrémédiable.
> Comme "busy status" est "read only" je cherche une autre piste.
> Il semble que lsof soit prometteur mais, ne connaissant rien au
> terminal je ne sais pas comment l'utiliser.
>
> J'en suis à un bête:
>
> set p2d to path to desktop as Unicode text
> set theDoc to p2d & "test chart.numbers:"
>
> set flag to do shell script "lsof +D " & quoted form of POSIX path of
> theDoc
>
> qui échoue sur: "La commande s’est arrêtée avec un état non nul."
>
> Pourriez-vous me donner un coup de main?
>
> Merci d'avance.
lsof renvoit un statut de 1 (!=0 donc erreur) pour la moindre bricole.
En fait presque tout le temps.
C'est un inconvénient ici.
Une piste:
Utiliser <x-man-page://1/true>.
Par "sécurité" on peut rajouter une redirection de stderr sur stdout
(2>&1 avec bash).
...
set fx to quoted form of (get POSIX path of f)
(* directory only *)
set cmd to "2>&1 lsof +c 0 +D " & fx & " || true" (* avoid undesirable
status 1 *)
set r to do shell script cmd
...
On pourrait ainsi tester si r != "".
Donc si r n'est pas "":
- Soit il y a une "vraie" erreur. Vient de la redirection de stderr.
(Mieux vaudrait vérifier avant que f est un dossier valide).
- Soit il existe un ou plusieurs fichiers ouverts dans le dossier.
A+
--
Daniel
_______________________________________________
archives :
http://listes.patpro.net/list/sshfr.fr.html
http://listes.patpro.net/mailman/listinfo/script_shell_fr
