entre deux bécannes sous Xubuntu, j'essaie de copier la clé publique de
l'un sur l'autre, basique me direz vous...
MAIS ça coince :
yt@ubuntu:~$ ssh-copy-id -i ~/.ssh/id_dsa.pub mfj@Gericom
mfj@<son adresse IPV6>'s password:
cat: erreur d'écriture: Aucun espace disponible sur le périphérique
du coup, je me tourne vers scp :
yt@ubuntu:~/.ssh$ scp id_dsa.pub mfj@Gericom:/home/mfj/Bureau/cle_yvon.pub
mfj@<son adresse IPV6>'s password:
id_dsa.pub
100% 599
0.6KB/s 00:00
scp: /home/mfj/Bureau/cle_yvon.pub: No space left on device
Étrange non ? il me reste qd même 9Go sur la partoche Xubuntu...
effectivement, quand je regarde par ssh le contenu du fichier
téléchargé, il est vide :
yt@ubuntu:~/.ssh$ ssh mfj@Gericom
mfj@<son adresse IPV6>'s password:
Welcome to Ubuntu 11.10 (GNU/Linux 3.0.0-14-generic i686)
* Documentation: https://help.ubuntu.com/
Last login: Wed Nov 30 13:21:51 2011 from
<mon adresse IPV6>
mfj@GERICOM:~$ ls Bureau
cle_yvon.pub
mfj@GERICOM:~$ cat Bureau/cle_yvon.pub
mfj@GERICOM:~$
Ben ce que j'ai appris est quand le dd commence à déconner, c'est plus > difficile de faire un recover quand il y a des partitions.
Oui mais le problème, c'est que si tu installes la version n+1 d'Ubuntu qui te cause pelin d'ennuis et que tu veuilles revenir à la version n, la seule solution propre que je connaisse c'est dans ce cas de réinstaller la version n avec un cd ou une clé usb et dans ton cas, on perds toutes les données!
Oui, bon, rien de surprenant à cela, je vais m'y mettre.
> Bon, mais en fait, sur PC, je ne sais pas comment on fait des > partitions, enfin, je n'ai jamais fait. > > Ce que je souhaite vivement savoir, c'est comment on installe Lubuntu > 11.10 sur un PC qui n'a pas win * d'installé. C'est pour remplacer un > Xubuntu qui déconne.
> Et aussi quelles partitions faire sur un disque de 90 Go environ.
/ de 8 à 12 Go (les montées de version sur ubuntu sont gourmands donc en temps normal c'est de la place perdue mais en cas d'upgrade c'est du temps de gagné et puis sur ubuntu comme on a pleins de logiciel qui sont disponibles on est tenté d'installer plein de choses donc /usr peut vite grossir). swap 2* la ram et au maxi 2Go /home le reste
Cependant j'ai déjà un problème avec le disque gravé pour Lubuntu. Quand, sur win 7, j'essaie de le lancer, il m'affiche :
wubi : No CD detected, cannot run CD menu. cf. copie écran : <http://cjoint.com/11dc/ALcoxlMYwKO_Lubuntu.PNG>
je pense que ce CD n'est pas bon... que je devrai en refaire un ???
sur l'explorateur windows, la barre de progression liée à ce CD est en rouge, j'imagine que ça indique une erreur qqpart...
Le 01/12/2011 10:24, yamo' a écrit :
Ben ce que j'ai appris est quand le dd commence à déconner, c'est plus
> difficile de faire un recover quand il y a des partitions.
Oui mais le problème, c'est que si tu installes la version n+1 d'Ubuntu
qui te cause pelin d'ennuis et que tu veuilles revenir à la version n,
la seule solution propre que je connaisse c'est dans ce cas de
réinstaller la version n avec un cd ou une clé usb et dans ton cas, on
perds toutes les données!
Oui, bon, rien de surprenant à cela, je vais m'y mettre.
> Bon, mais en fait, sur PC, je ne sais pas comment on fait des
> partitions, enfin, je n'ai jamais fait.
>
> Ce que je souhaite vivement savoir, c'est comment on installe Lubuntu
> 11.10 sur un PC qui n'a pas win * d'installé. C'est pour remplacer un
> Xubuntu qui déconne.
> Et aussi quelles partitions faire sur un disque de 90 Go environ.
/ de 8 à 12 Go (les montées de version sur ubuntu sont gourmands donc en
temps normal c'est de la place perdue mais en cas d'upgrade c'est du
temps de gagné et puis sur ubuntu comme on a pleins de logiciel qui sont
disponibles on est tenté d'installer plein de choses donc /usr peut vite
grossir).
swap 2* la ram et au maxi 2Go
/home le reste
Ben ce que j'ai appris est quand le dd commence à déconner, c'est plus > difficile de faire un recover quand il y a des partitions.
Oui mais le problème, c'est que si tu installes la version n+1 d'Ubuntu qui te cause pelin d'ennuis et que tu veuilles revenir à la version n, la seule solution propre que je connaisse c'est dans ce cas de réinstaller la version n avec un cd ou une clé usb et dans ton cas, on perds toutes les données!
Oui, bon, rien de surprenant à cela, je vais m'y mettre.
> Bon, mais en fait, sur PC, je ne sais pas comment on fait des > partitions, enfin, je n'ai jamais fait. > > Ce que je souhaite vivement savoir, c'est comment on installe Lubuntu > 11.10 sur un PC qui n'a pas win * d'installé. C'est pour remplacer un > Xubuntu qui déconne.
> Et aussi quelles partitions faire sur un disque de 90 Go environ.
/ de 8 à 12 Go (les montées de version sur ubuntu sont gourmands donc en temps normal c'est de la place perdue mais en cas d'upgrade c'est du temps de gagné et puis sur ubuntu comme on a pleins de logiciel qui sont disponibles on est tenté d'installer plein de choses donc /usr peut vite grossir). swap 2* la ram et au maxi 2Go /home le reste
Cependant j'ai déjà un problème avec le disque gravé pour Lubuntu. Quand, sur win 7, j'essaie de le lancer, il m'affiche :
wubi : No CD detected, cannot run CD menu. cf. copie écran : <http://cjoint.com/11dc/ALcoxlMYwKO_Lubuntu.PNG>
je pense que ce CD n'est pas bon... que je devrai en refaire un ???
sur l'explorateur windows, la barre de progression liée à ce CD est en rouge, j'imagine que ça indique une erreur qqpart...
Une Bévue
Le 01/12/2011 10:20, denis.paris a écrit :
Je ne sais pas ou tu as trouvé ça, mais c'est faut. Il faut toujours partionner un disque.
C'est ce que j'ai lu sur des groupes liés à Mac OS X...
Bon, mais en fait, sur PC, je ne sais pas comment on fait des partitions, enfin, je n'ai jamais fait.
Oups... Je crois qu'il te manque quelques bases et qu'il va falloir lire un peu... (RTFM !)
ouais.
Ce que je souhaite vivement savoir, c'est comment on installe Lubuntu 11.10 sur un PC qui n'a pas win * d'installé. C'est pour remplacer un Xubuntu qui déconne.
Tu mets le CD, tu boot, tu choisis "disque entier" et tu te laisses guider: le programme fait cela très bien
Et aussi quelles partitions faire sur un disque de 90 Go environ.
typiquement 10 Go pour /, 1 Go pour le swap, le reste en /home
Comme tu as fait une croix sur le contenu du disque et que tu débutes (ce n'est pas un reproche, hein) profites-en pour refaire plusieurs fois l'installation pour te faire la main, on ne réussit pas toujours du premier coup.
OK, mais bon la première install, sans partitionnement, a marché du premier coup.
Il faut que tu te familiarises avec le système de fichiers Linux, c'est très différent de Windows (je ne parle pas de ext4 ou NTFS, ça c'est un détail, mais les points de montages, etc..) et les commandes de bases du shell. Là encore RTFM !
je ne coonais que très peu win *, je viens plutôt de Mac OS X.
Le 01/12/2011 10:20, denis.paris a écrit :
Je ne sais pas ou tu as trouvé ça, mais c'est faut. Il faut toujours
partionner un disque.
C'est ce que j'ai lu sur des groupes liés à Mac OS X...
Bon, mais en fait, sur PC, je ne sais pas comment on fait des
partitions, enfin, je n'ai jamais fait.
Oups... Je crois qu'il te manque quelques bases et qu'il va falloir lire
un peu... (RTFM !)
ouais.
Ce que je souhaite vivement savoir, c'est comment on installe Lubuntu
11.10 sur un PC qui n'a pas win * d'installé. C'est pour remplacer un
Xubuntu qui déconne.
Tu mets le CD, tu boot, tu choisis "disque entier" et tu te laisses
guider: le programme fait cela très bien
Et aussi quelles partitions faire sur un disque de 90 Go environ.
typiquement 10 Go pour /, 1 Go pour le swap, le reste en /home
Comme tu as fait une croix sur le contenu du disque et que tu débutes
(ce n'est pas un reproche, hein) profites-en pour refaire plusieurs fois
l'installation pour te faire la main, on ne réussit pas toujours du
premier coup.
OK, mais bon la première install, sans partitionnement, a marché du
premier coup.
Il faut que tu te familiarises avec le système de fichiers Linux, c'est
très différent de Windows (je ne parle pas de ext4 ou NTFS, ça c'est un
détail, mais les points de montages, etc..) et les commandes de bases du
shell. Là encore RTFM !
je ne coonais que très peu win *, je viens plutôt de Mac OS X.
Je ne sais pas ou tu as trouvé ça, mais c'est faut. Il faut toujours partionner un disque.
C'est ce que j'ai lu sur des groupes liés à Mac OS X...
Bon, mais en fait, sur PC, je ne sais pas comment on fait des partitions, enfin, je n'ai jamais fait.
Oups... Je crois qu'il te manque quelques bases et qu'il va falloir lire un peu... (RTFM !)
ouais.
Ce que je souhaite vivement savoir, c'est comment on installe Lubuntu 11.10 sur un PC qui n'a pas win * d'installé. C'est pour remplacer un Xubuntu qui déconne.
Tu mets le CD, tu boot, tu choisis "disque entier" et tu te laisses guider: le programme fait cela très bien
Et aussi quelles partitions faire sur un disque de 90 Go environ.
typiquement 10 Go pour /, 1 Go pour le swap, le reste en /home
Comme tu as fait une croix sur le contenu du disque et que tu débutes (ce n'est pas un reproche, hein) profites-en pour refaire plusieurs fois l'installation pour te faire la main, on ne réussit pas toujours du premier coup.
OK, mais bon la première install, sans partitionnement, a marché du premier coup.
Il faut que tu te familiarises avec le système de fichiers Linux, c'est très différent de Windows (je ne parle pas de ext4 ou NTFS, ça c'est un détail, mais les points de montages, etc..) et les commandes de bases du shell. Là encore RTFM !
je ne coonais que très peu win *, je viens plutôt de Mac OS X.
denis.paris
Le 02/12/2011 14:30, Une Bévue a écrit :
OK, mais bon la première install, sans partitionnement, a marché du premier coup.
Ubuntu n'a pas proposé un partitionnement par défaut?
Que donne df -h ?
Le 02/12/2011 14:30, Une Bévue a écrit :
OK, mais bon la première install, sans partitionnement, a marché du
premier coup.
Ubuntu n'a pas proposé un partitionnement par défaut?
Et ce ~/Téléchargements, c'est un dossier, ou un lien symbolique vers /tmp ? Ou un point de montage ? ...
tout simplement un dossier.
Benoit Izac
Bonjour,
le 02/12/2011 à 08:33, denis paris a écrit dans le message <4ed87f48$0$24980$ :
OK, mais sur mon système (je viens de tester) vi créé un fichier .monfichier.swp dans le même répertoire que le fichier en cours d'édition, et propose de le récupérer en cas de crash (j'ai testé aussi: un kill de vi dans une autre fenêtre). et ce comportement me paraît très logique puisqu'on a forcément le droit d'écrire dans le répertoire du fichier que l'on édite.
C'est faux !
** root # mkdir -m751 /tmp/test_00 # cd /tmp/test_00 # touch a; chmod 666 a
** user % cd /tmp/test_00 % touch b touch: cannot touch `b': Permission denied % vi a % cat a coucou
Tu ne nous dis pas quels sont les droits réels de ton "user", selon son groupe il est dans le "5" ou dans le "1", pour que ça fonctionne je suppose qu'il est dans le "5", donc dans le groupe "root"
Tu connais beaucoup d'utilisateurs dans le groupe « root » ?
En tout cas chez moi je peux faire "cd /tmp/test_00 mais j'ai un "access deny" quand je fais simplement "ls", ce qui est normal.
Oui mais sans rapport avec le sujet de la discussion : « on a forcément le droit d'écrire dans le répertoire du fichier que l'on édite »
Tu ne dis pas non plus ou se créé le fichier ".a.swp" quand tu modifies le fichier: probablement dans le ~/tmp du user, donc dans un répertoire qui survivra à un reboot, ce qui est le sujet de ce sous-fil.
Non, un utilisateur n'a pas de dossier « tmp » dans son $HOME normalement. Bon, je reconnais que je suis un mauvais exemple car j'en ai un, mais les fichiers qu'il contient sont de mon fait.
Si les droits avaient été "777" (ou le user owner du répertoire) le swap aurait été créé directement dans /tmp/test_00 et là en effet les modifications en cours sont perdues en cas de crash.
Pas chez moi : # ls -l /var/tmp total 0
Dans une console en tant qu'utilisateur, je tape : % vi a
Et pendant que vi est toujours actif : # ls -l /var/tmp total 0 -rw------- 1 benoit benoit 0 Dec 2 19:14 Ex0000002971
C'est le vi fournit par défaut sur Archlinux.
-- Benoit Izac
Bonjour,
le 02/12/2011 à 08:33, denis paris a écrit dans le message
<4ed87f48$0$24980$426a74cc@news.free.fr> :
OK, mais sur mon système (je viens de tester) vi créé un fichier
.monfichier.swp dans le même répertoire que le fichier en cours
d'édition, et propose de le récupérer en cas de crash (j'ai testé
aussi: un kill de vi dans une autre fenêtre). et ce comportement me
paraît très logique puisqu'on a forcément le droit d'écrire dans le
répertoire du fichier que l'on édite.
C'est faux !
** root
# mkdir -m751 /tmp/test_00
# cd /tmp/test_00
# touch a; chmod 666 a
** user
% cd /tmp/test_00
% touch b
touch: cannot touch `b': Permission denied
% vi a
% cat a
coucou
Tu ne nous dis pas quels sont les droits réels de ton "user", selon
son groupe il est dans le "5" ou dans le "1", pour que ça fonctionne
je suppose qu'il est dans le "5", donc dans le groupe "root"
Tu connais beaucoup d'utilisateurs dans le groupe « root » ?
En tout cas chez moi je peux faire "cd /tmp/test_00 mais j'ai un
"access deny" quand je fais simplement "ls", ce qui est normal.
Oui mais sans rapport avec le sujet de la discussion : « on a forcément
le droit d'écrire dans le répertoire du fichier que l'on édite »
Tu ne dis pas non plus ou se créé le fichier ".a.swp" quand tu
modifies le fichier: probablement dans le ~/tmp du user, donc dans un
répertoire qui survivra à un reboot, ce qui est le sujet de ce
sous-fil.
Non, un utilisateur n'a pas de dossier « tmp » dans son $HOME
normalement. Bon, je reconnais que je suis un mauvais exemple car j'en
ai un, mais les fichiers qu'il contient sont de mon fait.
Si les droits avaient été "777" (ou le user owner du répertoire) le
swap aurait été créé directement dans /tmp/test_00 et là en effet les
modifications en cours sont perdues en cas de crash.
Pas chez moi :
# ls -l /var/tmp
total 0
Dans une console en tant qu'utilisateur, je tape :
% vi a
Et pendant que vi est toujours actif :
# ls -l /var/tmp
total 0
-rw------- 1 benoit benoit 0 Dec 2 19:14 Ex0000002971
le 02/12/2011 à 08:33, denis paris a écrit dans le message <4ed87f48$0$24980$ :
OK, mais sur mon système (je viens de tester) vi créé un fichier .monfichier.swp dans le même répertoire que le fichier en cours d'édition, et propose de le récupérer en cas de crash (j'ai testé aussi: un kill de vi dans une autre fenêtre). et ce comportement me paraît très logique puisqu'on a forcément le droit d'écrire dans le répertoire du fichier que l'on édite.
C'est faux !
** root # mkdir -m751 /tmp/test_00 # cd /tmp/test_00 # touch a; chmod 666 a
** user % cd /tmp/test_00 % touch b touch: cannot touch `b': Permission denied % vi a % cat a coucou
Tu ne nous dis pas quels sont les droits réels de ton "user", selon son groupe il est dans le "5" ou dans le "1", pour que ça fonctionne je suppose qu'il est dans le "5", donc dans le groupe "root"
Tu connais beaucoup d'utilisateurs dans le groupe « root » ?
En tout cas chez moi je peux faire "cd /tmp/test_00 mais j'ai un "access deny" quand je fais simplement "ls", ce qui est normal.
Oui mais sans rapport avec le sujet de la discussion : « on a forcément le droit d'écrire dans le répertoire du fichier que l'on édite »
Tu ne dis pas non plus ou se créé le fichier ".a.swp" quand tu modifies le fichier: probablement dans le ~/tmp du user, donc dans un répertoire qui survivra à un reboot, ce qui est le sujet de ce sous-fil.
Non, un utilisateur n'a pas de dossier « tmp » dans son $HOME normalement. Bon, je reconnais que je suis un mauvais exemple car j'en ai un, mais les fichiers qu'il contient sont de mon fait.
Si les droits avaient été "777" (ou le user owner du répertoire) le swap aurait été créé directement dans /tmp/test_00 et là en effet les modifications en cours sont perdues en cas de crash.
Pas chez moi : # ls -l /var/tmp total 0
Dans une console en tant qu'utilisateur, je tape : % vi a
Et pendant que vi est toujours actif : # ls -l /var/tmp total 0 -rw------- 1 benoit benoit 0 Dec 2 19:14 Ex0000002971
C'est le vi fournit par défaut sur Archlinux.
-- Benoit Izac
denis.paris
Le 02/12/2011 19:21, Benoit Izac a écrit :
Bonjour,
le 02/12/2011 à 08:33, denis paris a écrit dans le message <4ed87f48$0$24980$ :
OK, mais sur mon système (je viens de tester) vi créé un fichier .monfichier.swp dans le même répertoire que le fichier en cours d'édition, et propose de le récupérer en cas de crash (j'ai testé aussi: un kill de vi dans une autre fenêtre). et ce comportement me paraît très logique puisqu'on a forcément le droit d'écrire dans le répertoire du fichier que l'on édite.
C'est faux !
** root # mkdir -m751 /tmp/test_00 # cd /tmp/test_00 # touch a; chmod 666 a
** user % cd /tmp/test_00 % touch b touch: cannot touch `b': Permission denied % vi a % cat a coucou
Tu ne nous dis pas quels sont les droits réels de ton "user", selon son groupe il est dans le "5" ou dans le "1", pour que ça fonctionne je suppose qu'il est dans le "5", donc dans le groupe "root"
Tu connais beaucoup d'utilisateurs dans le groupe « root » ?
En tout cas chez moi je peux faire "cd /tmp/test_00 mais j'ai un "access deny" quand je fais simplement "ls", ce qui est normal.
Oui mais sans rapport avec le sujet de la discussion : « on a forcément le droit d'écrire dans le répertoire du fichier que l'on édite »
Tu ne dis pas non plus ou se créé le fichier ".a.swp" quand tu modifies le fichier: probablement dans le ~/tmp du user, donc dans un répertoire qui survivra à un reboot, ce qui est le sujet de ce sous-fil.
Non, un utilisateur n'a pas de dossier « tmp » dans son $HOME normalement. Bon, je reconnais que je suis un mauvais exemple car j'en ai un, mais les fichiers qu'il contient sont de mon fait.
Si les droits avaient été "777" (ou le user owner du répertoire) le swap aurait été créé directement dans /tmp/test_00 et là en effet les modifications en cours sont perdues en cas de crash.
Pas chez moi : # ls -l /var/tmp total 0
Dans une console en tant qu'utilisateur, je tape : % vi a
Et pendant que vi est toujours actif : # ls -l /var/tmp total 0 -rw------- 1 benoit benoit 0 Dec 2 19:14 Ex0000002971
C'est le vi fournit par défaut sur Archlinux.
Le swap du fichier en cours d'édition est un fichier caché. Essaye ls -lA
Le 02/12/2011 19:21, Benoit Izac a écrit :
Bonjour,
le 02/12/2011 à 08:33, denis paris a écrit dans le message
<4ed87f48$0$24980$426a74cc@news.free.fr> :
OK, mais sur mon système (je viens de tester) vi créé un fichier
.monfichier.swp dans le même répertoire que le fichier en cours
d'édition, et propose de le récupérer en cas de crash (j'ai testé
aussi: un kill de vi dans une autre fenêtre). et ce comportement me
paraît très logique puisqu'on a forcément le droit d'écrire dans le
répertoire du fichier que l'on édite.
C'est faux !
** root
# mkdir -m751 /tmp/test_00
# cd /tmp/test_00
# touch a; chmod 666 a
** user
% cd /tmp/test_00
% touch b
touch: cannot touch `b': Permission denied
% vi a
% cat a
coucou
Tu ne nous dis pas quels sont les droits réels de ton "user", selon
son groupe il est dans le "5" ou dans le "1", pour que ça fonctionne
je suppose qu'il est dans le "5", donc dans le groupe "root"
Tu connais beaucoup d'utilisateurs dans le groupe « root » ?
En tout cas chez moi je peux faire "cd /tmp/test_00 mais j'ai un
"access deny" quand je fais simplement "ls", ce qui est normal.
Oui mais sans rapport avec le sujet de la discussion : « on a forcément
le droit d'écrire dans le répertoire du fichier que l'on édite »
Tu ne dis pas non plus ou se créé le fichier ".a.swp" quand tu
modifies le fichier: probablement dans le ~/tmp du user, donc dans un
répertoire qui survivra à un reboot, ce qui est le sujet de ce
sous-fil.
Non, un utilisateur n'a pas de dossier « tmp » dans son $HOME
normalement. Bon, je reconnais que je suis un mauvais exemple car j'en
ai un, mais les fichiers qu'il contient sont de mon fait.
Si les droits avaient été "777" (ou le user owner du répertoire) le
swap aurait été créé directement dans /tmp/test_00 et là en effet les
modifications en cours sont perdues en cas de crash.
Pas chez moi :
# ls -l /var/tmp
total 0
Dans une console en tant qu'utilisateur, je tape :
% vi a
Et pendant que vi est toujours actif :
# ls -l /var/tmp
total 0
-rw------- 1 benoit benoit 0 Dec 2 19:14 Ex0000002971
C'est le vi fournit par défaut sur Archlinux.
Le swap du fichier en cours d'édition est un fichier caché. Essaye ls -lA
le 02/12/2011 à 08:33, denis paris a écrit dans le message <4ed87f48$0$24980$ :
OK, mais sur mon système (je viens de tester) vi créé un fichier .monfichier.swp dans le même répertoire que le fichier en cours d'édition, et propose de le récupérer en cas de crash (j'ai testé aussi: un kill de vi dans une autre fenêtre). et ce comportement me paraît très logique puisqu'on a forcément le droit d'écrire dans le répertoire du fichier que l'on édite.
C'est faux !
** root # mkdir -m751 /tmp/test_00 # cd /tmp/test_00 # touch a; chmod 666 a
** user % cd /tmp/test_00 % touch b touch: cannot touch `b': Permission denied % vi a % cat a coucou
Tu ne nous dis pas quels sont les droits réels de ton "user", selon son groupe il est dans le "5" ou dans le "1", pour que ça fonctionne je suppose qu'il est dans le "5", donc dans le groupe "root"
Tu connais beaucoup d'utilisateurs dans le groupe « root » ?
En tout cas chez moi je peux faire "cd /tmp/test_00 mais j'ai un "access deny" quand je fais simplement "ls", ce qui est normal.
Oui mais sans rapport avec le sujet de la discussion : « on a forcément le droit d'écrire dans le répertoire du fichier que l'on édite »
Tu ne dis pas non plus ou se créé le fichier ".a.swp" quand tu modifies le fichier: probablement dans le ~/tmp du user, donc dans un répertoire qui survivra à un reboot, ce qui est le sujet de ce sous-fil.
Non, un utilisateur n'a pas de dossier « tmp » dans son $HOME normalement. Bon, je reconnais que je suis un mauvais exemple car j'en ai un, mais les fichiers qu'il contient sont de mon fait.
Si les droits avaient été "777" (ou le user owner du répertoire) le swap aurait été créé directement dans /tmp/test_00 et là en effet les modifications en cours sont perdues en cas de crash.
Pas chez moi : # ls -l /var/tmp total 0
Dans une console en tant qu'utilisateur, je tape : % vi a
Et pendant que vi est toujours actif : # ls -l /var/tmp total 0 -rw------- 1 benoit benoit 0 Dec 2 19:14 Ex0000002971
C'est le vi fournit par défaut sur Archlinux.
Le swap du fichier en cours d'édition est un fichier caché. Essaye ls -lA
Benoit Izac
Bonjour,
le 02/12/2011 à 19:53, denis paris a écrit dans le message <4ed91e92$0$8392$ :
# ls -l /var/tmp total 0 -rw------- 1 benoit benoit 0 Dec 2 19:14 Ex0000002971
C'est le vi fournit par défaut sur Archlinux.
Le swap du fichier en cours d'édition est un fichier caché. Essaye ls -lA
Et si c'était plutôt toi qui essayait ?
Fait des tests, après on discute, tu veux bien ?
-- Benoit Izac
Bonjour,
le 02/12/2011 à 19:53, denis paris a écrit dans le message
<4ed91e92$0$8392$426a34cc@news.free.fr> :
# ls -l /var/tmp
total 0
-rw------- 1 benoit benoit 0 Dec 2 19:14 Ex0000002971
C'est le vi fournit par défaut sur Archlinux.
Le swap du fichier en cours d'édition est un fichier caché. Essaye ls -lA
le 02/12/2011 à 19:53, denis paris a écrit dans le message <4ed91e92$0$8392$ :
# ls -l /var/tmp total 0 -rw------- 1 benoit benoit 0 Dec 2 19:14 Ex0000002971
C'est le vi fournit par défaut sur Archlinux.
Le swap du fichier en cours d'édition est un fichier caché. Essaye ls -lA
Et si c'était plutôt toi qui essayait ?
Fait des tests, après on discute, tu veux bien ?
C'est justement ce que j'ai fait: Cf mes messages d'hier et de ce matin !
J'ai pris cette peine mais ça n'a aucune importance, sauf que j'ai du louper un truc car je ne vois vraiment pas ce qui t'agace.
Bonne soirée tout de même.
Benoit Izac
Bonjour,
le 02/12/2011 à 20:42, denis paris a écrit dans le message <4ed92a23$0$21843$ :
C'est justement ce que j'ai fait: Cf mes messages d'hier et de ce matin !
J'ai pris cette peine mais ça n'a aucune importance, sauf que j'ai du louper un truc car je ne vois vraiment pas ce qui t'agace.
Ce qui m'agace, c'est que tu demandes un exemple de programme qui utilise /var/tmp, je te le donne et tu continues de nier.
Je t'ai dit que certain vi utilisaient /var/tmp pour mettre une copie de sauvegarde du fichier. Tu me rétorques que TA version de vi (vim si j'ai bien compris) n'utilisait pas /var/tmp.
Tu as ajouté que de toute manière un utilisateur pouvait toujours écrire dans le répertoire où ce trouve le fichier. Ce à quoi je t'ai montré un exemple qui contredisait ton affirmation.
Je te montre ensuite que MON vi utilise /var/tmp, à quoi tu me rétorques que le tiens non et que je devrais essayer. C'est fatiguant.
Pour te montrer une dernière fois que tu te trompes sur le fait que certain programmes utilisent /var/tmp pour de bonnes raisons, je te propose de faire ceci en root :
puis, sans fermer vim, tu jettes un oeil dans /var/tmp ou tu utilises lsof(8).
-- Benoit Izac
Bonjour,
le 02/12/2011 à 20:42, denis paris a écrit dans le message
<4ed92a23$0$21843$426a74cc@news.free.fr> :
C'est justement ce que j'ai fait: Cf mes messages d'hier et de ce matin !
J'ai pris cette peine mais ça n'a aucune importance, sauf que j'ai du
louper un truc car je ne vois vraiment pas ce qui t'agace.
Ce qui m'agace, c'est que tu demandes un exemple de programme qui
utilise /var/tmp, je te le donne et tu continues de nier.
Je t'ai dit que certain vi utilisaient /var/tmp pour mettre une copie de
sauvegarde du fichier. Tu me rétorques que TA version de vi (vim si j'ai
bien compris) n'utilisait pas /var/tmp.
Tu as ajouté que de toute manière un utilisateur pouvait toujours écrire
dans le répertoire où ce trouve le fichier. Ce à quoi je t'ai montré un
exemple qui contredisait ton affirmation.
Je te montre ensuite que MON vi utilise /var/tmp, à quoi tu me rétorques
que le tiens non et que je devrais essayer. C'est fatiguant.
Pour te montrer une dernière fois que tu te trompes sur le fait que
certain programmes utilisent /var/tmp pour de bonnes raisons, je te
propose de faire ceci en root :
le 02/12/2011 à 20:42, denis paris a écrit dans le message <4ed92a23$0$21843$ :
C'est justement ce que j'ai fait: Cf mes messages d'hier et de ce matin !
J'ai pris cette peine mais ça n'a aucune importance, sauf que j'ai du louper un truc car je ne vois vraiment pas ce qui t'agace.
Ce qui m'agace, c'est que tu demandes un exemple de programme qui utilise /var/tmp, je te le donne et tu continues de nier.
Je t'ai dit que certain vi utilisaient /var/tmp pour mettre une copie de sauvegarde du fichier. Tu me rétorques que TA version de vi (vim si j'ai bien compris) n'utilisait pas /var/tmp.
Tu as ajouté que de toute manière un utilisateur pouvait toujours écrire dans le répertoire où ce trouve le fichier. Ce à quoi je t'ai montré un exemple qui contredisait ton affirmation.
Je te montre ensuite que MON vi utilise /var/tmp, à quoi tu me rétorques que le tiens non et que je devrais essayer. C'est fatiguant.
Pour te montrer une dernière fois que tu te trompes sur le fait que certain programmes utilisent /var/tmp pour de bonnes raisons, je te propose de faire ceci en root :
