Il y a un programme que toute personne un tant soit peu expérimentée sous systèmes UNIX a déjà utilisé. Il est la base de tout travail quotidien. C'est ce bon bon vieux shell, sans lequel beaucoup de choses serait moins facilement faisable.
Le shell a pour but principal de lancer des programmes, de faciliter la tâche de l'utilisateur grâce aux substitutions, aux redirections, aux pipes, aux alias, à la complétion, et bien d'autres choses.
Très peu de gens utilisent pourtant des fonctions bien utiles du shell pour la simple et bonne raison qu'ils n'ont pas connaissance de ces fonctions.
Personnellement, j'ai toujours utiliser bash parce qu'il était le shell par défaut sur toutes les distribs que j'ai essayé.
Et pourtant, après maintes lectures ou plutôt survols - il faut bien l'avouer :) - de la longue page de man de bash, chaque fois je découvre de nouvelles fonctions...
Dernièrement, j'ai découvert une fonction très pratique, malheureusement spécifique à bash, il me semble. Il s'agit d'un pseudo fichier de bash (qui n'existe pas) de la forme /dev/tcp/hostname/port. En ouvrant ce fichier, bash fait automatiquement la connexion vers hostname:port. Cette syntaxe est aussi valable pour le protocole UDP avec /dev/udp/hostname/port.
Et moi qui croyait qu'il était pratiquement nécessaire d'installer netcat pour avoir un telnet-UDP !
Et même s'il est simple d'utiliser à travers des pipes des commandes telles que sed, awk, il est parfois utile de connaître des syntaxes du genre ${parameter%word}
Pour ceux qui ont la flemme d'ouvrir un terminal et de taper man bash, ou ceux qui n'ont pas la version traduite en français de cette page, voici un lien donné par Google :
http://dpobel.free.fr/man/html/affiche_man.php/105/man/bash/(...)
D'ailleurs, ayant pris un soudain intérêt pour le shell-scripting, j'ai écrit un client ftp entièrement en bash. Et je dis bien entièrement :) Toutes les commandes que j'utilise sont des commandes internes (builtin comme on dit) ou des syntaxes de bash. Je n'ai fait aucun usage de programme externe, ceux résidant dans /bin ou /usr/bin.
C'est disponible ici :
http://perso.wanadoo.fr/kdntl/depotoir/ftp.sh.txt(...)
Ça serait sympa si vous pouviez le tester. Mais attention, si mon truc bug et vous efface des fichiers, je suis pas responsable :p
J'aurais bien aimé aussi qu'un grand gourou du shell passe par là et améliore le script, en écrivant certaines lignes de manières plus élégantes, plus courtes par exemple.
Et vous, que trouvez-vous pratique voire étonnant dans votre shell favori ? Pourquoi le préférez-vous aux autres shells ? Est-il possible de faire un ftp.sh avec votre shell ?
# \o/
Posté par Victor . Évalué à 4.
bash, je t'aime !
(bon ok, jvai le tester ton client !)
# Advanced Bash-Scripting Guide
Posté par Gniarf . Évalué à 5.
http://www.tldp.org/LDP/abs/html/index.html(...)
[^] # Re: Advanced Bash-Scripting Guide
Posté par Damien Pobel (site web personnel) . Évalué à 4.
Sinon je vois que l'auteur cite une page de mon site, ça fait plaisir :)))
https://damien.pobel.fr
[^] # Re: Advanced Bash-Scripting Guide
Posté par Gniarf . Évalué à 2.
# Debian POWA
Posté par LLG . Évalué à 8.
Extrait de /usr/share/doc/bash/README.Debian.gz:
"9. Why is bash configured with --disable-net-redirections?
It can produce completely unexpected results. This kind of
feature should not be part of a shell but a special. tool. And
that tool has existed for years already, it's called netcat."
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Debian POWA
Posté par cho7 (site web personnel) . Évalué à 2.
T'as lu 1 argument sur 2 :
It can produce completely unexpected results
Voilà, c'est surtout ça la vrai raison. Et ne me demande pas le genre de résultats inattendus, je n'en sais fichtrement rien mais je ne vois pas pourquoi les gars de chez debian se seraient fait chier a retirer une feature simplement pour le plaisir.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Debian POWA
Posté par Wawet76 . Évalué à 5.
Loïc ne va pas pouvoir répondre à cause de l'intervention de cho7 ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Debian POWA
Posté par Juke (site web personnel) . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
# RoXoR !
Posté par Obsidian . Évalué à 4.
Déjà, cela montre ce que c'est que de lire une doc ! Moi-même je pensais avoir vu la majeure partie des fonctions du BASH et j'étais passé à coté de cela. Ensuite, ton FTP en BASH strict est un cas d'école ! Cela vaut tous les IOCCC ou Perl Haïkus du monde. Bon, ben j'aurai quelque chose à potasser ce soir !
En attendant, poste donc un commentaire, que je te plussoie ! :-)
# Et pour les amoureux de zsh ...
Posté par harbort1 . Évalué à 3.
A bon entendeur ...
[^] # Re: Et pour les amoureux de zsh ...
Posté par 桃白白 . Évalué à 7.
Quelle inutilité tout ca, alors que tout le mode sait que pour avoir le cleint ftp de bash, il suffit de taper ftp.
</second degré>
[^] # Re: Et pour les amoureux de zsh ...
Posté par calandoa . Évalué à 10.
Par exemple, imagine que tu veux extraire les plus longs éléments d'un tableau :
> print ${(M)array:#${~${(O@)array//?/?}[1]}}
(c'était peut être inutile avant de le découvir, mais quand on voit ce bonheur de conscision digne de l'obfuscated c code contest, on ne peut que s'en servir trois fois par jour :^)
Ou encore:
> print **/(#ia1)name(LK+50mw-1u0)
qui affiche tous les fichiers du répertoire et de ceux en dessous avec le nom « name » en majuscule ou minuscule, avec une faute de frappe tolérée, qui font plus de 50Ko, modifiés il y a moins d'une semaine et possédés par root.
Un site faisant un rapide bilan de tous ses avantages : http://strcat.neessen.net/zsh/(...)
Quelques « tips'n tricks » : http://grml.org/zsh/zsh-lovers.html(...)
Un guide assez complet et « user-friendly » http://zsh.sunsite.dk/Guide/(...)
Un pense-bête (vital) : http://zsh.sunsite.dk/Refcard/(...)
Au début, je suis passé à zsh sans être vraiment convaincu, mais je suis en train de lire le guide et je me chie dessus de bonheur jour après jour... je pense d'ailleurs qu'il va falloir le relire une ou deux fois ce guide, car à chaque chapitre j'oublie la moitié des fonctionnalités du chapitre précédant tellement il y en a.
Et puis il y a vraiment un avantage indiscutable : en plus de jouer les rebelles et de vous foutre de la gueule de tous vos copains sous Windozes, vous pourrez maintenant aussi bien vous marrer de tous vos potes linuxiens sous bash! Héhéhé!!!
[^] # Re: Et pour les amoureux de zsh ...
Posté par tipmeabout . Évalué à 2.
Tu viens de me donner l'argument pour de jamais passer à zsh: je tiens à mes slips !
[^] # Re: Et pour les amoureux de zsh ...
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
Tiens c'est drôle parce qu'il y a deux jours j'ai dû avoir recours à sysrescuecd dont le shell est zsh que je ne connais pas. En moins de 3 mn je me suis promis de l'essayer car j'ai eu comme qui dirait un coup de foudre. ;)
[^] # Re: Et pour les amoureux de zsh ...
Posté par Juke (site web personnel) . Évalué à 1.
# Defi !
Posté par jigso . Évalué à 2.
[^] # Re: Defi !
Posté par kd . Évalué à 1.
PORTDEBUT=1
PORTFIN=1024
for ((p=$PORTDEBUT;p<=$PORTFIN; p++)); do
(
if exec 5<>/dev/tcp/127.0.0.1/$p; then
echo "$p opened";
exec 5<>/dev/null;
else
echo "$p not opened";
fi
exit;
) 2>/dev/null &
done
Bon après, c'est sûr que si on veut faire des scans furtifs, ça risque pas d'être faisable. Il n'y a pas mieux pour réveiller un IDS que ce script, vu que bash utilise certainement la primitive C connect() pour se connecter.
[^] # Re: Defi !
Posté par tipmeabout . Évalué à 0.
ah tiens, mon prof me disais que ce genre de boucle ne se faisait pas en bash ... perso je passais par `seq 1 20` par exemple.
Je n'ai pas encore testé ce genre de boucle, histoire de voir si ça marche, ou si tu as lancé ça comme ça.
# Bon euh...
Posté par kd . Évalué à 2.
Voili voilou.
Sinon en remarque, dans le même genre, il serait possible de programmer pas mal de clients du même genre, pour pas mal de protocoles.
Ce qui est facile avec le protocole FTP c'est que c'est un protocole synchrone, c'est-à-dire que le serveur ne nous envoie des réponses... qu'en réponse à nos requêtes, comme en HTTP par exemple.
Pour ceux qui auraient envie de faire un client IRC en 100% bash par exemple, ça se corse beaucoup, non pas dans le parsing des commandes, mais dans le fait que le protocole est asynchrone. Résultat, on peut recevoir des données à n'importe quel moment.
Il faudrait alors faire des espèces de threads pour faire du polling sur /dev/tcp/host/port.
On peut "forker" le script grâce à ( commandes ) & par exemple, mais le sous-script qui tournera en tâche de fond ne pourra pas communiquer facilement, par variables interposées par exemple, avec le script-père.
Il reste alors la solution super goret (ultra gruik même !) qui consiste à partager les variables à travers des fichiers textes.
Si vous avez des idées, n'hésitez pas !
[^] # Re: Bon euh...
Posté par Damien Pobel (site web personnel) . Évalué à 3.
tu dois pouvoir faire plusieurs scripts qui communiquent facilement, mais bonjour le bordel :)
Sinon, petite remarque en passant, pour des scripts shells qui utilise le réseau j'utilise tcpconnect (dispo dans le paquet Debian tcputils).
https://damien.pobel.fr
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.