Le 20/05/08 21:28, dans <g0v8pg$qtu$00$, « Olivier Croquette » a écrit :
JiPaul wrote, On 20/05/08 19:54:
C'est pas aussi facile que de remplacer les : par des /, il faut aussi mettre /Volumes devant le cas échéant, et comme je viens de l'apprendre, remplacer les / par des : aussi (cf message de Laurent).
Je te laisse rajouter les autres exceptions... :-) (sauf si tu as besoin d'aide... ;-)
Je le répète: la difficulté réside justement dans les exceptions. Un script sed aussi complexe soit-il sera peut-être rapide, mais certainement bourré d'erreurs dûes aux cas particuliers, qu'à l'opposé Apple prend en compte dans "POSIX path of ...".
Oui. Les cas particuliers sont toujours longs à traiter car longs à trouver. Comme par exemple un blanc dans un nom ne marche pas avec le script du dessus.
Certes je trouve la solution osascript trop lente, mais je ne suis pas prêt à sacrifier la justesse des résultats pour la rapidité...
Sûr.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 20/05/08 21:28, dans <g0v8pg$qtu$00$1@news.t-online.com>, « Olivier
Croquette » <ocroquette@ocroquette.free.fr> a écrit :
JiPaul wrote, On 20/05/08 19:54:
C'est pas aussi facile que de remplacer les : par des /, il faut aussi
mettre /Volumes devant le cas échéant, et comme je viens de l'apprendre,
remplacer les / par des : aussi (cf message de Laurent).
Je te laisse rajouter les autres exceptions... :-) (sauf si tu as besoin
d'aide... ;-)
Je le répète: la difficulté réside justement dans les exceptions. Un
script sed aussi complexe soit-il sera peut-être rapide, mais
certainement bourré d'erreurs dûes aux cas particuliers, qu'à l'opposé
Apple prend en compte dans "POSIX path of ...".
Oui. Les cas particuliers sont toujours longs à traiter car longs à trouver.
Comme par exemple un blanc dans un nom ne marche pas avec le script du
dessus.
Certes je trouve la solution osascript trop lente, mais je ne suis pas
prêt à sacrifier la justesse des résultats pour la rapidité...
Sûr.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 20/05/08 21:28, dans <g0v8pg$qtu$00$, « Olivier Croquette » a écrit :
JiPaul wrote, On 20/05/08 19:54:
C'est pas aussi facile que de remplacer les : par des /, il faut aussi mettre /Volumes devant le cas échéant, et comme je viens de l'apprendre, remplacer les / par des : aussi (cf message de Laurent).
Je te laisse rajouter les autres exceptions... :-) (sauf si tu as besoin d'aide... ;-)
Je le répète: la difficulté réside justement dans les exceptions. Un script sed aussi complexe soit-il sera peut-être rapide, mais certainement bourré d'erreurs dûes aux cas particuliers, qu'à l'opposé Apple prend en compte dans "POSIX path of ...".
Oui. Les cas particuliers sont toujours longs à traiter car longs à trouver. Comme par exemple un blanc dans un nom ne marche pas avec le script du dessus.
Certes je trouve la solution osascript trop lente, mais je ne suis pas prêt à sacrifier la justesse des résultats pour la rapidité...
Sûr.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Patrick Stadelmann
In article <C458F971.CDA61%, Eric Levenez wrote:
Oui. Les cas particuliers sont toujours longs à traiter car longs à trouver. Comme par exemple un blanc dans un nom ne marche pas avec le script du dessus.
Sans compter qu'un volume n'est pas forcément monté dans /Volumes...
Si le passage par osascript est trop lent, il faut trouver ou écrire un programme qui fait ça en natif. Il me semble qu'il y avait une routine pour faire cela dans MoreFilesX (sample code d'Apple pour utiliser le File Manager, basé sur Carbon donc un peu dépassé).
Sinon CFURL à l'air de supporter les deux types de chemin, donc je regarderais de ce côté là.
Patrick -- Patrick Stadelmann
In article <C458F971.CDA61%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> wrote:
Oui. Les cas particuliers sont toujours longs à traiter car longs à trouver.
Comme par exemple un blanc dans un nom ne marche pas avec le script du
dessus.
Sans compter qu'un volume n'est pas forcément monté dans /Volumes...
Si le passage par osascript est trop lent, il faut trouver ou écrire un
programme qui fait ça en natif. Il me semble qu'il y avait une routine
pour faire cela dans MoreFilesX (sample code d'Apple pour utiliser le
File Manager, basé sur Carbon donc un peu dépassé).
Sinon CFURL à l'air de supporter les deux types de chemin, donc je
regarderais de ce côté là.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Oui. Les cas particuliers sont toujours longs à traiter car longs à trouver. Comme par exemple un blanc dans un nom ne marche pas avec le script du dessus.
Sans compter qu'un volume n'est pas forcément monté dans /Volumes...
Si le passage par osascript est trop lent, il faut trouver ou écrire un programme qui fait ça en natif. Il me semble qu'il y avait une routine pour faire cela dans MoreFilesX (sample code d'Apple pour utiliser le File Manager, basé sur Carbon donc un peu dépassé).
Sinon CFURL à l'air de supporter les deux types de chemin, donc je regarderais de ce côté là.
Patrick -- Patrick Stadelmann
Olivier Croquette
Laurent Pertois wrote, On 19/05/08 15:16:
Par contre, tu peux mettre des "/" qui seront alors vu, dans ton shell, comme des ":". De même, en ligne de commande, tu peux écrire des ":" qui seront vus, dans le Finder, comme des "/".
C'est marrant (si on peut dire), je viens de comprendre avec cette discussion un problème que j'avais eu il y a longtemps. J'utilise duplicity, un logiciel de sauvegarde Unix sur la ligne de commande. Les archives de ce dernier ont des noms de la forme:
Voilà une illustration du problème lorsqu'on tente de créer de tels fichiers sur un lecteur réseau (un NAS) monté via samba:
$ touch duplicity-full.2005-03-05T19:40:45-07:00.vol9.difftar.gz touch: duplicity-full.2005-03-05T19:40:45-07:00.vol9.difftar.gz: File name too long
Je remplace les ":" du nom par des "-":
$ touch duplicity-full.2005-03-05T19-40-45-07-00.vol9.difftar.gz $ ls duplicity-full.2005-03-05T19-40-45-07-00.vol9.difftar.gz duplicity-full.2005-03-05T19-40-45-07-00.vol9.difftar.gz
Donc ce sont bien les 2 points qui posent problème. Je me demande s'il y a une solution. En tout cas, le message d'erreur n'est pas très explicite.
NB: pour ce qui est de duplicity, j'utilise l'option --short-filenames qui utilise des noms plus courts et ne contenant pas ":", pour contourner ce problème.
Laurent Pertois wrote, On 19/05/08 15:16:
Par contre, tu peux mettre des "/" qui seront alors vu, dans ton shell,
comme des ":". De même, en ligne de commande, tu peux écrire des ":" qui
seront vus, dans le Finder, comme des "/".
C'est marrant (si on peut dire), je viens de comprendre avec cette
discussion un problème que j'avais eu il y a longtemps.
J'utilise duplicity, un logiciel de sauvegarde Unix sur la ligne de
commande. Les archives de ce dernier ont des noms de la forme:
Voilà une illustration du problème lorsqu'on tente de créer de tels
fichiers sur un lecteur réseau (un NAS) monté via samba:
$ touch duplicity-full.2005-03-05T19:40:45-07:00.vol9.difftar.gz
touch: duplicity-full.2005-03-05T19:40:45-07:00.vol9.difftar.gz: File
name too long
Je remplace les ":" du nom par des "-":
$ touch duplicity-full.2005-03-05T19-40-45-07-00.vol9.difftar.gz
$ ls duplicity-full.2005-03-05T19-40-45-07-00.vol9.difftar.gz
duplicity-full.2005-03-05T19-40-45-07-00.vol9.difftar.gz
Donc ce sont bien les 2 points qui posent problème.
Je me demande s'il y a une solution.
En tout cas, le message d'erreur n'est pas très explicite.
NB: pour ce qui est de duplicity, j'utilise l'option --short-filenames
qui utilise des noms plus courts et ne contenant pas ":", pour
contourner ce problème.
Par contre, tu peux mettre des "/" qui seront alors vu, dans ton shell, comme des ":". De même, en ligne de commande, tu peux écrire des ":" qui seront vus, dans le Finder, comme des "/".
C'est marrant (si on peut dire), je viens de comprendre avec cette discussion un problème que j'avais eu il y a longtemps. J'utilise duplicity, un logiciel de sauvegarde Unix sur la ligne de commande. Les archives de ce dernier ont des noms de la forme:
Voilà une illustration du problème lorsqu'on tente de créer de tels fichiers sur un lecteur réseau (un NAS) monté via samba:
$ touch duplicity-full.2005-03-05T19:40:45-07:00.vol9.difftar.gz touch: duplicity-full.2005-03-05T19:40:45-07:00.vol9.difftar.gz: File name too long
Je remplace les ":" du nom par des "-":
$ touch duplicity-full.2005-03-05T19-40-45-07-00.vol9.difftar.gz $ ls duplicity-full.2005-03-05T19-40-45-07-00.vol9.difftar.gz duplicity-full.2005-03-05T19-40-45-07-00.vol9.difftar.gz
Donc ce sont bien les 2 points qui posent problème. Je me demande s'il y a une solution. En tout cas, le message d'erreur n'est pas très explicite.
NB: pour ce qui est de duplicity, j'utilise l'option --short-filenames qui utilise des noms plus courts et ne contenant pas ":", pour contourner ce problème.
laurent.pertois
Olivier Croquette wrote:
Donc ce sont bien les 2 points qui posent problème. Je me demande s'il y a une solution. En tout cas, le message d'erreur n'est pas très explicite.
Là, tu découvres en plus les joies des restrictions en SMB qui sont adaptées à ce que Windows accepte ou non dans les noms de fichiers, et Windows est bien plus restrictif que Mac OS X.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Donc ce sont bien les 2 points qui posent problème.
Je me demande s'il y a une solution.
En tout cas, le message d'erreur n'est pas très explicite.
Là, tu découvres en plus les joies des restrictions en SMB qui sont
adaptées à ce que Windows accepte ou non dans les noms de fichiers, et
Windows est bien plus restrictif que Mac OS X.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Donc ce sont bien les 2 points qui posent problème. Je me demande s'il y a une solution. En tout cas, le message d'erreur n'est pas très explicite.
Là, tu découvres en plus les joies des restrictions en SMB qui sont adaptées à ce que Windows accepte ou non dans les noms de fichiers, et Windows est bien plus restrictif que Mac OS X.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Olivier Croquette
Laurent Pertois wrote, On 21/05/08 10:23:
Là, tu découvres en plus les joies des restrictions en SMB qui sont adaptées à ce que Windows accepte ou non dans les noms de fichiers, et Windows est bien plus restrictif que Mac OS X.
Exact, entretemps j'ai essayé sous Windows, et c'est ce que j'ai constaté. Par contre, je me demande si c'est le client ou le serveur qui génère spécifiquement cette erreur (File name too long) dans mon exemple.
Laurent Pertois wrote, On 21/05/08 10:23:
Là, tu découvres en plus les joies des restrictions en SMB qui sont
adaptées à ce que Windows accepte ou non dans les noms de fichiers, et
Windows est bien plus restrictif que Mac OS X.
Exact, entretemps j'ai essayé sous Windows, et c'est ce que j'ai
constaté. Par contre, je me demande si c'est le client ou le serveur qui
génère spécifiquement cette erreur (File name too long) dans mon exemple.
Là, tu découvres en plus les joies des restrictions en SMB qui sont adaptées à ce que Windows accepte ou non dans les noms de fichiers, et Windows est bien plus restrictif que Mac OS X.
Exact, entretemps j'ai essayé sous Windows, et c'est ce que j'ai constaté. Par contre, je me demande si c'est le client ou le serveur qui génère spécifiquement cette erreur (File name too long) dans mon exemple.
laurent.pertois
Olivier Croquette wrote:
Exact, entretemps j'ai essayé sous Windows, et c'est ce que j'ai constaté. Par contre, je me demande si c'est le client ou le serveur qui génère spécifiquement cette erreur (File name too long) dans mon exemple.
Mmmm, aucune idée :-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Exact, entretemps j'ai essayé sous Windows, et c'est ce que j'ai
constaté. Par contre, je me demande si c'est le client ou le serveur qui
génère spécifiquement cette erreur (File name too long) dans mon exemple.
Mmmm, aucune idée :-)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Exact, entretemps j'ai essayé sous Windows, et c'est ce que j'ai constaté. Par contre, je me demande si c'est le client ou le serveur qui génère spécifiquement cette erreur (File name too long) dans mon exemple.
Mmmm, aucune idée :-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
