Re: Ergonomie/lisibilité en CLI

2018-12-23 Par sujet Marc Chantreux
> 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  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:

https://github.com/eiro/p6-scripts/blob/master/zsh-plugins/ps1-configuration.zsh

a+
marc



Re: Ergonomie/lisibilité en CLI

2018-12-23 Par sujet Marc Chantreux
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

  
https://github.com/eiro/p6-scripts/blob/master/zsh-plugins/fzf-history-search-backward.zsh

a+
marc



Re: Ergonomie/lisibilité en CLI

2018-12-23 Par sujet Yves Rutschle
On Sun, Dec 23, 2018 at 03:51:24PM +0100, roger.tar...@free.fr 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.



Re: Ergonomie/lisibilité en CLI

2018-12-23 Par sujet Raphaël POITEVIN
roger.tar...@free.fr 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.
-- 
Raphaël



Re: Ergonomie/lisibilité en CLI

2018-12-23 Par sujet roger . tarani
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!



Re: Ergonomie/lisibilité en CLI

2018-12-23 Par sujet roger . tarani
Paquet tmux. À associer à mosh pour l'accès à distance, c'est parfait.
-- 
Daniel

tmux : vraiment 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 (et "less is more" mais more ne l'est pas)
Raphaël

Merci de me faire lâcher mes tablettes de , c'est noël!



Re: Ergonomie/lisibilité en CLI

2018-12-23 Par sujet steve

Le 23-12-2018, à 15:51:24 +0100, roger.tar...@free.fr 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 



Re: Ergonomie/lisibilité en CLI

2018-12-23 Par sujet Raphaël POITEVIN
roger.tar...@free.fr 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
-- 
Raphaël



Re: Ergonomie/lisibilité en CLI

2018-12-23 Par sujet daniel huhardeaux

Le 23/12/2018 à 15:51, roger.tar...@free.fr a écrit :

Bonjour la liste (de la veille de Noël ! )


Bonjour



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 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.

--
Daniel



Ergonomie/lisibilité en CLI

2018-12-23 Par sujet roger . tarani
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 ne sais pas vous, mais je trouve ma 
console plutôt pas trop ergonomique. 

Merci