Ne couvrant que 1) de votre question.
Naturellement, les API peuvent toujours changer à la volonté de leurs créateurs, et donc casser les logiciels dépendants, dans n'importe quelle langue. Cela dit, la grande idée des "API" d' E / S des outils Unix est qu'il n'y en a pratiquement pas (peut-être0x0a
en fin de ligne). Un bon script filtre les données avec les outils Unix au lieu de les créer. Cela signifie que votre script peut se casser parce que les spécifications d'entrée ou de sortie ont changé, mais pas parce que le format d'E / S (encore une fois, il n'y en a pas vraiment un) des outils individuels utilisés dans le script a changé (parce que quelque chose qui n'existe pas vraiment ne peut pas vraiment changer).
En parcourant une liste d'outils de base, il y en a peu que j'attribuerais également producteur , par opposition au seul filtre:
- wc - affiche le nombre d'octets, de mots, de lignes - format très simple, donc absolument improbable de changer, et de plus peu susceptible d'être utilisé dans un script.
- diff - il y a eu différents formats de sortie mais je n'ai entendu aucun problème. Également pas normalement utilisé sans supervision.
- Date - Maintenant, ici, nous devons vraiment faire attention à ce que nous produisons, en particulier en ce qui concerne les paramètres régionaux du système. Mais sinon le format de sortie est RFC étant donné que vous ne le spécifiez pas exactement vous-même.
- cal - ne parlons pas de cela, je sais que le format de sortie diffère beaucoup d'un système à l'autre.
- ls , qui , w , dernier - je ne peux pas aider si vous voulez analyser ls, ce n'était pas censé être. En outre, qui, w, last, sont des listers plus interactifs; Si vous les utilisez dans un script, vous devez faire attention à ce que vous faites.
- le temps a été souligné dans un autre post. Mais oui, c'est la même chose qu'avec ls. Plus pour une utilisation interactive / locale. Et le bash intégré est très différent de la version GNU, et la version GNU a des bogues non corrigés depuis de nombreuses années. Ne vous y fiez pas.
Voici des outils qui attendent un format d'entrée particulier plus spécifique qu'un flux d'octets:
- bc , dc - calculatrices. Déjà du côté plus hackish des choses (vraiment, je ne les utilise pas dans les scripts), et des formats d'E / S vraisemblablement très stables.
Il existe un autre domaine avec un risque de rupture beaucoup plus élevé, à savoir l'interface de ligne de commande. La plupart des outils ont des fonctionnalités différentes à la fois sur les systèmes et sur la chronologie. Des exemples sont
- Tous les outils utilisant regex - regex peuvent changer de signification en fonction des paramètres régionaux du système (par exemple LC_COLLATE) et il existe de nombreuses subtilités et particularités dans les implémentations de regex.
- N'utilisez tout simplement pas de commutateurs sophistiqués. Vous pouvez facilement utiliser,
man 1p find
par exemple, pour lire la page de manuel de recherche POSIX au lieu de la page de manuel du système. Sur mon système, j'ai besoin que manpages-posix soit installé.
Et même lorsque vous utilisez de tels commutateurs, normalement, aucune erreur ne sera subtilement introduite et n'empoisonnera vos données. La plupart des programmes refusent simplement de fonctionner avec un commutateur inconnu.
Pour conclure, je dirais que le shell a en fait le potentiel d'être l'un des langages les plus portables (il est portable lorsque vous scriptez de manière portable). Comparez-les à vos langages de script préférés où des erreurs subtiles se produisent, ou à votre programme compilé préféré qui cèdera à la compilation.
De plus, aux rares endroits où une rupture peut se produire en raison d'incompatibilités, cela ne serait probablement pas dû au temps induit, mais à la diversité des différents systèmes (ce qui signifie que si cela fonctionne pour vous, il l'a fait 20 ans auparavant et le sera dans 20 ans , aussi). C'est un corollaire de la simplicité des outils.