Journal Un coquillage qui parle le FTP

Posté par .
Tags : aucun
0
1
mar.
2005
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 . Évalué à 4.

    Ce truc (celui de bash, pas ton script : ) est d'une grandeur affolante !!!

    bash, je t'aime !

    (bon ok, jvai le tester ton client !)
  • # Advanced Bash-Scripting Guide

    Posté par . Évalué à 5.

    "An in-depth exploration of the art of shell scripting", guide nettement moins monstrueux :

    http://www.tldp.org/LDP/abs/html/index.html(...)
  • # Debian POWA

    Posté par . Évalué à 8.

    Et oui, heureusement, le bash de Debian est exempt de cette fonctionnalité de sale barbu pervers.

    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."
    • [^] # Re: Debian POWA

      Posté par . Évalué à 1.

      Tu précises "heureusement" : en quoi est-ce une bonne chose, d'après toi, que BASH n'inclut pas cette fonctionnalité outre que la "justification" que cette fonctionnalité ne doit pas faire partie d'un coquillage ?

      « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

      • [^] # Re: Debian POWA

        Posté par (page perso) . Évalué à 2.

        outre que la "justification" que cette fonctionnalité ne doit pas faire partie d'un coquillage


        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.
        • [^] # Re: Debian POWA

          Posté par . Évalué à -9.

          Excuses-moi de devoir te le dire mais je demandais à l'auteur du message auquel je répondais pourquoi lui trouve que c'est une bonne chose. Donc à moins que tu sois son avocat, son maître-à-penser ou son porte-parole, j'ose espérer qu'il a encore le droit de s'exprimer et que l'utilisation de Debian ne prive pas l'utilisateur sa liberté de penser par lui même. Donc c'est son opinion que je souhaite connaître.

          « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

          • [^] # Re: Debian POWA

            Posté par (page perso) . Évalué à 5.

            Et ça interdit à quelqu'un de donner son avis sur la question ?

            Loïc ne va pas pouvoir répondre à cause de l'intervention de cho7 ?
            • [^] # Re: Debian POWA

              Posté par . Évalué à -1.

              Non le problème est qu'il me répond à la place de l'auteur original du message que c'est "l'argument n°2" selon lequel cela peut produire des résultats inattendus alors qu'il l'avoue lui même : « ne me demande pas le genre de résultats inattendus, je n'en sais fichtrement rien ». Personnellement, j'écoute rarement les gens qui parlent d'une chose dont ils ne savent fichtrement rien mais sur laquelle ils se contentent de ressortir l'avis des autres.

              Sans compter que affirmer que « ça peut produire des résultats innattendus » sans exemple, c'est un peu comme dire que « Windows est beaucoup plus sécurisé que Linux parce qu'il est mieux conçu et par des gens beaucoup plus compétents ».

              Bref, je suppose que l'auteur du message a potentiellement plus de détails à fournir et à partager ue Monsieur qui avoue lui même ... n'en savoir fichtrement rien ! Je pense que c'est une démarche assez raisonnable que de demander des détails sans avoir besoin d'avoir à faire face à une méfiance systématique dès qu'on ne se contente pas de l'idée donnée et suivie par Debian non ?

              « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

          • [^] # Re: Debian POWA

            Posté par (page perso) . Évalué à 1.

            Je suis un peu d'accord avec ta reaction mais dans ce cas, pourquoi ne l'a tu pas precisé clairement ou pourquoi n'envoie tu pas de message privé ?
            • [^] # Re: Debian POWA

              Posté par . Évalué à 4.

              C'est très simple : il exprime en public qu'il est heureux que la fonctionnalité ne soit pas incluse, donc il me semble plus raisonnable de lui demander pourquoi publiquement. Par exemple, est-ce qu'il y a déjà eu des problèmes avec l'activation de cette fonctionnalité dans BASH ou des trucs dans le genre : il me semble que ce genre de réponse peut profiter à tout le monde.

              Par ailleurs, imaginons qu'il y a ait plusieurs lecteurs qui se posent la question : je doute que devoir répondre en privée à la même chose plusieurs fois soit un plaisir.

              « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

  • # RoXoR !

    Posté par . Évalué à 4.

    Alors là, cela force le respect !

    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 . Évalué à 3.

    ne pas oublier zftp qui est une fonction fournit en standard avec zsh et qui est un client ftp écrit en zsh :)

    A bon entendeur ...
    • [^] # Re: Et pour les amoureux de zsh ...

      Posté par . Évalué à 7.

      <second degré>
      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 . Évalué à 10.

        Ahahah... un plaisantain qui défend bash face à zsh... c'est un peu comparer une crèche avec polytechnique!

        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é!!!
  • # Defi !

    Posté par . Évalué à 2.

    À quand un nmap.sh via ls /dev/tcp/hostname ?
    • [^] # Re: Defi !

      Posté par . Évalué à 1.

      bah...


      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 . Évalué à 0.

        for ((p=$PORTDEBUT;p<=$PORTFIN; p++))

        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 . Évalué à 2.

    Juste pour dire que j'ai mis à jour le script parce qu'il y avait un gros bug de fichier tronqué. Le script oubliait à chaque fois de copier la fin des fichiers.

    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 (page perso) . Évalué à 3.

      et avec des tubes ? (mkfifo)

      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).

      http://damien.pobel.fr

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.