Forum Programmation.c from Bash to C

Posté par  .
Étiquettes : aucune
-8
4
avr.
2010
Salut,

Je n'ai malheureusement pas le temps de me mettre en C ou de parCourir tous les forums dédiés à Cette programmation... Je CherChe donC une âme Charitable pour me "traduire" Cette petite fonCtion bash:

myfunc()
{
if [ "$1" ]
then
/bin/a arg1 arg2 "$@"
else
/bin/b
fi
}


(si au moins un argument alors programme a avec mes arguments et le(s) argument(s) initialement passé(s), sinon programme b)

MerCi d'avanCe. :-)
  • # Précisions

    Posté par  . Évalué à -1.

    L'idée est de, in fine, produire un exécutable qui, suivant le passage d'argument(s), démarrera le bon programme (sans doute avec du exec quelque chose...).
    Un numéro figure au début du post. Il est passé de 0 à -1: que cela signifie-t-il?
    • [^] # C'est du C

      Posté par  (site web personnel) . Évalué à 8.

      Cela s'appelle la post decrémentation en C.

      Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

  • # 100 balles, un Mars et...

    Posté par  . Évalué à 5.

  • # lire ton cours ;)

    Posté par  . Évalué à 6.

    tu as surement un cours qui correspond à l'exercice que tu nous decris...

    une piste pourrait etre de faire une recherche sur ARGV ARGC
    qui devrait decrire comment gerer les arguments en C
  • # Pourquoi en C ?

    Posté par  . Évalué à 4.

    La vraie question est : pourquoi veux-tu faire ça ? Il est d'usage d'écrire ce genre de wrapper en Shell. Pourquoi se compliquer la vie à le faire en C, à part pour masquer le procédé aux yeux de l'utilisateur averti ?

    Et pourtant, je programme beaucoup en C…
    • [^] # Re: Pourquoi en C ?

      Posté par  . Évalué à 3.

      Pour la portabilité ? Mais c'est vrai qu'avec les chemins codés en dur la portabilité en prend un coup !

      On alors comme dit au dessus parce que c'est un exercice...
    • [^] # Re: Pourquoi en C ?

      Posté par  . Évalué à 2.

      à part pour masquer le procédé aux yeux de l'utilisateur averti ?

      C'est tout à fait cela : l'exécutable généré prendra en fait la place du programme a,qui sera renommé, et du coup, ce dernier sera nécessairement appelé avec les paramètres arg1 et arg2...

      Prenons l'exemple de la commande ls: je veux que celle-ci soit systématiquement appelée avec les paramètres -l -h mais je ne veux pas m'appuyer sur les artifices des shells (alias, fonctions, etc...) et je veux de plus que, si aucun argument n'est passé alors le man soit affiché. Je cache alors l'original ls (.ls par exemple ou un renommage complet) et le remplace par mon ls maison. L'exemple est un peu tiré par les cheveux mais l'idée est là: empêcher l'utilisation directe de l'original sans avoir à ré-écrire ce dernier...
      • [^] # Re: Pourquoi en C ?

        Posté par  . Évalué à 4.

        Pourquoi veux-tu absolument en faire un binaire ?

        Tu as le droit de remplacer un programme binaire par un script portant le même nom.
        Dans ton exemple, il suffit de baptiser ton script /bin/ls et le tour est joué.
        • [^] # Re: Pourquoi en C ?

          Posté par  . Évalué à 1.

          D'après toi, il serait inutile de remplacer un binaire par un autre binaire...
          En d'autres termes, hormis le fait que le script sera plus facilement étudiable, le fait de remplacer le binaire 'ls' par un script - disons bash ou python - ne posera aucun problème aux différents autres binaires (ou scripts) qui appelaient le binaire original?
          • [^] # Re: Pourquoi en C ?

            Posté par  . Évalué à 0.

            Heu... tu utilises des ordinateurs depuis longtemps ? :-)
            Nan je veux dire pour autre chose que cliquer dans des menus.
          • [^] # Re: Pourquoi en C ?

            Posté par  . Évalué à 3.

            le fait de remplacer le binaire 'ls' par un script - disons bash ou python - ne posera aucun problème aux différents autres binaires (ou scripts) qui appelaient le binaire original?
            Exactement.
            Il suffit d'aller faire un tour dans /bin ou /usr/bin pour voir que c'est déjà le cas:


            $ file /bin/* | grep script
            /bin/bzdiff: POSIX shell script text executable
            /bin/bzexe: POSIX shell script text executable
            /bin/bzgrep: POSIX shell script text executable
            /bin/bzmore: POSIX shell script text executable
            /bin/gunzip: Bourne-Again shell script text executable
            /bin/gzexe: Bourne-Again shell script text executable
            /bin/lesspipe: POSIX shell script text executable
            ...
          • [^] # Re: Pourquoi en C ?

            Posté par  . Évalué à 2.

            Est-ce que, par hasard, ce serait pour équiper une borne publique ? Parce qu'en dehors de cela, il n'y a guère de raisons de vouloir faire ce que tu veux faire : ça n'empêchera pas une personne motivée d'aller voir et il faudra coder tes noms de fichiers sinon, il suffira d'ouvrir ton exécutable dans un éditeur de texte pour les voir apparaître en clair. Ça rendra en revanche l'administration beaucoup plus compliquée.
        • [^] # Re: Pourquoi en C ?

          Posté par  (site web personnel) . Évalué à 1.

          Sauf que que l'exécutable en C serait la seule solution pour faire un code suid (je ne dis pas que c'est le but ici, mais ça peut être un argument…)
  • # Fork ?

    Posté par  . Évalué à -1.

    Salut,

    Vu que c'est un script shell, tu ne dois pas rechercher la portabilité. Donc tu pourrais utiliser l'appel système fork (reproduire le comportement du shell en quelque sorte).

    Ça ne prend que quelques lignes. Je pourrais te coder ça dans la soirée si tu en as toujours besoin ;-).

    redfire.
  • # Premier jet

    Posté par  . Évalué à -1.

    Re,

    Code disponible ici (je ne parvenais pas à lui donner la bonne apparence sur linuxfr).

    J'ai écrit ça rapidement mais ça devrait fonctionner. Donc pour exécuter tes différents programmes, tu as juste à mettre le nom du programme 1 dans app1 (entre les guillemets) et pareil dans app2 (le nom suffit, il va chercher lui-même dans $PATH).

    Comportement : si au moins un argument alors programme 1 avec arguments sinon programme 2.

    J'ai testé le retour des appels systèmes bien qu'en principe si l'un d'eux échoue, ce petit programme ne sera pas le soucis réel...

    Je ne sais pas si tu as déjà compilé un programme C mais dans le doute :

    gcc -Wall -o nom du programme fichier.c

    Si des erreurs se sont glissées dans le code, n'hésitez pas à le signaler. Je reconnais que c'est un peu l'artillerie lourde...

    À bientôt.

    redfire
  • # Oubli du lien

    Posté par  . Évalué à -2.

    Décidément la balise ... http://pastebin.com/dWSksLTh

Suivre le flux des commentaires

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