C'est vrai que laisser traîner un a.out, c'est pas très propre, mais cela ne change au rien au problème de PATH.
Il vaut donc mieux prendre l'habitude, effectivement, de nommer ses fichiers de sortie mais quand on code en C, il est carrément plus intelligent d'écrire tout de suite le Makefile associé. Pas long à écrire (surtout avec les expressions implicite), super facile à rappeler, et surtout, quand on fait "gcc test.c -o test", on a tendance à utiliser l'auto-complétion pour définir le nom de sortie, et il arrive toujours un moment ou l'on tape Entrée avant d'avoir tronqué l'extension. Et là, c'est "paf le fichier source".
Exact, et en plus, même sans aller jusque là, si on fait l'erreur de placer le point en début de chaîne, alors les exécutables locaux seront exécutés en priorité, ce qui peut complètement compromettre tout ce qui est réalisé à base de scripts shells, ce qui est quand même légion sous Unix. Sans compter les heures de débogages perdues à ne pas comprendre qu'on ne lance pas toujours le même exécutable avec la même commande ...
En outre, c'est un piège à éviter car non seulement c'est naturel à priori pour l'utilisateur, mais c'était également le comportement de DOS. Le nouvel utilisateur, habitué toutefois à la ligne de commande, contrairement aux plus jeunes d'entre nous, débarquait avec une floppée de (mauvaises) habitudes et avait tendance à vite remettre son "./" au début de son PATH pour retrouver le comportement orginal. C'est un peu comme le " alias dir='ls' " ... Il vaut mieux à la place prendre dès le départ les bons réflexes.
Pire, sous DOS, il y avait plusieurs types d'exécutables. Les *.com étaient prioritaires par rapport aux *.exe et comme le statut de fichier caché se donnait grâce à un flag et pas par une politique de nommage, on a eu toute une génération de virus compagnons qui traînaient dans les différents répertoires du système ...
Merci pour cette réponse, mais utilises-tu malgré tout le pilote "nvidia" propriétaire (pour avoir l'accélération) ? Car, autrement, avec "nv" tout fonctionne sans probleme, tout comme le framebuffer du noyau, etc. C'est d'ailleurs étrange que toutes ces fonctionalités soient capables de fonctionner avec un EDID cassé.
D'autre part, mon écran fait 1024x768 pixels, donc il faudra que j'adapte la modeline. Si tu as la bonne, cela m'arrange aussi.
Je te conseille dans un premier lieu de soigner la rédaction de tes messages si tu veux obtenir de l'aide sur un sujet aussi sensible, parce que là, ça fait vaguement script kiddy, comme attitude, et tu risques d'être le seul à être décrédibilisé.
Ensuite, sache que les instrusions non autorisées dans un système automatisé peuvent être désormais punies d'une peine allant jusqu'à trois ans de prison et 45 000 euros d'amende. Même si tu ne vas pas jusque là et que ces peines sont de toutes façons largement excessives, une chose est sûre : ce n'est pas parce que tu te fais pirater que cela te donne le droit d'en faire autant en retour (même si, généralement, ce n'est pas l'envie qui nous manque :-).
Si ton gusse cache son adresse IP, il n'y a pas de commande magique pour déduire sa position réelle, mais si tu en es là, ce n'est plus en termes techniques que tu dois raisonner, car visiblement le gars emploie les grands moyens. Même s'il est possible de forger des paquets avec une fausse adresse IP expéditeur, cela implique que la réponse ne peut lui parvenir, et il faut encore que ce paquet traverse sans encombre les routeurs de son fournisseur. Avec l'option -D de nmap, on peut spécifier une liste de fausses adresses mais la vraie reste forcément dans le lot. C'est donc un peu plus long à retrouver mais ça ne protège certainement pas ton pirate.
Le plus intelligent à faire dans ce cas est d'extraire une partie de tes logs et d'envoyer le tout en expliquant brièvement l'affaire aux boîtes "abuse" respectives de ton fournisseur d'accès et du sien (que tu retrouves en faisant un host sur les adresses attaquantes).
Et bien sûr, avant toute chose, il faut se servir un peu de son cerveau. Un scan massif est certes très désagréable et clairement pas conforme à la netiquette, mais ce n'est pas automatiquement une preuve de malveillance. Il se peut tout simplement qu'il s'agisse d'un internaute qui cherche des ressources volontairement ouvertes ou qui découvre un nouveau joujou logiciel d'audit réseau. Il est également fort probable, bien que l'on distingue en général aisément les deux, que tu aies en fait affaire à une machine Windows infectée, que le scan soit complètement automatique (même pas télécommandé) et que son propriétaire ne sache même pas qu'il te porte préjudice.
Dernier phénomène à prendre en compte avant de sortir l'artillerie : le Wifi. Ma maison est à portée d'une demi-douzaine de *Box de tous fournisseurs, et où que j'aille, il y en a toujours une qui est ouverte. Et pas seulement dans les boulangeries. A dire vrai, la dernière fois que j'ai configuré le Wifi d'un copain sur son WinXP neuf, on est quand même allé vérifier notre adresse IP sur un site quelquonque qui renvoie cette info, suivi d'un petit nslookup. On a bien fait : le pote en question est abonné chez Wanadoo mais son adresse appartenait à Club Internet ...
Tout ça pour dire que n'importe quel leecher peut aujourd'hui, sans aucune connaissance en informatique, aller acheter un portable à 600 euros, installer e-mule dessus et se balader en ville avec sa voiture pour trouver un relais qui lui permettra d'aller faire ses courses sans jamais être inquiété.
Devant cet épineux problème, le législateur a su se tirer d'affaire puisqu'il rend pénalement responsable le titulaire de l'accès qui la plupart du temps à déjà bien du mal à faire fonctionner sa boite à trente euros par mois, à moins qu'il fasse preuve de sa bonne foi. Puisque l'on n'est pas protégé par les structures chargées de le faire, c'est donc à toi d'être plus malin que ça si tu veux jouer aux administrateurs réseau.
Je cherche à écrire un shell qui vérifie l'existence d'un ou plusieurs fichiers (par ex "t*.txt"), et qui , si le ou les fichiers existent les déplace dans un répertoire old; s'ils n'existent pas, le programme sort avec un code de retour 1.
C'est dans le concept même que quelque chose cloche, et c'est pourquoi tu n'arriveras jamais à pondre ton algo.
" * " peut être substitué par un nombre indéfini de caractères, donc il est évident que le shell va développer cela en une liste des fichiers existants qui dont le nom valide le motif. S'il s'agissait de développer en toutes les combinaisons possibles, tu en obtiendrais une infinité !
Par contre, tu peux les développer dans un répertoire donné et vérifier s'ils existent tous dans un autre. Dans ce cas, le développement de toto="t*.txt*", effectué à la bonne place, fonctionnera. Mais pour le reste, tu n'as pas besoin d'une boucle : " mv " peut naturellement recevoir plus de deux arguments, auquel cas le dernier doit être un répertoire :
mv fichier1 fichier2 fichier3 monrepertoire/
Et si un des fichiers est inexistant, c'est la commande mv elle-même qui échouera et renverra ton code 1.
- Il manque un slash avant "dev"
- O_CREAT ne s'applique pas ici
- tu ne vérifies pas la validité de ton descripteur fd (en gros, tu ne vérifies pas si ton fichier a bien été ouvert).
- Tu n'as probablement pas les droits d'accès sur /dev/misc/lcd
En plus, les droits d'accès spécifiés ne s'appliquent qu'aux "autres". Essaie déja de faire " echo -n "tst" > /dev/misc/lcd " depuis la ligne de commande pour voir si tu parviens à tes fins.
En substance, c'est bien l'esprit, mais tu confonds tout de même plusieurs choses. Au niveau du hardware, la touche doit fonctionner exactement comme les autres, il n'y a pas de raison pour qu'elle soit accompagnée d'une piste parallèle sur la platine du clavier et faisant le tour des touches associées.
Par contre, il est plus que probable qu'elle ne soit pas transcrite dans le protocole PS/2, mais seulement accessible au travers d'un port I/O proprio.
Il n'y a pas forcément de keycode mais il y a toujours un scancode, et la touche Fn, n'étant pas partie intégrante des claviers standard, je ne suis pas sûr qu'elle soit gérée de la même façon que les touches modificatrices habituelles (voir mon post un peu plus bas).
Le noyau lit sur le port ps/2 ou usb sur lequel le clavier envoie ses codes keymap (en fait sur un portable c'est la même chose, c'est juste que la prise est shuntée)
C'est ce postulat de base qui me dérange. Tout ce qui suit en découle directement, du reste. Je pense que le clavier d'un portable est géré par un hardware propriétaire (puisqu'il est directement accessible, et non pas délocalisé et visible uniquement au travers du port PS/2 et du câble qui y est relié) et qu'à ce titre, la touche « Fn » qui, jusqu'à indication contraire, ne fait pas partie des spécifications PC standard et que l'on ne trouve pas sur un clavier autonome, n'est pas associée à un scancode donné.
Des tests effectués avec mon Toshiba 2410 montrent que ni xev, ni showkey -k, ni showkey -s (en mode console pour les deux derniers) ne renvoient d'événement pour un appui sur « Fn ». Par contre, j'en reçois quand je la combine avec certaines touches seulement, à savoir les modificateurs (Alt, Shift, etc) et les touches auxquelles une fonction spéciale Fn est associée, et seulement si cette fonction consiste à renvoyer un caractère comme, par exemple, le mappage du pavé numérique. Et même dans ce cas précis, je reçois alors le scancode de la touche sur laquelle j'ai appuyé, pas celle du pavé auquel elle est censée appartenir. Et dans tous les cas, aucune mention de la touche « Fn » elle-même.
Chose curieuse, l'utilisation de « Fn » prime sur tout le reste, commande showkey comprise, pour ce qui est de changer le périf vidéo de sortie, parce que c'est critique. Par contre, tout ce qui est réglage de luminosité, etc. est géré en userland, donc jamais par défaut sous Linux.
Autre chose intéressante : « Fn » utilisée avec les touches F10 ou F11 permet de simuler le Num Lock. Pas de scancode pour cette touche, donc, mais deux LED distinctes et mutuellement exclusives. D'autre part, chaque LED fonctionne en mode bascule, en passant du mode normalement allumé au mode normalement éteint et réciproquement sur sollicitation répetée des combinaisons « Fn + F10 » ou « Fn + F11 ». En temps normal, cela fonctionne très bien (et je ne crois pas que ce cas de figure précis soit pris en charge par Linux), mais sous une session showkey, la touche « Fn » fait bien réagir la LED, mais le mode ne change pas, car visiblement le code des touches F10 ou F11 est intercepté, mais pas celui de Fn.
Il fut d'ailleurs un temps où un « cat /proc/toshiba » renvoyait notamment un champ dont l'un des bits nous renseignait sur l'état de Fn, lorsque le module « toshiba » était bien chargé (je dis « il fut un temps » car mon dernier test ne fonctionne plus).
Donc, ce n'est pas simple, et c'est probablement spécifique à chaque constructeur.
C'est bien le problème. Pour autant que je sache, "Fn" n'est absolument pas une touche standard d'un clavier PC. C'est une fonctionnalité qui, je crois, a été ajouté par un fabricant d'ordinateurs portables et qui a été reprise par les autres. D'ailleurs, à y réfléchir, quelqu'un peut-il nous dire si oui ou non cette touche fait partie des recommandations PC annuelles ?
En conséquence, il y a de fortes chances pour cette touche soit en fait propriétaire et spécifique à chaque constructeur, ce qui implique l'utilisation d'un pilote pour la gérer.
Avec le temps, il est possible que X11 finissent par la prendre en charge directement, mais cela m'étonnerait que ce soit déjà fait.
- Plusieurs MO5, un MO6, un TO8D et un TO9+.
- Une mégadrive
- Une NES qui ne fonctionne plus
- Un CPC 6128+
- Un PC 8086 CGA 2x5''1/4 + Un dur de 10Mo installé par mes soins.
- Un 486DX33
et
Une boite originale de Windows 2.0 ! Estampillée Microsoft, elle porte la mention (à peu de chose près) : "Le système qui ouvre la voie vers le système d'exploitation de l'avenir : OS/2 " !
Bravo pour ta persévérence, mais dans un premier temps, et dans ton propre intérêt, apprend à faire des messages posés et construits avec le maximum d'infos pertinentes. A commencer par :
Quelle distribution as-tu tenté d'installer ?
Ensuite, qu'est-ce qui tu fait penser que tu as fait trois installations ? Le partionnement des disques ? Enfin, sache qu'un Linux est toujours réparable. En gros, on passe son temps à faire des configurations si ce n'est des compilations, mais on ne réinstalle jamais. Ca veut dire qu'il y a forcément une solution dans ton cas de figure, mais qu'il faut évidemment déjà connaître le système un tantinet pour pouvoir intervenir, et qu'il nous faut plus d'infos pour commencer à cerner ton problème.
[^] # Re: Répertoire courant
Posté par Obsidian . En réponse au message Lancer un .out dans une console. Évalué à 2.
Il vaut donc mieux prendre l'habitude, effectivement, de nommer ses fichiers de sortie mais quand on code en C, il est carrément plus intelligent d'écrire tout de suite le Makefile associé. Pas long à écrire (surtout avec les expressions implicite), super facile à rappeler, et surtout, quand on fait "gcc test.c -o test", on a tendance à utiliser l'auto-complétion pour définir le nom de sortie, et il arrive toujours un moment ou l'on tape Entrée avant d'avoir tronqué l'extension. Et là, c'est "paf le fichier source".
[^] # Re: Répertoire courant
Posté par Obsidian . En réponse au message Lancer un .out dans une console. Évalué à 2.
En outre, c'est un piège à éviter car non seulement c'est naturel à priori pour l'utilisateur, mais c'était également le comportement de DOS. Le nouvel utilisateur, habitué toutefois à la ligne de commande, contrairement aux plus jeunes d'entre nous, débarquait avec une floppée de (mauvaises) habitudes et avait tendance à vite remettre son "./" au début de son PATH pour retrouver le comportement orginal. C'est un peu comme le " alias dir='ls' " ... Il vaut mieux à la place prendre dès le départ les bons réflexes.
Pire, sous DOS, il y avait plusieurs types d'exécutables. Les *.com étaient prioritaires par rapport aux *.exe et comme le statut de fichier caché se donnait grâce à un flag et pas par une politique de nommage, on a eu toute une génération de virus compagnons qui traînaient dans les différents répertoires du système ...
[^] # Re: Répertoire courant
Posté par Obsidian . En réponse au message Lancer un .out dans une console. Évalué à 7.
Hmm, ça c'est un conseil à ne pas donner.
[^] # Re: je sais pas si ca peut aider
Posté par Obsidian . En réponse au message nVidia : Plantage du module noyau avec Xorg sur un Toshiba. Évalué à 2.
D'autre part, mon écran fait 1024x768 pixels, donc il faudra que j'adapte la modeline. Si tu as la bonne, cela m'arrange aussi.
A+
# Aïe ! Mes yeux !
Posté par Obsidian . En réponse au message scan nmap.... Évalué à 6.
Ensuite, sache que les instrusions non autorisées dans un système automatisé peuvent être désormais punies d'une peine allant jusqu'à trois ans de prison et 45 000 euros d'amende. Même si tu ne vas pas jusque là et que ces peines sont de toutes façons largement excessives, une chose est sûre : ce n'est pas parce que tu te fais pirater que cela te donne le droit d'en faire autant en retour (même si, généralement, ce n'est pas l'envie qui nous manque :-).
Si ton gusse cache son adresse IP, il n'y a pas de commande magique pour déduire sa position réelle, mais si tu en es là, ce n'est plus en termes techniques que tu dois raisonner, car visiblement le gars emploie les grands moyens. Même s'il est possible de forger des paquets avec une fausse adresse IP expéditeur, cela implique que la réponse ne peut lui parvenir, et il faut encore que ce paquet traverse sans encombre les routeurs de son fournisseur. Avec l'option -D de nmap, on peut spécifier une liste de fausses adresses mais la vraie reste forcément dans le lot. C'est donc un peu plus long à retrouver mais ça ne protège certainement pas ton pirate.
Le plus intelligent à faire dans ce cas est d'extraire une partie de tes logs et d'envoyer le tout en expliquant brièvement l'affaire aux boîtes "abuse" respectives de ton fournisseur d'accès et du sien (que tu retrouves en faisant un host sur les adresses attaquantes).
Et bien sûr, avant toute chose, il faut se servir un peu de son cerveau. Un scan massif est certes très désagréable et clairement pas conforme à la netiquette, mais ce n'est pas automatiquement une preuve de malveillance. Il se peut tout simplement qu'il s'agisse d'un internaute qui cherche des ressources volontairement ouvertes ou qui découvre un nouveau joujou logiciel d'audit réseau. Il est également fort probable, bien que l'on distingue en général aisément les deux, que tu aies en fait affaire à une machine Windows infectée, que le scan soit complètement automatique (même pas télécommandé) et que son propriétaire ne sache même pas qu'il te porte préjudice.
Dernier phénomène à prendre en compte avant de sortir l'artillerie : le Wifi. Ma maison est à portée d'une demi-douzaine de *Box de tous fournisseurs, et où que j'aille, il y en a toujours une qui est ouverte. Et pas seulement dans les boulangeries. A dire vrai, la dernière fois que j'ai configuré le Wifi d'un copain sur son WinXP neuf, on est quand même allé vérifier notre adresse IP sur un site quelquonque qui renvoie cette info, suivi d'un petit nslookup. On a bien fait : le pote en question est abonné chez Wanadoo mais son adresse appartenait à Club Internet ...
Tout ça pour dire que n'importe quel leecher peut aujourd'hui, sans aucune connaissance en informatique, aller acheter un portable à 600 euros, installer e-mule dessus et se balader en ville avec sa voiture pour trouver un relais qui lui permettra d'aller faire ses courses sans jamais être inquiété.
Devant cet épineux problème, le législateur a su se tirer d'affaire puisqu'il rend pénalement responsable le titulaire de l'accès qui la plupart du temps à déjà bien du mal à faire fonctionner sa boite à trente euros par mois, à moins qu'il fasse preuve de sa bonne foi. Puisque l'on n'est pas protégé par les structures chargées de le faire, c'est donc à toi d'être plus malin que ça si tu veux jouer aux administrateurs réseau.
Bon courage.
[^] # Re: Ebauche de solution
Posté par Obsidian . En réponse au message A l'aide. Évalué à 2.
[^] # Re: le coup du génie de la lampe
Posté par Obsidian . En réponse au journal Que libéreriez-vous si vous aviez 100 millions de dollars ?. Évalué à 2.
# Revoir problématique
Posté par Obsidian . En réponse au message mv conditionnel. Évalué à 4.
C'est dans le concept même que quelque chose cloche, et c'est pourquoi tu n'arriveras jamais à pondre ton algo.
" * " peut être substitué par un nombre indéfini de caractères, donc il est évident que le shell va développer cela en une liste des fichiers existants qui dont le nom valide le motif. S'il s'agissait de développer en toutes les combinaisons possibles, tu en obtiendrais une infinité !
Par contre, tu peux les développer dans un répertoire donné et vérifier s'ils existent tous dans un autre. Dans ce cas, le développement de toto="t*.txt*", effectué à la bonne place, fonctionnera. Mais pour le reste, tu n'as pas besoin d'une boucle : " mv " peut naturellement recevoir plus de deux arguments, auquel cas le dernier doit être un répertoire :
mv fichier1 fichier2 fichier3 monrepertoire/
Et si un des fichiers est inexistant, c'est la commande mv elle-même qui échouera et renverra ton code 1.
[^] # Re: je m'y colle
Posté par Obsidian . En réponse au journal Hans Reiser arrêté. Évalué à 5.
Ben là, en l'occurence, c'est plutôt ->[||||] ...
# Alors, en vrac :
Posté par Obsidian . En réponse au message ecriture sur peripherique. Évalué à 5.
- O_CREAT ne s'applique pas ici
- tu ne vérifies pas la validité de ton descripteur fd (en gros, tu ne vérifies pas si ton fichier a bien été ouvert).
- Tu n'as probablement pas les droits d'accès sur /dev/misc/lcd
En plus, les droits d'accès spécifiés ne s'appliquent qu'aux "autres". Essaie déja de faire " echo -n "tst" > /dev/misc/lcd " depuis la ligne de commande pour voir si tu parviens à tes fins.
[^] # Re: fnfx
Posté par Obsidian . En réponse au message a quel code corresponds la combinaison Fn+Fx(1-12) ?. Évalué à 2.
Par contre, il est plus que probable qu'elle ne soit pas transcrite dans le protocole PS/2, mais seulement accessible au travers d'un port I/O proprio.
[^] # Re: .
Posté par Obsidian . En réponse au message a quel code corresponds la combinaison Fn+Fx(1-12) ?. Évalué à 2.
[^] # Re: fnfx
Posté par Obsidian . En réponse au message a quel code corresponds la combinaison Fn+Fx(1-12) ?. Évalué à 2.
C'est ce postulat de base qui me dérange. Tout ce qui suit en découle directement, du reste. Je pense que le clavier d'un portable est géré par un hardware propriétaire (puisqu'il est directement accessible, et non pas délocalisé et visible uniquement au travers du port PS/2 et du câble qui y est relié) et qu'à ce titre, la touche « Fn » qui, jusqu'à indication contraire, ne fait pas partie des spécifications PC standard et que l'on ne trouve pas sur un clavier autonome, n'est pas associée à un scancode donné.
Des tests effectués avec mon Toshiba 2410 montrent que ni xev, ni showkey -k, ni showkey -s (en mode console pour les deux derniers) ne renvoient d'événement pour un appui sur « Fn ». Par contre, j'en reçois quand je la combine avec certaines touches seulement, à savoir les modificateurs (Alt, Shift, etc) et les touches auxquelles une fonction spéciale Fn est associée, et seulement si cette fonction consiste à renvoyer un caractère comme, par exemple, le mappage du pavé numérique. Et même dans ce cas précis, je reçois alors le scancode de la touche sur laquelle j'ai appuyé, pas celle du pavé auquel elle est censée appartenir. Et dans tous les cas, aucune mention de la touche « Fn » elle-même.
Chose curieuse, l'utilisation de « Fn » prime sur tout le reste, commande showkey comprise, pour ce qui est de changer le périf vidéo de sortie, parce que c'est critique. Par contre, tout ce qui est réglage de luminosité, etc. est géré en userland, donc jamais par défaut sous Linux.
Autre chose intéressante : « Fn » utilisée avec les touches F10 ou F11 permet de simuler le Num Lock. Pas de scancode pour cette touche, donc, mais deux LED distinctes et mutuellement exclusives. D'autre part, chaque LED fonctionne en mode bascule, en passant du mode normalement allumé au mode normalement éteint et réciproquement sur sollicitation répetée des combinaisons « Fn + F10 » ou « Fn + F11 ». En temps normal, cela fonctionne très bien (et je ne crois pas que ce cas de figure précis soit pris en charge par Linux), mais sous une session showkey, la touche « Fn » fait bien réagir la LED, mais le mode ne change pas, car visiblement le code des touches F10 ou F11 est intercepté, mais pas celui de Fn.
Il fut d'ailleurs un temps où un « cat /proc/toshiba » renvoyait notamment un champ dont l'un des bits nous renseignait sur l'état de Fn, lorsque le module « toshiba » était bien chargé (je dis « il fut un temps » car mon dernier test ne fonctionne plus).
Donc, ce n'est pas simple, et c'est probablement spécifique à chaque constructeur.
[^] # Re: fnfx
Posté par Obsidian . En réponse au message a quel code corresponds la combinaison Fn+Fx(1-12) ?. Évalué à 2.
En conséquence, il y a de fortes chances pour cette touche soit en fait propriétaire et spécifique à chaque constructeur, ce qui implique l'utilisation d'un pilote pour la gérer.
Avec le temps, il est possible que X11 finissent par la prendre en charge directement, mais cela m'étonnerait que ce soit déjà fait.
# Moi j'ai
Posté par Obsidian . En réponse au journal [Journal inutile]Dans mon grenier.... Évalué à 5.
- Une mégadrive
- Une NES qui ne fonctionne plus
- Un CPC 6128+
- Un PC 8086 CGA 2x5''1/4 + Un dur de 10Mo installé par mes soins.
- Un 486DX33
et
Une boite originale de Windows 2.0 ! Estampillée Microsoft, elle porte la mention (à peu de chose près) : "Le système qui ouvre la voie vers le système d'exploitation de l'avenir : OS/2 " !
Collector.
# Bienvenue
Posté par Obsidian . En réponse au message AU SECOURS, AIDEZ-MOI! J'AI ME SUIS PLANTé!!!!!. Évalué à 3.
Bravo pour ta persévérence, mais dans un premier temps, et dans ton propre intérêt, apprend à faire des messages posés et construits avec le maximum d'infos pertinentes. A commencer par :
Quelle distribution as-tu tenté d'installer ?
Ensuite, qu'est-ce qui tu fait penser que tu as fait trois installations ? Le partionnement des disques ? Enfin, sache qu'un Linux est toujours réparable. En gros, on passe son temps à faire des configurations si ce n'est des compilations, mais on ne réinstalle jamais. Ca veut dire qu'il y a forcément une solution dans ton cas de figure, mais qu'il faut évidemment déjà connaître le système un tantinet pour pouvoir intervenir, et qu'il nous faut plus d'infos pour commencer à cerner ton problème.
Bon courage.
[^] # Simple :
Posté par Obsidian . En réponse au journal Hans Reiser arrêté. Évalué à 2.
[^] # Re: Retour d'experience
Posté par Obsidian . En réponse au journal Présentation microsoft UTC. Évalué à 3.
[^] # Re: Gnome 3
Posté par Obsidian . En réponse au sondage Vivement. Évalué à 8.
http://en.wikipedia.org/wiki/Repetitive_strain_injury
[^] # Re: script
Posté par Obsidian . En réponse au message script shell de compression et nettoyage. Évalué à 1.
$ man find
[^] # Re: script
Posté par Obsidian . En réponse au message script shell de compression et nettoyage. Évalué à 3.
1 ) Nettoyer des fichiers de quelle nature ?
[^] # Re: precisions ?
Posté par Obsidian . En réponse au message package de GET. Évalué à 1.
[^] # Re: Moi, je dis :
Posté par Obsidian . En réponse au journal [mavie] Le javascript ca pue. Évalué à 2.
[^] # Re: Pour être plus exact.
Posté par Obsidian . En réponse au journal 1984. Évalué à 4.
Nan, c'est un fake. C'est pas possible autrement ...
[^] # Re: Moi, je dis :
Posté par Obsidian . En réponse au journal [mavie] Le javascript ca pue. Évalué à 2.