Par où commencer pour créer des applications CLI? [fermé]


8

Après avoir utilisé Linux pendant un mois ou deux, je sais ce que je fais maintenant.

Lors de la création de programmes, en utilisant n'importe quel langage, j'ai évidemment utilisé du code comme celui-ci:

$ python test.py

Et donc si je voulais test.pylire un fichier donné, je devrais utiliser:

$ python test.py something.file

Ce que j'aimerais faire maintenant, il essaie de créer une application en ligne de commande, donc je peux utiliser

$ myapp something.file

Un programme comme le pythonin $ python test.pyou le nanoin$ nano program.pl

Mais où diable dois-je commencer à créer des applications comme celles-ci? Un peu de chalutage sur le Web ne m'a mené nulle part.

Si vous pouvez me le dire, ce serait bien, mais j'accepterai volontiers un tas de liens.

Je suis totalement ouvert s'il y a plus d'une façon, je ne me soucie pas vraiment de la langue (une excuse pour en apprendre une autre!) Ou quoi que ce soit.


3
Voulez-vous apprendre la programmation Unix C ou voulez-vous simplement pouvoir exécuter vos scripts python sans avoir à spécifier la pythonpartie?
jw013

@ jw013 Je veux apprendre la programmation Unix C. (Bien que je serais intéressé de savoir comment vous pourriez exécuter des scripts python sans le python.)
ACarter

4
Vous devriez probablement résoudre votre question alors :) Les applications CLI peuvent être écrites dans n'importe quelle langue qui a un compilateur ou un interprète Unix, donc si vous n'êtes intéressé que par C, dites-le. La programmation Unix C se compose en fait de deux parties: la partie Unix et la partie C. En l'état, "Comment apprendre la programmation Unix C?" sera probablement fermé pour être trop général, et il y a probablement des doublons partout sur ce site. "Comment puis-je apprendre la programmation C" est également trop général et peut-être aussi hors sujet. Il serait certainement fermé le SO.
jw013

@ jw013 Ce que je recherche vraiment, ce sont des conseils comme "Les applications CLI peuvent être écrites dans n'importe quelle langue qui a un compilateur ou un interprète Unix", alors merci.
ACarter

1
Ah ok. Il y a toujours un peu de bosse initiale abrupte dans la courbe d'apprentissage lorsque vous essayez d'entrer dans l'environnement Unix, mais une fois que vous l'avez dépassé, je suis sûr que vous trouverez que l'effort en valait la peine. Malheureusement, je ne connais aucune ressource que je puisse indiquer pour commencer - vous devez essentiellement ramasser des morceaux au fur et à mesure: \
Bonne

Réponses:


15

Vous pouvez exécuter des scripts python en les rendant exécutables ( chmod +x test.py) et en créant #!/usr/bin/env pythonla première ligne. Une fois que vous faites cela, l'exécution test.py argsinvoquera python pour exécuter votre script. Lisez à propos de shebang si vous voulez en savoir plus.


Ça n'a pas marché pour moi. $ test.py 30a donné une erreur de bash: -bash: test.py: command not found. Merci pour votre aide jusqu'à présent!
ACarter

8
@ACarter C'est parce que ce n'est pas dans votre $PATH. Soit utiliser un chemin, comme /path/to/test.pyou ./test.pysi vous êtes /path/todéjà dans , soit ajouter /path/toà votre $PATH. Il existe de nombreuses questions en double sur ce site à propos de ce dernier.
jw013

Dès que vous mettez quelque chose dans votre $PATH, laissez de côté les fins de fichier comme .py.
Reactormonk

Vous avez besoin du #!/usr/bin/env pythonen haut de votre script avant de pouvoir supprimer l'extension .py. Mais tout script contenant cette invocation ou une autre similaire (par exemple #!/bin/shpour les scripts shell) peut être nommé sans extension. Cela n'a rien à voir avec le fait que ce soit dans votre PATH ou non.
Michael Hampton

2
Juste pour être clair, les extensions n'ont pas d'importance dans le monde Unix, contrairement à Windows. où les extensions aiment .EXEet .COMcomptent. Cependant, la raison derrière la suppression de l'extension est que les exécutables génériques devraient être simplement des exécutables génériques. Le sens de cette tautologie est que les utilisateurs veulent juste la fonctionnalité et ne devraient pas avoir besoin de savoir ou de se soucier si c'est Perl ou Python ou sh ou bash ou awk etc. - c'est un détail d'implémentation généralement non pertinent. Et, faire un script exécutable et ajouter un shebang en fait un exécutable générique.
jw013

2

En C, cela ressemble à ceci:

int main(int argc, char *argv[]) {

L'argc est le nombre d'arguments. Notez que le nom du programme / outil compte.

Les arguments eux-mêmes se retrouvent dans le vecteur d'argument (ou tableau), argv.

Ensuite, il y a la partie délicate de l'écriture de code pour les traiter de la manière souhaitée.

Compilez ensuite avec gcc. Vous spécifiez le nom du programme avec l' -oindicateur (outfile). Exécutez le fichier à partir de son répertoire actuel comme ceci: ./tool_name input_file_1 ... input_file_n(ou placez-le dans un répertoire qui apparaît lorsque vous écrivez echo $PATH, alors vous pouvez l'invoquer de n'importe où, c'est-à-dire sans le point).


1

J'utilise Go. Il s'agit d'un langage compilé, multiplateforme, avec la facilité de programmation d'un langage dynamique et la prise en charge de la concurrence et de la communication.

Je ne reviens pas à Python car c'est très drôle de développer avec Go.

http://golang.org/
https://github.com/languages/Go

Ici, vous avez un programme simple qui obtient les arguments utilisés dans cette commande:

package main

import (
  "fmt"
  "flag"
)

func main() {
  fmt.Println("Arguments: ", flag.Args())
}

http://play.golang.org/p/1dpUT11-cc


Go est idéal pour certains cas d'utilisation ciblés; cependant, comparer Go et Python pour les utilitaires généraux, c'est comme comparer un couteau de chasse (Go) avec un couteau suisse (Python)
Mike Pennington

1
Go est un langage à usage général, utilisé par exemple sur Youtube, dans les applications Web ou pour créer des jeux (il y a un jeu terminé et un autre en développement). En plus d'être utilisé dans les applications CLI.
Marc

5
Il veut juste savoir comment faire un programme exécutable; nous n'avons pas vraiment besoin d'entrer dans une guerre des langues
Michael Mrozek
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.