Version imprimable
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 breakCitation:
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.
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.Citation:
Envoyé par Flodelarab
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.Citation:
Envoyé par chrtophe
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.
oui, certes, mais :Citation:
Mon point était qu'on s'en fiche un peu d'où ça vient, Ctrl+C pour copier est devenu universel
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.
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.Citation:
Tu ne vas pas forcer l'équipe sous Linux à installer Zsh parce que tu es sous Mac
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.
tout à fait; en respectant scrupuleusement la norme POSIX.Citation:
il est tout à fait possible de faire un script qui fonctionnera quel que soit le shell
mais pas csh qui n'est pas du tout POSIX.
Oui N_BaH,
Oui Gugelhupf,
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ù,Citation:
Envoyé par Gugelhupf
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.
Oui c'est facile :Citation:
Envoyé par chrtophe
> python monscript.py
:dehors:
mouais,
sous réserve de pas faire un dev sur Python 2 à exécuter sur une machine avec Python 3. :)
Marrant, déjà hors sujet puisque c'est juste de la conf de tty et non du shellCitation:
Envoyé par MaximeCh
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.
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.Citation:
va dire à ton pote windows de le mettre en place sur ses consoles powershell ou msdos
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 :aie:Citation:
Envoyé par disedorgue
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 faitCitation:
Envoyé par chrtophe
tar+gzip ne sont pas des appels systèmes.Citation:
Envoyé par CaptainDangeax
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.
À 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.
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)