Toute façon, chais pas le changer

" Mais non... Jamais eu aucun problème..."
-> Franchement si t´avais pas essayé NetBSD j´aurai pas peur de te répondre que " le pionnier, ici, c´est moi" ; )

Pour en changer c´est très simple, mais c´est pas interessant.

Panther> On ajoute tout ce qu´on a écrit ici à ton kiwi ?

J´ai pas bien compris ce que c´est que la commande " >"
J´ai par exemple stocké le contenu d´un dossier contenant des texte dans un fichier nommé " fichier1"
Mais maintenant, je sais pas bien à quoi sers ce fichier, vu que je ne peut pas l´ouvrir, je ne le vois même pas dans le dossier ( dans le finder) alors qu´avec ls dans le terminal, il y est . ..
( c´est assez confu, désolé, j´espere que vous comprendrez)

Relis ce que t´as dit DasHuhn sur STDIN et STDOUT mais je sais pas comment t´expliquer le reste...

Voilà je t´avais bien dit que t´en avais trop fait. J´ai pas le temps de répondre maintenant dsl.

J´en ai trop fait, c´est à dire ?

Je parlais à Panther. Tu ne devrais pas chercher à comprendre les > et tout ça pour le moment. Mais briévement : quand tu utilises > c´est comme si tu débranchais le tuyau stdout de l´écran pour le replacer sur le fichier dont tu donnes le nom après : les caractères qui sont envoyés dans ton tuyau de sortie iront dans le fichier.

Je comprends pas ton problème avec le fichier :o es-tu sur que ce n´est pas un fichier caché ( avec un point au début de son nom) ? Qu´il est bien dans le bon répertoire où tu cherches ?

Certes, certes, j´avais pas totalement lu ce que tu avais mis dans ton message antérieur sur les STDIN et STDOUT. Désolé... Oublies ça Lutin-de-la-CIA et tu y repensera lorsque tu aura une parfaite maitrise de la force.

( Je suis Lutin ( voir carte de visite) )
Ok
Je vais bientot finir ça http://www.macosxtech.com.com/dossiers/index.php?art=13
Et j´aimerais un exemple assez concret de ce à quoi peut servir le Terminal ( à mon niveau, si possible )

Tu veux dire : par rapport à une interface graphique ?

- Combinarité des programmes ( tu peux les assembler comme des legos pour obtenir un certain résultat)
- Accès à plein de choses pas disponibles graphiquement - c´est plus facile ( beaucoup plus facile même) de développer pour ligne de commande donc parfois ils ont la flemme de développer un truc graphiquement.
- Accès aux informations de déboggage... quand un programme est encore en développement, il est rare que les développeurs se fassent chier à inclure les rapports de bugs dans l´interface. Ainsi, parfois, ils conseillent de refaire ce qui a fait planté le programme en le lançant depuis la ligne de commande - comme ça l´utilisateur n´a qu´à envoyer les 5 derniers messages du programme aux développeurs, qui eux les comprendront.
- Portabilité : les développements pour ligne de commande utilisent toujours les mêmes recettes, sans cesses recomposées depuis la création d´Unix... alors on les trouve partout ! Si tu programmes, ça veut dire que tu ne seras pas dépaysé. Si tu utilises des programmes, ça veut dire que tu trouveras toujours les mêmes outils, avec très peu de variations.
- Scriptabilité : même si ça a peu de sens sur Mac avec AppleScript pour les applications graphiques, les shells disposent d´un langage de programmation interne très puissant.
- Légereté : ça se sent pas avec les machines dont on dispose aujourd´hui... mais des programmes qui importent en MP3 haute qualité n´ont pas besoin d´interface graphique puisque leur travail est toujours le même - pourquoi réserver de la place en mémoire pour rien alors ? C´est le grand défaut des interfaces graphiques : chaque programme veut toujours réinventer la roue, et plusieurs partagent généralement des fonctions. Ca serait quand même plus utile que chacun se spécialise dans une branche...
- Si tu comptes un jour programmer, plus de temps tu passeras dans le bain plus tu comprendras certaines choses vite.

Merci, mais c´est pas ça que je demande ( même si ce truc est bien aussi )
Je voudrait par exemple, pour toi, la derniere fosi que tu t´es servi du Terminal, c´était pour faire quoi ?

achdezo >

- Combinarité des programmes : C´est pas justement un truc du C++ et de l´objectiv C, l´héritage ?

-> ils ont la flemme de développer un truc graphiquement.

Il faut vraiment avoir la flemme… Parce qu´avec Interface Builder, c´est tellement simple et rapide !

Pour le reste, c´est comme d´habitude.

Entre écrire code+interface ou juste code, même en y mettant la meilleure volonté c´est plus rapide de n´écrire que le code

Dites personne ne sait ici comment lancer une application graphique à partir du Terminal, tout en lui laissant la main.

Je m´explique, par exemple pour lancer Safari, je fait `open Safari`, l´application se lance mais le shell me rend la main, or je voudrais qu´il la garde ( c´est pour faire des tests avec time).

Battx> Tant que j´ai pas à déplacer des fichiers, un shell me suffit largement. Et après tu as des outils qui remplissent les mêmes fonctions que le Finder ( en moins bien ça c´est clair ^^) depuis la ligne de commande, du moins j´en ai vu sous Linux. Mais quand il s´agit d´envoyer un fichier sur un FTP, ou un truc du genre, j´utilise le terminal.
Cela dit, maintenant que je possède un Finder qui répond quand je lui demande ( je ne disposais pas de ça sur mon ancien VIEUX Mac) je suis parfaitement conscient que le shell est limité dans la gestion des fichiers.

" C´est pas justement un truc du C++ et de l´objectiv C, l´héritage ?   "
-> C´est pas la même chose. Tu parles de réutiliser du code, ce qui est, c´est vrai, une très bonne chose : en Python, en AppleScript, en C ou même en ASM, quand on n´a pas à recoder quelque chose, c´est tout bon. Mais les programmes non graphiques proposent aussi d´enchaîner les tuyaux comme j´en ai parlé déjà sur ce topic. Même si on a fait des progrès avec le " drag&" et AppleScript, c´est pas tout à fait au point.

" Il faut vraiment avoir la flemme… Parce qu´avec Interface Builder, c´est tellement simple et rapide !   "
-> Sauf que quand tu débugues un de tes logiciels qui fait 5000 lignes, tu te prends pas la tête à coder des routines graphiques pour indiquer où en est le programme et où il sature. Au contraire, de simples
NSLog(@"Lancement de machin truc");
te suffisent. Et comme de toute façon l´utilisateur n´a pas les compétences nécessaires pour comprendre un message d´erreur quand c´est le Runtime qui foire un truc... la Console et un lancement en ligne de commande suffisent laaaargement.

Et c´est pas ma faute si quand je demande un équivalent de lsof graphique sur Mac on me répond " connais pas". T´en as un toi ? Perso je vais me lancer ( pas motivé ^^) dans le mien, parce que ça manque. Mais force est de constater que plein de choses existent en ligne de commande et pas graphiquement. Sans oublier la portabilité, si tu veux une lib graphique portable c´est AWT ( Java), Swing ( Java), GTK ( C/C++, regarde Gimp), Tkinter ( hahaha, Python), un autre truc à base de TCL/TK ( aMSN, mwahaha aussi), etc...

Et de toute façon si tu veux te lancer dans l´informatique t´as pas le choix.

Panther> Application.app/Contents/MacOS/Executable Mach-0

Exemple :

Chapter24:~ dashuhn$ cd / Applications
Chapter24:/Applications dashuhn$ cd Adium.app/Contents/MacOS/
Chapter24:/Applications/Adium.app/Contents/MacOS dashuhn$ time . /Adium

real 0m5.250s
user 0m1.060s
sys 0m0.410s

( Non l´exemple ne présente aucun interêt mais je crois que j´ai compris ce que tu voulais faire DON´T WORRY)

Gracie signor, je vais essayer des décompressions pour l´instant.

Mouarf, veut pas le lancer:

-bash: . /StuffIt Expander: cannot execute binary file

Au fait, ton message en haut, j´ai pas essayé NetBSD mais FreeBSD Et c´est tout faible, il y a un installateur puis tous les outils standards de Linux genre KDE ou autres conneries du genre.