cerhu > linux.debian.user.french

roger.tarani (23/12/2018, 17h00)
Bonjour la liste (de la veille de Noël ! )

Enfin un petit peu de temps pour aborder un sujet pas bien urgent.

En CLI, il arrive souvent que les programmes crachent des tonnes de messages
>>$$ aupointqu'onnesaitplustrop%%

==oùsetrouvelacommandeentrée**
dansceflotdetexte$$<<

J'utilise la console de manière "normale". Et je crois bien ne pas connaître toutes les ressources de la CLI.
Oui, il y a la commande history, mais...
Oui, il y a emacs, vi, etc. mais je parle juste de CLI.

Pour améliorer ça, j'ai quelques idées simples que j'aimerais discuter avec vous.
Déjà pour vérifier que ça n'existe pas déjà :
- mettre automatiquement en inversion vidéo juste la commande entrée; ou au moins un saut de ligne
- insérer automatiquement quelques espaces et \n dans la réponse pour éviter du texte en continu
- dissocier la console en deux ou juxtaposer deux consoles (une sur stdin et une sur stdout) : on entre des commandes d'un côté et on obtient la réponse du programme de l'autre côté
- ajouter une possibilité de réduire/expanser des zones de messages (collapse/expand), ce qui suppose de les baliser (globalement, ou plus finement; voir analyseur ci-après)
- diriger les messages vers un analyseur pour en extraire ce qui compte (requiert de connaître l'API du programme)
- utiliser des règles de coloration syntaxique qui améliorent la lisibilité (tout en blanc sur fond noir via ssh, ou en vert sur fond noir en local; et les couleurs psychédéliques de la commandes ls,au bout d'un moment... ben, on s'y habitue !); sur ce dernier point, je nesais pas vous, mais je trouve ma console plutôt pas trop ergonomique.

Merci
daniel huhardeaux (23/12/2018, 17h20)
Le 23/12/2018 à 15:51, roger.tarani a écrit :
> Bonjour la liste (de la veille de Noël ! )


Bonjour

[..]
> Pour améliorer ça, j'ai quelques idées simples que j'aimerais discuter avec vous.
> Déjà pour vérifier que ça n'existe pas déjà :
> - mettre automatiquement en inversion vidéo juste la commande entrée; ou au moins un saut de ligne
> - insérer automatiquement quelques espaces et \n dans la réponse pour éviter du texte en continu
> - dissocier la console en deux ou juxtaposer deux consoles (une sur stdin et une sur stdout) : on entre des commandes d'un côté et on obtient la réponse du programme de l'autre côté
> - ajouter une possibilité de réduire/expanser des zones de messages (collapse/expand), ce qui suppose de les baliser (globalement, ou plus finement; voir analyseur ci-après)
> - diriger les messages vers un analyseur pour en extraire ce qui compte (requiert de connaître l'API du programme)
> - utiliser des règles de coloration syntaxique qui améliorent la lisibilité (tout en blanc sur fond noir via ssh, ou en vert sur fond noir en local; et les couleurs psychédéliques de la commandes ls, au bout d'un moment... ben, on s'y habitue !); sur ce dernier point, je ne sais pas vous, mais je trouve ma console plutôt pas trop ergonomique.

Paquet tmux. À associer à mosh pour l'accès à distance, c'est parfait.
Raphaël POITEVIN (23/12/2018, 18h20)
roger.tarani writes:
> J'utilise la console de manière "normale". Et je crois bien ne pas
> connaître toutes les ressources de la CLI.
> Oui, il y a la commande history, mais...
> Oui, il y a emacs, vi, etc. mais je parle juste de CLI.


Il y a more et less.

> Pour améliorer ça, j'ai quelques idées simples que j'aimerais discuter
> avec vous.
> Déjà pour vérifier que ça n'existe pas déjà:
> - mettre automatiquement en inversion vidéo juste la commande entrée;
> ou au moins un saut de ligne


Pas concerné pour ma part mais peut-être que zsh améliore ça.

> - insérer automatiquement quelques espaces et \n dans la réponse pour
> éviter du texte en continu
> - dissocier la console en deux ou juxtaposer deux consoles (une sur
> stdin et une sur stdout) : on entre des commandes d'un côté et on
> obtient la réponse du programme de l'autre côté


Envoyer dans un pipe nommé la sortie et lire celle-ci avec une autre
console.

Bon noël
steve (23/12/2018, 18h30)
Le 23-12-2018, à 15:51:24 +0100, roger.tarani a écrit :

>- diriger les messages vers un analyseur pour en extraire ce qui compte (requiert de connaître l'API du programme)


ccze est pas mal pour ça. Par exemple:

tail -f /var/log/syslog | ccze
roger.tarani (23/12/2018, 19h20)
Paquet tmux. À associer à mosh pour l'accès à distance,c'est parfait.
roger.tarani (23/12/2018, 19h30)
Je disais dans mon message parti trop vite...

** Paquet tmux. À associer à mosh pour l'accès à distance, c'est parfait.
Daniel

tmux : vraiment très simple et agréable (je n'arrive toujours pasà me faire à emacs dont je ne vois pas le bout...)
et on peut intégrer ce qu'on veut dans les panneaux ("panes"). Parfait, en effet.

** more et less
Envoyer dans un pipe nommé la sortie et lire celle-ci avec une autre console.
Raphaël

Oui, less me sert souvent ("less is more" mais more ne l'est pas).

** >- diriger les messages vers un analyseur pour en extraire ce qui compte(requiert de connaître l'API du programme)
ccze est pas mal pour ça. Par exemple:
tail -f /var/log/syslog | ccze
Steve

En effet, il analyse bien et rend les logs plus digestes.

Merci à vous de me faire lâcher mes tablettes en pierre mono (mono fenêtre, mono session, mono panneau).
Merci, c'est noël!
Raphaël POITEVIN (24/12/2018, 00h10)
roger.tarani writes:
> tmux : vraiment très simple et agréable (je n'arrive toujours pas à me
> faire à emacs dont je ne vois pas le bout...)


On ne fait certainement pas les mêmes choses. Emacs est un intégrateur
de tâches. Je ne connais pas tmux ne l?utilisant pas. On n?a jamais fini
d?apprendre Emacs. Je ne m?en passerai pas.
Yves Rutschle (24/12/2018, 00h50)
On Sun, Dec 23, 2018 at 03:51:24PM +0100, roger.tarani wrote:
> - mettre automatiquement en inversion vidéo juste la commande entrée; ou au moins un saut de ligne


Un truc très simple à faire, c'est de changer la variable
d'environement PS1 de bash pour y mettre de la couleur (ou
de l'inversion vidéo ou autre), ce qui permet de retrouver
facilement le début de la sortie de la dernière commande.

Y.
Marc Chantreux (24/12/2018, 01h50)
salut,

> Envoyer dans un pipe nommé la sortie et lire celle-ci avec une autre console.


je n'ai pas d'outils tout fait mais c'est justement à mes yeux la force
d'unix. testé avec tmux+zsh:

outthere/new () {

# créer des fichiers out et err
touch /tmp/$$.{err,out}

# demander a tmux de splitter la fenêtre
# (a adapter si tu veux créer d'autres fenêtre)
# perso je préfère spliter et utiliser c-bz pour passer en
# fullscreen
tmux split tail -fn0 /tmp/$$.err \;\
split tail -fn0 /tmp/$$.out \;\
select-pane -t $TMUX_PANE

}

# outthere execute une commande en redirigant les std vers les bons
# fichiers
outthere () "$@" >/tmp/$$.out 2>/tmp/$$.err

# ce qui à l'usage nous donne

outthere grep -RF root /etc/*

voilà :) tu n'as plus qu'a claquer tout ca dans ton ~/.zshrc.

> Oui, less me sert souvent ("less is more" mais more ne l'est pas).


j'utilise peu less et more: mon pager de choix c'est vim (parceque
tellement pratique et extensible... tu peux écrire facilement des syntax
highlight ou des extensions et naviguer facilement dans les fichiers
avec gF):

grep -RFni root /etc/* |& v -

> ** >- diriger les messages vers un analyseur pour en extraire ce qui compte (requiert de connaître l'API du programme)


perso je prépare ma commande dans le shell, ensuite j'appelle fc qui
m'ouvre la dite commande dans vim.

dans vim tu peux piper un range (par defaut .) a une commande unix
et ! est une action que tu peux utiliser en mode normal. !! va donc
filtrer avec une commande a saisir.

!!zsh

et hop ... tu as le résutat de ta commande.

> En effet, il analyse bien et rend les logs plus digestes.


perso j'aime bien filtrer interactivement dans vim:

* voir ce que tu cherches:

:set hlsearch incsearch

* pour executer une action sur le dernier motif trouvé, il suffit de ne
pas mettre de pattern dans la partie recherche. donc

:g##d supprime toute les lignes qui contiennent un motif
:v##d supprime toute les lignes qui le ne contiennent pas

* u pour revenir a l'état précédent
* * pour selectionner le mot sur lequel tu es
* q/ pour éditer le motif dans un buffer vim

alors certes je parle de vim mais perso, mes outils préférés sont:

* tilix parceque c'est un terminal joli
* zsh parceque la syntaxe est bien plus évoluée que celle de bash
* tmux parceque ... pour tout plein de raisons
* fzf pour écrire plein de petites commandes interactives avec du fuzzy
searching. genre voilà comment j'ai remplacé le traditionnel avec
un truc coloré et qui me permet de fuzzy searcher

[..]

a+
marc
Marc Chantreux (24/12/2018, 02h30)
> Un truc très simple à faire, c'est de changer la variable
> d'environement PS1 de bash pour y mettre de la couleur (ou
> de l'inversion vidéo ou autre), ce qui permet de retrouver
> facilement le début de la sortie de la dernière commande.


le problème pour inverser la video juste pour la saisie de commande,
c'est qu'il faudrait hooker le <enter> final pour réinverser.

par contre sous zsh y'a le syntax highlighting:

aptitude install zsh-syntax-highlighting

puis dans ton .zshrc

. /usr/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh

pour laisser des lignes vides et mettre de la couleur dans ton prompt,
il suffit effectivement de parametrer PS1. le mien est devenu assez
copieux mais à la base c'était un truc comme ca:

export PS1='%K{blue}%F{white}%B?? %m %~ %b%f%k
?? ? '

il faut lire la section 'SIMPLE PROMPT ESCAPES' de man zshmisc pour le
détail.

notez que precmd est une fonction qui est executée a chaque prompt, on
peut donc modifier le prompt a la volée (par exemple si on arrive dans
un depot git). mon precmd:

[..]

a+
marc
roger.tarani (24/12/2018, 11h10)
Ça devient vraiment sympa de pouvoir paramétrer le shell aussi finement.

zsh : je suis resté à bash car situé entre le vieux sh et l'évolué esh et capable de faire tourner tous les scripts (bash etsh, mais pas zsh je crois).
Mais la syntaxe de zsh serait beaucoup(?) plus riche.
En pratique, c'est quoi les avantages et les inconvénients de zsh (parrapport à bash) ?

Y a-t-il un moyen de travailler (zsh ou bash) avec une double syntaxe, cad la syntaxe fine pas facile à mémoriser à moins de l'utilisertout le temps, et une syntaxe plus facile à mémoriser ?
Bon, c'est une question générale, en fait. C'est un peu comme lorsqu'on découvre les crontab ou les RE : il faut les assimiler, et puison s'y fait. Mais il y a souvent des erreurs qui peuvent se glisser, un jour qu'on est fatigué ou pressé.
Existe-t-il une sorte d'éditeur qui permette d'avoir la commande en zsh ou en RE, et sa traduction en quelques exemples faciles à mémoriser ?
C'est aussi un peu comme une macro : on peaufine une expression incompréhensible pour le commun des mortels, et on lui colle un nom. Un peu comme on nomme un programme en assembleur.

J'espère que je suis clair.

----- Original Message -----
From: Marc Chantreux <mc>
To: debian-user-french
Sent: Mon, 24 Dec 2018 01:28:12 +0100 (CET)
Subject: Re: Ergonomie/lisibilité en CLI

> Un truc très simple à faire, c'est de changer la variable
> d'environement PS1 de bash pour y mettre de la couleur (ou
> de l'inversion vidéo ou autre), ce qui permet de retrouver
> facilement le début de la sortie de la dernière commande.


le problème pour inverser la video juste pour la saisie de commande,
c'est qu'il faudrait hooker le <enter> final pour réinverser.

par contre sous zsh y'a le syntax highlighting:

aptitude install zsh-syntax-highlighting

puis dans ton .zshrc

. /usr/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh

pour laisser des lignes vides et mettre de la couleur dans ton prompt,
il suffit effectivement de parametrer PS1. le mien est devenu assez
copieux mais à la base c'était un truc comme ca:

export PS1='%K{blue}%F{white}%B?? %m %~ %b%f%k
?? ? '

il faut lire la section 'SIMPLE PROMPT ESCAPES' de man zshmisc pour le
détail.

notez que precmd est une fonction qui est executée a chaque prompt, on
peut donc modifier le prompt a la volée (par exemple si on arrive dans
un depot git). mon precmd:

[..]

a+
marc
Marc Chantreux (24/12/2018, 13h30)
salut,

(parceque j'aime lancer un troll a quelques heures du départ en vacances)

> zsh : je suis resté à bash car situé entre le vieux sh et l'évolué
> esh et capable de faire tourner tous les scripts (bash et sh, mais pas
> zsh je crois). Mais la syntaxe de zsh serait beaucoup(?) plus riche.


j'ai été un grand fan quand je ne connaissais que les shells
historiques, j'ai même été à l'origine de la traduction francaise d'ABS
(advanced bash scripting) ... j'ai découvert zsh parceque quelqu'un
avait écrit un post je ne sais plus ou lors de la sortie d'une version
majeure de bash (v3.0 je crois). la conclusion était que l'amélioration
était significative mais que bash restait à la traine. il conseillait de
regarder zsh ... ce que j'ai fais.

depuis je ne subit bash que parceque d'autres me l'infligent (par contre
je me suis mis a utiliser mksh, le ksh de openbsd et rc) en produisant
des outils qu'il m'arrive de devoir maintenir.

le shell scripting a deux énemis à mes yeux:

* la croyance dans la portabilité POSIX
* bash ... un shell a peine superieur à mksh avec le rapport
poids/puissance le pire du monde

mes choix actuels sont

* lorsque j'ai besoin de qqchose de léger, j'utilise rc (fourni par le
paquet 9base)
ou mksh.
* lorsque j'ai besoin de confort (tant pour la puissance de zle que pour
la richesse du langage)

maintenant à chaque fois que quelqu'un vient me montrer les évolutions
de bash, c'est un peu comme quand on me parle de l'évolution de python
ou JS: je trouve ça super cool que mon interlocuteur aie enfin à
disposition des fonctionalités que j'utilise depuis 20 ans mais pourquoi
avoir attendu tout ce temps ? jette un coup d'oeil dans man zshexpn:
cette partie du manuel à elle seule justifie de switcher. (si tu fais
man zsh, tu tombes sur la liste de toutes les sections) je ne détaille
pas ici parceque ce serait vite un roman mais

* une chaine est une chaine (le word splitting n'est pas automatique),
c'est con mais ca rend l'écriture plus naturelle quand tu viens de
langages dynamiques

* il y a plein de raccourcis pratiques pour modifier des chaines ou des
tableaux

cd =perl6(:A:h:h)
est l'équivalent de
cd $( dirname $( dirname $( realpath $( which perl6 )))
= => which
:A => realpath
:h => dirname

notes que tu a evité plein de forks juste parceque la syntaxe vole à
ton secours. c'est souvent le cas

* la syntaxe "alternative" (cf. zshmisc) est pour moi suffisante

for it in *.svg; do
gzip -c9 $it
done

s'écrit en zsh

for it (*.svg) gzip -c9 $it

perso j'ai un petit alias

@='for it'

du coup au quotidien j'écris plutot

@ (*.svg) gzip -c9 $it

* les extendedglob ... permettent des choses extrêmement puissantes
(comme le fait de pouvoir rajouter ses propres filtres, le ** pour
les motifs récursifs) ... globs que tu peux stocker dans des variables
que tu vas pouvoir ensuite jouer avec le modifier ~

images='(#i)*.(png|jpe#g|svg)'
@ ( a.png a.PNG a.jpg a.jpeg ) { [[ $it == $~images ]] && echo ok }

ls -l **/$~images # recursive parceque ** (adieu find dans les cas
simples)

* le shell courant lit dans le dernier élément du pipe courant. ca a
l'air de rien comme ca parceque tu te dis que les deux lignes
suivantes se valent

hostname | read h
h=$(hostname)

sauf que pouvoir écrire

fmt='$login is member of $gid'
getent passwd mc | IFS=: read login _ uid gid _
print ${(e)fmt}

mc is member of 1000

note l'expansion modifier e (evaluation) qui te permet de créer des
templates. si tu utilises les glob expansions en plus tu peux écrire
des trucs cools du genre

fmt='%F{blue}$login%f is member of %K{red}$gid%k'
getent passwd mc | IFS=: read login _ uid gid _
print ${(%e)fmt}

et voilà de la couleur :)

> En pratique, c'est quoi les avantages et les inconvénients de zsh (par rapport à bash) ?


l'expressivité de zsh permet d'éviter des forks a répétitions à base de
bricolages qui l'ont de sens que lorsque tu les écris comme t'obligent à
en faire les shells traditionnels. zsh n'est pas seulement plus
aggréable à écrire mais aussi tellement plus aggréable à maintenir.

le seul inconvénient c'est qu'il y a beaucoup de choses écrites en/pour bash.
il m'arrive donc souvent de prendre un script et de le réécrire avec mes
conventions, me coupant ainsi d'une possible communauté upstream.

> Y a-t-il un moyen de travailler (zsh ou bash) avec une double syntaxe,
> cad la syntaxe fine pas facile à mémoriser à moins de l'utiliser tout
> le temps, et une syntaxe plus facile à mémoriser ?


les bases de bash et zsh sont les mêmes: ksh. apres tu vas avoir de
petites subtilités. je parlais par exemple du word splitting

words="they don't come easy"
for w in $words; do
echo $w
done

te donne ca sous bash

they
don't
come
easy

et ca sous zsh

they don't come easy

parcequ'en zsh, une chaine est une chaine, un tableau est un tableau, et
tu peux splitter ($=words) une chaine en mots

donc les versions zsh sont

words=(they don\'t come easy)
for w in $words; do
echo $w
done

ou

words="they don't come easy"
for w in $=words; do
echo $w
done

et si tu veux dépiler des trucs compliqués avec des " et des ' dedans,
regarde du coté de (z) et (Q) et rcquotes. exemple

command_with_parameters='say "another word" and "i''ll use zsh"'
@ ( ${(Q)${(z)command_with_parameters}} )
print $it

say
another word
and
i'll use zsh

notes que j'ai écris i''ll alors que j'étais dans une chaine
simplement quotée: merci rcquotes.

(z) splite la chaine en tableau avec le zsh parsing, en résulte un
tableau.
(Q) vire les quotes proprement... comme c'est appliqué au tableau
produit par ${(z)...}, ce sont tous les éléments du tableau qui vont
être traités séparément.

je pourrais continuer pendant des heures. notons aussi que zsh sais
travailler avec des références symboliques de variables et evite bien
des bricolages a coup de eval

> Existe-t-il une sorte
> d'éditeur qui permette d'avoir la commande en zsh ou en RE, et sa
> traduction en quelques exemples faciles à mémoriser ?


le meilleur éditeur est la CLI elle-même: si tu as configuré la
completio (compinit), tu as plein d'informations en plus des
propositions elle-même.

> J'espère que je suis clair.


je crois comprendre et je te rejoinds: ne pas apprendre te force à
réinventer pauvrement (et c'est une quote d'un unixien celebre ... Denis
Ritchie je crois).

a+
marc
roger.tarani (24/12/2018, 15h20)
Ce n'est pas un troll selon moi car c'est constructif, argumenté et appuyé par des exemples concrets.

Usuellement, on choisit ses premiers outils parce qu'on a besoin de régler un problème plutôt urgemment (et on n'a donc pas le temps d'étudier tout ce qui se existe). Alors, on prend l'outil dont on a le plus entendu parler. Et c'est rarement le meilleur outil (tiens, ça me fait penser à pourquoi les gens ont utilisé aussi massivement Windows et Office... ; et aussi à comment je percevais Linux avant de décider de l'utiliser : trop compliqué, un truc pour les experts).

Ton message n'est pas un troll mais un cadeau.
Merci !

----- Original Message -----
From: Marc Chantreux <mc>
To: roger tarani <roger.tarani>
Cc: 'Liste Debian' <debian-user-french>
Sent: Mon, 24 Dec 2018 12:25:29 +0100 (CET)
Subject: zsh vs bash

salut,

(parceque j'aime lancer un troll a quelques heures du départ en vacances)

> zsh : je suis resté à bash car situé entre le vieux sh et l'évolué
> esh et capable de faire tourner tous les scripts (bash et sh, mais pas
> zsh je crois). Mais la syntaxe de zsh serait beaucoup(?) plus riche.


j'ai été un grand fan quand je ne connaissais que les shells
historiques, j'ai même été à l'origine de la traductionfrancaise d'ABS
(advanced bash scripting) ... j'ai découvert zsh parceque quelqu'un
avait écrit un post je ne sais plus ou lors de la sortie d'une version
majeure de bash (v3.0 je crois). la conclusion était que l'amélioration
était significative mais que bash restait à la traine. il conseillait de
regarder zsh ... ce que j'ai fais.

depuis je ne subit bash que parceque d'autres me l'infligent (par contre
je me suis mis a utiliser mksh, le ksh de openbsd et rc) en produisant
des outils qu'il m'arrive de devoir maintenir.

le shell scripting a deux énemis à mes yeux:

* la croyance dans la portabilité POSIX
* bash ... un shell a peine superieur à mksh avec le rapport
poids/puissance le pire du monde

mes choix actuels sont

* lorsque j'ai besoin de qqchose de léger, j'utilise rc (fourni par le
paquet 9base)
ou mksh.
* lorsque j'ai besoin de confort (tant pour la puissance de zle que pour
la richesse du langage)

maintenant à chaque fois que quelqu'un vient me montrer les évolutions
de bash, c'est un peu comme quand on me parle de l'évolution de python
ou JS: je trouve ça super cool que mon interlocuteur aie enfin à
disposition des fonctionalités que j'utilise depuis 20 ans mais pourquoi
avoir attendu tout ce temps ? jette un coup d'oeil dans man zshexpn:
cette partie du manuel à elle seule justifie de switcher. (si tu fais
man zsh, tu tombes sur la liste de toutes les sections) je ne détaille
pas ici parceque ce serait vite un roman mais

* une chaine est une chaine (le word splitting n'est pas automatique),
c'est con mais ca rend l'écriture plus naturelle quand tu viens de
langages dynamiques

* il y a plein de raccourcis pratiques pour modifier des chaines ou des
tableaux

cd =perl6(:A:h:h)
est l'équivalent de
cd $( dirname $( dirname $( realpath $( which perl6 )))
= => which
:A => realpath
:h => dirname

notes que tu a evité plein de forks juste parceque la syntaxe vole à
ton secours. c'est souvent le cas

* la syntaxe "alternative" (cf. zshmisc) est pour moi suffisante

for it in *.svg; do
gzip -c9 $it
done

s'écrit en zsh

for it (*.svg) gzip -c9 $it

perso j'ai un petit alias

@='for it'

du coup au quotidien j'écris plutot

@ (*.svg) gzip -c9 $it

* les extendedglob ... permettent des choses extrêmement puissantes
(comme le fait de pouvoir rajouter ses propres filtres, le ** pour
les motifs récursifs) ... globs que tu peux stocker dans des variables
que tu vas pouvoir ensuite jouer avec le modifier ~

images='(#i)*.(png|jpe#g|svg)'
@ ( a.png a.PNG a.jpg a.jpeg ) { [[ $it == $~images ]] && echo ok }

ls -l **/$~images # recursive parceque ** (adieu find dans les cas
simples)

* le shell courant lit dans le dernier élément du pipe courant. ca a
l'air de rien comme ca parceque tu te dis que les deux lignes
suivantes se valent

hostname | read h
h=$(hostname)

sauf que pouvoir écrire

fmt='$login is member of $gid'
getent passwd mc | IFS=: read login _ uid gid _
print ${(e)fmt}

mc is member of 1000

note l'expansion modifier e (evaluation) qui te permet de créer des
templates. si tu utilises les glob expansions en plus tu peux écrire
des trucs cools du genre

fmt='%F{blue}$login%f is member of %K{red}$gid%k'
getent passwd mc | IFS=: read login _ uid gid _
print ${(%e)fmt}

et voilà de la couleur :)

> En pratique, c'est quoi les avantages et les inconvénients de zsh (par rapport à bash) ?


l'expressivité de zsh permet d'éviter des forks a répétitions à base de
bricolages qui l'ont de sens que lorsque tu les écris comme t'obligentà
en faire les shells traditionnels. zsh n'est pas seulement plus
aggréable à écrire mais aussi tellement plus aggréable à maintenir.

le seul inconvénient c'est qu'il y a beaucoup de choses écrites en/pour bash.
il m'arrive donc souvent de prendre un script et de le réécrire avec mes
conventions, me coupant ainsi d'une possible communauté upstream.

> Y a-t-il un moyen de travailler (zsh ou bash) avec une double syntaxe,
> cad la syntaxe fine pas facile à mémoriser à moins de l'utiliser tout
> le temps, et une syntaxe plus facile à mémoriser ?


les bases de bash et zsh sont les mêmes: ksh. apres tu vas avoir de
petites subtilités. je parlais par exemple du word splitting

words="they don't come easy"
for w in $words; do
echo $w
done

te donne ca sous bash

they
don't
come
easy

et ca sous zsh

they don't come easy

parcequ'en zsh, une chaine est une chaine, un tableau est un tableau, et
tu peux splitter ($=words) une chaine en mots

donc les versions zsh sont

words=(they don't come easy)
for w in $words; do
echo $w
done

ou

words="they don't come easy"
for w in $=words; do
echo $w
done

et si tu veux dépiler des trucs compliqués avec des " et des ' dedans,
regarde du coté de (z) et (Q) et rcquotes. exemple

command_with_parameters='say "another word" and "i''ll use zsh"'
@ ( ${(Q)${(z)command_with_parameters}} )
print $it

say
another word
and
i'll use zsh

notes que j'ai écris i''ll alors que j'étais dans une chaine
simplement quotée: merci rcquotes.

(z) splite la chaine en tableau avec le zsh parsing, en résulte un
tableau.
(Q) vire les quotes proprement... comme c'est appliqué au tableau
produit par ${(z)...}, ce sont tous les éléments du tableau qui vont
être traités séparément.

je pourrais continuer pendant des heures. notons aussi que zsh sais
travailler avec des références symboliques de variables et evite bien
des bricolages a coup de eval

> Existe-t-il une sorte
> d'éditeur qui permette d'avoir la commande en zsh ou en RE, et sa
> traduction en quelques exemples faciles à mémoriser ?


le meilleur éditeur est la CLI elle-même: si tu as configuréla
completio (compinit), tu as plein d'informations en plus des
propositions elle-même.

> J'espère que je suis clair.


je crois comprendre et je te rejoinds: ne pas apprendre te force à
réinventer pauvrement (et c'est une quote d'un unixien celebre ... Denis
Ritchie je crois).

a+
marc
Marc Chantreux (24/12/2018, 16h10)
hello,

> Ton message n'est pas un troll mais un cadeau.


joyeux noel alors :)

> Merci !


avec plaisir

marc
Discussions similaires
Lisibilité

Lisibilité

pb de lisibilité sur le net

Ergonomie ?


Fuseau horaire GMT +2. Il est actuellement 13h01. | Privacy Policy