Discussion :

[chrtophe]

J'aimerais surtout enfin que le monde Unix fasse son ménage et sorte un terminal+shell qui interprète Ctrl+C (^C) comme copier et non SIGINT.

ctrl-C pour faire un copier, ça vient de Windows, même si ça c'est imposé dans les GUI. Sous MS-DOS ctrl-C interrompait aussi le programme. On peut encore avoir ce comportement dans cmd.exe avec la commande break

[Gugelhupf]

Est-ce que ce n'est pas théorique ? Les gens appellent leurs scripts machin.sh, et croient réellement faire du standard, alors que l'exécutable est un raccourci vers bash ou zsh; et dans le code, ils utilisent vraiment des particularismes bash. Bref, avalanche de faux-semblants pour faire croire qu'on fait "standard". L'exécutable "sh" est suranné.

Hello, que tu sois sous Linux (implémentation Bash) ou macOS (implémentation Zsh) tu peux utiliser la syntaxe Bourne Shell. Tu ne vas pas forcer l'équipe sous Linux à installer Zsh parce que tu es sous Mac, ou t'amuser à aller installer Zsh sur les serveurs Linux, mais tu peux faire abstraction des Bash, Zsh et autres avec Bourne Shell, tu as même des validateurs de syntaxe.

[MaximeCh]

ctrl-C pour faire un copier, ça vient de Windows, même s ça c'est imposé dns les GUI. Sous MS-DOS ctrl-C interrompait aussi le programme. On peut encore avoir ce comportement dans cmd.exe avec la commande break

Mon point était qu'on s'en fiche un peu d'où ça vient, Ctrl+C pour copier est devenu universel, l'ergonomie des navigateurs web et des GUIs s'est répandue partout. Les gen z ont appris l'informatique avec un web browser pas un shell. Même moi qui suis gen Y.
ll n'y a vraiment que les boomers genX qui y sont vaguement attachés : il faut évoluer.

P.S. C'est un sujet sensible, souvent reconnu clivant. De mon point de vue gros intérêt à trancher et aller de l'avant.

[chrtophe]

Mon point était qu'on s'en fiche un peu d'où ça vient, Ctrl+C pour copier est devenu universel

oui, certes, mais :
ctrl-c est devenu universel pour copier dans les GUI, mais reste universel pour interrompre un processus dans un shell. Si tu fais de la ligne de commande, il faut le savoir. Par contre, je ne sais pas le comportement avec PowerShell, ni avec le nouveau terminal Windows. Point intéressant pour ceux qui font de l'environnement hétérogène.

Tu ne vas pas forcer l'équipe sous Linux à installer Zsh parce que tu es sous Mac

zsh est relativement récent sur Mac (depuis Catalina). Et en cas de mise à jour depuis système antérieur, il reste par défaut sur Bash avec une notification et une commande pour basculer sur zsh par défaut. De toute façon tu dois tenir compte des différences de plateforme dans tes scripts, après ça dépend ce que tu fais.

Je ne suis pas spécialiste shell, mais je pense qu'il est tout à fait possible de faire un script qui fonctionnera quel que soit le shell, mais du coup, aucun intérêt particulier à utiliser l'un ou l’autre. Soit on veut faire dans le compatible/facilement reprenable, soit on utilise celui qu'on veut avec pour avantage les addons par rapport à d'autres shells, avec pour inconvénient l'éventuelle non portabilité et donc l'obligation de rester sur le shell choisi.

[N_BaH]

il est tout à fait possible de faire un script qui fonctionnera quel que soit le shell

tout à fait; en respectant scrupuleusement la norme POSIX.
mais pas csh qui n'est pas du tout POSIX.

[Escapetiger]

Oui N_BaH,
Oui Gugelhupf,

Hello, je vais essayer d'apporter 1 réponse simple à ces 4 questions: Le meilleur shell est celui qui est disponible "partout", par défaut Bourne Shell (cf: #!/bin/sh) dont Bash, Zsh, et autres apportent une surcouche.

C'est grâce à tout ça que des missions sont réussies en tant qu'ingénieur/administrateur système (j'y adjoins mes collègues réseau, DBA, supervision, sécurité, etc.) chez des clients CAC 40, grandes administrations, où,
fort heureusement, les prestataires précédents (dont des internes qui sont souvent ex-prestataires) ont pris le temps, la force de caractère, le professionnalisme, de respecter l'historique de la société et de ses usages en termes POSIX, de présence de VI (voir à ce propos la «bataille historique» Guerre d'éditeurs), pour intervenir de façon tout terrain (cf. 4 x 4) sur leurs infrastructures partout dans le monde ...

[Edit]
On peut evidemment adopter d'autres pratiques mais ça doit faire l'objet d'un projet à part entière de refonte du SI (Système d'Information) initié par la Direction, validé par les Directions opérationnelles, etc.

[Invité]

Je ne suis pas spécialiste shell, mais je pense qu'il est tout à fait possible de faire un script qui fonctionnera quel que soit le shell

Oui c'est facile :
> python monscript.py

[chrtophe]

mouais,
sous réserve de pas faire un dev sur Python 2 à exécuter sur une machine avec Python 3.

[disedorgue]

Mon point était qu'on s'en fiche un peu d'où ça vient, Ctrl+C pour copier est devenu universel, l'ergonomie des navigateurs web et des GUIs s'est répandue partout. Les gen z ont appris l'informatique avec un web browser pas un shell. Même moi qui suis gen Y.
ll n'y a vraiment que les boomers genX qui y sont vaguement attachés : il faut évoluer.

P.S. C'est un sujet sensible, souvent reconnu clivant. De mon point de vue gros intérêt à trancher et aller de l'avant.

Marrant, déjà hors sujet puisque c'est juste de la conf de tty et non du shell

De plus, avant de faire ch... les unixiens pour leur console / terminal qui utilisent Ctrl-C pour autre chose qu'un copier, va dire à ton pote windows de le mettre en place sur ses consoles powershell ou msdos

Et un truc plus merdique que ton copier, c'est les fichiers textes dont chaque OS (UNIX / MAC / WINDOWS) y va de de sa petite sauce pour ne pas mettre tout le monde d'accord.

[chrtophe]

va dire à ton pote windows de le mettre en place sur ses consoles powershell ou msdos

Comme je le disais, tu as l'option dans cmd.exe. Pour PowerShell, je sais pas, mais je présumes que tu dois pouvoir activer/désctiver le truc.

[CaptainDangeax]

Il y a au moins 3 choses que bash ne sait pas faire: renommer et/ou effacer un fichier et créer un répertoire (d'ailleurs, je ne pense pas que les ksh ou zsh savent le faire), est-ce que fish shell sait le faire ?

PS: ici, je parle de façon native, sans utiliser de commandes externes telles que mv, rm ou mkdir.

Je ne suis pas du tout d'accord avec ton point de vue. Dans ton exemple les commandes mv rm et mkdir sont externes, elles sont codées, maintenues, compatibles avec les différents filesystems qu'on peut rencontrer, ne font qu'une chose et sont réputées bien le faire. Les intégrer directement dans le shell veut dire soit ré-écrire soit recopier le code si la licence le permet, pour ensuite créer la surcharge de travail pour maintenir plusieurs versions du même exécutable et intégrer tous les correctifs. As-tu entendu parler de la factorisation du code ? As-tu entendu parler des bibliothèques de fonction ? Je pense que ta remarque est due à une approche fondamentalement mauvaise du codage informatique. KISS: keep it simple and stupid, un programme=une fonctionnalité. Don't reinvent the wheel. Pourquoi pas une nouvelle version de TAR+GZIP directement dans le shell, et puis le gestionnaire de paquets tant qu'on y est

[CaptainDangeax]

...
Je ne suis pas spécialiste shell, mais je pense qu'il est tout à fait possible de faire un script qui fonctionnera quel que soit le shell...

Je plussoie, une mission précédente mettait en oeuvre un script bash qui fonctionnait indifféremment sur AIX, Solaris et Redhat Linux... J'ai pu le faire parce que bash était installé par défaut sur tous les environnements mais si ça n'avait pas été le cas, je me serais restreint à bourne Shell. Ensuite, à moi de gérer les subtilités ou les différentes versions de package manager, mais j'étais payé pour ça en fait

[disedorgue]

Je ne suis pas du tout d'accord avec ton point de vue. Dans ton exemple les commandes mv rm et mkdir sont externes, elles sont codées, maintenues, compatibles avec les différents filesystems qu'on peut rencontrer, ne font qu'une chose et sont réputées bien le faire. Les intégrer directement dans le shell veut dire soit ré-écrire soit recopier le code si la licence le permet, pour ensuite créer la surcharge de travail pour maintenir plusieurs versions du même exécutable et intégrer tous les correctifs. As-tu entendu parler de la factorisation du code ? As-tu entendu parler des bibliothèques de fonction ? Je pense que ta remarque est due à une approche fondamentalement mauvaise du codage informatique. KISS: keep it simple and stupid, un programme=une fonctionnalité. Don't reinvent the wheel. Pourquoi pas une nouvelle version de TAR+GZIP directement dans le shell, et puis le gestionnaire de paquets tant qu'on y est

tar+gzip ne sont pas des appels systèmes.
Et si on suit cette politique pourquoi un shell comme bash a des commande tel que echo ou kill ?

Et pourquoi implémente-il des simulations de device tel que /dev/tcp ?

Je ne dis pas qu'il doit réimplémenter les commande rm,mv et mkdir, mais au moins avoir des commandes équivalentes qui ne font qu'appeler l'appel système.

[Pyramidev]

À part ça, du côté des shells alternatifs peu connus, je viens de découvrir Nushell qui n'est pas mature, mais qui est conceptuellement intéressant. Le monde de l'informatique est vaste.

[pcouaillier]

Pour améliorer la productivité j'utilisais OhMyZsh qui permet de facilement ajouter des extensions dans Zsh pour améliorer la productivité.

Le problème avec les extensions c'est que la surcouche + les extensions peuvent ralentir l'utilisation.

Depuis je suis passé sur fish. Pour une configuration équivalente j'ai pu mesurer que fish est 3 à 4 fois plus rapide.

La raison est simple... Les extensions fish (via fisher) sont beaucoup plus légère à charger.


Du coup j'utilise l'architecture suivante :

• ~/.local/bin <= script #!/usr/bin/env sh
• ~/.config/fish <= extension fish (natif dans fish)