©xm/-Moteur, c'est le script qui
vous intéresse.©xm/-TestConfig (expliqué
plus loin).© Laurent Sebilleau 2001-2002: l.sebilleau@free.fr
Bienvenue !
Tout d'abord une bonne nouvelle: si vous pouvez lire ces lignes, l'installation est terminée. Vous avez quelque part un dossier qui contient ce fichier et un dossier nommé Scripts. Ce dossier Scripts contient:
Dans le dossier Auto:
©xm/-Moteur, c'est le script qui
vous intéresse.©xm/-TestConfig (expliqué
plus loin).Requis: système 8.5.1, Applescript v 1.3.4 (pas testé en dessous) + Compléments standards.
Il est intéressant (mais pas indispensable) de disposer également d'iDo Script Scheduler (pour les exécutions automatiques) et de Folder Action Plus si l'on veut utiliser les scripts de dossier.
Il est certain qu'à un moment ou un autre, le script vous demandera de localiser l'application Stuffit Deluxe. Si vous l'avez, tant mieux, sinon sélectionnez n'importe quelle appli à la place et n'essayez pas de créer des archives.
Il ne vous reste qu'à lire au moins le premier point pour avoir une idée de la manière dont ça fonctionne. Have a lot of fun !
Très souvent, on se retrouve en train de copier ou de déplacer de fichiers, de les renommer en bloc, par exemple pour archiver, sauvegarder, classer les images du jour produites par un scanner. On songe à automatiser ces opérations avec un script, mais si le principe est simple, la réalisation pratique peut demander une certaine mise au point.
L'idée de ce script est donc de fournir un outil rapide et sûr à mettre en œuvre pour automatiser ce genre de traitements avec un minimum de programmation ou même pas du tout. Il prend tout ce qu'il y a dans un dossier, applique les traitements voulus à ces fichiers et dossiers, puis les déplace ailleurs afin qu'ils ne soient pas traités une deuxième fois. Les opérations à réaliser sont définies par l'utilisateur sans toucher au script principal, mais en plaçant dans le dossier cible des items portant des noms spéciaux qui définissent les opérations à réaliser. On peut donc réaliser sa petite usine à partir du Finder, en éditant des noms d'items.
Le script peut être lancé manuellement, automatiquement la nuit, ou encore par l'intermédiaire d'un script de dossier. Enfin, les traitements peuvent être répartis sur plusieurs dossiers successifs: le script prend en charge la totalité de la chaîne de traitement ainsi créée.
Le script prend pour argument un ou plusieurs dossiers de travail dans lequel il trouve à la fois les items à traiter (fichiers ou dossiers) et les instructions à suivre. Le premier travail est donc de constituer ces dossiers. Il y a plusieurs exemples prêts à fonctionner dans le dossier Configs Standard. Je vous suggère de commencer par "Corbeille comptée". A chaque exécution du script, le contenu de ce dossier est rangé dans un sous-dossier qui est numéroté. Lorsque le nombre de sous-dossiers dépasse une limite qu'on peut choisir, le plus ancien est mis à la corbeille (la vraie). Cette installation vous permet par exemple de conserver les x dernières versions d'un travail.
Le dossier contient deux choses:
©pf/ Ce script contient des
compteurs d'exécution propres au dossier. Un dossier de
travail doit toujours contenir une copie de ce script (sinon le
script l'ignore). Donc une copie, un double, pas un alias, sans
quoi le dossier partagera ses compteurs avec un autre et nul ne
peut prédire ce qu'il en adviendra. Une autre
manière de fabriquer un de ces fichiers est de
double-cliquer l'application PrefsEditor.©met/3-Lot n°Pour faire fonctionner, glisser un alias du script
©xm/-Moteur dans le dossier (attention ! pas l'original ni une
copie de l'original), quelques fichiers ordinaires qui traînent
sur votre bureau et double-cliquez l'alias du script "moteur". Le
script vous crée un dossier appelé ®r-Lot n°
1, un fichier .Historique.log dans le dossier de travail et un autre
.Historique.log dans le dossier Auto. Vous pouvez les consulter avec
SimpleText.
Si vous répétez l'opération, (ajouter des
items dans le dossier "Corbeille comptée", double-clic sur
l'alias "Moteur"), un deuxième dossier ®r-Lot n° 2
est créé, puis un troisième. Lors du
quatrième essai, le premier dossier passe à la
corbeille (j'espère que vos fichiers n'étaient pas
importants, mais rassurez-vous, le script ne vide JAMAIS la
corbeille), de manière à ce que seuls les trois plus
récents soient conservés. Comme vous l'avez sans doute
déjà compris, les paramètres de
l'opération se trouvent dans le nom de l'item de commande:
©met/3-Lot
n°
"©pf/).Vous pouvez agémenter cet essai en
ajoutant dans le dossier de travail une instruction de copie. Pour ce
faire, choisissez un dossier de destination où seront
placées les copies. Vous pouvez en créer un où
vous voulez ou en choisir un existant. Si ce dossier de destination
ne se trouve pas dans le dossier de travail (c'est le plus
fréquent), faites glisser un alias de ce dossier dans le
dossier de travail. Dans tous les cas (dossier ou alias) renommez cet
item suivant la convention en lui donnant un nom qui commence par
©c/- (n'oubliez pas l'espace avant , et mettez ce qui vous
chante après le tiret). Vous pouvez aussi directement copier
le nom du dossier ©c/-Copies qui se trouve en
Référence. L'important est le nom de l'item se trouvant
dans le dossier de travail, pas celui de la destination réelle
qui est ignoré. Maintenant, le traitement des fichiers
contenus dans votre dossier de travail comportera deux étapes:
les copier dans la destination choisie, puis les placer dan un
dossier numéroté comme avant. On peut ainsi constituer
des traitements plus complexes: à chaque nouvelle
opération, on ajoute un item dans le dossier de travail et on
lui donne un nom qui spécifie à la fois
l'opération voulue et ses paramètres quand il y en
a.
Les opérations standard que le script est capable d'effectuer sont des créations d'alias, des copies, des archives et de déplacements. Ces déplacements (indispensables si l'on ne veut pas que les fichiers soient traités plusieurs fois) peuvent être associés à un "emballage" dans un dossier nommé automatiquement et dans ce cas, le déplacement peut être différé, soit sur la base d'un compteur comme dans l'exemple que nous avons étudié, soit par un calcul de date. Enfin, pour permettre la réalisation d'opérations spéciales, il est capable d'exécuter des petits scripts compilés au milieu de ses opérations. On peut ainsi lui ajouter des fonctionnalités avec un minimum de programmation.
Lorsqu'il existe dans le dossier de travail
des dossiers de destination (ou leurs alias), le script les explore
tous pour voir s'il s'agit aussi de dossiers de travail (s'ils
contiennent aussi un script ©pf/ )
et dans ce cas, exécute aussi les travaux demandés dans
ces dossiers. Autrement dit, on peut répartir les
opérations que l'on ne pourrait pas réaliser dans un
seul dossier de travail en plusieurs dossiers successifs et
même organiser des traitements complexes en forme
d'arborescence avec des boucles, etc ... Le script TestConfig permet
de tester l'exécution de ces enchaînements (il
n'effectue aucune opération: il parcourt simplement
l'enchaînement des dossiers et les liste dans l'historique
général)
Vous avez remarqué que le script crée automatiquement des historiques: un historique général dans le dossier Auto, et un historique particulier à chaque dossier. Si seule la chronologie des fichiers entrés vous intéresse (par exemple pour créer une liste des messages ou des fax arrivés), vous pouvez simplement demander le déplacement de ces fichiers sans aucun traitement.
Nous allons maintenant décrire en détail le fonctionnement du script. Mais vous pouvez aussi faire fonctionner les exemples fournis et les modifier. Le commentaire de chaque item décrit son effet, et vous pouvez simplement les copier dans le dossier de travail que vous configurez. Vous n'aurez besoin du reste que si vous vous lancez dans des opérations plus complexes ou comprendre un fonctionnement inattendu.
Créez le ou choisissez-en un. Ce
dossier est celui où vous placerez les items à traiter.
Ceci fait, placez y dans tous les cas un script ©pf/. Pour en
créer un nouveau, vous pouvez lancez PrefsEditor.
Si vous souhaitez les placer d'abord dans un
dossier créé automatiquement, copiez dans le dossier le
fichier ©men/-Lot n° . Remplacez "Lot n°" par
n'importe quel intitulé à votre convenance. Dans la
suite, les traitements seront appliqués à ce
dossier.
Les traitements courants sont les copies, les créations d'archives (si vous disposez de Stuffit Deluxe), et la création d'alias. On peut y ajouter le renommage des fichiers par scripts additionnels (La liste complète des commandes est disponible plus loin).
Dans la plupart des cas, vous devrez créer ou choisir un dossier de destination dans lequel les archives, copies et alias seront placés. Ceci étant fait, placez un alias de ce dossier dans le dossier de travail. Puis modifiez le nom de cet alias pour lui donner le nom de l'opération voulue. Le plus simple est d'aller pêcher le nom approprié dans le dossier "Commandes:2-Traitements". Vous n'avez pas à modifier le nom du dossier original, seul le nom de l'alias placé dans le dossier de travail compte.
Dans la plupart des cas, vous voudrez les
mettre à l'abri des exécutions ultérireures dans
un autre dossier. Choisissez ou créez le, placez un alias dans
le dossier de travail. Donnez à l'alias un nom
commençant par ©m/- (sortie en vrac ou tel que),
à moins que vous ne vous vouliez vous lancer dans des options
plus complexes.
Faites glisser dans le dossier de travail un
alias du script application ©xm/-Moteur (il se trouve dans le
dossier "Scripts:Auto". Placez-y quelques fichiers d'essai.
Double-cliquez cet alias et observez le résultat. Consultez
l'historique. Si une erreur s'est produite, un dossier .erreurs
apparaîtra: il contient un historique des erreurs et les
fichiers qui ont créé l'erreur.
Si le fonctionnement manuel décrit
ci-dessus ne vous convient pas, vous pouvez choisir une autre
solution. Dans ce cas, l'alias ©xm/-Moteur que nous avons
placé dans le dossier de travail devient inutile: supprimez
le.
Glissez déposez le dossier de travail
sur l'application ©xm/-Moteur ou l'un de ses alias.
Associez au dossier de travail le script
LSBRun (n'essayez pas directement ©xm/-Moteur, il est trop gros
pour fonctionner correctement). Dans ce cas, placer des items dans le
dossier déclenchera automatiquement
l'exécution.
Si vous souhaitez que le script soit lancé même quand le dossier de travail est fermé, installez Folder Action Plus.
Faites glisser un alias de votre dossier de
travail dans le dossier Auto. Tout les dossiers qui s'y trouvent
(alias ou originaux) seront considérés comme des
dossiers de travail qu'il faut traiter. Lancez l'application
©xm/-Moteur par le moyen automatique que vous
préférez. Une solution basée sur iDo Script
Scheduler est fournie avec le package.
Sur chaque dossier de travail, le script exécute les opérations dans l'ordre suivants:
sont placés dans une liste (targ_list), sauf dans
le cas où il s'agit d'une action de dossier suite à
un ajout d'items dans un dossier de travail. Dans ce cas la liste
d'items à traiter est celle fournie par l'appel au script
de dossier. C'est à cette liste que seront
appliquées les opérations qui suivent.©xa/ (ordre alphabétique) en leur
passant la targ_list. Ceux-ci renvoient la targ_list (ils peuvent
donc la modifier: filtrage, résolution d'alias, etc…)
Ils peuvent également créer une liste annexe qui
sera déplacée en fin de script.©xp/ (ordre alphabétique).
Même remarque sur la targ_list que pour les autres
scripts.©pf/) il
reprend la liste de tous les dossiers de destination
spécifiés dans toutes les commandes et les ajoute en
tête de sa liste de dossiers de travail à traiter
(cette liste se comporte comme une pile, donc le parcours de
l'arborescence des dossiers de travail enchâinés se
fait en profondeur d'abord).Notez que la plupart des opérations mentionnées
ci-dessus sont optionnelles. A la limite, si le dossier de travail ne
contient que le script ©pf/, le script emballe les items dans
des dossiers numérotés qui restent indéfiniment
sur place.
Notez également qu'un certain nombre d'opérations peuvent être enchaînées dans un seul dossier. Il est simplement impossible de déplacer les items en plusieurs endroits à la fois (ce serait une duplication). Certaines configurations peuvent cependant être impossibles à mettre en place dans un seul dossier parceque l'ordre des opérations est incompatible. Pensez que vous n'êtes pas limités à un seul dossier et que vous pouvez répartir le travail entre plusieurs dossiers successifs.
Le tableau ci-dessous donne la liste des commandes définies. Elles sont toutes inscrites dans le nom d'un item du dossier de travail qui est appelé ici support. Les guillemets ne font pas partie de ces noms. Le type du support est soit quelconque (on peut utiliser ce que l'on veut , fichier, dossier ou alias, à condition qu'on puisse le nommer) soit un dossier ou son alias lorsqu'une destination est nécessaire.
Les commandes commencent toutes par espace©. Suit un code
désignant la commande se terminant par un "/", ensuite vient
un paramètre numérique dans certaines commandes
seulement (nombre de jours ou nombre de lots). Enfin on trouve un
tiret. Au delà de ce tiret commence la partie éditable
par l'utilisateur. Deux cas se produisent: cette partie peut
être utilisée comme base pour créer des noms de
dossiers automatiquement. Par exemple, un item nommé "
©men/-Images " va provoquer la création de dossiers
nommés "Images 1", "Images 2", etc…
Dans ce cas, cette partie est représentée par le mot "racine" dans la table ci-dessous.
Au contraire, le mot "Ignoré" signifie que cette partie n'est pas utilisée. On peut donc y mettre ce que l'on veut ou même rien du tout.
Sortie en vrac signale que les items sont déversés un par un dans la destination. S'ils étaient dans un dossier provisoire de stockage, ce dossier est détruit. Inversement, sortie empaquetée signifie que les items transférés sont réunis dans un dossier avant le déplacement. S'ils sont déjà dans un dossier d'attente, le dossier est simplement renommé, puis déplacé.
| Nom du support | Type du support | Fonction |
| Opérations | ||
|
" ©men/-racine"
|
quelconque | empaquetage préalable: les items sont rangés dans un dossier avant opérations |
|
" ©a/-ignoré"
|
Dossier ou alias de dossier | créer des alias |
|
" ©c/-ignoré"
|
Dossier ou alias de dossier | créer des copies |
|
" ®arc/-ignoré"
|
Dossier ou alias de dossier | créer des archives |
| Déplacements | ||
|
" ©m/-ignoré"
|
Dossier ou alias de dossier | sortie en vrac vers un autre dossier |
|
" ©mp/-racine"
|
Dossier ou alias de dossier | sortie en paquet vers un autre dossier, le reste du nom donne le préfixe du nom à créer |
|
" ©mt/-ignoré"
|
quelconque | Suppression |
|
" ©f/-ignoré"
|
Dossier ou alias de dossier | Déplacement en vrac de la liste annexe (celle-ci est créée par les scripts additionnels) |
| Déplacements comptés | Les items sont stockés localement (un dossier par exécution) puis déplacés lorsque le nombre de ces dossiers dépasse la limite fixée. | |
|
" ©mec/x-racine"
|
Dossier ou alias de dossier | empaquetage préalable, et déplacement quand le nombre de dossiers > x |
|
" ©met/x-racine"
|
quelconque | empaquetage préalable, comme ci-dessus, déplacement vers la corbeille |
| Déplacements datés |
Les items sont stockés localement (un dossier
par jour) puis déplacés lorsque la date de
ces dossiers est plus ancienne que date d'aujourd'hui -
limite. (N.B. Cette accumulation peut créer des conflits de noms, penser à utiliser un script de renommage) |
|
|
" ©md/x-ignoré"
|
Dossier ou alias de dossier | sortie en vrac vers un autre dossier après délai x (spécifié en jours) |
|
" ©mdp/x-racine"
|
Dossier ou alias de dossier | idem,mais empaqueté dans un dossier |
|
" ©mdt/x-ignoré"
|
quelconque | suppression après délai comme ci-dessus |
|
" ©mds/x-racine"
|
Dossier ou alias de dossier | Stock cumulé, les items sont stockés localement dans un dossier numéroté. Celui-ci est déplacé tous les x jours. |
|
Exécutables " ©x"
|
||
|
" ©xa/-racine"
|
Script compilé | scripts additionnels avant opérations (racine est passé en paramètre) |
|
" ©xm/-"
|
Application | réservé |
|
" ©xp/-racine"
|
Script compilé | scripts additionnels après opérations et avant déplacements |
|
" ©xm/-Ignoré"
|
Dossier ou alias de dossier | N'effectue aucune opération, mais assure la propagation de l'exécution au dossier spécifié. |
| Dossiers de stockage | ||
|
" ®r-"
|
dossier | Stocks provisoires pour les déplacements comptés |
|
" ®l-"
|
dossier | Stocks pour les items dont la destination n'a pas été fixée. |
|
" ®q-"
|
dossier | Stocks provisoires pour les déplacements datés |
|
" ®s-"
|
dossier | Dossiers d'accumulation |
| Divers | ||
|
" .log.Historique"
|
Fichier texte | fichiers logs |
|
" .err.log"
|
Fichier texte | fichiers errors logs |
|
" .erreurs"
|
Dossier | identifie le dossier d'erreurs |
|
" ©hist/"
|
quelconque | Historique détaillé |
N.B. Pour d'autres fonctions courantes, consulter la bibliothèque de scripts additionnels.
On peut naturellement dupliquer le script "Moteur" autant qu'on veut, mais ce n'est ni nécessaire ni recommandé si on ne sait pas exactement ce que l'on fait. Il vaut mieux avoir compris avant les différentes options de lancement.
Le réglage précis de la propagation
d'exécution se fait dossier par dossier en positionnant des
valeurs booléennes. On peut le faire directement en
éditant le script ©pf/ du dossier avec un éditeur
de script, mais on remet aussi les compteurs à zéro ce
qui est gênant. C'est la raison pour laquelle j'ai prévu
une petite appli PrefsEditor qui permet de faire les réglages
sans modifier les compteurs. Si on la lance, elle permet de
créer un nouveau fichier ©pf/. Si l'on fait glisser un
©pf/ existant dessus, elle permet de l'éditer.
Les scripts additionnels ont évidemment pour but d'ajouter des fonctionnalités que le script principal ne peut incorporer ne serait-ce que pour des raisons de dimensions. Ils permettent également de personnaliser également des fonctions sans avoir à les insérer au petit bonheur dans un programme complexe.Vous trouverez un modèle de script de ce genre et un certain nombre d'exemples d'usage courant qui peuvent être utilisés tels quels (les copier ou les aliaser dans le dossier de travail). Ils peuvent être appelés à deux moments différents de l'exécution, mais la forme d'appel reste la même.
Vous constaterez également qu'il est facile d'adapter un grand nombre de scripts d'exemple fournis avec des logiciels ou provenant de bibliothèques Applescript pour les incorporer à vos chaînes de traitement (le plus souvent, il suffit de copier/coller leur handler "open" dans un squelette de script additionnel et d'adapter les noms de paramètres).
Le script principal leur passe un certain nombre de paramètres utiles:
En outre, le script principal donne accès à quelques services utiles dont la syntaxe est montrée dans le script d'exemple. En particulier:
©pf/)@.©f/- doit être spécifié pour que cela
fonctionne.Il y a un historique général dans lequel est enregistrée la liste des dossiers effectivement traités à chaque exécution et les erreurs imprévues (ou plutôt non gérées par le script: un disque plein par exemple). Cet historique est créé dans le même dossier que le script principal.
Il y a un historique particulier à chaque dossier de
travail que l'on peut ou non activer. Il liste le détail des
opérations traitées. Si vous rajoutez dans le dossier
de travail un item nommé ©hist/, le script listera
entièrement la targ_list à plusieurs étapes de
l'exécution, en particulier avant et après l'appel des
scripts additionnels. Ceci permet de comprendre plus facilement des
comportement inattendus ou de repérer des erreurs.
Il existe enfin un historique des erreurs particulier à
chaque dossier. Il n'est créé qu'en cas de besoin dans
un dossier spécial nommé .erreurs où le script
déplace également les items qui ont causé
l'erreur. Supposez que vous ayez demandé le déplacement
vers un dossier où se trouvent déjà des items de
même nom. Le script crée alors un dossier
numéroté pour y déplacer les items qu'il ne peut
déplacer dans la destination prévue afin que l'erreur
ne se reproduise pas.
En principe, les erreurs sont captées partout, si bien que vous ne devriez jamais retrouver le matin une fenêtre de dialogue à la noix signalant que tout s'est arrêté (dès le début de préférence) parcequ'une erreur bizarroïde est survenue.
La personnalisation du script principal est possible en
particulier le choix du préfixe discriminant les items
à traiter des items de commande (si space ne plaît pas)
et l'intitulé des différents messages à passer
dans les historiques. Tout se trouve en début du script. Comme
il n'y a pas de macros, j'utilise des properties. La modification des
messages peut se faire sans précaution particulière,
par contre celle des préfixes réclame un peu plus
d'attention.
La première chose à faire est de recopier cette liste de préfixes modifiés dans le script TestConfig pour qu'il continue à fonctionner (j'aurais pu les déclarer dans un script commun chargé par tous les deux au démarrage, mais je ne veux pas trop pénaliser les temps d'exécution).
La deuxième précaution à prendre est de choisir un bon ensemble de délimiteurs: il ne faut pas prendre deux fois le même caractère pour définir les propriétés suivantes:
" -- le préfixe de nom de
fichiers servant à distinguer les cibles et les fichiers
orgcar le script analyse les préfixes en recherchant uniquement la première occurence du délimiteur. Si par exemple vous redéfinissez:
vous aurez des ennuis.
Vous pouvez anturellement éditer et modifier le code principal, même si l'objectif principal du script était de vous éviter cette tâche. Certains algorithmes ou tournures pourront vous paraître maladroits ou inutilement complexes, mais (au moins dans certains cas), il s'agit d'éviter des bugs plus ou moins connus du Finder qui se produisent lorsqu'on liste un dossier qui ne contient qu'un seul item. Comme il y a plusieurs erreurs différentes, j'appelle ça la malédiction du solitaire. Si vous réécrivez ce code, prenez soin de vous assurer qu'il marche lorsqu'il n'existe qu'un seul item à traiter.
Les alias posent un problème assez compliqué: faut-il les résoudre ou non ? Comme il m'a paru impossible de trouver une solution automatique dans tous les cas, j'ai préféré mettre en œuvre une règle simple:
Ceci veut dire que si vous déplacez un alias dans un dossier de travail où se trouve une instruction de copie, il y aura un alias dans le dossier de destination. Si vous voulez copier l'original, ajoutez le script additionnel qui résoudra les alias avant la copie (en détruisant l'alias). Dans ce cas précis, lorsque vous souhaitez faire des résolutions d'alias au vol, il vaut certainement mieux mettre en place des chaînes de traitement ne comportant que des alias et non un mélange d'alias et de fichiers (utilisez ou crééz un filtre: voir le script additionnel Filtredossier). Le script n'aura aucune difficulté à traiter le mélange tant qu'il n'y a pas d'erreur, mais s'il est amené à déplacer des items responsables d'erreur, il peut se produire des comportements inattendus. Il convient d'ajouter que les alias que vous glissez-déposez sur une appli sont TOUJOURS résolus par le Finder avant de les passer à l'appli. Le fichier alias proprement dit est impossible à trouver, car il n'existe pas de fonction permettant de remonter d'un item vers ses alias.
Ceci veut dire également que les dossiers de destination peuvent être placés dans le dossier de travail ou en dehors et remplacés par un alias. Le script fonctionnera de la même manière dans les deux cas.
En principe, comme on l'a vu, le script ne se contente pas de traiter le dossier de travail initial qu'on lui a passé lors du lancement, mais il explore également les dossiers de destination spécifiés dans les commandes pour traiter également leur contenu. Ce comportement peut être cependant modifié dossier par dossier selon les besoins. L'application PrefsEditor permet de le faire sans modifier la valeur actuelle des compteurs.
Signalons tout de suite qu'il n'est pas nécessaire de se préoccupper d'éviter les boucles sans fin, dans le cas où une chaîne de traitement n'a pas de fin mais retombe sur le dossier d'entrée. Un mécanisme de signatures permet de les éviter dans tous les cas de figure.
La propagation de l'exécution est conditionnée par
deux drapeaux, prop_flag et seek_flag qui sont des properties du
script ©pf/ qui figure dans chaque dossier. Leur utilisation a
été décrite plus haut.
Il reste à signaler qu'on peut demander la propagation
d'exécution dans un autre dossier, sans pourtant
définir de commande associée à ce dossier. Il
suffit de créer un alias de ce dossier dans le dossier de
travail et de lui donner un nom commençant par ©xm/-
Il est également possible de lancer une application par le même moyen.