10.2.8 fraichement installé
je liste les fichiers à la racine de mon home, et ça me sort ça :
[Manet:~] manet% ls -l
total 112
drwx------ 7 manet staff 238 Nov 28 11:46 Desktop
drwx------ 16 manet staff 544 Nov 26 11:14 Documents
ls: ./Envoyer l???enregistrement: No such file or directory
lrwxr-xr-x 1 manet staff 55 Nov 27 11:10 Envoyer
l???enregistrement
drwx------ 29 manet staff 986 Nov 27 16:11 Library
(ensuite, c'est normal)
c'est quoi cette ligne blanche suivie de xxx -> no such file ?
j'ai essayé de réparer sans succès.
--
Philippe Manet
Le 5/12/03 17:06, dans <1g5i75s.87o4sa14c9hr4N%, « Romuald Brunet » a écrit :
Éric Lévénez wrote:
Moi je veux que tout mes fichier .html s'ouvrent avec mon navigateur, ne pas savoir intuitivement avec quoi un fichier va s'ouvrir est une horreur. Il faut toujours vérifier dans les infos du fichier pour ne pas faire de bêtise (voir plus haut sur ces problèmes de sécurité).
Je suis d'accord avec David sur ce point, la possibilité d'avoir plusieurs fichiers .html qui s'ouvrent avec des applications différentes est très utile.
Tout cela n'a aucun sens sur un système multiutilisateur. Forcer l'application d'ouverture d'un fichier dans le fichier lui-même est un non sens d'ergonomie. Si un utilisateur a placé des meta-datas dans un fichier .html pour l'ouvrir avec l'appli X au lieu de Y, cela ne conviendra sûrement pas à un autre utilisateur du même fichier. Ce genre de comportement ne doit pas être intégré au fichier ! C'est du non-sens total.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 5/12/03 17:06, dans <1g5i75s.87o4sa14c9hr4N%nospam@chivil.com>, « Romuald
Brunet » <nospam@chivil.com> a écrit :
Éric Lévénez <news@levenez.com> wrote:
Moi je veux que tout mes fichier .html s'ouvrent avec mon navigateur, ne pas
savoir intuitivement avec quoi un fichier va s'ouvrir est une horreur. Il
faut toujours vérifier dans les infos du fichier pour ne pas faire de bêtise
(voir plus haut sur ces problèmes de sécurité).
Je suis d'accord avec David sur ce point, la possibilité d'avoir
plusieurs fichiers .html qui s'ouvrent avec des applications différentes
est très utile.
Tout cela n'a aucun sens sur un système multiutilisateur. Forcer
l'application d'ouverture d'un fichier dans le fichier lui-même est un non
sens d'ergonomie. Si un utilisateur a placé des meta-datas dans un fichier
.html pour l'ouvrir avec l'appli X au lieu de Y, cela ne conviendra sûrement
pas à un autre utilisateur du même fichier. Ce genre de comportement ne doit
pas être intégré au fichier ! C'est du non-sens total.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 5/12/03 17:06, dans <1g5i75s.87o4sa14c9hr4N%, « Romuald Brunet » a écrit :
Éric Lévénez wrote:
Moi je veux que tout mes fichier .html s'ouvrent avec mon navigateur, ne pas savoir intuitivement avec quoi un fichier va s'ouvrir est une horreur. Il faut toujours vérifier dans les infos du fichier pour ne pas faire de bêtise (voir plus haut sur ces problèmes de sécurité).
Je suis d'accord avec David sur ce point, la possibilité d'avoir plusieurs fichiers .html qui s'ouvrent avec des applications différentes est très utile.
Tout cela n'a aucun sens sur un système multiutilisateur. Forcer l'application d'ouverture d'un fichier dans le fichier lui-même est un non sens d'ergonomie. Si un utilisateur a placé des meta-datas dans un fichier .html pour l'ouvrir avec l'appli X au lieu de Y, cela ne conviendra sûrement pas à un autre utilisateur du même fichier. Ce genre de comportement ne doit pas être intégré au fichier ! C'est du non-sens total.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Éric Lévénez
Le 5/12/03 17:42, dans <bqr1f3$iuf$, « Schmurtz » a écrit :
Tout cela est un très bon exemple des problème qu'a eu Apple pour sortir un système, d'un côté avec les conceptes et la simplicité des systèmes précédents, de l'autre le monde unix beaucoup moins intuitif [snip]
Tu fais partie du deuxième monde, nous du premier.
En fait ce qui est amusant c'est que c'est l'inverse. Je veux une simplicité d'utilisation et tu vous voulez garder une complexité technique parce qu'Apple a toujours fait cela.
À l'origine, les extensions n'étaient pas enregistrées dans le nom du fichier, mais dans un champs à part : 8 octets étaient réservés pour le nom et 3 pour le type.
Non. Là tu confonds avec MS-DOS. Unix est plus vieux.
Personnellement, je prefère reconnaitre un type de fichier par son icône plutôt que par un groupe de trois lettre. Les trois lettres sont toujours abstraite, l'icône l'est moins souvent.
Là aussi tu confonds tout. Premièrement une extension n'est pas une série de 3 lettres, mais N séries de P lettres. Deuxièmement avoir une extension à un fichier ne veut pas dire que l'application n'a aucune icône !
Les méta-données ne sont pas si inutile que tu ne le penses. J'ai remarqué que vim enregistre des informations comme la taille des tabulations pour chaque fichier. Pour cela, il utilise un commentaire en haut du fichier ce qui le contraint à connaitre tous les types de commentaires des fichiers qui peut être mené à éditer, et qui oblige à rajouter ces données dans le contenu du fichier alors que ces données sont spécifiques à l'éditeur utilisé.
J'utilise vim depuis pas mal d'années, mais jamais il ne m'a écrit des données comme tu le dis. Mais de toute façon vim est le pire des softs pour ce genre de chose. Quelle horreur d'ouvrir un fichier et de voir qu'au lieu d'être au début on se trouve en plein milieu par ce qu'un jour on l'a édité à ce niveau. Vouloir sauvegarder la position du curseur est une erreur bien sûr. Qui voudrait ouvrir un PDF et voir que l'on se trouve à la page 10 ? Microsoft fait aussi ce genre d'erreur avec Office. Horrible. Cela n'a de sens qu'avec un système type DVD (comme dans Panther), mais cela n'a rien à voir avec des meta-datas.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 5/12/03 17:42, dans <bqr1f3$iuf$4@news.polytechnique.fr>, « Schmurtz »
<moi@ici.com> a écrit :
Tout cela est un très bon exemple des problème qu'a eu Apple pour sortir
un système, d'un côté avec les conceptes et la simplicité des systèmes
précédents, de l'autre le monde unix beaucoup moins intuitif [snip]
Tu fais partie du deuxième monde, nous du premier.
En fait ce qui est amusant c'est que c'est l'inverse. Je veux une simplicité
d'utilisation et tu vous voulez garder une complexité technique parce
qu'Apple a toujours fait cela.
À l'origine, les extensions n'étaient pas enregistrées dans le nom du
fichier, mais dans un champs à part : 8 octets étaient réservés pour le
nom et 3 pour le type.
Non. Là tu confonds avec MS-DOS. Unix est plus vieux.
Personnellement, je prefère reconnaitre un type de fichier par son icône
plutôt que par un groupe de trois lettre. Les trois lettres sont
toujours abstraite, l'icône l'est moins souvent.
Là aussi tu confonds tout. Premièrement une extension n'est pas une série de
3 lettres, mais N séries de P lettres. Deuxièmement avoir une extension à un
fichier ne veut pas dire que l'application n'a aucune icône !
Les méta-données ne sont pas si inutile que tu ne le penses. J'ai
remarqué que vim enregistre des informations comme la taille des
tabulations pour chaque fichier. Pour cela, il utilise un commentaire en
haut du fichier ce qui le contraint à connaitre tous les types de
commentaires des fichiers qui peut être mené à éditer, et qui oblige à
rajouter ces données dans le contenu du fichier alors que ces données
sont spécifiques à l'éditeur utilisé.
J'utilise vim depuis pas mal d'années, mais jamais il ne m'a écrit des
données comme tu le dis. Mais de toute façon vim est le pire des softs pour
ce genre de chose. Quelle horreur d'ouvrir un fichier et de voir qu'au lieu
d'être au début on se trouve en plein milieu par ce qu'un jour on l'a édité
à ce niveau. Vouloir sauvegarder la position du curseur est une erreur bien
sûr. Qui voudrait ouvrir un PDF et voir que l'on se trouve à la page 10 ?
Microsoft fait aussi ce genre d'erreur avec Office. Horrible. Cela n'a de
sens qu'avec un système type DVD (comme dans Panther), mais cela n'a rien à
voir avec des meta-datas.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 5/12/03 17:42, dans <bqr1f3$iuf$, « Schmurtz » a écrit :
Tout cela est un très bon exemple des problème qu'a eu Apple pour sortir un système, d'un côté avec les conceptes et la simplicité des systèmes précédents, de l'autre le monde unix beaucoup moins intuitif [snip]
Tu fais partie du deuxième monde, nous du premier.
En fait ce qui est amusant c'est que c'est l'inverse. Je veux une simplicité d'utilisation et tu vous voulez garder une complexité technique parce qu'Apple a toujours fait cela.
À l'origine, les extensions n'étaient pas enregistrées dans le nom du fichier, mais dans un champs à part : 8 octets étaient réservés pour le nom et 3 pour le type.
Non. Là tu confonds avec MS-DOS. Unix est plus vieux.
Personnellement, je prefère reconnaitre un type de fichier par son icône plutôt que par un groupe de trois lettre. Les trois lettres sont toujours abstraite, l'icône l'est moins souvent.
Là aussi tu confonds tout. Premièrement une extension n'est pas une série de 3 lettres, mais N séries de P lettres. Deuxièmement avoir une extension à un fichier ne veut pas dire que l'application n'a aucune icône !
Les méta-données ne sont pas si inutile que tu ne le penses. J'ai remarqué que vim enregistre des informations comme la taille des tabulations pour chaque fichier. Pour cela, il utilise un commentaire en haut du fichier ce qui le contraint à connaitre tous les types de commentaires des fichiers qui peut être mené à éditer, et qui oblige à rajouter ces données dans le contenu du fichier alors que ces données sont spécifiques à l'éditeur utilisé.
J'utilise vim depuis pas mal d'années, mais jamais il ne m'a écrit des données comme tu le dis. Mais de toute façon vim est le pire des softs pour ce genre de chose. Quelle horreur d'ouvrir un fichier et de voir qu'au lieu d'être au début on se trouve en plein milieu par ce qu'un jour on l'a édité à ce niveau. Vouloir sauvegarder la position du curseur est une erreur bien sûr. Qui voudrait ouvrir un PDF et voir que l'on se trouve à la page 10 ? Microsoft fait aussi ce genre d'erreur avec Office. Horrible. Cela n'a de sens qu'avec un système type DVD (comme dans Panther), mais cela n'a rien à voir avec des meta-datas.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Schmurtz
En fait ce qui est amusant c'est que c'est l'inverse. Je veux une simplicité d'utilisation et tu vous voulez garder une complexité technique parce qu'Apple a toujours fait cela.
j'avais aussi dit : "l'autre le monde unix beaucoup moins intuitif et basé sur des politiques plutôt sécuritaire, minimaliste : fragmentation du code en multiples bibliothèque pour éviter le redondance et le code inutile, le moins structures complexes"
et pour moi le "moins de structure commplexe" était aussi synonyme de simplicité.
À l'origine, les extensions n'étaient pas enregistrées dans le nom du fichier, mais dans un champs à part : 8 octets étaient réservés pour le nom et 3 pour le type.
Non. Là tu confonds avec MS-DOS. Unix est plus vieux.
Mais l'unix d'avant le MS-DOS utilisait quasiment pas les extensions, puisque qu'il était basé sur les applications binaires (marqué par le bit d'exécution) et des fichiers ascii. Ce qui ne veut pas dire que c'est avec MS-DOS que sont apparus les extensions, mais juste que c'est avec lui quelles se sont démocratisées.
Personnellement, je prefère reconnaitre un type de fichier par son icône plutôt que par un groupe de trois lettre. Les trois lettres sont toujours abstraite, l'icône l'est moins souvent.
Là aussi tu confonds tout. Premièrement une extension n'est pas une série de 3 lettres, mais N séries de P lettres. Deuxièmement avoir une extension à un fichier ne veut pas dire que l'application n'a aucune icône !
OK, mais tant qu'à avoir une icône, je préfère ne pas avoir d'extension (juste pour ne pas voir la technique sous-jacente).
Les méta-données ne sont pas si inutile que tu ne le penses. J'ai remarqué que vim enregistre des informations comme la taille des tabulations pour chaque fichier. Pour cela, il utilise un commentaire en haut du fichier ce qui le contraint à connaitre tous les types de commentaires des fichiers qui peut être mené à éditer, et qui oblige à rajouter ces données dans le contenu du fichier alors que ces données sont spécifiques à l'éditeur utilisé.
J'utilise vim depuis pas mal d'années, mais jamais il ne m'a écrit des données comme tu le dis.
Personnellement, je n'utilise pas vim. C'est juste en lisant des fichiers écrit avec vim (l'entête précise clairement que c'est vim qui les à ajoutés).
Mais de toute façon vim est le pire des softs pour ce genre de chose. Quelle horreur d'ouvrir un fichier et de voir qu'au lieu d'être au début on se trouve en plein milieu par ce qu'un jour on l'a édité à ce niveau. Vouloir sauvegarder la position du curseur est une erreur bien sûr. Qui voudrait ouvrir un PDF et voir que l'on se trouve à la page 10 ? Microsoft fait aussi ce genre d'erreur avec Office. Horrible. Cela n'a de sens qu'avec un système type DVD (comme dans Panther), mais cela n'a rien à voir avec des meta-datas.
Je suis tout à fait d'accord avec toi pour le positionnement automatique. Surtout quand général, quand j'ouvre deux fois de suite un même document, c'est pas pour modifier/lire la même chose.
-- Schmurtz
En fait ce qui est amusant c'est que c'est l'inverse. Je veux une simplicité
d'utilisation et tu vous voulez garder une complexité technique parce
qu'Apple a toujours fait cela.
j'avais aussi dit :
"l'autre le monde unix beaucoup moins intuitif et basé sur
des politiques plutôt sécuritaire, minimaliste : fragmentation du code
en multiples bibliothèque pour éviter le redondance et le code inutile,
le moins structures complexes"
et pour moi le "moins de structure commplexe" était aussi synonyme de
simplicité.
À l'origine, les extensions n'étaient pas enregistrées dans le nom du
fichier, mais dans un champs à part : 8 octets étaient réservés pour le
nom et 3 pour le type.
Non. Là tu confonds avec MS-DOS. Unix est plus vieux.
Mais l'unix d'avant le MS-DOS utilisait quasiment pas les extensions,
puisque qu'il était basé sur les applications binaires (marqué par le
bit d'exécution) et des fichiers ascii. Ce qui ne veut pas dire que
c'est avec MS-DOS que sont apparus les extensions, mais juste que c'est
avec lui quelles se sont démocratisées.
Personnellement, je prefère reconnaitre un type de fichier par son icône
plutôt que par un groupe de trois lettre. Les trois lettres sont
toujours abstraite, l'icône l'est moins souvent.
Là aussi tu confonds tout. Premièrement une extension n'est pas une série de
3 lettres, mais N séries de P lettres. Deuxièmement avoir une extension à un
fichier ne veut pas dire que l'application n'a aucune icône !
OK, mais tant qu'à avoir une icône, je préfère ne pas avoir d'extension
(juste pour ne pas voir la technique sous-jacente).
Les méta-données ne sont pas si inutile que tu ne le penses. J'ai
remarqué que vim enregistre des informations comme la taille des
tabulations pour chaque fichier. Pour cela, il utilise un commentaire en
haut du fichier ce qui le contraint à connaitre tous les types de
commentaires des fichiers qui peut être mené à éditer, et qui oblige à
rajouter ces données dans le contenu du fichier alors que ces données
sont spécifiques à l'éditeur utilisé.
J'utilise vim depuis pas mal d'années, mais jamais il ne m'a écrit des
données comme tu le dis.
Personnellement, je n'utilise pas vim. C'est juste en lisant des
fichiers écrit avec vim (l'entête précise clairement que c'est vim qui
les à ajoutés).
Mais de toute façon vim est le pire des softs pour
ce genre de chose. Quelle horreur d'ouvrir un fichier et de voir qu'au lieu
d'être au début on se trouve en plein milieu par ce qu'un jour on l'a édité
à ce niveau. Vouloir sauvegarder la position du curseur est une erreur bien
sûr. Qui voudrait ouvrir un PDF et voir que l'on se trouve à la page 10 ?
Microsoft fait aussi ce genre d'erreur avec Office. Horrible. Cela n'a de
sens qu'avec un système type DVD (comme dans Panther), mais cela n'a rien à
voir avec des meta-datas.
Je suis tout à fait d'accord avec toi pour le positionnement
automatique. Surtout quand général, quand j'ouvre deux fois de suite un
même document, c'est pas pour modifier/lire la même chose.
En fait ce qui est amusant c'est que c'est l'inverse. Je veux une simplicité d'utilisation et tu vous voulez garder une complexité technique parce qu'Apple a toujours fait cela.
j'avais aussi dit : "l'autre le monde unix beaucoup moins intuitif et basé sur des politiques plutôt sécuritaire, minimaliste : fragmentation du code en multiples bibliothèque pour éviter le redondance et le code inutile, le moins structures complexes"
et pour moi le "moins de structure commplexe" était aussi synonyme de simplicité.
À l'origine, les extensions n'étaient pas enregistrées dans le nom du fichier, mais dans un champs à part : 8 octets étaient réservés pour le nom et 3 pour le type.
Non. Là tu confonds avec MS-DOS. Unix est plus vieux.
Mais l'unix d'avant le MS-DOS utilisait quasiment pas les extensions, puisque qu'il était basé sur les applications binaires (marqué par le bit d'exécution) et des fichiers ascii. Ce qui ne veut pas dire que c'est avec MS-DOS que sont apparus les extensions, mais juste que c'est avec lui quelles se sont démocratisées.
Personnellement, je prefère reconnaitre un type de fichier par son icône plutôt que par un groupe de trois lettre. Les trois lettres sont toujours abstraite, l'icône l'est moins souvent.
Là aussi tu confonds tout. Premièrement une extension n'est pas une série de 3 lettres, mais N séries de P lettres. Deuxièmement avoir une extension à un fichier ne veut pas dire que l'application n'a aucune icône !
OK, mais tant qu'à avoir une icône, je préfère ne pas avoir d'extension (juste pour ne pas voir la technique sous-jacente).
Les méta-données ne sont pas si inutile que tu ne le penses. J'ai remarqué que vim enregistre des informations comme la taille des tabulations pour chaque fichier. Pour cela, il utilise un commentaire en haut du fichier ce qui le contraint à connaitre tous les types de commentaires des fichiers qui peut être mené à éditer, et qui oblige à rajouter ces données dans le contenu du fichier alors que ces données sont spécifiques à l'éditeur utilisé.
J'utilise vim depuis pas mal d'années, mais jamais il ne m'a écrit des données comme tu le dis.
Personnellement, je n'utilise pas vim. C'est juste en lisant des fichiers écrit avec vim (l'entête précise clairement que c'est vim qui les à ajoutés).
Mais de toute façon vim est le pire des softs pour ce genre de chose. Quelle horreur d'ouvrir un fichier et de voir qu'au lieu d'être au début on se trouve en plein milieu par ce qu'un jour on l'a édité à ce niveau. Vouloir sauvegarder la position du curseur est une erreur bien sûr. Qui voudrait ouvrir un PDF et voir que l'on se trouve à la page 10 ? Microsoft fait aussi ce genre d'erreur avec Office. Horrible. Cela n'a de sens qu'avec un système type DVD (comme dans Panther), mais cela n'a rien à voir avec des meta-datas.
Je suis tout à fait d'accord avec toi pour le positionnement automatique. Surtout quand général, quand j'ouvre deux fois de suite un même document, c'est pas pour modifier/lire la même chose.
-- Schmurtz
david.andriana
Éric Lévénez wrote:
(snip)
OK, je crois que tu n'as pas bien compris comment pouvaient être utilisées les méta-données.
C'est pas grave.
-- David
Éric Lévénez <news@levenez.com> wrote:
(snip)
OK, je crois que tu n'as pas bien compris comment pouvaient être
utilisées les méta-données.
OK, je crois que tu n'as pas bien compris comment pouvaient être utilisées les méta-données.
C'est pas grave.
-- David
Eric Jacoboni
Schmurtz writes:
Je suis tout à fait d'accord avec toi pour le positionnement automatique. Surtout quand général, quand j'ouvre deux fois de suite un même document, c'est pas pour modifier/lire la même chose.
Ça dépend aussi de la situation... Moi, je suis bien content que Emacs me positionne au dernier endroit que j'ai édité quand je traduit un document...
-- Éric Jacoboni, né il y a 1374092034 secondes
Schmurtz <moi@ici.com> writes:
Je suis tout à fait d'accord avec toi pour le positionnement
automatique. Surtout quand général, quand j'ouvre deux fois de suite un
même document, c'est pas pour modifier/lire la même chose.
Ça dépend aussi de la situation... Moi, je suis bien content que Emacs
me positionne au dernier endroit que j'ai édité quand je traduit un
document...
Je suis tout à fait d'accord avec toi pour le positionnement automatique. Surtout quand général, quand j'ouvre deux fois de suite un même document, c'est pas pour modifier/lire la même chose.
Ça dépend aussi de la situation... Moi, je suis bien content que Emacs me positionne au dernier endroit que j'ai édité quand je traduit un document...
-- Éric Jacoboni, né il y a 1374092034 secondes
Éric Lévénez
Le 5/12/03 19:22, dans <bqr7ag$iuf$, « Schmurtz » a écrit :
Quotage coupé à la tronçonneuse, donc illisible.
À l'origine, les extensions n'étaient pas enregistrées dans le nom du fichier, mais dans un champs à part : 8 octets étaient réservés pour le nom et 3 pour le type.
Non. Là tu confonds avec MS-DOS. Unix est plus vieux.
Mais l'unix d'avant le MS-DOS utilisait quasiment pas les extensions, puisque qu'il était basé sur les applications binaires (marqué par le bit d'exécution) et des fichiers ascii. Ce qui ne veut pas dire que c'est avec MS-DOS que sont apparus les extensions, mais juste que c'est avec lui quelles se sont démocratisées.
Unix n'a effectivement jamais utilisé les extensions, et cela continue avec Mac OS X. Mais les extensions sont utilisées par les programmes applicatifs, et cela depuis l'origine. La méthode de MS-DOS n'est pas une démocratisation mais un détournement non maîtrisé.
J'utilise vim depuis pas mal d'années, mais jamais il ne m'a écrit des données comme tu le dis.
Personnellement, je n'utilise pas vim. C'est juste en lisant des fichiers écrit avec vim (l'entête précise clairement que c'est vim qui les à ajoutés).
Des tas de softs peuvent être configuré pour écrire des choses de façon automatique, il ne faut pas prendre cela pour définitif ou pour un comportement "normal".
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 5/12/03 19:22, dans <bqr7ag$iuf$8@news.polytechnique.fr>, « Schmurtz »
<moi@ici.com> a écrit :
Quotage coupé à la tronçonneuse, donc illisible.
À l'origine, les extensions n'étaient pas enregistrées dans le nom du
fichier, mais dans un champs à part : 8 octets étaient réservés pour le
nom et 3 pour le type.
Non. Là tu confonds avec MS-DOS. Unix est plus vieux.
Mais l'unix d'avant le MS-DOS utilisait quasiment pas les extensions,
puisque qu'il était basé sur les applications binaires (marqué par le
bit d'exécution) et des fichiers ascii. Ce qui ne veut pas dire que
c'est avec MS-DOS que sont apparus les extensions, mais juste que c'est
avec lui quelles se sont démocratisées.
Unix n'a effectivement jamais utilisé les extensions, et cela continue avec
Mac OS X. Mais les extensions sont utilisées par les programmes applicatifs,
et cela depuis l'origine. La méthode de MS-DOS n'est pas une démocratisation
mais un détournement non maîtrisé.
J'utilise vim depuis pas mal d'années, mais jamais il ne m'a écrit des
données comme tu le dis.
Personnellement, je n'utilise pas vim. C'est juste en lisant des
fichiers écrit avec vim (l'entête précise clairement que c'est vim qui
les à ajoutés).
Des tas de softs peuvent être configuré pour écrire des choses de façon
automatique, il ne faut pas prendre cela pour définitif ou pour un
comportement "normal".
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 5/12/03 19:22, dans <bqr7ag$iuf$, « Schmurtz » a écrit :
Quotage coupé à la tronçonneuse, donc illisible.
À l'origine, les extensions n'étaient pas enregistrées dans le nom du fichier, mais dans un champs à part : 8 octets étaient réservés pour le nom et 3 pour le type.
Non. Là tu confonds avec MS-DOS. Unix est plus vieux.
Mais l'unix d'avant le MS-DOS utilisait quasiment pas les extensions, puisque qu'il était basé sur les applications binaires (marqué par le bit d'exécution) et des fichiers ascii. Ce qui ne veut pas dire que c'est avec MS-DOS que sont apparus les extensions, mais juste que c'est avec lui quelles se sont démocratisées.
Unix n'a effectivement jamais utilisé les extensions, et cela continue avec Mac OS X. Mais les extensions sont utilisées par les programmes applicatifs, et cela depuis l'origine. La méthode de MS-DOS n'est pas une démocratisation mais un détournement non maîtrisé.
J'utilise vim depuis pas mal d'années, mais jamais il ne m'a écrit des données comme tu le dis.
Personnellement, je n'utilise pas vim. C'est juste en lisant des fichiers écrit avec vim (l'entête précise clairement que c'est vim qui les à ajoutés).
Des tas de softs peuvent être configuré pour écrire des choses de façon automatique, il ne faut pas prendre cela pour définitif ou pour un comportement "normal".
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Éric Lévénez
Le 5/12/03 19:47, dans <1g5iem5.qo6pb716oze0wN@[192.168.0.120]>, « David Andriana » a écrit :
Éric Lévénez wrote:
(snip)
OK, je crois que tu n'as pas bien compris comment pouvaient être utilisées les méta-données.
Si tu le dis.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 5/12/03 19:47, dans <1g5iem5.qo6pb716oze0wN@[192.168.0.120]>, « David
Andriana » <david.andriana@free.fr> a écrit :
Éric Lévénez <news@levenez.com> wrote:
(snip)
OK, je crois que tu n'as pas bien compris comment pouvaient être
utilisées les méta-données.
Si tu le dis.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 5/12/03 19:47, dans <1g5iem5.qo6pb716oze0wN@[192.168.0.120]>, « David Andriana » a écrit :
Éric Lévénez wrote:
(snip)
OK, je crois que tu n'as pas bien compris comment pouvaient être utilisées les méta-données.
Si tu le dis.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Éric Lévénez
Le 5/12/03 20:14, dans , « Eric Jacoboni » a écrit :
Schmurtz writes:
Je suis tout à fait d'accord avec toi pour le positionnement automatique. Surtout quand général, quand j'ouvre deux fois de suite un même document, c'est pas pour modifier/lire la même chose.
Ça dépend aussi de la situation... Moi, je suis bien content que Emacs me positionne au dernier endroit que j'ai édité quand je traduit un document...
Certains aiment ce genre de comportement des applis d'autres pas. Cela doit donc être réglable _dans l'application_ et donc par utilisateur, et cela ne doit pas être imposé dans des meta-datas intégrées au fichier lui-même.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 5/12/03 20:14, dans <m21xrjt6ts.fsf@mac.scrogneugneu.org>, « Eric
Jacoboni » <jaco@teaser.fr> a écrit :
Schmurtz <moi@ici.com> writes:
Je suis tout à fait d'accord avec toi pour le positionnement
automatique. Surtout quand général, quand j'ouvre deux fois de suite un
même document, c'est pas pour modifier/lire la même chose.
Ça dépend aussi de la situation... Moi, je suis bien content que Emacs
me positionne au dernier endroit que j'ai édité quand je traduit un
document...
Certains aiment ce genre de comportement des applis d'autres pas. Cela doit
donc être réglable _dans l'application_ et donc par utilisateur, et cela ne
doit pas être imposé dans des meta-datas intégrées au fichier lui-même.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 5/12/03 20:14, dans , « Eric Jacoboni » a écrit :
Schmurtz writes:
Je suis tout à fait d'accord avec toi pour le positionnement automatique. Surtout quand général, quand j'ouvre deux fois de suite un même document, c'est pas pour modifier/lire la même chose.
Ça dépend aussi de la situation... Moi, je suis bien content que Emacs me positionne au dernier endroit que j'ai édité quand je traduit un document...
Certains aiment ce genre de comportement des applis d'autres pas. Cela doit donc être réglable _dans l'application_ et donc par utilisateur, et cela ne doit pas être imposé dans des meta-datas intégrées au fichier lui-même.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Eric Jacoboni
Éric Lévénez writes:
Certains aiment ce genre de comportement des applis d'autres pas. Cela doit donc être réglable _dans l'application_ et donc par utilisateur, et cela ne doit pas être imposé dans des meta-datas intégrées au fichier lui-même.
Bien sûr... Rien ne doit être imposé, tout doit être permis.
En ce qui concerne Emacs, (setq-default transient-mark-mode t). -- Éric Jacoboni, né il y a 1374100476 secondes
Éric Lévénez <news@levenez.com> writes:
Certains aiment ce genre de comportement des applis d'autres pas. Cela doit
donc être réglable _dans l'application_ et donc par utilisateur, et cela ne
doit pas être imposé dans des meta-datas intégrées au fichier lui-même.
Bien sûr... Rien ne doit être imposé, tout doit être permis.
En ce qui concerne Emacs, (setq-default transient-mark-mode t).
--
Éric Jacoboni, né il y a 1374100476 secondes
Certains aiment ce genre de comportement des applis d'autres pas. Cela doit donc être réglable _dans l'application_ et donc par utilisateur, et cela ne doit pas être imposé dans des meta-datas intégrées au fichier lui-même.
Bien sûr... Rien ne doit être imposé, tout doit être permis.
En ce qui concerne Emacs, (setq-default transient-mark-mode t). -- Éric Jacoboni, né il y a 1374100476 secondes
pmanet
Éric Lévénez wrote:
Quand un Macounet envoie par exemple un fichier Office par email à un Windosien, 9 fois sur 10 il y a un problème lié aux ressources.
absolument ; quand j'envoie un pdf aux beurkistes, ils en reçoivent 2 ; le fichier ressource est le premier, évidemment ils le cliquent d'abord, ça ne fonctionne pas, et ils ralent...
-- Philippe Manet
Éric Lévénez <news@levenez.com> wrote:
Quand un Macounet envoie par exemple un fichier Office par email à un
Windosien, 9 fois sur 10 il y a un problème lié aux ressources.
absolument ; quand j'envoie un pdf aux beurkistes, ils en reçoivent 2 ;
le fichier ressource est le premier, évidemment ils le cliquent d'abord,
ça ne fonctionne pas, et ils ralent...
Quand un Macounet envoie par exemple un fichier Office par email à un Windosien, 9 fois sur 10 il y a un problème lié aux ressources.
absolument ; quand j'envoie un pdf aux beurkistes, ils en reçoivent 2 ; le fichier ressource est le premier, évidemment ils le cliquent d'abord, ça ne fonctionne pas, et ils ralent...
