"Langages de scripts sous linux", écrit par C. Blaess bien que faisant simplement une présentation de plusieurs langages de scripts (Shell Bash, Sed, Awk, Perl, Tcl, Tk, Python, Ruby) est véritablement complet. Il donne enormément d'informations pour l'écriture de scripts sous Linux, et il se destine, surtout pour la partie Bash, aussi bien aux débutants (qui peuvent apprendre beaucoup de commandes de ce shell pouvant être utile tous les jours), qu'aux utilisateurs un peu plus avancé désirant mieux parfaire leur maîtrise du système.
Tout les différents langages sont mis sur un même pied d'égalité, C. Blaess les présente tous avec leurs points forts et les situations où ils sont vraiment utiles. De bonnes explications et de bon exemples rehaussent le tout.
Un livre a mettre en toute les mains.
Aller plus loin
# Incomplet
Posté par Pascal Terjan (site web personnel) . Évalué à -5.
[^] # Re: Incomplet
Posté par elanfou . Évalué à -6.
[^] # Re: Incomplet
Posté par matiasf . Évalué à -4.
Mais non !
PHP c'est compile comme Perl et ca arrive pas a la cheville de sed...
[^] # Re: Incomplet
Posté par Tame . Évalué à 0.
www.php.net, c'est a gauche :)
[^] # Re: Le PHP n'a rien a faire dans ce bouquin
Posté par Amaury . Évalué à 10.
Et pour cela, les langages de prédilections plus ou moins destinés à cet usage sont :
- shell + sed + awk d'un coté,
- et des langages conçus pour (à l'origine, par exemple Perl sait depuis faire plein d'autres choses) synthétiser les 3 précédents "langages" : Perl, Python, Ruby (et tcl/tk pour les applis X).
Même si ces langages ont pas mal évolué depuis (Perl, Python etc), il faut bien voir qu'à l'origine ils étaient surtout utilisés pour concevoir des scripts "standalone", executés localement sur une babasse (ou un réseau), pour faire de l'admin de base.
En revanche, PHP a été conçu dans un esprit totalement différent : concevoir un langage pour faciliter l'écriture de scripts CGI. Et même si sa popularité commence à lui permettre de "dévier" vers un usage moins orienté "web" (on commence à voir des scripts locaux à une bécane écrits en PHP - énôôôôrme bétise AMHA), il reste bien distinct du triplet Python/Perl/Ruby.
Donc bon, si vous commencez à maîtriser le PHP et que vous voulez vous faire quelques scripts d'admin locaux à votre bécane ou autre (non CGI, donc), je ne saurais trop vous conseiller de jetre un oeil du coté d'un de ces 3 langages... parmis lesquels Perl est sans doutes le plus facilement acessible. Mais par pitié laissez PHP là où il est bon c'est à dire sur le web...
[^] # Suis-je tombé dedans?
Posté par schyzomarijks . Évalué à 4.
Avec PHP, on manipule des chaines de caractères, analyser un systèle de fichier, gérer les droit d'accès au fichier...
Je crois que c'est plus une question de tradition. Mais a première vu, je ne vois pas de contre indication à l'utilisation de PHP pour faire du script.
[^] # Re: Suis-je tombé dedans?
Posté par Amaury . Évalué à 10.
PHP est un langage jeune. PHP a été conçu pour faire des CGI. Il le fait pas mal.
Perl a été conçu pour faire de l'admin. Ca fait 10 ans que des milliers d'admins utilisent et contribuent à ce langage. Le nombre de modules pour Perl est innimaginable.
De toutes façon, les trolls "Titi est mieux que toto" sont stériles. J'ai pas d'action chez Perl ni PHP... et j'utilise les 2 langages, mais je trouve la "dérive" de PHP vers l'admin sys contre-nature... tout cela parce que plein de gens ont appris à programmer avec PHP et que pour cette raison ils vouent un culte à ce langage.
Regarde 2 secondes la beauté de la gestion des regexp en Perl, tu vas comprendre ta douleur (quelles horreurs ces preg/ereg !!!).
Bon, n'embrayons pas sur un troll entre langages, c'est juste mon avis et il ne vaut qu'en tant que tel, et visiblement l'auteur du bouquin le partage aussi car PHP n'y figure pas.
[^] # Re: Suis-je tombé dedans?
Posté par sToR_K . Évalué à -5.
-Le nombre de module de PHP est énorme(et AMA le developpement des modules PHP est plus actif)
-Pour la beauté des regexp en perl, cela tient plus de la branlette intelectuelle qu'autre chose...
-Je trouve aussi que Perl est un langage parfait pour l'admin systeme mais l'accessibilité de PHP lui permettra bientot(?) de faire parti de ces langages
PS:
je trouve la "dérive" de PHP vers l'admin sys contre-nature
.... comme la s*d*mie?
[^] # Re: Le PHP n'a rien a faire dans ce bouquin
Posté par Netsabes . Évalué à 0.
[^] # Re: Le PHP n'a rien a faire dans ce bouquin
Posté par didbaba . Évalué à -3.
[^] # Re: Le PHP n'a rien a faire dans ce bouquin
Posté par Pascal Terjan (site web personnel) . Évalué à 7.
Je ne vois pas le rapport entre avoir PHP sur sa machine et avoir un serveur Web !
Tu installes la version CGI de PHP dans /usr/local/bin, tu fais un script PHP avec au début #!/usr/local/bin/php -q et voila !
Voir http://www.php.net/manual/en/commandline.php(...) pour plus d'infos.
[^] # Re: Le PHP n'a rien a faire dans ce bouquin
Posté par didbaba . Évalué à 1.
Maintenant je sais, merc.
Il va vraiment falloir qu'un jour je me décide à lire ce manuel.
[^] # euh pour le web...
Posté par blackshack . Évalué à 1.
[^] # Re: Le PHP n'a rien a faire dans ce bouquin
Posté par sToR_K . Évalué à -2.
(Nos arguments sont à peu près équivalents)
# C. Blaess ?
Posté par Eric Leblond (site web personnel) . Évalué à 7.
Éspérons que ce livre le récompense financièrement du fabuleux travail qu'il a effectué jusqu'ici.
Allez, répétez après moi : "tiens ? et si je l'achetais ?"
[^] # Cristophe Blaess...
Posté par blackshack . Évalué à 2.
Félicitation mr Blaess
'd'ailleurs j'ai mis la news car j'ai acheté le bouquin et que j'ai commence a le lire...'
[^] # Re: Cristophe Blaess...
Posté par martinc . Évalué à 1.
Très bon bouquin (sauf la reliure trop fragile), synthétique mais pas simpliste et pas cher pour ce qu'il apporte.
# Ah ... c'est le livre des programmateurs ?
Posté par Dugland Bob . Évalué à -2.
cf : 4ème de couv, ça la fout mal pour le traducteur des manpages
vu et dispo chez Dialogues à Brest (http://www.dialoguesenligne.com/(...) )
[-1 mesquin]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.