knowledge - Contributions [fr]

ANSI

2026-09-10T11:55:35Z

Jpinon : /* Couleurs étendues */

== Les codes d'échappement ==
{| class="wikitable"
!Code
!Abbr
!Name
!Effect
|-
|CSI <var>n</var> A
|CUU
|Cursor Up
| rowspan="4" |Moves the cursor <var>n</var> (default <code>1</code>) cells in the given direction. If the cursor is already at the edge of the screen, this has no effect.
|-
|CSI <var>n</var> B
|CUD
|Cursor Down
|-
|CSI <var>n</var> C
|CUF
|Cursor Forward
|-
|CSI <var>n</var> D
|CUB
|Cursor Back
|-
|CSI <var>n</var> E
|CNL
|Cursor Next Line
|Moves cursor to beginning of the line <var>n</var> (default <code>1</code>) lines down. (not ANSI.SYS)
|-
|CSI <var>n</var> F
|CPL
|Cursor Previous Line
|Moves cursor to beginning of the line <var>n</var> (default <code>1</code>) lines up. (not ANSI.SYS)
|-
|CSI <var>n</var> G
|CHA
|Cursor Horizontal Absolute
|Moves the cursor to column <var>n</var> (default <code>1</code>). (not ANSI.SYS)
|-
|CSI <var>n</var> ; <var>m</var> H
|CUP
|Cursor Position
|Moves the cursor to row <var>n</var>, column <var>m</var>. The values are 1-based, and default to <code>1</code> (top left corner) if omitted. A sequence such as <code>CSI ;5H</code> is a synonym for <code>CSI 1;5H</code> as well as <code>CSI 17;H</code> is the same as <code>CSI 17H</code> and <code>CSI 17;1H</code>
|-
|CSI <var>n</var> J
|ED
|Erase in Display
|Clears part of the screen. If <var>n</var> is <code>0</code> (or missing), clear from cursor to end of screen. If <var>n</var> is <code>1</code>, clear from cursor to beginning of the screen. If <var>n</var> is <code>2</code>, clear entire screen (and moves cursor to upper left on DOS ANSI.SYS). If <var>n</var> is <code>3</code>, clear entire screen and delete all lines saved in the scrollback buffer (this feature was added for xterm and is supported by other terminal applications).
|-
|CSI <var>n</var> K
|EL
|Erase in Line
|Erases part of the line. If <var>n</var> is <code>0</code> (or missing), clear from cursor to the end of the line. If <var>n</var> is <code>1</code>, clear from cursor to beginning of the line. If <var>n</var> is <code>2</code>, clear entire line. Cursor position does not change.
|-
|CSI <var>n</var> S
|SU
|Scroll Up
|Scroll whole page up by <var>n</var> (default <code>1</code>) lines. New lines are added at the bottom. (not ANSI.SYS)
|-
|CSI <var>n</var> T
|SD
|Scroll Down
|Scroll whole page down by <var>n</var> (default <code>1</code>) lines. New lines are added at the top. (not ANSI.SYS)
|-
|CSI <var>n</var> ; <var>m</var> f
|HVP
|Horizontal Vertical Position
|Same as CUP, but counts as a format effector function (like CR or LF) rather than an editor function (like CUD or CNL). This can lead to different handling in certain terminal modes.
|-
|CSI <var>n</var> m
|SGR
|Select Graphic Rendition
|Sets colors and style of the characters following this code
|-
|CSI 5i
|
|AUX Port On
|Enable aux serial port usually for local serial printer
|-
|CSI 4i
|
|AUX Port Off
|Disable aux serial port usually for local serial printer
|-
|CSI 6n
|DSR
|Device Status Report
|Reports the cursor position (CPR) by transmitting <code>ESC[n;mR</code>, where <var>n</var> is the row and <var>m</var> is the column.
|-
|CSI s
|SAV
|Save cursor
|Save the current cursor position (L;C). to be used with RCL
|-
|CSI u
|RCL
|Restore cursor
|Move back cursor to the position saved by SAV
|}

== Les styles ==
Il s'agit de détailler les codes :
{| class="wikitable"
|CSI <var>n</var> m
|SGR
|Select Graphic Rendition
|Sets colors and style of the characters following this code
|}
Le tableau suivant donne les modes existants:
{| class="wikitable"
|-
!''n''
!Name
!Note
!Exemple *
|-
|0
|Reset ''or'' normal
|All attributes become turned off
|[[Fichier:ANSO0M.png|sans_cadre]]
|-
|1
|Bold or increased intensity
|As with faint, the color change is a PC (SCO / CGA) invention.[''better source needed'']
|N/A
|-
|2
|Faint, decreased intensity, ''or'' dim
|May be implemented as a light font weight like bold.
|N/A
|-
|3
|Italic
|Not widely supported. Sometimes treated as inverse or blink.
|N/A
|-
|4
|Underline
|Style extensions exist for Kitty, VTE, mintty and iTerm2.
|[[Fichier:ANSI4M.png|sans_cadre]]
|-
|5
|Slow blink
|Sets blinking to less than 150 times per minute
|
|-
|6
|Rapid blink
|MS-DOS ANSI.SYS, 150+ per minute; not widely supported
|N/A
|-
|7
|Reverse video ''or'' invert
|Swap foreground and background colors; inconsistent emulation[''dubious – discuss'']
|[[Fichier:ANSI7m.png|sans_cadre]]
|-
|8
|Conceal ''or'' hide
|Not widely supported.
|N/A
|-
|9
|Crossed-out, ''or'' strike
|Characters legible but marked as if for deletion. Not supported in Terminal.app
|N/A
|-
|10
|Primary (default) font
|
|N/A
|-
|11–19
|Alternative font
|Select alternative font ''n'' − 10
|N/A
|-
|20
|Fraktur (Gothic)
|Rarely supported
|N/A
|-
|21
|Doubly underlined; or: not bold
|Double-underline per ECMA-48, but instead disables bold intensity on several terminals, including in the Linux kernel's console before version 4.17.
|[[Fichier:ANSI4M.png|sans_cadre]]
|-
|22
|Normal intensity
|Neither bold nor faint; color changes where intensity is implemented as such.
|[[Fichier:ANSO0M.png|sans_cadre]]
|-
|23
|Neither italic, nor blackletter
|
|
|-
|24
|Not underlined
|Neither singly nor doubly underlined
|[[Fichier:ANSO0M.png|sans_cadre]]
|-
|25
|Not blinking
|Turn blinking off
|[[Fichier:ANSO0M.png|sans_cadre]]
|-
|26
|Proportional spacing
|ITU T.61 and T.416, not known to be used on terminals
|N/A
|-
|27
|Not reversed
|
|N/A
|-
|28
|Reveal
|Not concealed
|
|}
<nowiki>*</nowiki> Les exemples sont pris sut putty/mobaxterm. N/A c'est que, sur les terminaux caractère standards ce code est sans effet.

== Les couleurs ==

=== Couleurs de bases ===
On à 8 couleurs de bases + les mêmes couleurs en surintensité. (à la CGA pour ceux qui s'en souviennent)
{| class="wikitable"
|30–37
|Set foreground color
|[[Fichier:ForogroundANSI.png|sans_cadre]]
|-
|90-97
|Set bright foreground color
|[[Fichier:Ansi9x.png|sans_cadre]]
|-
|40–47
|Set background color
|[[Fichier:ANSIbackground.png|sans_cadre]]
|-
|100-107
|Set bright background color
|[[Fichier:10xansi.png|sans_cadre]]
|}
On peut chainer les changements en une seule commande:<syntaxhighlight lang="bash">
printf "\n\e[31;47m Hello Wor\e[0m\n\n"
</syntaxhighlight>Passe en rouge sur fond blanc!

[[Fichier:Ansii combine.png|sans_cadre]]

=== Couleurs étendues ===
Là on passe aux écrans EGA, On agrandie la palette:

[[Fichier:PaletteANSI.png|sans_cadre|395x395px]]

Le nombre indique la couleur de fond :<syntaxhighlight lang="text">
ESC[48:5:⟨n⟩m Select background color
</syntaxhighlight>La couleur du texte est soit blanc soit noir pour qu'on puise le voir. Pour changer la couleur du texte on peut, de la même façon, <syntaxhighlight lang="text">
ESC[38:5:⟨n⟩m Select foreground color
</syntaxhighlight>Attention tous les terminaux ne savent pas interpréter ces codes:

* Ceux qui ne savent pas : putty, cygwin (et donc mobaxterm)
* Ceux qui savent : Le terminal de base linux sur raspberry PI (en mode texte), lxterminal, MINGW64 sous Windows et le terminal Windows (utilisé par WSL, powerShell...).
<syntaxhighlight lang="perl">
#!/usr/bin/perl
my $c=0;
for ($i=16; $i<=231; $i++) {
printf "\033[48:5:%3sm ", $i;
$c++;
if (($c % 36)==0){
print ("\n");
}
}

</syntaxhighlight>Nous donne:

[[Fichier:Rainbowlut.png|sans_cadre|512x512px]]

==== En 24 bits ====
On passe au VGA. 8 bits par composantes '''r''', '''g''' et '''b'''. 8x3=24 bits. Ca fait quelque chose comme 17 million de couleurs différentes (16 777 216 exactement). <syntaxhighlight lang="perl">
#!/usr/bin/perl
#
for ($y=0; $y<=255; $y+=4){
for ($x=0; $x<=255; $x+=2){
printf ("\033[48;2;%s;%s;%sm ",$x,$y,255-$x);
}
print ("\033[0m\n");
}

</syntaxhighlight>Nous donne un joli:

[[Fichier:RGBANSI.png|sans_cadre|593x593px]]

Comme quoi dans un terminal en mode caractère on peut faire de joli dessins!

Ces couleurs en 24 bits sont, elles, correctement gérées par putty/mobaxterm.

== Utiliser dans du code ==
L'utilisation des codes ANSI dans un programme peut se faire en incluant simplement les codes d’échappement dans les chaines de caractères écrites à l'écran.

Ainsi pour écrire!

[[Fichier:ANSI example.png|sans_cadre|180x180px]]

On utilisera la chaine :<syntaxhighlight lang="bash">
"Hello \033[7m world \033[0m !"
</syntaxhighlight>

=== En shell ===
Attention en bash ou tout descendant du bourne shell un simple:<syntaxhighlight lang="bash">
echo "Hello \033[7m world \033[0m !"
</syntaxhighlight>Donnera ...<syntaxhighlight lang="text">
Hello \033[7m world \033[0m !
</syntaxhighlight>Il faut préciser l'option -e (enable escape characters) <syntaxhighlight lang="bash">
echo -e "Hello \033[7m world \033[0m !"
</syntaxhighlight>Ou (seulement en bash) la commande printf dont la syntaxes est celle du C.<syntaxhighlight lang="bash">
printf "Hello \033[7m world \033[0m !\n"
</syntaxhighlight>

=== En C/C++ ===
<syntaxhighlight lang="c++">
void main(int argc, char** argv){
printf ("Hello \033[7m world \033[0m !\n");
}
</syntaxhighlight>

=== En perl ===
On peut faire simplement :<syntaxhighlight lang="perl">
print "Hello \033[7m world \033[0m !\n";
</syntaxhighlight>[[Fichier:HelloWorld-ANSIPL.png|sans_cadre|147x147px]]

Mais on peut utiliser la module Term::ANSIColor

Il y a pas mal de façon de l'utiliser. La plus simple :
<syntaxhighlight lang="perl">
use Term::ANSIColor qw(:constants);

print "[".GREEN."PASS".RESET."]\n";
print "[".RED."FAIL".RESET."]\n";
</syntaxhighlight>
[[Fichier:PASSFAIL-ANSI-PL.png|sans_cadre|109x109px]]

Les constantes utilisables:

<syntaxhighlight lang="text">
CLEAR RESET BOLD DARK
FAINT ITALIC UNDERLINE UNDERSCORE
BLINK REVERSE CONCEALED

BLACK RED GREEN YELLOW
BLUE MAGENTA CYAN WHITE
BRIGHT_BLACK BRIGHT_RED BRIGHT_GREEN BRIGHT_YELLOW
BRIGHT_BLUE BRIGHT_MAGENTA BRIGHT_CYAN BRIGHT_WHITE

ON_BLACK ON_RED ON_GREEN ON_YELLOW
ON_BLUE ON_MAGENTA ON_CYAN ON_WHITE
ON_BRIGHT_BLACK ON_BRIGHT_RED ON_BRIGHT_GREEN ON_BRIGHT_YELLOW
ON_BRIGHT_BLUE ON_BRIGHT_MAGENTA ON_BRIGHT_CYAN ON_BRIGHT_WHITE
</syntaxhighlight>On se limite aux couleurs mais le module permet beaucoup de choses. Une description en français est disponible sur [https://perldoc.perl.org/Term::ANSIColor la page du module] lui même.

=== En java ===
<syntaxhighlight lang="java">
class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello \033[7m world \033[0m !");
}
}
</syntaxhighlight>Bon au retour à la ligne près (certaint l'incluent par défaut d'autres pas) c'est toujours la même chaine.

Un langage fait le malin pour pas faire comme les autres python

=== En python ===
Un simple <syntaxhighlight lang="python3">
print ("Hello \033[7m world \033[0m !")
</syntaxhighlight>Afficahit un truc moche :Il interprètait (un peu) les codes ANSI pour les remplacer par... des espaces. Etrange.
Pour utiliser les codes ANSI il fallait utiliser une autre syntaxe et, de plus, seul les changements de couleurs (3x pour la couleur du texte et 4x pour le fond) sont acceptés.<syntaxhighlight lang="python">
print (u"Hello \u001B[47m\u001B[30m World \u001B[0m !")
</syntaxhighlight>Nous donne "presque" ce que nous attendons.

[[Fichier:Python-Hello-almost-perfect.png|sans_cadre|505x505px]]

Le "World" est écrit en noir sur fond ''blanc sale''. en Gris quoi.

N'essayez pas de remplacer \001B[47m par \001B[107m ça ne marches pas.

Python a "sa syntaxe":<syntaxhighlight lang="python">
print (u"\nHello \u001B[47;1m\u001B[30m World \u001B[0m !")
</syntaxhighlight>Le ;1 après le \u001B[47 et le m dit que la couleur doit être "vive".

Un nombre limité de fonctions de gestion de curseur sont aussi gérées:
----

* '''Up''': <code>\u001b[{n}A</code> moves cursor up by <code>n</code>
* '''Down''': <code>\u001b[{n}B</code> moves cursor down by <code>n</code>
* '''Right''': <code>\u001b[{n}C</code> moves cursor right by <code>n</code>
* '''Left''': <code>\u001b[{n}D</code> moves cursor left by <code>n</code>

----

* '''Next Line''': <code>\u001b[{n}E</code> moves cursor to beginning of line <code>n</code> lines down
* '''Prev Line''': <code>\u001b[{n}F</code> moves cursor to beginning of line <code>n</code> lines down

----

* '''Set Column''': <code>\u001b[{n}G</code> moves cursor to column <code>n</code>
* '''Set Position''': <code>\u001b[{n};{m}H</code> moves cursor to row <code>n</code> column <code>m</code>

----

* '''Clear Screen''': <code>\u001b[{n}J</code> clears the screen
** <code>n=0</code> clears from cursor until end of screen,
** <code>n=1</code> clears from cursor to beginning of screen
** <code>n=2</code> clears entire screen
* '''Clear Line''': <code>\u001b[{n}K</code> clears the current line
** <code>n=0</code> clears from cursor to end of line
** <code>n=1</code> clears from cursor to start of line
** <code>n=2</code> clears entire line

----

* '''Save Position''': <code>\u001b[{s}</code> saves the current cursor position
* '''Save Position''': <code>\u001b[{u}</code> restores the cursor to the last saved position

Ces infos ont été trouvées sur : https://www.lihaoyi.com/post/BuildyourownCommandLinewithANSIescapecodes.html

En Python ce qui est compliqué devient très simple (numpy par exemple permet de gérer des matrices de réels en deux lignes de code) mais ce qui était simple (écrite en inversion vidéo) devient très compliqué!

== Avec vi (vim) ==
On peut vouloir ajouter des codes ANSI dans un fichier texte. Il faut cependant ajouter un ESC dans le flux de caractères. Pour cela on tape au clavier (en mode insertion):<syntaxhighlight lang="text">
<Ctrl>V + <Esc>
</syntaxhighlight>Dans vi son on tape:<syntaxhighlight lang="text">
^[[7mHello world!^[[0m
</syntaxhighlight>et bien le cat de ce fichier donnera:

[[Fichier:ANSI Hello.png|sans_cadre]]

ANSI

2026-09-10T11:42:25Z

Jpinon :

== Les codes d'échappement ==
{| class="wikitable"
!Code
!Abbr
!Name
!Effect
|-
|CSI <var>n</var> A
|CUU
|Cursor Up
| rowspan="4" |Moves the cursor <var>n</var> (default <code>1</code>) cells in the given direction. If the cursor is already at the edge of the screen, this has no effect.
|-
|CSI <var>n</var> B
|CUD
|Cursor Down
|-
|CSI <var>n</var> C
|CUF
|Cursor Forward
|-
|CSI <var>n</var> D
|CUB
|Cursor Back
|-
|CSI <var>n</var> E
|CNL
|Cursor Next Line
|Moves cursor to beginning of the line <var>n</var> (default <code>1</code>) lines down. (not ANSI.SYS)
|-
|CSI <var>n</var> F
|CPL
|Cursor Previous Line
|Moves cursor to beginning of the line <var>n</var> (default <code>1</code>) lines up. (not ANSI.SYS)
|-
|CSI <var>n</var> G
|CHA
|Cursor Horizontal Absolute
|Moves the cursor to column <var>n</var> (default <code>1</code>). (not ANSI.SYS)
|-
|CSI <var>n</var> ; <var>m</var> H
|CUP
|Cursor Position
|Moves the cursor to row <var>n</var>, column <var>m</var>. The values are 1-based, and default to <code>1</code> (top left corner) if omitted. A sequence such as <code>CSI ;5H</code> is a synonym for <code>CSI 1;5H</code> as well as <code>CSI 17;H</code> is the same as <code>CSI 17H</code> and <code>CSI 17;1H</code>
|-
|CSI <var>n</var> J
|ED
|Erase in Display
|Clears part of the screen. If <var>n</var> is <code>0</code> (or missing), clear from cursor to end of screen. If <var>n</var> is <code>1</code>, clear from cursor to beginning of the screen. If <var>n</var> is <code>2</code>, clear entire screen (and moves cursor to upper left on DOS ANSI.SYS). If <var>n</var> is <code>3</code>, clear entire screen and delete all lines saved in the scrollback buffer (this feature was added for xterm and is supported by other terminal applications).
|-
|CSI <var>n</var> K
|EL
|Erase in Line
|Erases part of the line. If <var>n</var> is <code>0</code> (or missing), clear from cursor to the end of the line. If <var>n</var> is <code>1</code>, clear from cursor to beginning of the line. If <var>n</var> is <code>2</code>, clear entire line. Cursor position does not change.
|-
|CSI <var>n</var> S
|SU
|Scroll Up
|Scroll whole page up by <var>n</var> (default <code>1</code>) lines. New lines are added at the bottom. (not ANSI.SYS)
|-
|CSI <var>n</var> T
|SD
|Scroll Down
|Scroll whole page down by <var>n</var> (default <code>1</code>) lines. New lines are added at the top. (not ANSI.SYS)
|-
|CSI <var>n</var> ; <var>m</var> f
|HVP
|Horizontal Vertical Position
|Same as CUP, but counts as a format effector function (like CR or LF) rather than an editor function (like CUD or CNL). This can lead to different handling in certain terminal modes.
|-
|CSI <var>n</var> m
|SGR
|Select Graphic Rendition
|Sets colors and style of the characters following this code
|-
|CSI 5i
|
|AUX Port On
|Enable aux serial port usually for local serial printer
|-
|CSI 4i
|
|AUX Port Off
|Disable aux serial port usually for local serial printer
|-
|CSI 6n
|DSR
|Device Status Report
|Reports the cursor position (CPR) by transmitting <code>ESC[n;mR</code>, where <var>n</var> is the row and <var>m</var> is the column.
|-
|CSI s
|SAV
|Save cursor
|Save the current cursor position (L;C). to be used with RCL
|-
|CSI u
|RCL
|Restore cursor
|Move back cursor to the position saved by SAV
|}

== Les styles ==
Il s'agit de détailler les codes :
{| class="wikitable"
|CSI <var>n</var> m
|SGR
|Select Graphic Rendition
|Sets colors and style of the characters following this code
|}
Le tableau suivant donne les modes existants:
{| class="wikitable"
|-
!''n''
!Name
!Note
!Exemple *
|-
|0
|Reset ''or'' normal
|All attributes become turned off
|[[Fichier:ANSO0M.png|sans_cadre]]
|-
|1
|Bold or increased intensity
|As with faint, the color change is a PC (SCO / CGA) invention.[''better source needed'']
|N/A
|-
|2
|Faint, decreased intensity, ''or'' dim
|May be implemented as a light font weight like bold.
|N/A
|-
|3
|Italic
|Not widely supported. Sometimes treated as inverse or blink.
|N/A
|-
|4
|Underline
|Style extensions exist for Kitty, VTE, mintty and iTerm2.
|[[Fichier:ANSI4M.png|sans_cadre]]
|-
|5
|Slow blink
|Sets blinking to less than 150 times per minute
|
|-
|6
|Rapid blink
|MS-DOS ANSI.SYS, 150+ per minute; not widely supported
|N/A
|-
|7
|Reverse video ''or'' invert
|Swap foreground and background colors; inconsistent emulation[''dubious – discuss'']
|[[Fichier:ANSI7m.png|sans_cadre]]
|-
|8
|Conceal ''or'' hide
|Not widely supported.
|N/A
|-
|9
|Crossed-out, ''or'' strike
|Characters legible but marked as if for deletion. Not supported in Terminal.app
|N/A
|-
|10
|Primary (default) font
|
|N/A
|-
|11–19
|Alternative font
|Select alternative font ''n'' − 10
|N/A
|-
|20
|Fraktur (Gothic)
|Rarely supported
|N/A
|-
|21
|Doubly underlined; or: not bold
|Double-underline per ECMA-48, but instead disables bold intensity on several terminals, including in the Linux kernel's console before version 4.17.
|[[Fichier:ANSI4M.png|sans_cadre]]
|-
|22
|Normal intensity
|Neither bold nor faint; color changes where intensity is implemented as such.
|[[Fichier:ANSO0M.png|sans_cadre]]
|-
|23
|Neither italic, nor blackletter
|
|
|-
|24
|Not underlined
|Neither singly nor doubly underlined
|[[Fichier:ANSO0M.png|sans_cadre]]
|-
|25
|Not blinking
|Turn blinking off
|[[Fichier:ANSO0M.png|sans_cadre]]
|-
|26
|Proportional spacing
|ITU T.61 and T.416, not known to be used on terminals
|N/A
|-
|27
|Not reversed
|
|N/A
|-
|28
|Reveal
|Not concealed
|
|}
<nowiki>*</nowiki> Les exemples sont pris sut putty/mobaxterm. N/A c'est que, sur les terminaux caractère standards ce code est sans effet.

== Les couleurs ==

=== Couleurs de bases ===
On à 8 couleurs de bases + les mêmes couleurs en surintensité. (à la CGA pour ceux qui s'en souviennent)
{| class="wikitable"
|30–37
|Set foreground color
|[[Fichier:ForogroundANSI.png|sans_cadre]]
|-
|90-97
|Set bright foreground color
|[[Fichier:Ansi9x.png|sans_cadre]]
|-
|40–47
|Set background color
|[[Fichier:ANSIbackground.png|sans_cadre]]
|-
|100-107
|Set bright background color
|[[Fichier:10xansi.png|sans_cadre]]
|}
On peut chainer les changements en une seule commande:<syntaxhighlight lang="bash">
printf "\n\e[31;47m Hello Wor\e[0m\n\n"
</syntaxhighlight>Passe en rouge sur fond blanc!

[[Fichier:Ansii combine.png|sans_cadre]]

=== Couleurs étendues ===
Là on passe aux écrans EGA, On agrandie la palette:

[[Fichier:PaletteANSI.png|sans_cadre|395x395px]]

Le nombre indique la couleur de fond :<syntaxhighlight lang="text">
ESC[48:5:⟨n⟩m Select background color
</syntaxhighlight>La couleur du texte est soit blanc soit noir pour qu'on puise le voir. Pour changer la couleur du texte on peut, de la même façon, <syntaxhighlight lang="text">
ESC[38:5:⟨n⟩m Select foreground color
</syntaxhighlight>Attention avec putty, cygwin et donc mobaxterm, par défaut, ces subtilités ne sont pas gérées. En revanche le terminal de base linux sur raspberry PI et MINGW64 sous Windows marche tres bien.<syntaxhighlight lang="perl">
#!/usr/bin/perl
my $c=0;
for ($i=16; $i<=231; $i++) {
printf "\033[48:5:%3sm ", $i;
$c++;
if (($c % 36)==0){
print ("\n");
}
}

</syntaxhighlight>Nous donne:

[[Fichier:Rainbowlut.png|sans_cadre|512x512px]]

==== En 24 bits ====
On passe au VGA. 8 bits par composantes '''r''', '''g''' et '''b'''. 8x3=24 bits. Ca fait quelque chose comme 17 million de couleurs différentes (16 777 216 exactement). <syntaxhighlight lang="perl">
#!/usr/bin/perl
#
for ($y=0; $y<=255; $y+=4){
for ($x=0; $x<=255; $x+=2){
printf ("\033[48;2;%s;%s;%sm ",$x,$y,255-$x);
}
print ("\033[0m\n");
}

</syntaxhighlight>Nous donne un joli:

[[Fichier:RGBANSI.png|sans_cadre|593x593px]]

Comme quoi dans un terminal en mode caractère on peut faire de joli dessins!

Ces couleurs en 24 bits sont, elles, correctement gérées par putty/mobaxterm.

== Utiliser dans du code ==
L'utilisation des codes ANSI dans un programme peut se faire en incluant simplement les codes d’échappement dans les chaines de caractères écrites à l'écran.

Ainsi pour écrire!

[[Fichier:ANSI example.png|sans_cadre|180x180px]]

On utilisera la chaine :<syntaxhighlight lang="bash">
"Hello \033[7m world \033[0m !"
</syntaxhighlight>

=== En shell ===
Attention en bash ou tout descendant du bourne shell un simple:<syntaxhighlight lang="bash">
echo "Hello \033[7m world \033[0m !"
</syntaxhighlight>Donnera ...<syntaxhighlight lang="text">
Hello \033[7m world \033[0m !
</syntaxhighlight>Il faut préciser l'option -e (enable escape characters) <syntaxhighlight lang="bash">
echo -e "Hello \033[7m world \033[0m !"
</syntaxhighlight>Ou (seulement en bash) la commande printf dont la syntaxes est celle du C.<syntaxhighlight lang="bash">
printf "Hello \033[7m world \033[0m !\n"
</syntaxhighlight>

=== En C/C++ ===
<syntaxhighlight lang="c++">
void main(int argc, char** argv){
printf ("Hello \033[7m world \033[0m !\n");
}
</syntaxhighlight>

=== En perl ===
On peut faire simplement :<syntaxhighlight lang="perl">
print "Hello \033[7m world \033[0m !\n";
</syntaxhighlight>[[Fichier:HelloWorld-ANSIPL.png|sans_cadre|147x147px]]

Mais on peut utiliser la module Term::ANSIColor

Il y a pas mal de façon de l'utiliser. La plus simple :
<syntaxhighlight lang="perl">
use Term::ANSIColor qw(:constants);

print "[".GREEN."PASS".RESET."]\n";
print "[".RED."FAIL".RESET."]\n";
</syntaxhighlight>
[[Fichier:PASSFAIL-ANSI-PL.png|sans_cadre|109x109px]]

Les constantes utilisables:

<syntaxhighlight lang="text">
CLEAR RESET BOLD DARK
FAINT ITALIC UNDERLINE UNDERSCORE
BLINK REVERSE CONCEALED

BLACK RED GREEN YELLOW
BLUE MAGENTA CYAN WHITE
BRIGHT_BLACK BRIGHT_RED BRIGHT_GREEN BRIGHT_YELLOW
BRIGHT_BLUE BRIGHT_MAGENTA BRIGHT_CYAN BRIGHT_WHITE

ON_BLACK ON_RED ON_GREEN ON_YELLOW
ON_BLUE ON_MAGENTA ON_CYAN ON_WHITE
ON_BRIGHT_BLACK ON_BRIGHT_RED ON_BRIGHT_GREEN ON_BRIGHT_YELLOW
ON_BRIGHT_BLUE ON_BRIGHT_MAGENTA ON_BRIGHT_CYAN ON_BRIGHT_WHITE
</syntaxhighlight>On se limite aux couleurs mais le module permet beaucoup de choses. Une description en français est disponible sur [https://perldoc.perl.org/Term::ANSIColor la page du module] lui même.

=== En java ===
<syntaxhighlight lang="java">
class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello \033[7m world \033[0m !");
}
}
</syntaxhighlight>Bon au retour à la ligne près (certaint l'incluent par défaut d'autres pas) c'est toujours la même chaine.

Un langage fait le malin pour pas faire comme les autres python

=== En python ===
Un simple <syntaxhighlight lang="python3">
print ("Hello \033[7m world \033[0m !")
</syntaxhighlight>Afficahit un truc moche :Il interprètait (un peu) les codes ANSI pour les remplacer par... des espaces. Etrange.
Pour utiliser les codes ANSI il fallait utiliser une autre syntaxe et, de plus, seul les changements de couleurs (3x pour la couleur du texte et 4x pour le fond) sont acceptés.<syntaxhighlight lang="python">
print (u"Hello \u001B[47m\u001B[30m World \u001B[0m !")
</syntaxhighlight>Nous donne "presque" ce que nous attendons.

[[Fichier:Python-Hello-almost-perfect.png|sans_cadre|505x505px]]

Le "World" est écrit en noir sur fond ''blanc sale''. en Gris quoi.

N'essayez pas de remplacer \001B[47m par \001B[107m ça ne marches pas.

Python a "sa syntaxe":<syntaxhighlight lang="python">
print (u"\nHello \u001B[47;1m\u001B[30m World \u001B[0m !")
</syntaxhighlight>Le ;1 après le \u001B[47 et le m dit que la couleur doit être "vive".

Un nombre limité de fonctions de gestion de curseur sont aussi gérées:
----

* '''Up''': <code>\u001b[{n}A</code> moves cursor up by <code>n</code>
* '''Down''': <code>\u001b[{n}B</code> moves cursor down by <code>n</code>
* '''Right''': <code>\u001b[{n}C</code> moves cursor right by <code>n</code>
* '''Left''': <code>\u001b[{n}D</code> moves cursor left by <code>n</code>

----

* '''Next Line''': <code>\u001b[{n}E</code> moves cursor to beginning of line <code>n</code> lines down
* '''Prev Line''': <code>\u001b[{n}F</code> moves cursor to beginning of line <code>n</code> lines down

----

* '''Set Column''': <code>\u001b[{n}G</code> moves cursor to column <code>n</code>
* '''Set Position''': <code>\u001b[{n};{m}H</code> moves cursor to row <code>n</code> column <code>m</code>

----

* '''Clear Screen''': <code>\u001b[{n}J</code> clears the screen
** <code>n=0</code> clears from cursor until end of screen,
** <code>n=1</code> clears from cursor to beginning of screen
** <code>n=2</code> clears entire screen
* '''Clear Line''': <code>\u001b[{n}K</code> clears the current line
** <code>n=0</code> clears from cursor to end of line
** <code>n=1</code> clears from cursor to start of line
** <code>n=2</code> clears entire line

----

* '''Save Position''': <code>\u001b[{s}</code> saves the current cursor position
* '''Save Position''': <code>\u001b[{u}</code> restores the cursor to the last saved position

Ces infos ont été trouvées sur : https://www.lihaoyi.com/post/BuildyourownCommandLinewithANSIescapecodes.html

En Python ce qui est compliqué devient très simple (numpy par exemple permet de gérer des matrices de réels en deux lignes de code) mais ce qui était simple (écrite en inversion vidéo) devient très compliqué!

== Avec vi (vim) ==
On peut vouloir ajouter des codes ANSI dans un fichier texte. Il faut cependant ajouter un ESC dans le flux de caractères. Pour cela on tape au clavier (en mode insertion):<syntaxhighlight lang="text">
<Ctrl>V + <Esc>
</syntaxhighlight>Dans vi son on tape:<syntaxhighlight lang="text">
^[[7mHello world!^[[0m
</syntaxhighlight>et bien le cat de ce fichier donnera:

[[Fichier:ANSI Hello.png|sans_cadre]]

Fichier:ANSI Hello.png

2026-09-10T11:41:57Z

Jpinon :

Hello World reverse

Camera PI

2026-09-04T22:25:58Z

Jpinon : Page créée avec « == Installation == L'utilisation d'une caméra est assez simple quand elle est branchée sur le port CSI. On la branche et tout est installé par défaut. On peut le vérifier avec<syntaxhighlight lang="bash"> dmesg | grep -i csi </syntaxhighlight>Moi j'ai les lignes:<syntaxhighlight lang="text"> /soc/csi@7e801000: Fixed dependency cycle(s) with /soc/i2c0mux/i2c@1/ov5647@36 </syntaxhighlight>J'ai bien une caméra sur le port CSI qui utilise le capteur ov5647 su... »

== Installation ==
L'utilisation d'une caméra est assez simple quand elle est branchée sur le port CSI.

On la branche et tout est installé par défaut.

On peut le vérifier avec<syntaxhighlight lang="bash">
dmesg | grep -i csi
</syntaxhighlight>Moi j'ai les lignes:<syntaxhighlight lang="text">
/soc/csi@7e801000: Fixed dependency cycle(s) with
/soc/i2c0mux/i2c@1/ov5647@36
</syntaxhighlight>J'ai bien une caméra sur le port CSI qui utilise le capteur ov5647 super connu.

== Utilisation ==
Pour l'utiliser c'est très simple :<syntaxhighlight lang="bash">
rpicam-hello -t 0
</syntaxhighlight>Les logs sur la console sont bavardes mais on a bien une fenêtre à l'écran qui affiche ce que voit la caméra.

<CTRL> + C pour sortir!

Avec <syntaxhighlight lang="bash">
rpicam-still -o test.jpg
</syntaxhighlight>Ca ouvre l'écran et on a 10 sec pour prendre la pause!

=== Utilisation a travers une connexion ssh ===
Si on veut que ce soit l'écran du PI qui affiche la prise de vue :<syntaxhighlight lang="bash">
export DISPLAY=:0
</syntaxhighlight>Sera nécessaire avant utilisation.

Ne tentez pas de vous connecter en ssh -X il n'arrivera pas à mètre en place DRI3 pour faire le Transfer (e tout ca moi sur WSL).

=== Streamer la video ===
On lance un streaming par :<syntaxhighlight lang="bash">
rpicam-vid --nopreview --listen -t 0 --inline -o tcp://0.0.0.0:8888
</syntaxhighlight>Et ailleurs dans le LAN on regarde avec VLC et l'URL : tcp/h264://192.168.8.132:8888

Ca marche. C'est super lent, un délai de 4 sec entre la captation et la restitution, mais ca marche.

Écran Adafruit 2.8 pouces TFT

2026-09-04T21:16:37Z

Jpinon : /* Activation du tactile résistif */

= Installation du PiTFT capacitif Adafruit sur Raspberry Pi =

== Présentation ==
Ce module PiTFT 2.8" d’Adafruit combine :
* Un écran TFT ILI9341 (320×240)
* Un contrôleur tactile capacitif FT5x06 ou FT6206
* Une interface GPIO directe pour Raspberry Pi B+, Pi 2, Pi 3

== Préparation du système ==
* OS recommandé : Raspberry Pi OS Lite ou Desktop
* Mise à jour :
<syntaxhighlight lang="bash">
sudo apt update && sudo apt full-upgrade
</syntaxhighlight>

== Activation de l'écran ==
Que se soit un écran résistif ou capacitif il faut choisir son orientation.

Il y a 4 orientations possibles: 0, 90, 180 et 270.

[[Fichier:Adafruit 2.8'' orientation 0.jpg|sans_cadre]]

[[Fichier:Adafruit 2.8'' 90.jpg|sans_cadre]]

Voici l'exemple 0 et 90 (RJ45 et USB a droite). L'un en mode graphique l'autre en mode texte.

Ma position favorite (si j'ose dire) c'est 270 :

[[Fichier:Ecran Adafruit 270.jpg|sans_cadre]]

On peut le poser sur son seul côté dénué de connecteurs.

=== Activation du tactile résistif ===
Ajouter dans <code>/boot/firmware/config.txt</code> :<syntaxhighlight lang="ini">
dtoverlay=pitft28-resistive,rotate=90,speed=64000000,fps=30,drm

</syntaxhighlight>Pour utiliser l'écran résistif il faudra le caligrer:<syntaxhighlight lang="bash">
DISPLAY=:0 xinput_calibrator
</syntaxhighlight>

=== Activation du tactile capacitif ===
Ajouter dans <code>/boot/firmware/config.txt</code> :
<syntaxhighlight lang="ini">dtoverlay=pitft28-capacitive,rotate=90,speed=64000000,fps=30,drm</syntaxhighlight>

Si besoin de GPIO personnalisés :
<syntaxhighlight lang="ini">dtoverlay=pitft28-capacitive,touch-reset=5,touch-int=17</syntaxhighlight>

== Ruse HDMI pour éviter la perte de framebuffer ==
Sans écran HDMI, le Pi peut désactiver <code>/dev/fb0</code>. Pour forcer sa création :
<syntaxhighlight lang="ini">
hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=87
hdmi_cvt=320 240 60 1 0 0 0
</syntaxhighlight>

== Tests post-installation ==
* Vérifier le périphérique tactile :
<syntaxhighlight lang="bash">
cat /proc/bus/input/devices
dmesg | grep ft5
sudo evtest /dev/input/eventX
</syntaxhighlight>

* Vérifier l’affichage :
<syntaxhighlight lang="bash">
sudo cat /dev/urandom > /dev/fb0
</syntaxhighlight>

== Reboot ==
<syntaxhighlight lang="bash">
sudo reboot
</syntaxhighlight>

== Dépannage ==
=== GPIO bloqués ===
Utiliser <code>gpiod</code> pour tester :
<syntaxhighlight lang="bash">
gpioset gpiochip0 5=1
gpioget gpiochip0 5
</syntaxhighlight>

=== FT5x06 actif mais dalle muette ===
* Vérifier la nappe tactile
* Tester le registre 0x02 via I²C :
<syntaxhighlight lang="bash">
sudo i2cget -y 1 0x38 0x02
</syntaxhighlight>

= Utilisation des 4 boutons physiques =
== Objectif ==
Utiliser les 4 boutons physiques à gauche de l’écran Adafruit PiTFT comme des touches clavier virtuelles : `1`, `2`, `3`, `4`.
== Matériel ==
* Raspberry Pi avec écran Adafruit PiTFT 2.8" capacitif
* Boutons connectés aux GPIO : 17, 22, 23, 27
== Méthode ==
Ajouter les lignes suivantes dans <code>/boot/firmware/config.txt</code> :

<syntaxhighlight lang="ini">
dtoverlay=gpio-key,gpio=17,keycode=2,label="BTN1" # KEY_1
dtoverlay=gpio-key,gpio=22,keycode=3,label="BTN2" # KEY_2
dtoverlay=gpio-key,gpio=23,keycode=4,label="BTN3" # KEY_3
dtoverlay=gpio-key,gpio=27,keycode=5,label="BTN4" # KEY_4
</syntaxhighlight>Explication Chaque ligne:
* Configure le GPIO en entrée avec pull-up
* Associe un <code>keycode</code> Linux standard
* Crée un périphérique <code>/dev/input/eventX</code> géré par le noyau
== Codes clavier utilisés ==
{| class="wikitable"
! Touche simulée !! Code Linux !! GPIO utilisé
|-
| 1 || 2 (KEY_1) || GPIO 17
|-
| 2 || 3 (KEY_2) || GPIO 22
|-
| 3 || 4 (KEY_3) || GPIO 23
|-
| 4 || 5 (KEY_4) || GPIO 27
|}
== Test ==
Lancer :
<syntaxhighlight lang="bash">
sudo evtest
</syntaxhighlight>

Appuyer sur les boutons : chaque pression génère un événement <code>EV_KEY</code> correspondant à la touche simulée.

== Utilisation dans un script ==
Exemple en shell :
<syntaxhighlight lang="bash">
read -n1 key
case "$key" in
1) echo "Bouton 1 pressé" ;;
2) echo "Bouton 2 pressé" ;;
3) echo "Bouton 3 pressé" ;;
4) echo "Bouton 4 pressé" ;;
esac
</syntaxhighlight>

= Cohabitation entre ecran LCD Adafruit et HDMI =
Une [[Cohabitation écran Adafruit PiTFT 2.8" et HDMI|page spécifique]] concerne ce point.

= Le rétro-éclairage =
Après pas mal de bidouillage (même mon ami copilot y a perdu son latin) j'ai trouvé le mécanisme. Je ne suis pas du tout certain que ca marche sur tous les modèles pareil!

Moi j'ai un écran Adafruit 2.8 pouces capacitif qui date de presque dix ans qui tourne sur un Raspberry PI2.

Dans ce cas c'est GPIO 18 qui gère le rétro-éclairage.

Les GPIO sont gérés par un gpiochip512.

Les sudo sont saoulant avec les redirections je conseille de faire les tests en tant que root. <code>sudo su -</code><syntaxhighlight lang="bash">
cat /sys/class/gpio/gpiochip512/label
</syntaxhighlight>Nous donne pinctrl-bcm2835 qui est le gestionaire de GPIO du SoC bcm2835 (c'est un PI2 donc ca devrait être un bcm2836 mais c'est le contrôleur de GPIO qui est resté basé sur la version précédente)

On regarde ensuite les caractéristiques :<syntaxhighlight lang="bash">
cat /sys/class/gpio/gpiochip512/base
cat /sys/class/gpio/gpiochip512/ngpio
</syntaxhighlight>Nous donne respectivement 512 et 54.

Donc, le gestionnaire de GPIO possède 54 lignes numérotées à partir de 512. La plage est alors de 512 à 566.

Notre GPIO 18 est dont repéré 512+18 = 530<syntaxhighlight lang="bash">
echo 530 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio530/direction
echo 1 > /sys/class/gpio/gpio530/value # Allumé
echo 0 > /sys/class/gpio/gpio530/value # Éteint

</syntaxhighlight>

Écran Adafruit 2.8 pouces TFT

2026-09-04T20:26:18Z

Jpinon : /* Activation de l'écran */

= Installation du PiTFT capacitif Adafruit sur Raspberry Pi =

== Présentation ==
Ce module PiTFT 2.8" d’Adafruit combine :
* Un écran TFT ILI9341 (320×240)
* Un contrôleur tactile capacitif FT5x06 ou FT6206
* Une interface GPIO directe pour Raspberry Pi B+, Pi 2, Pi 3

== Préparation du système ==
* OS recommandé : Raspberry Pi OS Lite ou Desktop
* Mise à jour :
<syntaxhighlight lang="bash">
sudo apt update && sudo apt full-upgrade
</syntaxhighlight>

== Activation de l'écran ==
Que se soit un écran résistif ou capacitif il faut choisir son orientation.

Il y a 4 orientations possibles: 0, 90, 180 et 270.

[[Fichier:Adafruit 2.8'' orientation 0.jpg|sans_cadre]]

[[Fichier:Adafruit 2.8'' 90.jpg|sans_cadre]]

Voici l'exemple 0 et 90 (RJ45 et USB a droite). L'un en mode graphique l'autre en mode texte.

Ma position favorite (si j'ose dire) c'est 270 :

[[Fichier:Ecran Adafruit 270.jpg|sans_cadre]]

On peut le poser sur son seul côté dénué de connecteurs.

=== Activation du tactile résistif ===
Ajouter dans <code>/boot/firmware/config.txt</code> :<syntaxhighlight lang="ini">
dtoverlay=pitft28-resistive,rotate=90,speed=64000000,fps=30,drm

</syntaxhighlight>

=== Activation du tactile capacitif ===
Ajouter dans <code>/boot/firmware/config.txt</code> :
<syntaxhighlight lang="ini">dtoverlay=pitft28-capacitive,rotate=90,speed=64000000,fps=30,drm</syntaxhighlight>

Si besoin de GPIO personnalisés :
<syntaxhighlight lang="ini">dtoverlay=pitft28-capacitive,touch-reset=5,touch-int=17</syntaxhighlight>

== Ruse HDMI pour éviter la perte de framebuffer ==
Sans écran HDMI, le Pi peut désactiver <code>/dev/fb0</code>. Pour forcer sa création :
<syntaxhighlight lang="ini">
hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=87
hdmi_cvt=320 240 60 1 0 0 0
</syntaxhighlight>

== Tests post-installation ==
* Vérifier le périphérique tactile :
<syntaxhighlight lang="bash">
cat /proc/bus/input/devices
dmesg | grep ft5
sudo evtest /dev/input/eventX
</syntaxhighlight>

* Vérifier l’affichage :
<syntaxhighlight lang="bash">
sudo cat /dev/urandom > /dev/fb0
</syntaxhighlight>

== Reboot ==
<syntaxhighlight lang="bash">
sudo reboot
</syntaxhighlight>

== Dépannage ==
=== GPIO bloqués ===
Utiliser <code>gpiod</code> pour tester :
<syntaxhighlight lang="bash">
gpioset gpiochip0 5=1
gpioget gpiochip0 5
</syntaxhighlight>

=== FT5x06 actif mais dalle muette ===
* Vérifier la nappe tactile
* Tester le registre 0x02 via I²C :
<syntaxhighlight lang="bash">
sudo i2cget -y 1 0x38 0x02
</syntaxhighlight>

= Utilisation des 4 boutons physiques =
== Objectif ==
Utiliser les 4 boutons physiques à gauche de l’écran Adafruit PiTFT comme des touches clavier virtuelles : `1`, `2`, `3`, `4`.
== Matériel ==
* Raspberry Pi avec écran Adafruit PiTFT 2.8" capacitif
* Boutons connectés aux GPIO : 17, 22, 23, 27
== Méthode ==
Ajouter les lignes suivantes dans <code>/boot/firmware/config.txt</code> :

<syntaxhighlight lang="ini">
dtoverlay=gpio-key,gpio=17,keycode=2,label="BTN1" # KEY_1
dtoverlay=gpio-key,gpio=22,keycode=3,label="BTN2" # KEY_2
dtoverlay=gpio-key,gpio=23,keycode=4,label="BTN3" # KEY_3
dtoverlay=gpio-key,gpio=27,keycode=5,label="BTN4" # KEY_4
</syntaxhighlight>Explication Chaque ligne:
* Configure le GPIO en entrée avec pull-up
* Associe un <code>keycode</code> Linux standard
* Crée un périphérique <code>/dev/input/eventX</code> géré par le noyau
== Codes clavier utilisés ==
{| class="wikitable"
! Touche simulée !! Code Linux !! GPIO utilisé
|-
| 1 || 2 (KEY_1) || GPIO 17
|-
| 2 || 3 (KEY_2) || GPIO 22
|-
| 3 || 4 (KEY_3) || GPIO 23
|-
| 4 || 5 (KEY_4) || GPIO 27
|}
== Test ==
Lancer :
<syntaxhighlight lang="bash">
sudo evtest
</syntaxhighlight>

Appuyer sur les boutons : chaque pression génère un événement <code>EV_KEY</code> correspondant à la touche simulée.

== Utilisation dans un script ==
Exemple en shell :
<syntaxhighlight lang="bash">
read -n1 key
case "$key" in
1) echo "Bouton 1 pressé" ;;
2) echo "Bouton 2 pressé" ;;
3) echo "Bouton 3 pressé" ;;
4) echo "Bouton 4 pressé" ;;
esac
</syntaxhighlight>

= Cohabitation entre ecran LCD Adafruit et HDMI =
Une [[Cohabitation écran Adafruit PiTFT 2.8" et HDMI|page spécifique]] concerne ce point.

= Le rétro-éclairage =
Après pas mal de bidouillage (même mon ami copilot y a perdu son latin) j'ai trouvé le mécanisme. Je ne suis pas du tout certain que ca marche sur tous les modèles pareil!

Moi j'ai un écran Adafruit 2.8 pouces capacitif qui date de presque dix ans qui tourne sur un Raspberry PI2.

Dans ce cas c'est GPIO 18 qui gère le rétro-éclairage.

Les GPIO sont gérés par un gpiochip512.

Les sudo sont saoulant avec les redirections je conseille de faire les tests en tant que root. <code>sudo su -</code><syntaxhighlight lang="bash">
cat /sys/class/gpio/gpiochip512/label
</syntaxhighlight>Nous donne pinctrl-bcm2835 qui est le gestionaire de GPIO du SoC bcm2835 (c'est un PI2 donc ca devrait être un bcm2836 mais c'est le contrôleur de GPIO qui est resté basé sur la version précédente)

On regarde ensuite les caractéristiques :<syntaxhighlight lang="bash">
cat /sys/class/gpio/gpiochip512/base
cat /sys/class/gpio/gpiochip512/ngpio
</syntaxhighlight>Nous donne respectivement 512 et 54.

Donc, le gestionnaire de GPIO possède 54 lignes numérotées à partir de 512. La plage est alors de 512 à 566.

Notre GPIO 18 est dont repéré 512+18 = 530<syntaxhighlight lang="bash">
echo 530 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio530/direction
echo 1 > /sys/class/gpio/gpio530/value # Allumé
echo 0 > /sys/class/gpio/gpio530/value # Éteint

</syntaxhighlight>

Fichier:Ecran Adafruit 270.jpg

2026-09-04T20:25:22Z

Jpinon :

A 270 degres

Fichier:Adafruit 2.8'' 90.jpg

2026-09-04T20:20:06Z

Jpinon :

Ecran a 90 degré mode texte

Fichier:Adafruit 90.jpg

2026-09-04T20:18:55Z

Jpinon :

a 90 degres en mode texte

Fichier:Adafruit 2.8'' orientation 0.jpg

2026-09-04T20:14:41Z

Jpinon :

Ecran Adafruit 2,8 pouces configuré avec l'orientation par défaut.

Écran Adafruit 2.8 pouces TFT

2026-09-04T19:53:55Z

Jpinon : /* Activation du tactile capacitif */

= Installation du PiTFT capacitif Adafruit sur Raspberry Pi =

== Présentation ==
Ce module PiTFT 2.8" d’Adafruit combine :
* Un écran TFT ILI9341 (320×240)
* Un contrôleur tactile capacitif FT5x06 ou FT6206
* Une interface GPIO directe pour Raspberry Pi B+, Pi 2, Pi 3

== Préparation du système ==
* OS recommandé : Raspberry Pi OS Lite ou Desktop
* Mise à jour :
<syntaxhighlight lang="bash">
sudo apt update && sudo apt full-upgrade
</syntaxhighlight>

== Activation de l'écran ==

=== Activation du tactile résistif ===
Ajouter dans <code>/boot/firmware/config.txt</code> :<syntaxhighlight lang="ini">
dtoverlay=pitft28-resistive,rotate=90,speed=64000000,fps=30,drm

</syntaxhighlight>

=== Activation du tactile capacitif ===
Ajouter dans <code>/boot/firmware/config.txt</code> :
<syntaxhighlight lang="ini">dtoverlay=pitft28-capacitive,rotate=90,speed=64000000,fps=30,drm</syntaxhighlight>

Si besoin de GPIO personnalisés :
<syntaxhighlight lang="ini">dtoverlay=pitft28-capacitive,touch-reset=5,touch-int=17</syntaxhighlight>

== Ruse HDMI pour éviter la perte de framebuffer ==
Sans écran HDMI, le Pi peut désactiver <code>/dev/fb0</code>. Pour forcer sa création :
<syntaxhighlight lang="ini">
hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=87
hdmi_cvt=320 240 60 1 0 0 0
</syntaxhighlight>

== Tests post-installation ==
* Vérifier le périphérique tactile :
<syntaxhighlight lang="bash">
cat /proc/bus/input/devices
dmesg | grep ft5
sudo evtest /dev/input/eventX
</syntaxhighlight>

* Vérifier l’affichage :
<syntaxhighlight lang="bash">
sudo cat /dev/urandom > /dev/fb0
</syntaxhighlight>

== Reboot ==
<syntaxhighlight lang="bash">
sudo reboot
</syntaxhighlight>

== Dépannage ==
=== GPIO bloqués ===
Utiliser <code>gpiod</code> pour tester :
<syntaxhighlight lang="bash">
gpioset gpiochip0 5=1
gpioget gpiochip0 5
</syntaxhighlight>

=== FT5x06 actif mais dalle muette ===
* Vérifier la nappe tactile
* Tester le registre 0x02 via I²C :
<syntaxhighlight lang="bash">
sudo i2cget -y 1 0x38 0x02
</syntaxhighlight>

= Utilisation des 4 boutons physiques =
== Objectif ==
Utiliser les 4 boutons physiques à gauche de l’écran Adafruit PiTFT comme des touches clavier virtuelles : `1`, `2`, `3`, `4`.
== Matériel ==
* Raspberry Pi avec écran Adafruit PiTFT 2.8" capacitif
* Boutons connectés aux GPIO : 17, 22, 23, 27
== Méthode ==
Ajouter les lignes suivantes dans <code>/boot/firmware/config.txt</code> :

<syntaxhighlight lang="ini">
dtoverlay=gpio-key,gpio=17,keycode=2,label="BTN1" # KEY_1
dtoverlay=gpio-key,gpio=22,keycode=3,label="BTN2" # KEY_2
dtoverlay=gpio-key,gpio=23,keycode=4,label="BTN3" # KEY_3
dtoverlay=gpio-key,gpio=27,keycode=5,label="BTN4" # KEY_4
</syntaxhighlight>Explication Chaque ligne:
* Configure le GPIO en entrée avec pull-up
* Associe un <code>keycode</code> Linux standard
* Crée un périphérique <code>/dev/input/eventX</code> géré par le noyau
== Codes clavier utilisés ==
{| class="wikitable"
! Touche simulée !! Code Linux !! GPIO utilisé
|-
| 1 || 2 (KEY_1) || GPIO 17
|-
| 2 || 3 (KEY_2) || GPIO 22
|-
| 3 || 4 (KEY_3) || GPIO 23
|-
| 4 || 5 (KEY_4) || GPIO 27
|}
== Test ==
Lancer :
<syntaxhighlight lang="bash">
sudo evtest
</syntaxhighlight>

Appuyer sur les boutons : chaque pression génère un événement <code>EV_KEY</code> correspondant à la touche simulée.

== Utilisation dans un script ==
Exemple en shell :
<syntaxhighlight lang="bash">
read -n1 key
case "$key" in
1) echo "Bouton 1 pressé" ;;
2) echo "Bouton 2 pressé" ;;
3) echo "Bouton 3 pressé" ;;
4) echo "Bouton 4 pressé" ;;
esac
</syntaxhighlight>

= Cohabitation entre ecran LCD Adafruit et HDMI =
Une [[Cohabitation écran Adafruit PiTFT 2.8" et HDMI|page spécifique]] concerne ce point.

= Le rétro-éclairage =
Après pas mal de bidouillage (même mon ami copilot y a perdu son latin) j'ai trouvé le mécanisme. Je ne suis pas du tout certain que ca marche sur tous les modèles pareil!

Moi j'ai un écran Adafruit 2.8 pouces capacitif qui date de presque dix ans qui tourne sur un Raspberry PI2.

Dans ce cas c'est GPIO 18 qui gère le rétro-éclairage.

Les GPIO sont gérés par un gpiochip512.

Les sudo sont saoulant avec les redirections je conseille de faire les tests en tant que root. <code>sudo su -</code><syntaxhighlight lang="bash">
cat /sys/class/gpio/gpiochip512/label
</syntaxhighlight>Nous donne pinctrl-bcm2835 qui est le gestionaire de GPIO du SoC bcm2835 (c'est un PI2 donc ca devrait être un bcm2836 mais c'est le contrôleur de GPIO qui est resté basé sur la version précédente)

On regarde ensuite les caractéristiques :<syntaxhighlight lang="bash">
cat /sys/class/gpio/gpiochip512/base
cat /sys/class/gpio/gpiochip512/ngpio
</syntaxhighlight>Nous donne respectivement 512 et 54.

Donc, le gestionnaire de GPIO possède 54 lignes numérotées à partir de 512. La plage est alors de 512 à 566.

Notre GPIO 18 est dont repéré 512+18 = 530<syntaxhighlight lang="bash">
echo 530 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio530/direction
echo 1 > /sys/class/gpio/gpio530/value # Allumé
echo 0 > /sys/class/gpio/gpio530/value # Éteint

</syntaxhighlight>

Etc/hosts debian

2026-08-24T21:50:59Z

Jpinon :

== Le problème ==
A partie de la version 11 (Buster) les distributions Debian (et les Ubuntu et autres qui en découlent) gèrent le <code>/etc/hosts</code> d'une façon différente d'avant.

Un truc qui marchait depuis plus de 50 ans :

Ajouter un nouveau hôte distant avec un :<syntaxhighlight lang="bash">
sudo vi /etc/hosts
</syntaxhighlight>On croit que ca marche mais au prochain reboot... la modification est perdue.

Pourquoi changer un truc truc qui marche depuis 50 ans... je ne sais pas. Ils ont surement de très très bonnes raisons mais ils nous saoulent!

Bon si on regarde le contenu du fichier:<syntaxhighlight lang="bash"># Your system has configured 'manage_etc_hosts' as True.
# As a result, if you wish for changes to this file to persist
# then you will need to either
# a.) make changes to the master file in /etc/cloud/templates/hosts.debian.tmpl
# b.) change or remove the value of 'manage_etc_hosts' in
# /etc/cloud/cloud.cfg or cloud-config from user-data
#
127.0.1.1 hote.domaine.fr hote
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters</syntaxhighlight>C<nowiki>'est clairement expliqué suffit de lire le commentaire... ce que je n'avais pas fait sur mon Raspberry PI avec un micro écran de 5''</nowiki>. Ok ma faute mais quand même.

Il y a donc deux solutions:

== Les solutions ==

=== Le fichier hosts.debian.tmpl ===
Je trouve que c'est la solution la plus simple.

Avant on faisait :<syntaxhighlight lang="bash">
sudo vi /etc/hosts
</syntaxhighlight>Maintenant on fait :<syntaxhighlight lang="bash">
sudo vi /etc/cloud/templates/hosts.debian.tmpl
</syntaxhighlight>Ils se sont fait plaisir sur le PATH!

Le template ressemble à ça:<syntaxhighlight lang="bash">## template:jinja
{#
This file (/etc/cloud/templates/hosts.debian.tmpl) is only utilized
if enabled in cloud-config. Specifically, in order to enable it
you need to add the following to config:
manage_etc_hosts: True
-#}
# Your system has configured 'manage_etc_hosts' as True.
# As a result, if you wish for changes to this file to persist
# then you will need to either
# a.) make changes to the master file in /etc/cloud/templates/hosts.debian.tmpl
# b.) change or remove the value of 'manage_etc_hosts' in
# /etc/cloud/cloud.cfg or cloud-config from user-data
#
{# The value '{{hostname}}' will be replaced with the local-hostname -#}
127.0.1.1 {{fqdn}} {{hostname}}
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters</syntaxhighlight>Si j'ai bien tout compris c'est pour que, après le DHCP le nom de domaine peut changer donc <code><nowiki>{{fqdn}}</nowiki></code> a une origine externe. De même si on change le hostname de la machine pas besoin de changer le <code>/etc/hosts</code>.

Bon pourquoi pas....

Il faut donc ajouter ses "hôtes" dans le fichier. Moi je fais ca après le <code>127.0.0.1 localhost</code> mais finalement on fait ça ou on veut.

=== Le fichier /etc/cloud/cloud.cfg ===

Dans ce fichier il y a une section (il est long je donne pas tout):<syntaxhighlight lang="text">cloud_init_modules:
- seed_random
- bootcmd
- write_files
- disk_setup
- mounts
- set_hostname
- update_hostname
- update_etc_hosts
- ca_certs
- rsyslog
- users_groups
- ssh
- set_passwords</syntaxhighlight>Il suffit ce commenter le <code>- update_etc_hosts</code>.

Personnellement je préfère la solution avec le template. Tant qu'à changer quelque chose utilisons la nouvelle methode.

Etc/hosts debian

2026-08-24T21:49:49Z

Jpinon :

A partie de la version 11 (Buster) les distributions Debian (et les Ubuntu et autres qui en découlent) gèrent le <code>/etc/hosts</code> d'une façon différente d'avant.

Un truc qui marchait depuis plus de 50 ans :

Ajouter un nouveau hôte distant avec un :<syntaxhighlight lang="bash">
sudo vi /etc/hosts
</syntaxhighlight>On croit que ca marche mais au prochain reboot... la modification est perdue.

Pourquoi changer un truc truc qui marche depuis 50 ans... je ne sais pas. Ils ont surement de très très bonnes raisons mais ils nous saoulent!

Bon si on regarde le contenu du fichier:<syntaxhighlight lang="bash"># Your system has configured 'manage_etc_hosts' as True.
# As a result, if you wish for changes to this file to persist
# then you will need to either
# a.) make changes to the master file in /etc/cloud/templates/hosts.debian.tmpl
# b.) change or remove the value of 'manage_etc_hosts' in
# /etc/cloud/cloud.cfg or cloud-config from user-data
#
127.0.1.1 hote.domaine.fr hote
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters</syntaxhighlight>C<nowiki>'est clairement expliqué suffit de lire le commentaire... ce que je n'avais pas fait sur mon Raspberry PI avec un micro écran de 5''</nowiki>. Ok ma faute mais quand même.

Il y a donc deux solutions:

== Le fichier hosts.debian.tmpl ==
Je trouve que c'est la solution la plus simple.

Avant on faisait :<syntaxhighlight lang="bash">
sudo vi /etc/hosts
</syntaxhighlight>Maintenant on fait :<syntaxhighlight lang="bash">
sudo vi /etc/cloud/templates/hosts.debian.tmpl
</syntaxhighlight>Ils se sont fait plaisir sur le PATH!

Le template ressemble à ça:<syntaxhighlight lang="bash">## template:jinja
{#
This file (/etc/cloud/templates/hosts.debian.tmpl) is only utilized
if enabled in cloud-config. Specifically, in order to enable it
you need to add the following to config:
manage_etc_hosts: True
-#}
# Your system has configured 'manage_etc_hosts' as True.
# As a result, if you wish for changes to this file to persist
# then you will need to either
# a.) make changes to the master file in /etc/cloud/templates/hosts.debian.tmpl
# b.) change or remove the value of 'manage_etc_hosts' in
# /etc/cloud/cloud.cfg or cloud-config from user-data
#
{# The value '{{hostname}}' will be replaced with the local-hostname -#}
127.0.1.1 {{fqdn}} {{hostname}}
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters</syntaxhighlight>Si j'ai bien tout compris c'est pour que, après le DHCP le nom de domaine peut changer donc <code><nowiki>{{fqdn}}</nowiki></code> a une origine externe. De même si on change le hostname de la machine pas besoin de changer le <code>/etc/hosts</code>.

Bon pourquoi pas....

Il faut donc ajouter ses "hôtes" dans le fichier. Moi je fais ca après le <code>127.0.0.1 localhost</code> mais finalement on fait ça ou on veut.

== Solution /etc/cloud/cloud.cfg ==
Dans ce fichier il y a une section (il est long je donne pas tout):<syntaxhighlight lang="text">cloud_init_modules:
- seed_random
- bootcmd
- write_files
- disk_setup
- mounts
- set_hostname
- update_hostname
- update_etc_hosts
- ca_certs
- rsyslog
- users_groups
- ssh
- set_passwords</syntaxhighlight>Il suffit ce commenter le <code>- update_etc_hosts</code>.

Personnellement je préfère la solution avec le template. Tant qu'à changer quelque chose utilisons la nouvelle methode.

Etc/hosts debian

2026-08-24T21:48:58Z

Jpinon : Page créée avec « A partie de la version 11 (Buster) les distributions Debian (et les Ubuntu et autres qui en découlent) gèrent le <code>/etc/hosts</code> d'une façon différente d'avant. Un truc qui marchait depuis plus de 50 ans : Ajouter un nouveau hôte distant avec un :<syntaxhighlight lang="bash"> sudo vi /etc/hosts </syntaxhighlight>On croit que ca marche mais au prochain reboot... la modification est perdue. Pourquoi changer un truc truc qui marche depuis 50 ans...... »

A partie de la version 11 (Buster) les distributions Debian (et les Ubuntu et autres qui en découlent) gèrent le <code>/etc/hosts</code> d'une façon différente d'avant.

Un truc qui marchait depuis plus de 50 ans :

Ajouter un nouveau hôte distant avec un :<syntaxhighlight lang="bash">
sudo vi /etc/hosts
</syntaxhighlight>On croit que ca marche mais au prochain reboot... la modification est perdue.

Pourquoi changer un truc truc qui marche depuis 50 ans... je ne sais pas. Ils ont surement de très très bonnes raisons mais ils nous saoulent!

Bon si on regarde le contenu du fichier:<syntaxhighlight lang="bash"># Your system has configured 'manage_etc_hosts' as True.
# As a result, if you wish for changes to this file to persist
# then you will need to either
# a.) make changes to the master file in /etc/cloud/templates/hosts.debian.tmpl
# b.) change or remove the value of 'manage_etc_hosts' in
# /etc/cloud/cloud.cfg or cloud-config from user-data
#
127.0.1.1 labo labo
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters</syntaxhighlight>C<nowiki>'est clairement expliqué suffit de lire le commentaire... ce que je n'avais pas fait sur mon Raspberry PI avec un micro écran de 5''</nowiki>. Ok ma faute mais quand même.

Il y a donc deux solutions:

== Le fichier hosts.debian.tmpl ==
Je trouve que c'est la solution la plus simple.

Avant on faisait :<syntaxhighlight lang="bash">
sudo vi /etc/hosts
</syntaxhighlight>Maintenant on fait :<syntaxhighlight lang="bash">
sudo vi /etc/cloud/templates/hosts.debian.tmpl
</syntaxhighlight>Ils se sont fait plaisir sur le PATH!

Le template ressemble à ça:<syntaxhighlight lang="bash">## template:jinja
{#
This file (/etc/cloud/templates/hosts.debian.tmpl) is only utilized
if enabled in cloud-config. Specifically, in order to enable it
you need to add the following to config:
manage_etc_hosts: True
-#}
# Your system has configured 'manage_etc_hosts' as True.
# As a result, if you wish for changes to this file to persist
# then you will need to either
# a.) make changes to the master file in /etc/cloud/templates/hosts.debian.tmpl
# b.) change or remove the value of 'manage_etc_hosts' in
# /etc/cloud/cloud.cfg or cloud-config from user-data
#
{# The value '{{hostname}}' will be replaced with the local-hostname -#}
127.0.1.1 {{fqdn}} {{hostname}}
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters</syntaxhighlight>Si j'ai bien tout compris c'est pour que, après le DHCP le nom de domaine peut changer donc <code><nowiki>{{fqdn}}</nowiki></code> a une origine externe. De même si on change le hostname de la machine pas besoin de changer le <code>/etc/hosts</code>.

Bon pourquoi pas....

Il faut donc ajouter ses "hôtes" dans le fichier. Moi je fais ca après le <code>127.0.0.1 localhost</code> mais finalement on fait ça ou on veut.

== Solution /etc/cloud/cloud.cfg ==
Dans ce fichier il y a une section (il est long je donne pas tout):<syntaxhighlight lang="text">cloud_init_modules:
- seed_random
- bootcmd
- write_files
- disk_setup
- mounts
- set_hostname
- update_hostname
- update_etc_hosts
- ca_certs
- rsyslog
- users_groups
- ssh
- set_passwords</syntaxhighlight>Il suffit ce commenter le <code>- update_etc_hosts</code>.

Personnellement je préfère la solution avec le template. Tant qu'à changer quelque chose utilisons la nouvelle methode.

Accueil

2026-08-24T21:27:52Z

Jpinon :

Bienvenu sur ma nouvelle "Knowledge base" [[Spécial:Version|Version]] autohébergée.

Une page temporaire pour la mise à jour de ce wiki-ci: [[MAJ WIKI]] (a faire)
{| class="wikitable"
! rowspan="5" |Développement
| colspan="2" |[[Fichier:Logo C++.png|sans_cadre|61x61px]] C/C++ : C'est[[Fichier:Le.png|sans_cadre|44x44px]] langage de programmation.
|Les [[sockets C]]
Gérer l'écran "à la vi" avec [[Curses en C|curses]]

Gérer le [[Temps à la milliseconde en C|temps à la milliseconde]].
|-
| colspan="2" |[[Fichier:Perl logo.png|sans_cadre|48x48px]]Perl : Le meilleur langage de script.
|Quelques [[Quelques modules Perl|modules Perl]] utiles.
Petits [[hacks en perl]].
|-
| colspan="2" |[[Fichier:Python Logo.png|alt=Python|sans_cadre|74x74px]]Python : Pas mon préféré mais il est tellement utilisé!
|Syntaxe [[Les bases de Python|de base]],
Gestion des [[Exceptions en Python|exceptions]].

Python et ses [[Environnements virtuels Python|environnements virtuels]].

Les [[Modules et outils de développement Python|modules et les outils de développement]].

[[Gestion des documents PDF en Python|Gestion des documents PDF]].

[[Petits exemples de code Python|Petits exemples de code]].
|-
|Outils
|[[Fichier:Git logo.png|sans_cadre|67x67px]]Git
|[[GIT Utilisation simple|Utilisation simple]]
[[GIT-HUB]]
|-
|Shell
|sh/bash
[[Fichier:Bash.png|sans_cadre]]
|Syntaxe du [[If en bash|if]], [[For in bash|for]] et [[While in bash|while]].
Les [[Redirections bash|redirections]].

Les [[Alias en bash|alias]].

Traiter des [[CSV bash|fichiers csv]]
Traitement de phrases [[Encodage d'objets complexes#Usage en shell (commande jq)|JSON avec jq]]

[[Bash random|Générer de hasard]].
|-
! rowspan="8" |Système
| rowspan="2" |Global
|[[Encodage]] de caractères
|Le [[code morse]], le [[code baudot]], les codes [[ASCII]], les séquences [[ANSI]] le code [[Code Gray|Gray]] et un OVNI, le code [[Extended Binary Coded Decimal Interchange Code|EBCEDIC]]
les code [[UNICODE]].
|-
|Encodage d'objets
|Les [[entiers]]
le [[temps]]

Les [[nombres flottants]]

[[Encodage d'objets complexes|Les objets complexes]]

Encodage de binaire en [[base64]].
|-
| rowspan="3" |Linux [[Fichier:Linux-logo.png|sans_cadre|93x93px]]
|Général
|[[Généralités Linux|Généralités]] quel que soient les distributions de linux (ou UNIX).
Lancer un [[deamon avec systemd]].

Configurer une client [[Connexion SSH|ssh]].

Installer [[web-ssh]]
|-
|Debian (Ubuntu...)
[[Fichier:Debian.png|sans_cadre|80x80px]]
|[[Gestion des services Debian/Ubuntu|Gestion des services]]

[[Nettoyage APT]]

Informations sur une [[Info distribution DEBIAN|distribution]]

[[Etc/hosts debian|Gérer /etc/hosts]] sur les versions récentes (>11 "buster")
|-
|[[Fichier:Windows Subsystem for Linux logo.png|gauche|sans_cadre|64x64px]]WSL
|Utiliser et personnaliser [[WSL /etc/hosts|/etc/hosts]]
[[Relancer WSL]]

[[Monter un disque externe dans wsl]]

[[Utiliser un port USB dans WSL]]
|-
|Windows [[Fichier:Microsoft Windows Logo.png|sans_cadre|96x96px]]
|..., 10, 11
|[[Wireshark]] (images manquantes)
CYGWIN

[[MINGW32]]

[[Scoop]]
|-
|[[Open WRT]]
[[Fichier:Open WRT LOGO.png|sans_cadre|135x135px]]
|Global
[[GL Inet]]

[[Fichier:Gl-inet-router.png|sans_cadre|147x147px]]
|[[GL Inet Reset|Reset]] sortie d'usine.
Réglage du serveur [[Open WRT DHCP|DHCP]]

Ajouter un [[OpenWRTpackages|package]].

[[Open WRT Commandes de base pour le réseau|Commandes de base pour le réseau]].

[[tcpdump]]

Comment [[configurer un routeur pour activer le ssh depuis le côté WAN.]]

Comment [[configurer un routeur pour activer le WEB depuis le coté WAN]]

Gérer des ampoules [[Wiz et OpenWRT|Phillips Wiz]].

Installer un outil de [[Test de la bande passante Open WRT|test de la bande passante]] de la patte "wan"
|-
|Auto hébergement
[[Fichier:AnarchySymbol.png|sans_cadre|107x107px]]
|[[Fichier:Raspberry.png|sans_cadre|40x40px]] [[Raspberry PI]]
|L'auto hébergement est assez facile à réaliser chez sois. Une solution est d'utiliser un ou plusieurs raspberry PI.
[[Auto Hebergement|La base]] explique l'installation de base d'un PI comme serveur solitaire.

En revanche on donne ci-dessous un exemple d'architecture complète avec un cluster de 5 Raspberry PI :

# [[Infrastructure basée PI|Architecture]]
# <code>front-router</code>[[Le routeur en tête réseau PI|Le routeur en tête]]
# <code>main-host</code> un [[Node-red dans le LAN|serveur IoT avec note-red]].
#<code>git</code>[[PI GitLab|Un serveur Git]]
#<code>database</code>[[PI MariaDB|Un serveur de base de données]]
#<code>mediawiki</code> [[PI MediaWiki|Un serveur mediawiki]]
|-
! rowspan="3" |APIs
| rowspan="3" |Géolocalisation et cartographie
|IP API
|[[Abstract API]] Donne une localisation a partir d'une IP
[[IPinfo]] Une autre bibliotheque de localisation d'IP
|-
|Ephemérides
|[[Sunset and sunrise times API]] va nous dire quand le soleil se lève quand il se couche, la lune…
|-
|Trafic Aérien
|[[FlightRadar24]]
|-
! rowspan="6" |Logiciels
| rowspan="4" |Middleware
|Bases de données relationelles
|Le langage [[SQL]]
Les "minimales": [[MariaDB]]

Les encore plus minimales: [[SQLite]]

Les maximales: [[Oracle]], [[PostgeSQL]]
|-
|Bases de données NoSQL
|[[mongodb]]
|-
|Messages
|[[MQTT]]
|-
|Serveur applicatifs/web
|[[Apache]]

[[Weblogic]]

[[RPi-NodeRed|Nodered]] (exemple avec Raspberry PI) et certaines [[Applications node-red|applications]].
|-
| rowspan="2" |Bureautique
[[Fichier:Bureautique.png|sans_cadre|166x166px]]
|Excel
|[[Gestion des dates sous Excel|Gestion des dates]]<nowiki/>
[[EXCEL Gestion des chaines de caractères|Gest]][[EXCEL Gestion des chaines de caractères|io]][[EXCEL Gestion des chaines de caractères|n d]][[EXCEL Gestion des chaines de caractères|es cha]][[EXCEL Gestion des chaines de caractères|în]][[EXCEL Gestion des chaines de caractères|es de c]][[EXCEL Gestion des chaines de caractères|ar]][[EXCEL Gestion des chaines de caractères|actère]][[EXCEL Gestion des chaines de caractères|s]]

[[Identifier si la clé d'une ligne est présente dans un autre tableau]].
|-
|Outlook
|[[Outlook - Gestion des archives|Gestion des archives]]
|-
! rowspan="4" |Sécurite
|Chiffrement / déchiffrement
[[Fichier:Aliceetbob.png|sans_cadre]]
|OpenSSL
|[[Les bases de Open SSL|La base]]
[[OpenSSL et AES]] (symetrique)

[[OpenSSL_et_RSA]] (asymetrique)

Avec [[SMIME et Certificats x509|x509 et SMIME]] on marie les deux

Comment [[OpenSSL extraire un certificat|extraire un certificat]] d'un serveur en production.

PGP et [[GPG]] (chiffrer de documents)

Générer un [[mode de passe sécurisé]]

Les autres commandes [[openssl]].
|-
| rowspan="3" |Certificats
[[Fichier:Certif.png|sans_cadre|60x60px]]
|Generalités
|[[Les certificats X.509|Un certificat c'est quoi?]]
|-
|PKI
|[[PKI familiale|Faire une PKI "familiale"]]
|-
|https
|[[Certificats Serveur https|Certificats Serveur]]
[[Certificats Client https|Certificats Client]]

[[Let's encrypt]]
|-
! rowspan="10" |Embarqué
| rowspan="3" |Microcontroleurs
[[Fichier:Esp32.png|sans_cadre|93x93px]]
|[[Fichier:Arduino Logo.png|sans_cadre|40x40px]][[Arduino]]
|
|-
|[[ESP8266]]
|Le module [[SON/OFF Smart Switch|Smart Switch]] de SONOFF
|-
|[[Fichier:Espessif logo.png|gauche|sans_cadre|40x40px]][[ESP32]]
|Environnement de dev [[ESP-IDF]], Utiliser [[mkspiffs]].
La carte "breakout" [[ESP32_DEVKITV1]]
La carte "AZ delivery" [[ESP32_DEVKITV2]]

Faire des [[ESP32 Requetês HTTPs|requetês HTTPs]]

[[ESP32 Firmware Update|Firmware Update]]

[[ESP32 Matrice de led|Exemple d'utilisation de matrice de LED]] (circuit MAX 72xx)

Programmation module [[ESP32C3 avec écran spotear]].
|-
!Fusion
|Dev ESP 32 sur Raspberry PI
|Ici un article qui touche aux deux sujets. [[Poste de DEV ESP32 sur PI|Comment programmes les microcontrôleurs ESP32 à partir d'un raspberry PI]].
|-
| rowspan="3" |SBC (single board computers)
[[Fichier:Sbc.png|sans_cadre|147x147px]]
| rowspan="2" |[[Fichier:Logo PI.png|sans_cadre|36x36px]][[Raspberry PI]]
|[[Les modèles de Raspberry PI]]
La configuration réseau [[DHCP ou IP fixe]]

Le truc différentiant pour un raspberry PI : le [[GPIO-PI|GPIO]].

Ecran [[Écran Adafruit 2.8 pouces TFT|Adafruit 2.8']]'et [[Cohabitation écran Adafruit PiTFT 2.8" et HDMI|Cohabitation des écrans]].

Utiliser le [[frame-buffer]]

[[Wayland X11 et ssh]].

[[Demarrer PI4 en USB|Gérer un PI4 dont le lecteur de carte SD est HS]].

Utiliser la [[camera PI]]

Créer un [[Nouveau Menu Raspberry PI|nouveau sous menu dans le "main menu"]] du bureau.
|-
|Installer :
[[RPi-NodeRed|NodeRed]], [[Mosquitto]], [[MariaDB sur Raspberry PI|MariaDB]]

Le service graphique de gestion des mises à jour [[PackageKit]]
|-
|[[Fichier:Bpi.png|sans_cadre|48x48px]]Banana PI
|
|-
| rowspan="3" |Objets connectés
|[[Fichier:PHILLIPS HUE LOGO.png|sans_cadre|87x87px]]
|Description [[PHILLIPS HUE|API]] de base
Le site de Phillips : https://developers.meethue.com/develop/hue-api-v2/getting-started/
|-
|[[Fichier:X-sense logo.png|sans_cadre|52x52px]]x-sense
|[[X-sense|Description générale]]
Utilisation avec le module [[python-xsense]]
|-
|[[Fichier:Wiz.png|sans_cadre|103x103px]]Phillips Wiz
|Les limites de ces [[Securite PHILLIPS WIZ|ampoules au niveau sécurité]].
Utilisation avec un [[Wiz et OpenWRT|routeur OpenWrt]]
|-
! rowspan="10" |Electronique
| rowspan="2" |[[Fichier:Compsantselec.png|sans_cadre|91x91px]]Composants
|Composants actifs
|[[Le transistor bipolaire]]
|-
|Les batteries
|Généralités sur [[Les batteries]]
|-
|Circuits
|Filtres
|Filtre de rejection : https://poujouly.net/2015/10/25/filtre-notch-50hz/ (oui un lien externe pour le moment)
|-
| rowspan="5" |Le labo
|Le protocoles
|[[UART/RS323]]

[[SCPI uart]]
|-
| rowspan="4" |Les outils de mesures connectables
[[Fichier:Laboelec.png|sans_cadre|207x207px]]
|[[Multimètre]] modèle :

* [[Multicomp PRO MP730027]]
|-
|[[Générateur de fonctions arbitraire]] modèles :

* [[GwINSTEK AFG-2012]]
* [[Multicomp MP75511]]
* [[FeelTech FY6600]]
|-
|[[Osciloscope]]
|-
|[[Alimantation]]

[[Alimentation USB C]]
|-
| rowspan="2" |Conception
|[[Fichier:Autodesk Eagle logo.png|sans_cadre|123x123px]]
|Logiciel de conception de circuits et de modélisation de circuit imprimés.
[[EAGLE - Plans de masse|Plans de masse]]

[[Les unités dans EAGLE]]
|-
|LTspice
|Logiciel de simulation électronique
[[LTspice fichier de simulation|Utiliser un signal numérisé en entré d'une simulation]].
|-
! rowspan="7" |CAO FAO
| rowspan="2" |[[Fichier:Mecanique.png|sans_cadre|78x78px]]Mécanique
|Visserie
|[[Fichier:Logo-iso.png|sans_cadre|105x105px]][[Dimensions visserie ISO]]
|-
|Usinage
|Dimensions des [[fraises en unités Imériales/US]]
|-
|Fabrication additive
|Imprimantes 3D FDM
|[[Fichier:Ultimaker logo.png|sans_cadre|37x37px]] [[Ultimaker 2]]
|-
|CNC
|Fraiseuses
|La base… la [[CNC 3018|3018]].
Faire des perçages avec un [[CNC Percages gcode|programme python]].

Graver des [[PCB avec CNC|PCB]]

[[Changer la broche CNC3018|Changer la broche]]
|-
|Découpeuse (Vinyle ou autre)
|Silhouette
|[[SILHOUETTE Paramètres de base|Paramètres de base]]
|-
|Logiciels de CAO
|[[Fichier:Freecad logo.png|alt=FREE CAD|sans_cadre|47x47px]]FreeCad
|[[FreeCad]]
|-
|Outillage
|Metrologie
|[[Comparateur Numérique]]
|-
! rowspan="5" |Projets complets
| rowspan="4" |Création/Configuration de serveur
| rowspan="4" |Exemple chez GANDI
|[[Serveur mediawiki basé docker]]
|-
|[[Serveur nodered basé docker]]
|-
|[[Serveur Owncloud]]
|-
|[[Serveur DNS GANDI|Serveur DNS]]
|-
|Objets connectés
|[[Fichier:Esp32.png|sans_cadre|29x29px]]ESP32
|[[ESP32 Horloge à LED|Une Horloge à LED]]
|-
! rowspan="3" |Photos
|Matériel
|D90
[[Fichier:D90.png|sans_cadre|58x58px]]
|[[Connectique D90|Connectique]]
|-
|[[Fichier:Theorie.png|sans_cadre|67x67px]]Théorie
|
|Les [[bases en optique pour la photo]]
|-
|Logiciel
|
|
|}

Petits exemples de code Python

2026-08-24T09:32:08Z

Jpinon : /* Script pour générer automatiquement des mots de passes */

== Script pour générer automatiquement des mots de passes ==
Dans la section [[Bash random|bash traitant des la génération du hasard]] j'avais mentionné des outils que auraient pu servir a générer des mots de passes.

Ici on fait un programme python pour faire ça mais en gérant les contraintes des systèmes modernes.

Les règles :

• contenir au moins un caractère de la classe majuscule (A-Z)

 • contenir au moins un caractère de la classe minuscule (a-z)

 • contenir au moins un caractère de la classe chiffre (0-9)

 • contenir au moins un caractère de la classe caractère spécial parmi ! , . / ? & _ * + = - > < @ ^ # £ µ §

 • NE PAS contenir plus de trois caractères de types identiques consécutifs.

Une longueur de mot de passe réglable avec une taille par défaut de 15 et un minimum de 8.<syntaxhighlight lang="python3">

import argparse
import random
import string

# Define character classes
LOWERCASE = string.ascii_lowercase
UPPERCASE = string.ascii_uppercase
DIGITS = string.digits
SPECIALS = "!,.?/&_*+=-<@^#£µ§"
ALL_CHARS = LOWERCASE + UPPERCASE + DIGITS + SPECIALS

def get_char_type(char):
"""Identifies the type of a character."""
if char in LOWERCASE:
return 'lower'
if char in UPPERCASE:
return 'upper'
if char in DIGITS:
return 'digit'
if char in SPECIALS:
return 'special'
return None

def has_required_chars(password):
"""Checks if the password contains at least one of each required character type."""
return (any(c in LOWERCASE for c in password) and
any(c in UPPERCASE for c in password) and
any(c in DIGITS for c in password) and
any(c in SPECIALS for c in password))

def no_more_than_three_consecutive(password):
"""
Checks that the password does not contain more than three consecutive
characters of the same type.
"""
if len(password) < 4:
return True

for i in range(len(password) - 3):
char1_type = get_char_type(password[i])
char2_type = get_char_type(password[i+1])
char3_type = get_char_type(password[i+2])
char4_type = get_char_type(password[i+3])
if char1_type == char2_type == char3_type == char4_type:
return False
return True

def generate_password(length):
"""
Generates a password that meets all specified criteria.
"""
while True:
# Ensure the password has at least one of each required character type
password_chars = [
random.choice(LOWERCASE),
random.choice(UPPERCASE),
random.choice(DIGITS),
random.choice(SPECIALS)
]

# Fill the rest of the password length with random characters
remaining_length = length - len(password_chars)
if remaining_length > 0:
password_chars.extend(random.choices(ALL_CHARS, k=remaining_length))

# Shuffle the characters to avoid predictable patterns
random.shuffle(password_chars)
password = "".join(password_chars)

# Check if the generated password meets all criteria
if has_required_chars(password) and no_more_than_three_consecutive(password):
return password

def main():
"""Main function to parse arguments and generate password."""
parser = argparse.ArgumentParser(
description="Generate a secure password with specific criteria."
)
parser.add_argument(
"-n",
"--length",
type=int,
default=12,
help="The length of the password to generate (default: 12)."
)
args = parser.parse_args()

if args.length < 8:
print("Error: Password length must be at least 8 to meet all criteria.")
return

password = generate_password(args.length)
print(password)

if __name__ == "__main__":
main()

</syntaxhighlight>Son usagle est indentique sous windows (power shell) et Linux (bash) :<syntaxhighlight lang="text">
$ python ./password_generator.py
6C#+q4Tq8d=t
</syntaxhighlight>

== Script pour éviter le delog automatique et afficher l'heure ==
Souvent les connexions à la console ssh ont un time-out d'inactivité très (trop) court.

Voici un petit programme python qui affiche l'heure au centre de l'écran et attends l'appuy sur une touche.<syntaxhighlight lang="python3">
#!/bin/python3
import time
import sys
import select
import termios
import tty
import shutil
import hashlib

hashcode="dcc07eeab919998abfedd85c8946b83754501d8d"

# Obtenir la taille du terminal
size = shutil.get_terminal_size()
cols = size.columns
rows = size.lines

# FORMAT
date_format=" \u25C0\u25C0 %Y-%m-%d %H:%M:%S \u25B6\u25B6 ";
# Calcul de la chaine
ssize=len(time.strftime(date_format))

# Calculer la position centrale
center_x = (cols // 2)-(ssize//2)
center_y = rows // 2

# sleep_time to ajuste animation
sleep_time=0.03
phase=0

# Sauvegarder les paramÃ¨tres du terminal
fd = sys.stdin.fileno()
old_settings = termios.tcgetattr(fd)
tty.setcbreak(fd) # Mode caractÃ¨re par caractÃ¨re
time_start=time.time()
time_stop=time_start+0.5
time_slice=time_stop-time_start
count=0
increment=1

print ("\033[?25l\033[s",end="")
try:
while True:
try:
if select.select([sys.stdin], [], [], 0)[0]:
key = sys.stdin.read(1)
if key in ('q', 'Q', '\033'):
print(f"\033[{center_y-1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y+1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H\033[0mEnter code:______\033[6D",end="", flush=True)
code=input()
hash_input_code = hashlib.sha1(code.encode()).hexdigest()
if hash_input_code == hashcode:
break
if key in ('t', 'T'):
print(f"\033[{center_y-1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y+1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H\033[0m time slice:{time_slice:.5f} \033[6D",end="", flush=True)
code=input()
if key in ('s', 'S'):
print(f"\033[{center_y-1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y+1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H\033[0m sleep:{sleep_time:.5f} \033[6D",end="", flush=True)
code=input()
if key in ('p', 'P'):
print(f"\033[{center_y-1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y+1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H\033[0m phase:{phase:.5f} \033[6D",end="", flush=True)
code=input()

print(f"\033[{center_y-1};{center_x}H\033[0m Screen lock 'q' or <esc> to exit", end="")
print(f"\033[{center_y};{center_x}H", end="")
now = time.time()
ts=time.localtime(now)
f=time.strftime("\033[103m\033[31m"+date_format+"\033[0m",ts)
print (f,end="",flush=True)

print(f"\033[{center_y+1};{center_x}H",end="")
## Ajust frequency
if time_slice>0.95 and time_slice<1.05: # > 95% Green
print ("\033[92m",end="")
else:
if time_slice>0.75 and time_slice<1.25: # > 75% Yellow
print ("\033[93m",end="")
else:
print ("\033[31m",end="") # <75% red

## print time arrow

print (" "*count,end="",flush=True)
if increment > 0:
print (f"-> ",end="",flush=True)
else:
print (f"<- ",end="",flush=True)
time.sleep(sleep_time)
count+=increment
if count>=ssize-2:
time_start=time.time()
increment=-1
if count<=0:
time_stop=time.time()
time_slice=abs(time_stop-time_start)
if time_slice < 1:
t=time.time()
phase=t-int(t)
sleep_time+=0.001
else:
sleep_time-=0.001
if sleep_time<0:
sleep_time=0
increment=+1
te=time.time()
except KeyboardInterrupt:
print("\007", end="", flush=True)

finally:
termios.tcsetattr(fd, termios.TCSADRAIN, old_settings) # Restaurer terminal
print(f"\033[{center_y-1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y+1};{center_x}H"+" "*ssize, end="")

print("\033[u\033[?25h", end="") # Restaurer position curseur

</syntaxhighlight>Le script s'autoexplique. On utilise le module [[Python date et heure#Le module time|time]] el des [[ANSI|codes ansi]].

[[Fichier:Image-slock.png|sans_cadre|425x425px]]

L'heure et la date s'affiche au milieu de l'écran avec le carret qui disparait. Si on tape une touche on remplace le texte jaune de la date par des espaces,le carret réapparait et le curseur revient là ou il était.

Si il y avait du texte sous la date comme c'est le cas dans cet exemple il sera perdu et remplacé par des espaces.

Petits exemples de code Python

2026-08-24T08:13:53Z

Jpinon : /* Script pour éviter le delog automatique et afficher l'heure */

== Script pour générer automatiquement des mots de passes ==
Dans la section [[Bash random|bash traitant des la génération du hasard]] j'avais mis un exemple de générateur de lot de passe.

Ici on fait un programme python pour faire ça mais en gérant les contraintes des systèmes modernes.

Les règles :

• contenir au moins un caractère de la classe majuscule (A-Z)

 • contenir au moins un caractère de la classe minuscule (a-z)

 • contenir au moins un caractère de la classe chiffre (0-9)

 • contenir au moins un caractère de la classe caractère spécial parmi ! , . / ? & _ * + = - > < @ ^ # £ µ §

 • NE PAS contenir plus de trois caractères de types identiques consécutifs.

Une longueur de mot de passe réglable avec une taille par défaut de 15 et un minimum de 8.<syntaxhighlight lang="python3">

import argparse
import random
import string

# Define character classes
LOWERCASE = string.ascii_lowercase
UPPERCASE = string.ascii_uppercase
DIGITS = string.digits
SPECIALS = "!,.?/&_*+=-<@^#£µ§"
ALL_CHARS = LOWERCASE + UPPERCASE + DIGITS + SPECIALS

def get_char_type(char):
"""Identifies the type of a character."""
if char in LOWERCASE:
return 'lower'
if char in UPPERCASE:
return 'upper'
if char in DIGITS:
return 'digit'
if char in SPECIALS:
return 'special'
return None

def has_required_chars(password):
"""Checks if the password contains at least one of each required character type."""
return (any(c in LOWERCASE for c in password) and
any(c in UPPERCASE for c in password) and
any(c in DIGITS for c in password) and
any(c in SPECIALS for c in password))

def no_more_than_three_consecutive(password):
"""
Checks that the password does not contain more than three consecutive
characters of the same type.
"""
if len(password) < 4:
return True

for i in range(len(password) - 3):
char1_type = get_char_type(password[i])
char2_type = get_char_type(password[i+1])
char3_type = get_char_type(password[i+2])
char4_type = get_char_type(password[i+3])
if char1_type == char2_type == char3_type == char4_type:
return False
return True

def generate_password(length):
"""
Generates a password that meets all specified criteria.
"""
while True:
# Ensure the password has at least one of each required character type
password_chars = [
random.choice(LOWERCASE),
random.choice(UPPERCASE),
random.choice(DIGITS),
random.choice(SPECIALS)
]

# Fill the rest of the password length with random characters
remaining_length = length - len(password_chars)
if remaining_length > 0:
password_chars.extend(random.choices(ALL_CHARS, k=remaining_length))

# Shuffle the characters to avoid predictable patterns
random.shuffle(password_chars)
password = "".join(password_chars)

# Check if the generated password meets all criteria
if has_required_chars(password) and no_more_than_three_consecutive(password):
return password

def main():
"""Main function to parse arguments and generate password."""
parser = argparse.ArgumentParser(
description="Generate a secure password with specific criteria."
)
parser.add_argument(
"-n",
"--length",
type=int,
default=12,
help="The length of the password to generate (default: 12)."
)
args = parser.parse_args()

if args.length < 8:
print("Error: Password length must be at least 8 to meet all criteria.")
return

password = generate_password(args.length)
print(password)

if __name__ == "__main__":
main()

</syntaxhighlight>Son usagle est indentique sous windows (power shell) et Linux (bash) :<syntaxhighlight lang="text">
$ python ./password_generator.py
6C#+q4Tq8d=t
</syntaxhighlight>

== Script pour éviter le delog automatique et afficher l'heure ==
Souvent les connexions à la console ssh ont un time-out d'inactivité très (trop) court.

Voici un petit programme python qui affiche l'heure au centre de l'écran et attends l'appuy sur une touche.<syntaxhighlight lang="python3">
#!/bin/python3
import time
import sys
import select
import termios
import tty
import shutil
import hashlib

hashcode="dcc07eeab919998abfedd85c8946b83754501d8d"

# Obtenir la taille du terminal
size = shutil.get_terminal_size()
cols = size.columns
rows = size.lines

# FORMAT
date_format=" \u25C0\u25C0 %Y-%m-%d %H:%M:%S \u25B6\u25B6 ";
# Calcul de la chaine
ssize=len(time.strftime(date_format))

# Calculer la position centrale
center_x = (cols // 2)-(ssize//2)
center_y = rows // 2

# sleep_time to ajuste animation
sleep_time=0.03
phase=0

# Sauvegarder les paramÃ¨tres du terminal
fd = sys.stdin.fileno()
old_settings = termios.tcgetattr(fd)
tty.setcbreak(fd) # Mode caractÃ¨re par caractÃ¨re
time_start=time.time()
time_stop=time_start+0.5
time_slice=time_stop-time_start
count=0
increment=1

print ("\033[?25l\033[s",end="")
try:
while True:
try:
if select.select([sys.stdin], [], [], 0)[0]:
key = sys.stdin.read(1)
if key in ('q', 'Q', '\033'):
print(f"\033[{center_y-1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y+1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H\033[0mEnter code:______\033[6D",end="", flush=True)
code=input()
hash_input_code = hashlib.sha1(code.encode()).hexdigest()
if hash_input_code == hashcode:
break
if key in ('t', 'T'):
print(f"\033[{center_y-1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y+1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H\033[0m time slice:{time_slice:.5f} \033[6D",end="", flush=True)
code=input()
if key in ('s', 'S'):
print(f"\033[{center_y-1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y+1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H\033[0m sleep:{sleep_time:.5f} \033[6D",end="", flush=True)
code=input()
if key in ('p', 'P'):
print(f"\033[{center_y-1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y+1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H\033[0m phase:{phase:.5f} \033[6D",end="", flush=True)
code=input()

print(f"\033[{center_y-1};{center_x}H\033[0m Screen lock 'q' or <esc> to exit", end="")
print(f"\033[{center_y};{center_x}H", end="")
now = time.time()
ts=time.localtime(now)
f=time.strftime("\033[103m\033[31m"+date_format+"\033[0m",ts)
print (f,end="",flush=True)

print(f"\033[{center_y+1};{center_x}H",end="")
## Ajust frequency
if time_slice>0.95 and time_slice<1.05: # > 95% Green
print ("\033[92m",end="")
else:
if time_slice>0.75 and time_slice<1.25: # > 75% Yellow
print ("\033[93m",end="")
else:
print ("\033[31m",end="") # <75% red

## print time arrow

print (" "*count,end="",flush=True)
if increment > 0:
print (f"-> ",end="",flush=True)
else:
print (f"<- ",end="",flush=True)
time.sleep(sleep_time)
count+=increment
if count>=ssize-2:
time_start=time.time()
increment=-1
if count<=0:
time_stop=time.time()
time_slice=abs(time_stop-time_start)
if time_slice < 1:
t=time.time()
phase=t-int(t)
sleep_time+=0.001
else:
sleep_time-=0.001
if sleep_time<0:
sleep_time=0
increment=+1
te=time.time()
except KeyboardInterrupt:
print("\007", end="", flush=True)

finally:
termios.tcsetattr(fd, termios.TCSADRAIN, old_settings) # Restaurer terminal
print(f"\033[{center_y-1};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y};{center_x}H"+" "*ssize, end="")
print(f"\033[{center_y+1};{center_x}H"+" "*ssize, end="")

print("\033[u\033[?25h", end="") # Restaurer position curseur

</syntaxhighlight>Le script s'autoexplique. On utilise le module [[Python date et heure#Le module time|time]] el des [[ANSI|codes ansi]].

[[Fichier:Image-slock.png|sans_cadre|425x425px]]

L'heure et la date s'affiche au milieu de l'écran avec le carret qui disparait. Si on tape une touche on remplace le texte jaune de la date par des espaces,le carret réapparait et le curseur revient là ou il était.

Si il y avait du texte sous la date comme c'est le cas dans cet exemple il sera perdu et remplacé par des espaces.

Bash random

2026-08-24T08:05:10Z

Jpinon :

Les ordinateurs savent faire beaucoup de chose mais ont beaucoup de mal avec le hasard. Leur conception déterministe ne les prédispose pas à ce genre de travail. Deux solutions émergent:

* Se baser sur un phénomène physique aléatoire ou réputé tel mais c'est très difficile et il faut avoir un capteur pour cela.
* Utiliser un algorithme pseudo aléatoire. La suite de nombre sera réputé aléatoire même su toujours la même. Exemple les chiffres de PI. La suite est aléatoire mais commence toujours par 3.14... l'ordinateur utilise souvent le temps pour prendre "en marche" cette séquence.

== Sulution basée sur des répétitions de uuid ==

Dans la page de génération de uuid j'avais mentionné la disponibillité d'un outil de génération :<syntaxhighlight lang="bash">cat /proc/sys/kernel/random/uuid</syntaxhighlight>Qui nous donne des chaines du type :<syntaxhighlight lang="text">45448407-faf9-42af-af54-fbe6194a510c</syntaxhighlight>Le script suivant :<syntaxhighlight lang="python3">
while [ 1 ]
do
export RND=`cat /proc/sys/kernel/random/uuid | cut -b 1-8,10-13,15-18,20-23,25-`
echo -n $RND
done
</syntaxhighlight>Va nous donner une suite ininterrompue de digits en hexa.

Si on veut du binaire xxd est notre amis mai, attention, le binaire n'est pas affichable. On redirige vers un fichier.<syntaxhighlight lang="bash">
while [ 1 ]
do
export RND=`cat /proc/sys/kernel/random/uuid | cut -b 1-8,10-13,15-18,20-23,25-`
echo -n $RND
done | xxd -r -p > binary-random.bin

</syntaxhighlight>On fait tourner ce scriot quelques secondes et on l'arrête par <CTRL>+C.

On récupère un fichier binaire aléatoire.

On peut l'afficher avec <code>od -x</code> ou avec <code>base64</code> par exemple.

Redirections bash

2026-08-07T08:33:11Z

Jpinon : Jpinon a déplacé la page Redirections bash vers Redirections bash (et en bourne shell en géneral)

#REDIRECTION [[Redirections bash (et en bourne shell en géneral)]]

Redirections bash (et en bourne shell en géneral)

2026-08-07T08:33:11Z

Jpinon : Jpinon a déplacé la page Redirections bash vers Redirections bash (et en bourne shell en géneral)

Les redirections c'est la base des batches !

== Echanges standard entre un process et son environnement. ==
Un process (process ou processus en français j'utiliserais les deux mots indéférament) est une suite d'instructions qui sont exécutées par le système les unes après les autres. Il n'y a pas de notion de parallélisme à ce niveau.

A sa création un process possède trois "flux" standard.

* Une entrée
* deux sorties (normal et erreurs)
[[Fichier:Process-bash000.png|centré|sans_cadre|492x492px]]

Si rien n'est précisé l'entrée standard est le clavier et les deux sorties (standard et erreur sont l'écran)
[[Fichier:Process-bash001.png|centré|sans_cadre|750x750px]]

Déjà, de façon, transparente ce clavier et cet écrans sont transformés dans le cas du ssh (ou du telnet). Dans ce cas les entrées sorties sont redirigées vers le réseau lui même ver le client ssh qui... finalement l'envoie à un clavier et un écran même si ce n'est pas celui de ma machine sur laquelle tourne le processus.

Un exemple typique : un simple ls.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
$ ls rrr
ls: cannot access 'rrr': No such file or directory
$
</syntaxhighlight>Le premier ls ci dessus envoie sa sortie standard vers l'écran (le flux en bleu sur le schéma). Dans le cas second ls, il s'agit d'une erreur donc vers la sortie d'erreur (flux en rouge).

Il est impossible, pour le moment, de savoir si ce qui est à l'écran a été envoyé vers la sortie standard ou la sortie d'erreur. (sauf le bon sens)

Pour le cas de l'entrée standard l'exemple est plus subtil, on va utiliser grep. grep est un programme assez simple (bon il a plein d'options mais on en parlera pas là) il lit l'entrée standard ligne par ligne et ne l'affiche sur la sortie que si elle comprends un chaine donnée en paramètre.<syntaxhighlight lang="bash">
$ grep toto
Bonjour toi
Bonjour vous
Hello toto
Hello toto
Ca va toto?
Ca va toto?
au revoir toto
au revoir toto
salut
</syntaxhighlight>le shell envoie aussi à l'écran ce que l'on tape au clavier avant de l'envoyer au programme (il appelle ca l'écho).

que se passe t'il dans notre exemple? On entre le ligne <code>"Bonjour toi"</code>. Le shell l'envoie à l'écran et au process (grep). grep lit la ligne<code>"Bonjour toi"</code>et vérifie si elle contient la chaine qu'on lui a donné en paramètre <code>"toto"</code>. Ce n'est pas le cas, grep ignore la ligne. Il se passe la même chose pour <code>"Bonjour vous"</code>. En revanche pour <code>"Hello toto"</code> le shell l'envoie a l'écran (echo) et à grep. Grep voit qu'elle contient bien la chaine <code>"toto",</code> alors elle écrit la ligne sur la sortie standard.

Donc on voit la ligne en double. D'abord l'echo de ce qu'on tape ensuite la sortie de grep.

== Redirections des flux standards ==
L'un des concepts les puis puissant du shell unix (linux par la suite) est que ces 3 flux peuvent êtres branchées sur n'importe quoi d'autre (on vient d'effleurer le sujet avec ssh).

=== Les types de redirections ===

==== redirection entre process ====
c'est la redirection de la sortie d'un process vers l'entrée d'un autre. Ca s'appelle un 'pipe' (un tube, un tuyau... )
[[Fichier:Process-bash002.png|centré|sans_cadre|916x916px]]

Pour chainer ainsi deux process on utilise le caractère "pipe" soit <code>"|"</code>.
Il s'agit d'une barre verticale qui semble être un tuyau dans le mauvais sens. Il faut connaitre comment les premières machines affichaient ce caractère : pas <code>"|"</code> mais <code>"¦"</code>.

Une barre avec un petit trou pour laisser passer le flux. Ce caractère à été simplifié et maintenant et on ne comprends plus bien.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
$ ls -l | grep toto
$ ls -l | grep "c"
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>La première commande est un bête ls qui donne la liste des fichiers.
La seconde filtre ces lignes pour n'afficher que les lignes contenant la chaine <code>"toto"</code>.. c'est à dire aucune.
La troisième filtre les lignes pour n'afficher que celles contenant <code>"c"</code> c'est a dire deux d'entres elles.

Attention on parle là de flux de caractères. Les redirections et les process de ces exemples ne "comprennent" pas ce qu'on leur envoie dans les flux.
si on avait utilisé grep avec <code>"n":</code><syntaxhighlight lang="bash">
$ ls -l | grep "n"
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>Aucun fichier ne contient de <code>"n"</code> mais grep traite le flux ligne de texte par ligne de texte. Il trouve des <code>"n"</code> dans le nom du user et du groupe il affiche la ligne.
Nous ne sommes pas dans des shell type powershell qui traitent des objets. Ici on traite des flux de caractres est bête et méchants.

'''<big>SECTION Pour les experts</big>''' (qui connaissent [[strace]]).

'''Vous êtes débutant passez cette section vous y reviendrez plus tard!'''<syntaxhighlight lang="bash">strace -e openat grep "toto" resultat.txt</syntaxhighlight>Nous donne bien une ligne:<syntaxhighlight lang="text">
openat(AT_FDCWD, "resultat.txt", O_RDONLY|O_NOCTTY) = 3
</syntaxhighlight>C'est bien le process "grep" qui ouvre le fichier <code>resultat.txt</code>.

Mais si on fait :<syntaxhighlight lang="bash">
cat toto | strace -e openat grep "toto"
</syntaxhighlight>pas de lignes d'ouverture de resultat.txt dans grep. C'est cat qui ouvre le ficher!

SI on trace ce que fait cat et pas ce que fait grep:<syntaxhighlight lang="bash">
strace -e openat cat resultat.txt | grep "toto"
</syntaxhighlight>On récupère bien notre ligne<syntaxhighlight lang="text">
openat(AT_FDCWD, "resultat.txt", O_RDONLY) = 3
</syntaxhighlight>Si on fait :<syntaxhighlight lang="bash">
strace -e openat cat < resultat.txt | grep "toto"
</syntaxhighlight>On ne voit plus rien car c'est bash qui ouvre le fichier pour l'envoyer a cat (voir plus loin)

'''<big>FIN DE SECTION EXPERTS</big>'''

==== Fichiers ====

==== ">" Rediriger la sortie standard vers un fichier ====
Autant <code>"|"</code> dirige la sortie d'un processus vers l'entrée d'un autre processus <code>">"</code> redirige simplement la sortie standard d'un process vers un fichier disque.

Exemple simple un simple ls.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>La commande ls envoie la liste des fichier vers la sortie standard. Jusque là on n'a rien fait!<syntaxhighlight lang="bash">$ ls -l > resultat.txt</syntaxhighlight>Cette commande ne réponds rien et c'est normal. On lui a demandé de rediriger la sortie standard vers un fichier <code>"resultat.txt"</code>

Si on refait un ls.<syntaxhighlight lang="bash">$ ls -l
total 48
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
-rw-r--r-- 1 jpinon jpinon 344 Aug 5 23:21 resultat.txt</syntaxhighlight>Effectivement on a un nouveau fichier!

SI on regarde ce qu'il i a dedans (cat, vi, nano... chacun sa méthode) mais on y trouve :<syntaxhighlight lang="text">
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
-rw-r--r-- 1 jpinon jpinon 0 Aug 5 23:21 resultat.txt
</syntaxhighlight>On remarque que <code>"resultat.txt"</code> est déjà dedans mais avec une taille nulle. Etrange? pas tant que ça et ca nous montre bien comment ça se passe.

Lors de la commande <code>"ls -l > resultat.txt"</code> le shell (bash ici) voit que la sortie de <code>ls</code> devra aller dans un fichier <code>"resultat.txt"</code> qu'il s'empresse de créer mais, pour le moment, il est vide. Le shell lance alors le <code>"ls -l"</code> qui fait la liste des fichiers, dont resultat.txt qui est vide, et l'envoie dans le fichier "resultat.txt" qui se remplis alors.

A la sortie resultat.txt est donc plein mais, quand il a été lut par ls il était vide!

'''Tout est simple et logique en bash!'''

==== ">>" Pour pas tout casser ====
La redirection > envoie dans un fichier le contenu de la sortie standard d'un process. Cependant si ce fichier existe il sera écrasé par le contenu en question. Ce n'est pas toujours ce que l'on souhaite!

On veut parfois "ajouter à la fin". <syntaxhighlight lang="bash">
echo "Etat des disques" > status.txt
df -h >> status.txt
</syntaxhighlight>On crée un fichier contenant la ligne "etat des disques" et on y ajoute le résultat de <code>df -h</code>.

J'i mon petit script de création de fichier python vide:<syntaxhighlight lang="bash">
# fichier create-py.sh
echo -n "#!" > $1.py
which python3 >> $1.py
echo "" >> $1.py
echo -n "# " >> $1.py
date "+created on %Y-%m-%d@%H:%M by $USER" >> test.py
chmod a+x $1.py

</syntaxhighlight>On l'appelle avec :<syntaxhighlight lang="bash">./create-py test</syntaxhighlight>... et on a un test.py :<syntaxhighlight lang="python3">
#!/usr/bin/python3
# created on 2026-08-06@01:00 by jpinon
</syntaxhighlight>Correctement configuré pour être lancé directement à la ligne de commande. Il reste plus qu'à....

==== "<" rediriger un fichier vers l'entrée standard d'un process. ====
C'est la partie la moins élégante de la syntaxe je trouve mais bon. On peut utiliser un fichier comme l'entrée d'un process.

C'est assez rarement utilisé parce que'à la fois pas clair et pas très utile. Suivez moi bien:<syntaxhighlight lang="bash">
cat
</syntaxhighlight>affiche le résultat de l'entrée standard sur la sortie standard. Le truc le plus inutile possible!<syntaxhighlight lang="bash">
$ cat
hello
hello
bonjour
bonjour
jaquot
jaquot
blabla
blabla
</syntaxhighlight>Ca répète tout ce qu'on tape jusqu'à la fin du texte (EOF ou <Ctrl> D)

si on voulait lui faire écrire ce qu'il y a dans un fichier on sait qu'il faut faire :<syntaxhighlight lang="bash">
cat resultat.txt
</syntaxhighlight>Ca marche mais c'est pas ce que je veux vous montrer. C'est juste le fonctionnement de la commande <code>cat</code>. SI on lui donne un paramètre au lieu de copier l'entrée standard elle prends le paramètre en question, ouvre le fichier disque qui correspond de l'envoie sur la sortie standard. Là c'est le programme <code>cat</code> qui fait le travail.

Si on fait :<syntaxhighlight lang="bash">cat < resultat.txt # Attention un < s'est introduit dans cette commande!</syntaxhighlight>le résultat est exactement le même mais les actions effectuées sont totalement différentes!

Que fait le shell?

* Il ouvre <code>cat</code> sans paramètres qui va alors lire les lignes une par une sur l'entrée standard et les envoyer sur la sortie standard jusqu'à EOF. Il est bête mais on lui en demande pas plus.
* Mais le shell vois aussi que l'entrée standard de cat doit être "alimentée", non pas par le clavier mais par le contenu d'un fichier "resultat.txt"
* doc cat prends ce qu'il a en entrée (le shell lui envoie le contenu de resultat.txt) et l'envoie sur la sortie standard (ici l'écran)

On pourrait envisager un:<syntaxhighlight lang="bash">
cat < resultat.txt > resultat1.txt
</syntaxhighlight>...qui en fait est l'équivalant d'une copie de <code>resultat.txt</code> vers <code>resultat1.txt</code>.<syntaxhighlight lang="bash">
cp resultat1 resultat2
</syntaxhighlight>aurait fait pareil.

Encore plus pervère<syntaxhighlight lang="bash">
cat < resultat.txt | grep jpinon > resultat2.txt
</syntaxhighlight>Le shell traite comme ça:

* ouverture de <code>cat</code> "tout nu" qui lit sur l'entrée et envoie vers la sortie
* son entrée est connectée par shell sur le fichier <code>resultat.txt</code>. Ok, donc cat ne le sait pas mais il lit les lignes de <code>resultat.txt</code> une par une (c'est le shell qui les lui envoie).
* <code>cat</code> ecrit vers sa sortie standars mais le shell la redirrige vers <code>grep</code>.
* <code>grep</code> est presque aussi bête que <code>cat</code>. Il lit des lignes sur son entrée standard et les sort sur la sur la sortie standard pour peu que la ligne contienne la chaine en paramètre
* mais le shell est malin, il lui envoie sur son entrée standard la sortie de <code>cat</code>.
* a la fin le shell détourne la sortie de <code>grep</code> vers <code>resultat2.txt</code>

Tout ca se résume dans :
[[Fichier:Process-bash004.png|centré|sans_cadre|914x914px]]

==== Remarque sur l'usage de "-" ====
Quelquefois il est indispensable de donner un fichier à une commande. dans ce cas là on peut remplacer ne nom du fichier par <code>"-"</code>.

Par exemple :<syntaxhighlight lang="bash">
cat -
</syntaxhighlight>est équivalant à:<syntaxhighlight lang="bash">
cat
</syntaxhighlight>bon pas très utile. Mais pensons au compilateur cc. une option est de lui demander de juste s'arreter au code assembleur mais pas d'aller jusqu'au code machine.<syntaxhighlight lang="bash">
cc -S hello.c
</syntaxhighlight>va, par défaut nous sortir un fichier hello.s qui contient le code assembleur. Imaginons que l'on veuille avoir ce code assembleur pour l'envoyer à un ami mais on le voudrait "gzippé". Problème cc sait sortir dans un fichier texte, on peut lui donner le nom du fichier de sortie par l'option "-o fichier.s" mais il ne sait pas zipper.

On porait faire ça en deux commandes :<syntaxhighlight lang="bash">
cc -o code.s -S hello.c
gzip code.s
</syntaxhighlight>en sortie on aura un fichier code.s.gz tres bien mais on a appris a faire des redirections! Alors on en fait!<syntaxhighlight lang="bash">cc -o - -S hello.c | gzip > code.s.gz</syntaxhighlight>C'est pas beau!

Avec un beau dessin :
[[Fichier:Process-bash005.png|centré|sans_cadre|916x916px]]

On pourrait même l'envoyer directement à notre amis. Ce fichier code.s.gz j'en ai pas besoin moi!<syntaxhighlight lang="bash">cc -o - -S hello.c | gzip | mail -s "le code assembleur de hello.c" monami@gmail.com</syntaxhighlight>
[[Fichier:Process-bash006.png|centré|sans_cadre|916x916px]]

Bon comme ça ca parait un peu inutile mais imaginez une tâche [[cron]] qui lance, tous les jours à 4h le matin la commande suivante:<syntaxhighlight lang="bash">
df -h | mail -s "Etat des disques" moi@mondomaine.fr
</syntaxhighlight>Et oui! tous les matin j'aurais l'état de remplissage des disque de ma machine dans mes mails. On pourrait améliorer avec un <code>grep</code> entre <code>df</code> et <code>mail</code> pour ne mentionner que les disques qui posent un problème.

=== Redirection du flux d'erreur ===
Pour le moment on se traine notre (nos) flux d'erreurs qui vont vers la console. C'est bien car, même quand les sortie standards sont redirigées on peut voir que ça s'est mal passé.

Imaginons que les erreurs suivent le même chemin que la sortie avec:<syntaxhighlight lang="bash">
cc -o - -S hello.c | gzip | mail -s "le code assembleur de hello.c" monami@gmail.com
</syntaxhighlight>imaginons une erreur de compilation (j'ai oublié le int devant le main()):<syntaxhighlight lang="bash">
$ cc -S hello.c
hello.c:3:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
3 | main(){
| ^~~~
$
</syntaxhighlight>Dans le cas présent ca m'affiche l'erreur et tout s'arrête après <code>cc</code>. J'aurais mon message et mon ami ne recevra pas de mail.

Si la sortie d'erreur était gérée par le même flux que la sortie standard, je ne m'apercevrais de rien et mon ami recevrait le mail avec le message d'erreur. La loose!

Et bien voila pourquoi la sortie standard est gérée a part.

==== 2> redirection vers un fichier. ====
Pour reprendre l'exemple ci dessus.<syntaxhighlight lang="bash">cc -S -o - hello.c 2> error.txt</syntaxhighlight>ca donne :
[[Fichier:Process-bash007.png|centré|sans_cadre|1019x1019px]]

le code source est généré (par défaut pour <code>cc</code>) dans <code>stdout</code> et la sortie standard est dans <code>error.txt</code>

==== 2>> redirection (avec ajout) dans un fichier. ====
De la même façon que pour la sortie standard <code>>></code> la sortie erreur est redirigée vers un fichier mais en mode "append".<syntaxhighlight lang="bash">
cc -S -o - hello.c 2>> error.txt
</syntaxhighlight>les erreurs s'accumulent dans <code>error.txt</code>

==== Redirection de la sortie d'erreur dans un pipe. ====
La c'est le moment complexe de l'affaire!

Il n'y a pas d'opérateur de redirection 2| mais il y a des opérateurs redirige tel flux vers tel autre. Faut jouer avec.

===== 2>&1 Forcer stderr vers stdout =====
[[Fichier:Process-bash008.png|centré|sans_cadre|1017x1017px]]
<syntaxhighlight lang="bash">ls 2>&1</syntaxhighlight>On les erreurs et la sortie standard dans le même flux, ici ca sert pas a grand chose mais:<syntaxhighlight lang="bash">
df -h 2>&1 | mail -s "Etat du disque" moi@mondomaine.fr
</syntaxhighlight>C'est plus utile! On envoie un mail avec l'état des disques. Si il y a une erreur on a l'erreur dans le corps du mail aussi.
[[Fichier:Process-bash009..png|centré|sans_cadre|1017x1017px]]

Le problème est que l'on ne peut plus traiter différemment stderr et stdout dans le flux "violet".

=== x>&x généralisation de l'opérateur ===

Tout d'abord pour tester on va écrire un petit programme en C.<syntaxhighlight lang="c">
// Programme stdtest.c
// On compilera avec cc -o stdtest stdtest.c
#include <stdio.h>

int main(void)
{
fprintf(stdout, "Message sur stdout\n");
fprintf(stderr, "Message sur stderr\n");

return 0;
}
</syntaxhighlight>Est-ce nécessaire de l'expliquer ? On envoie une ligne sur la sortie standard et une autre sur l'erreur standard.

On compile et on teste:<syntaxhighlight lang="bash">
$ ./stdtest
Message sur stdout
Message sur stderr
$ ./stdtest > /dev/null
Message sur stderr
$ ./stdtest 2> /dev/null
Message sur stdout

</syntaxhighlight>Ici j'introduit le fichier <code>/dev/null</code>. Quand on y envoie un flux il va.. nulle part.

Si on envoie <code>stdout</code> sur <code>/dev/null</code>, seul <code>seterr</code> s'affiche et si on y envoie <code>stderr</code> seul <code>stdout</code> s'affiche.

Et si on y envoie les deux :<syntaxhighlight lang="bash">
$ ./stdtest 2> /dev/null > /dev/null
$
</syntaxhighlight>Il ne se passe rien et c'est bien normal.

Maintenant regardons le fonctionnement de <code>grep</code>. Sur ma machine, <code>grep</code> est en fait un alias vers <code>grep --color=auto</code>. dans ce mode grep mets en couleur (rouge) la chaine qu'il a trouvé.

[[Fichier:Grep std.png|sans_cadre]]

Grep a "touché" stdout et on voit le rouge.

[[Fichier:Grep both.png|sans_cadre]]

L'opérateur 2>&1 redirige 2 (stderr vers 1 stdout). le grep lit les deux lignes, les deux sont en rouge.

Logiquement on se dit que 1>&2 devrait rediriger la sortie standard dans la sortie erreur.

[[Fichier:Stderrall.png|sans_cadre]]

Tout est envoyé dans stderr et grep qui est connecté a stdout ne voit rien!

Et le top du top :

[[Fichier:Avecflux3.png|sans_cadre]]

* <code>3>&1</code> : On crée un 3 qui envoie sur 1 (stdout)
* <code>1>&2</code> : On a déjà vu ca redirige la sortie standard dans la sortie erreur
* <code>2>&3</code> : Redirige la sortie d'erreur vers la sortie <code>3</code> qui a été initialisée pour envoyer vers <code>stdout</code> avant qu'on la redirige vers <code>stderr</code>.

On swappe les flux comme pour swapper le contenu de deux variables, il en faut une troisième.

Selon la représentation habituelle ca ferait:
[[Fichier:Process-bash010.png.png|centré|sans_cadre|1017x1017px]]

Où même (vue de près)
[[Fichier:Swapzoom.png.png|centré|sans_cadre|620x620px]]

C'est puissant mais est-ce vraiment clair...

Donc la formule magique c'est : <code>3>&1 1>&2 2>&3</code> !

== Forme simplifiée en bash. ==
Les commandes ci dessus fonctionnent avec bash mais fonctionnent avec n'importe quel bourne shell.

[[Fichier:Sh ksh bash.png|sans_cadre|392x392px]]

Mais on l'a vu la syntaxe est "obscure".

'''''<big>bash</big>''''' nous propose une syntaxe plus élégante :

* <code>> >(commande)</code> envoie la sortie standard à <code>commande</code> (pour le coup équivalent a un <code>|</code>).

Mais on comprends la syntaxe avec :

* 2> >(commande) qui envoie la sortie d'erreur à <code>commande</code>. Pour le coup c'est plus lisible que <code>3>&1 1>&2 2>&3</code>

Ca permet, en une ligne de faire une commande dont stdout est traité par un filtre et stdout par un autre:<syntaxhighlight lang="bash">./stdtest \
> >(./filtre-bleu) \
2> >(./filtre-rouge >&2)</syntaxhighlight>[[Fichier:Bash-complex-filters.png.png|sans_cadre|482x482px]]

== Avec des pipes nommées ==
Ce mécanisme fonctionne avec bash, ksh, zsh (j'ai pas testé mais il parait) en sh de base ca ne marche pas. J'ai essayé des combinaisons avec <code>3>&1 1>&2 2>&3</code> et même avec un flux 4 de plus mais j'y suis pas arrivé.

La seule solution sh que je sois arrivé a faire marcher ce sont les ''pipes nommées'':<syntaxhighlight lang="sh">mkfifo fifo_out fifo_err

./filtre-bleu < fifo_out &
./filtre-rouge < fifo_err >&2 &

./stdtest > fifo_out 2> fifo_err

rm fifo_out fifo_err</syntaxhighlight>

* On crée deux FIFO des espèces de faux fichiers dans lesquels on ne peut que lire dans l'ordre ce qu'on y à écrit.<code>mkfifo fifo_out fifo_err</code>
* On lance deux taches en background qui envoient
** tout ce qui sort de <code>fifo_out</code> dans <code>./filtre-bleu</code>
** tout ce qui sort de <code>fifo_err</code> dans <code>./filtre-rouge</code>

* On lance notre commande en redirigeant <code>stdout</code> dans <code>fifo_out</code> et <code>stderr</code> dans <code>fifo_err</code>
* On efface nos pipes nommées (ça termine en même temps les deux tâches qui y étaient attachées)

[[Fichier:Namedfifo.png.png|sans_cadre|571x571px]]

Redirections bash (et en bourne shell en géneral)

2026-08-07T08:01:55Z

Jpinon : /* Forme simplifiée en bash. */

Fichier:Namedfifo.png.png

2026-08-07T07:57:15Z

Jpinon : Jpinon a téléversé une nouvelle version de Fichier:Namedfifo.png.png

pipes nommees

Redirections bash (et en bourne shell en géneral)

2026-08-07T07:56:12Z

Jpinon : /* x>&x généralisation de l'opérateur */

Les redirections c'est la base des batches !

== Echanges standard entre un process et son environnement. ==
Un process (process ou processus en français j'utiliserais les deux mots indéférament) est une suite d'instructions qui sont exécutées par le système les unes après les autres. Il n'y a pas de notion de parallélisme à ce niveau.

A sa création un process possède trois "flux" standard.

* Une entrée
* deux sorties (normal et erreurs)
[[Fichier:Process-bash000.png|centré|sans_cadre|492x492px]]

Si rien n'est précisé l'entrée standard est le clavier et les deux sorties (standard et erreur sont l'écran)
[[Fichier:Process-bash001.png|centré|sans_cadre|750x750px]]

Déjà, de façon, transparente ce clavier et cet écrans sont transformés dans le cas du ssh (ou du telnet). Dans ce cas les entrées sorties sont redirigées vers le réseau lui même ver le client ssh qui... finalement l'envoie à un clavier et un écran même si ce n'est pas celui de ma machine sur laquelle tourne le processus.

Un exemple typique : un simple ls.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
$ ls rrr
ls: cannot access 'rrr': No such file or directory
$
</syntaxhighlight>Le premier ls ci dessus envoie sa sortie standard vers l'écran (le flux en bleu sur le schéma). Dans le cas second ls, il s'agit d'une erreur donc vers la sortie d'erreur (flux en rouge).

Il est impossible, pour le moment, de savoir si ce qui est à l'écran a été envoyé vers la sortie standard ou la sortie d'erreur. (sauf le bon sens)

Pour le cas de l'entrée standard l'exemple est plus subtil, on va utiliser grep. grep est un programme assez simple (bon il a plein d'options mais on en parlera pas là) il lit l'entrée standard ligne par ligne et ne l'affiche sur la sortie que si elle comprends un chaine donnée en paramètre.<syntaxhighlight lang="bash">
$ grep toto
Bonjour toi
Bonjour vous
Hello toto
Hello toto
Ca va toto?
Ca va toto?
au revoir toto
au revoir toto
salut
</syntaxhighlight>le shell envoie aussi à l'écran ce que l'on tape au clavier avant de l'envoyer au programme (il appelle ca l'écho).

que se passe t'il dans notre exemple? On entre le ligne <code>"Bonjour toi"</code>. Le shell l'envoie à l'écran et au process (grep). grep lit la ligne<code>"Bonjour toi"</code>et vérifie si elle contient la chaine qu'on lui a donné en paramètre <code>"toto"</code>. Ce n'est pas le cas, grep ignore la ligne. Il se passe la même chose pour <code>"Bonjour vous"</code>. En revanche pour <code>"Hello toto"</code> le shell l'envoie a l'écran (echo) et à grep. Grep voit qu'elle contient bien la chaine <code>"toto",</code> alors elle écrit la ligne sur la sortie standard.

Donc on voit la ligne en double. D'abord l'echo de ce qu'on tape ensuite la sortie de grep.

== Redirections des flux standards ==
L'un des concepts les puis puissant du shell unix (linux par la suite) est que ces 3 flux peuvent êtres branchées sur n'importe quoi d'autre (on vient d'effleurer le sujet avec ssh).

=== Les types de redirections ===

==== redirection entre process ====
c'est la redirection de la sortie d'un process vers l'entrée d'un autre. Ca s'appelle un 'pipe' (un tube, un tuyau... )
[[Fichier:Process-bash002.png|centré|sans_cadre|916x916px]]

Pour chainer ainsi deux process on utilise le caractère "pipe" soit <code>"|"</code>.
Il s'agit d'une barre verticale qui semble être un tuyau dans le mauvais sens. Il faut connaitre comment les premières machines affichaient ce caractère : pas <code>"|"</code> mais <code>"¦"</code>.

Une barre avec un petit trou pour laisser passer le flux. Ce caractère à été simplifié et maintenant et on ne comprends plus bien.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
$ ls -l | grep toto
$ ls -l | grep "c"
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>La première commande est un bête ls qui donne la liste des fichiers.
La seconde filtre ces lignes pour n'afficher que les lignes contenant la chaine <code>"toto"</code>.. c'est à dire aucune.
La troisième filtre les lignes pour n'afficher que celles contenant <code>"c"</code> c'est a dire deux d'entres elles.

Attention on parle là de flux de caractères. Les redirections et les process de ces exemples ne "comprennent" pas ce qu'on leur envoie dans les flux.
si on avait utilisé grep avec <code>"n":</code><syntaxhighlight lang="bash">
$ ls -l | grep "n"
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>Aucun fichier ne contient de <code>"n"</code> mais grep traite le flux ligne de texte par ligne de texte. Il trouve des <code>"n"</code> dans le nom du user et du groupe il affiche la ligne.
Nous ne sommes pas dans des shell type powershell qui traitent des objets. Ici on traite des flux de caractres est bête et méchants.

'''<big>SECTION Pour les experts</big>''' (qui connaissent [[strace]]).

'''Vous êtes débutant passez cette section vous y reviendrez plus tard!'''<syntaxhighlight lang="bash">strace -e openat grep "toto" resultat.txt</syntaxhighlight>Nous donne bien une ligne:<syntaxhighlight lang="text">
openat(AT_FDCWD, "resultat.txt", O_RDONLY|O_NOCTTY) = 3
</syntaxhighlight>C'est bien le process "grep" qui ouvre le fichier <code>resultat.txt</code>.

Mais si on fait :<syntaxhighlight lang="bash">
cat toto | strace -e openat grep "toto"
</syntaxhighlight>pas de lignes d'ouverture de resultat.txt dans grep. C'est cat qui ouvre le ficher!

SI on trace ce que fait cat et pas ce que fait grep:<syntaxhighlight lang="bash">
strace -e openat cat resultat.txt | grep "toto"
</syntaxhighlight>On récupère bien notre ligne<syntaxhighlight lang="text">
openat(AT_FDCWD, "resultat.txt", O_RDONLY) = 3
</syntaxhighlight>Si on fait :<syntaxhighlight lang="bash">
strace -e openat cat < resultat.txt | grep "toto"
</syntaxhighlight>On ne voit plus rien car c'est bash qui ouvre le fichier pour l'envoyer a cat (voir plus loin)

'''<big>FIN DE SECTION EXPERTS</big>'''

==== Fichiers ====

==== ">" Rediriger la sortie standard vers un fichier ====
Autant <code>"|"</code> dirige la sortie d'un processus vers l'entrée d'un autre processus <code>">"</code> redirige simplement la sortie standard d'un process vers un fichier disque.

Exemple simple un simple ls.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>La commande ls envoie la liste des fichier vers la sortie standard. Jusque là on n'a rien fait!<syntaxhighlight lang="bash">$ ls -l > resultat.txt</syntaxhighlight>Cette commande ne réponds rien et c'est normal. On lui a demandé de rediriger la sortie standard vers un fichier <code>"resultat.txt"</code>

Si on refait un ls.<syntaxhighlight lang="bash">$ ls -l
total 48
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
-rw-r--r-- 1 jpinon jpinon 344 Aug 5 23:21 resultat.txt</syntaxhighlight>Effectivement on a un nouveau fichier!

SI on regarde ce qu'il i a dedans (cat, vi, nano... chacun sa méthode) mais on y trouve :<syntaxhighlight lang="text">
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
-rw-r--r-- 1 jpinon jpinon 0 Aug 5 23:21 resultat.txt
</syntaxhighlight>On remarque que <code>"resultat.txt"</code> est déjà dedans mais avec une taille nulle. Etrange? pas tant que ça et ca nous montre bien comment ça se passe.

Lors de la commande <code>"ls -l > resultat.txt"</code> le shell (bash ici) voit que la sortie de <code>ls</code> devra aller dans un fichier <code>"resultat.txt"</code> qu'il s'empresse de créer mais, pour le moment, il est vide. Le shell lance alors le <code>"ls -l"</code> qui fait la liste des fichiers, dont resultat.txt qui est vide, et l'envoie dans le fichier "resultat.txt" qui se remplis alors.

A la sortie resultat.txt est donc plein mais, quand il a été lut par ls il était vide!

'''Tout est simple et logique en bash!'''

==== ">>" Pour pas tout casser ====
La redirection > envoie dans un fichier le contenu de la sortie standard d'un process. Cependant si ce fichier existe il sera écrasé par le contenu en question. Ce n'est pas toujours ce que l'on souhaite!

On veut parfois "ajouter à la fin". <syntaxhighlight lang="bash">
echo "Etat des disques" > status.txt
df -h >> status.txt
</syntaxhighlight>On crée un fichier contenant la ligne "etat des disques" et on y ajoute le résultat de <code>df -h</code>.

J'i mon petit script de création de fichier python vide:<syntaxhighlight lang="bash">
# fichier create-py.sh
echo -n "#!" > $1.py
which python3 >> $1.py
echo "" >> $1.py
echo -n "# " >> $1.py
date "+created on %Y-%m-%d@%H:%M by $USER" >> test.py
chmod a+x $1.py

</syntaxhighlight>On l'appelle avec :<syntaxhighlight lang="bash">./create-py test</syntaxhighlight>... et on a un test.py :<syntaxhighlight lang="python3">
#!/usr/bin/python3
# created on 2026-08-06@01:00 by jpinon
</syntaxhighlight>Correctement configuré pour être lancé directement à la ligne de commande. Il reste plus qu'à....

==== "<" rediriger un fichier vers l'entrée standard d'un process. ====
C'est la partie la moins élégante de la syntaxe je trouve mais bon. On peut utiliser un fichier comme l'entrée d'un process.

C'est assez rarement utilisé parce que'à la fois pas clair et pas très utile. Suivez moi bien:<syntaxhighlight lang="bash">
cat
</syntaxhighlight>affiche le résultat de l'entrée standard sur la sortie standard. Le truc le plus inutile possible!<syntaxhighlight lang="bash">
$ cat
hello
hello
bonjour
bonjour
jaquot
jaquot
blabla
blabla
</syntaxhighlight>Ca répète tout ce qu'on tape jusqu'à la fin du texte (EOF ou <Ctrl> D)

si on voulait lui faire écrire ce qu'il y a dans un fichier on sait qu'il faut faire :<syntaxhighlight lang="bash">
cat resultat.txt
</syntaxhighlight>Ca marche mais c'est pas ce que je veux vous montrer. C'est juste le fonctionnement de la commande <code>cat</code>. SI on lui donne un paramètre au lieu de copier l'entrée standard elle prends le paramètre en question, ouvre le fichier disque qui correspond de l'envoie sur la sortie standard. Là c'est le programme <code>cat</code> qui fait le travail.

Si on fait :<syntaxhighlight lang="bash">cat < resultat.txt # Attention un < s'est introduit dans cette commande!</syntaxhighlight>le résultat est exactement le même mais les actions effectuées sont totalement différentes!

Que fait le shell?

* Il ouvre <code>cat</code> sans paramètres qui va alors lire les lignes une par une sur l'entrée standard et les envoyer sur la sortie standard jusqu'à EOF. Il est bête mais on lui en demande pas plus.
* Mais le shell vois aussi que l'entrée standard de cat doit être "alimentée", non pas par le clavier mais par le contenu d'un fichier "resultat.txt"
* doc cat prends ce qu'il a en entrée (le shell lui envoie le contenu de resultat.txt) et l'envoie sur la sortie standard (ici l'écran)

On pourrait envisager un:<syntaxhighlight lang="bash">
cat < resultat.txt > resultat1.txt
</syntaxhighlight>...qui en fait est l'équivalant d'une copie de <code>resultat.txt</code> vers <code>resultat1.txt</code>.<syntaxhighlight lang="bash">
cp resultat1 resultat2
</syntaxhighlight>aurait fait pareil.

Encore plus pervère<syntaxhighlight lang="bash">
cat < resultat.txt | grep jpinon > resultat2.txt
</syntaxhighlight>Le shell traite comme ça:

* ouverture de <code>cat</code> "tout nu" qui lit sur l'entrée et envoie vers la sortie
* son entrée est connectée par shell sur le fichier <code>resultat.txt</code>. Ok, donc cat ne le sait pas mais il lit les lignes de <code>resultat.txt</code> une par une (c'est le shell qui les lui envoie).
* <code>cat</code> ecrit vers sa sortie standars mais le shell la redirrige vers <code>grep</code>.
* <code>grep</code> est presque aussi bête que <code>cat</code>. Il lit des lignes sur son entrée standard et les sort sur la sur la sortie standard pour peu que la ligne contienne la chaine en paramètre
* mais le shell est malin, il lui envoie sur son entrée standard la sortie de <code>cat</code>.
* a la fin le shell détourne la sortie de <code>grep</code> vers <code>resultat2.txt</code>

Tout ca se résume dans :
[[Fichier:Process-bash004.png|centré|sans_cadre|914x914px]]

==== Remarque sur l'usage de "-" ====
Quelquefois il est indispensable de donner un fichier à une commande. dans ce cas là on peut remplacer ne nom du fichier par <code>"-"</code>.

Par exemple :<syntaxhighlight lang="bash">
cat -
</syntaxhighlight>est équivalant à:<syntaxhighlight lang="bash">
cat
</syntaxhighlight>bon pas très utile. Mais pensons au compilateur cc. une option est de lui demander de juste s'arreter au code assembleur mais pas d'aller jusqu'au code machine.<syntaxhighlight lang="bash">
cc -S hello.c
</syntaxhighlight>va, par défaut nous sortir un fichier hello.s qui contient le code assembleur. Imaginons que l'on veuille avoir ce code assembleur pour l'envoyer à un ami mais on le voudrait "gzippé". Problème cc sait sortir dans un fichier texte, on peut lui donner le nom du fichier de sortie par l'option "-o fichier.s" mais il ne sait pas zipper.

On porait faire ça en deux commandes :<syntaxhighlight lang="bash">
cc -o code.s -S hello.c
gzip code.s
</syntaxhighlight>en sortie on aura un fichier code.s.gz tres bien mais on a appris a faire des redirections! Alors on en fait!<syntaxhighlight lang="bash">cc -o - -S hello.c | gzip > code.s.gz</syntaxhighlight>C'est pas beau!

Avec un beau dessin :
[[Fichier:Process-bash005.png|centré|sans_cadre|916x916px]]

On pourrait même l'envoyer directement à notre amis. Ce fichier code.s.gz j'en ai pas besoin moi!<syntaxhighlight lang="bash">cc -o - -S hello.c | gzip | mail -s "le code assembleur de hello.c" monami@gmail.com</syntaxhighlight>
[[Fichier:Process-bash006.png|centré|sans_cadre|916x916px]]

Bon comme ça ca parait un peu inutile mais imaginez une tâche [[cron]] qui lance, tous les jours à 4h le matin la commande suivante:<syntaxhighlight lang="bash">
df -h | mail -s "Etat des disques" moi@mondomaine.fr
</syntaxhighlight>Et oui! tous les matin j'aurais l'état de remplissage des disque de ma machine dans mes mails. On pourrait améliorer avec un <code>grep</code> entre <code>df</code> et <code>mail</code> pour ne mentionner que les disques qui posent un problème.

=== Redirection du flux d'erreur ===
Pour le moment on se traine notre (nos) flux d'erreurs qui vont vers la console. C'est bien car, même quand les sortie standards sont redirigées on peut voir que ça s'est mal passé.

Imaginons que les erreurs suivent le même chemin que la sortie avec:<syntaxhighlight lang="bash">
cc -o - -S hello.c | gzip | mail -s "le code assembleur de hello.c" monami@gmail.com
</syntaxhighlight>imaginons une erreur de compilation (j'ai oublié le int devant le main()):<syntaxhighlight lang="bash">
$ cc -S hello.c
hello.c:3:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
3 | main(){
| ^~~~
$
</syntaxhighlight>Dans le cas présent ca m'affiche l'erreur et tout s'arrête après <code>cc</code>. J'aurais mon message et mon ami ne recevra pas de mail.

Si la sortie d'erreur était gérée par le même flux que la sortie standard, je ne m'apercevrais de rien et mon ami recevrait le mail avec le message d'erreur. La loose!

Et bien voila pourquoi la sortie standard est gérée a part.

==== 2> redirection vers un fichier. ====
Pour reprendre l'exemple ci dessus.<syntaxhighlight lang="bash">cc -S -o - hello.c 2> error.txt</syntaxhighlight>ca donne :
[[Fichier:Process-bash007.png|centré|sans_cadre|1019x1019px]]

le code source est généré (par défaut pour <code>cc</code>) dans <code>stdout</code> et la sortie standard est dans <code>error.txt</code>

==== 2>> redirection (avec ajout) dans un fichier. ====
De la même façon que pour la sortie standard <code>>></code> la sortie erreur est redirigée vers un fichier mais en mode "append".<syntaxhighlight lang="bash">
cc -S -o - hello.c 2>> error.txt
</syntaxhighlight>les erreurs s'accumulent dans <code>error.txt</code>

==== Redirection de la sortie d'erreur dans un pipe. ====
La c'est le moment complexe de l'affaire!

Il n'y a pas d'opérateur de redirection 2| mais il y a des opérateurs redirige tel flux vers tel autre. Faut jouer avec.

===== 2>&1 Forcer stderr vers stdout =====
[[Fichier:Process-bash008.png|centré|sans_cadre|1017x1017px]]
<syntaxhighlight lang="bash">ls 2>&1</syntaxhighlight>On les erreurs et la sortie standard dans le même flux, ici ca sert pas a grand chose mais:<syntaxhighlight lang="bash">
df -h 2>&1 | mail -s "Etat du disque" moi@mondomaine.fr
</syntaxhighlight>C'est plus utile! On envoie un mail avec l'état des disques. Si il y a une erreur on a l'erreur dans le corps du mail aussi.
[[Fichier:Process-bash009..png|centré|sans_cadre|1017x1017px]]

Le problème est que l'on ne peut plus traiter différemment stderr et stdout dans le flux "violet".

=== x>&x généralisation de l'opérateur ===

Tout d'abord pour tester on va écrire un petit programme en C.<syntaxhighlight lang="c">
// Programme stdtest.c
// On compilera avec cc -o stdtest stdtest.c
#include <stdio.h>

int main(void)
{
fprintf(stdout, "Message sur stdout\n");
fprintf(stderr, "Message sur stderr\n");

return 0;
}
</syntaxhighlight>Est-ce nécessaire de l'expliquer ? On envoie une ligne sur la sortie standard et une autre sur l'erreur standard.

On compile et on teste:<syntaxhighlight lang="bash">
$ ./stdtest
Message sur stdout
Message sur stderr
$ ./stdtest > /dev/null
Message sur stderr
$ ./stdtest 2> /dev/null
Message sur stdout

</syntaxhighlight>Ici j'introduit le fichier <code>/dev/null</code>. Quand on y envoie un flux il va.. nulle part.

Si on envoie <code>stdout</code> sur <code>/dev/null</code>, seul <code>seterr</code> s'affiche et si on y envoie <code>stderr</code> seul <code>stdout</code> s'affiche.

Et si on y envoie les deux :<syntaxhighlight lang="bash">
$ ./stdtest 2> /dev/null > /dev/null
$
</syntaxhighlight>Il ne se passe rien et c'est bien normal.

Maintenant regardons le fonctionnement de <code>grep</code>. Sur ma machine, <code>grep</code> est en fait un alias vers <code>grep --color=auto</code>. dans ce mode grep mets en couleur (rouge) la chaine qu'il a trouvé.

[[Fichier:Grep std.png|sans_cadre]]

Grep a "touché" stdout et on voit le rouge.

[[Fichier:Grep both.png|sans_cadre]]

L'opérateur 2>&1 redirige 2 (stderr vers 1 stdout). le grep lit les deux lignes, les deux sont en rouge.

Logiquement on se dit que 1>&2 devrait rediriger la sortie standard dans la sortie erreur.

[[Fichier:Stderrall.png|sans_cadre]]

Tout est envoyé dans stderr et grep qui est connecté a stdout ne voit rien!

Et le top du top :

[[Fichier:Avecflux3.png|sans_cadre]]

* <code>3>&1</code> : On crée un 3 qui envoie sur 1 (stdout)
* <code>1>&2</code> : On a déjà vu ca redirige la sortie standard dans la sortie erreur
* <code>2>&3</code> : Redirige la sortie d'erreur vers la sortie <code>3</code> qui a été initialisée pour envoyer vers <code>stdout</code> avant qu'on la redirige vers <code>stderr</code>.

On swappe les flux comme pour swapper le contenu de deux variables, il en faut une troisième.

Selon la représentation habituelle ca ferait:
[[Fichier:Process-bash010.png.png|centré|sans_cadre|1017x1017px]]

Où même (vue de près)
[[Fichier:Swapzoom.png.png|centré|sans_cadre|620x620px]]

C'est puissant mais est-ce vraiment clair...

Donc la formule magique c'est : <code>3>&1 1>&2 2>&3</code> !

== Forme simplifiée en bash. ==
Les commandes ci dessus fonctionnent avec bash mais fonctionnent avec n'importe quel bourne shell.

[[Fichier:Sh ksh bash.png|sans_cadre|392x392px]]

Mais on l'a vu la syntaxe est "obscure".

'''''<big>bash</big>''''' nous propose une syntaxe plus élégante :

* <code>> >(commande)</code> envoie la sortie standard à <code>commande</code> (pour le coup équivalent a un <code>|</code>).

Mais on comprends la syntaxe avec :

* 2> >(commande) qui envoie la sortie d'erreur à <code>commande</code>. Pour le coup c'est plus lisible que <code>3>&1 1>&2 2>&3</code>

Ca permet, en une ligne de faire une commande dont stdout est traité par un filtre et stdout par un autre:<syntaxhighlight lang="bash">./stdtest \
> >(./filtre-bleu) \
2> >(./filtre-rouge >&2)</syntaxhighlight>[[Fichier:Bash-complex-filters.png.png|sans_cadre|482x482px]]

Ce mécanisme fonctionne avec bash, ksh, zsh (j'ai pas testé mais il parait) en sh de base ca ne marche pas. J'ai essayé des combinaisons avec <code>3>&1 1>&2 2>&3</code> et même avec un flux 4 de plus mais j'y suis pas arrivé.

La seule solution sh que je sois arrivé a faire marcher ce sont les ''pipes nommées'':<syntaxhighlight lang="sh">mkfifo fifo_out fifo_err

./filtre-bleu < fifo_out &
./filtre-rouge < fifo_err >&2 &

./stdtest > fifo_out 2> fifo_err

rm fifo_out fifo_err</syntaxhighlight>

* On crée deux FIFO des espèces de faux fichiers dans lesquels on ne peut que lire dans l'ordre ce qu'on y à écrit.<code>mkfifo fifo_out fifo_err</code>
* On lance deux taches en background qui envoient
** tout ce qui sort de <code>fifo_out</code> dans <code>./filtre-bleu</code>
** tout ce qui sort de <code>fifo_err</code> dans <code>./filtre-rouge</code>

* On lance notre commande en redirigeant <code>stdout</code> dans <code>fifo_out</code> et <code>stderr</code> dans <code>fifo_err</code>
* On efface nos pipes nommées (ça termine en même temps les deux tâches qui y étaient attachées)

[[Fichier:Namedfifo.png.png|sans_cadre|571x571px]]

Fichier:Namedfifo.png.png

2026-08-07T07:55:06Z

Jpinon :

pipes nommees

Fichier:Bash-complex-filters.png.png

2026-08-07T07:37:57Z

Jpinon :

les filtres complexes en bash

Fichier:Sh ksh bash.png

2026-08-07T07:30:30Z

Jpinon :

bourne shell

Redirections bash (et en bourne shell en géneral)

2026-08-07T07:11:47Z

Jpinon : /* x>&x généralisation de l'opérateur */

Redirections bash (et en bourne shell en géneral)

2026-08-07T07:08:31Z

Jpinon : /* x>&x généralisation de l'opérateur */

Les redirections c'est la base des batches !

== Echanges standard entre un process et son environnement. ==
Un process (process ou processus en français j'utiliserais les deux mots indéférament) est une suite d'instructions qui sont exécutées par le système les unes après les autres. Il n'y a pas de notion de parallélisme à ce niveau.

A sa création un process possède trois "flux" standard.

* Une entrée
* deux sorties (normal et erreurs)

[[Fichier:Process-bash000.png|sans_cadre|492x492px]]

Si rien n'est précisé l'entrée standard est le clavier et les deux sorties (standard et erreur sont l'écran)

[[Fichier:Process-bash001.png|sans_cadre|750x750px]]

Déjà, de façon, transparente ce clavier et cet écrans sont transformés dans le cas du ssh (ou du telnet). Dans ce cas les entrées sorties sont redirigées vers le réseau lui même ver le client ssh qui... finalement l'envoie à un clavier et un écran même si ce n'est pas celui de ma machine sur laquelle tourne le processus.

Un exemple typique : un simple ls.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
$ ls rrr
ls: cannot access 'rrr': No such file or directory
$
</syntaxhighlight>Le premier ls ci dessus envoie sa sortie standard vers l'écran (le flux en bleu sur le schéma). Dans le cas second ls, il s'agit d'une erreur donc vers la sortie d'erreur (flux en rouge).

Il est impossible, pour le moment, de savoir si ce qui est à l'écran a été envoyé vers la sortie standard ou la sortie d'erreur. (sauf le bon sens)

Pour le cas de l'entrée standard l'exemple est plus subtil, on va utiliser grep. grep est un programme assez simple (bon il a plein d'options mais on en parlera pas là) il lit l'entrée standard ligne par ligne et ne l'affiche sur la sortie que si elle comprends un chaine donnée en paramètre.<syntaxhighlight lang="bash">
$ grep toto
Bonjour toi
Bonjour vous
Hello toto
Hello toto
Ca va toto?
Ca va toto?
au revoir toto
au revoir toto
salut
</syntaxhighlight>le shell envoie aussi à l'écran ce que l'on tape au clavier avant de l'envoyer au programme (il appelle ca l'écho).

que se passe t'il dans notre exemple? On entre le ligne <code>"Bonjour toi"</code>. Le shell l'envoie à l'écran et au process (grep). grep lit la ligne<code>"Bonjour toi"</code>et vérifie si elle contient la chaine qu'on lui a donné en paramètre <code>"toto"</code>. Ce n'est pas le cas, grep ignore la ligne. Il se passe la même chose pour <code>"Bonjour vous"</code>. En revanche pour <code>"Hello toto"</code> le shell l'envoie a l'écran (echo) et à grep. Grep voit qu'elle contient bien la chaine <code>"toto",</code> alors elle écrit la ligne sur la sortie standard.

Donc on voit la ligne en double. D'abord l'echo de ce qu'on tape ensuite la sortie de grep.

== Redirections des flux standards ==
L'un des concepts les puis puissant du shell unix (linux par la suite) est que ces 3 flux peuvent êtres branchées sur n'importe quoi d'autre (on vient d'effleurer le sujet avec ssh).

=== Les types de redirections ===

==== redirection entre process ====
c'est la redirection de la sortie d'un process vers l'entrée d'un autre. Ca s'appelle un 'pipe' (un tube, un tuyau... )

[[Fichier:Process-bash002.png|sans_cadre|916x916px]]

Pour chainer ainsi deux process on utilise le caractère "pipe" soit <code>"|"</code>.
Il s'agit d'une barre verticale qui semble être un tuyau dans le mauvais sens. Il faut connaitre comment les premières machines affichaient ce caractère : pas <code>"|"</code> mais <code>"¦"</code>.

Une barre avec un petit trou pour laisser passer le flux. Ce caractère à été simplifié et maintenant et on ne comprends plus bien.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
$ ls -l | grep toto
$ ls -l | grep "c"
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>La première commande est un bête ls qui donne la liste des fichiers.
La seconde filtre ces lignes pour n'afficher que les lignes contenant la chaine <code>"toto"</code>.. c'est à dire aucune.
La troisième filtre les lignes pour n'afficher que celles contenant <code>"c"</code> c'est a dire deux d'entres elles.

Attention on parle là de flux de caractères. Les redirections et les process de ces exemples ne "comprennent" pas ce qu'on leur envoie dans les flux.
si on avait utilisé grep avec <code>"n":</code><syntaxhighlight lang="bash">
$ ls -l | grep "n"
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>Aucun fichier ne contient de <code>"n"</code> mais grep traite le flux ligne de texte par ligne de texte. Il trouve des <code>"n"</code> dans le nom du user et du groupe il affiche la ligne.
Nous ne sommes pas dans des shell type powershell qui traitent des objets. Ici on traite des flux de caractres est bête et méchants.

'''<big>SECTION Pour les experts</big>''' (qui connaissent [[strace]]).

'''Vous êtes débutant passez cette section vous y reviendrez plus tard!'''<syntaxhighlight lang="bash">strace -e openat grep "toto" resultat.txt</syntaxhighlight>Nous donne bien une ligne:<syntaxhighlight lang="text">
openat(AT_FDCWD, "resultat.txt", O_RDONLY|O_NOCTTY) = 3
</syntaxhighlight>C'est bien le process "grep" qui ouvre le fichier <code>resultat.txt</code>.

Mais si on fait :<syntaxhighlight lang="bash">
cat toto | strace -e openat grep "toto"
</syntaxhighlight>pas de lignes d'ouverture de resultat.txt dans grep. C'est cat qui ouvre le ficher!

SI on trace ce que fait cat et pas ce que fait grep:<syntaxhighlight lang="bash">
strace -e openat cat resultat.txt | grep "toto"
</syntaxhighlight>On récupère bien notre ligne<syntaxhighlight lang="text">
openat(AT_FDCWD, "resultat.txt", O_RDONLY) = 3
</syntaxhighlight>Si on fait :<syntaxhighlight lang="bash">
strace -e openat cat < resultat.txt | grep "toto"
</syntaxhighlight>On ne voit plus rien car c'est bash qui ouvre le fichier pour l'envoyer a cat (voir plus loin)

'''<big>FIN DE SECTION EXPERTS</big>'''

==== Fichiers ====

==== ">" Rediriger la sortie standard vers un fichier ====
Autant <code>"|"</code> dirige la sortie d'un processus vers l'entrée d'un autre processus <code>">"</code> redirige simplement la sortie standard d'un process vers un fichier disque.

Exemple simple un simple ls.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>La commande ls envoie la liste des fichier vers la sortie standard. Jusque là on n'a rien fait!<syntaxhighlight lang="bash">$ ls -l > resultat.txt</syntaxhighlight>Cette commande ne réponds rien et c'est normal. On lui a demandé de rediriger la sortie standard vers un fichier <code>"resultat.txt"</code>

Si on refait un ls.<syntaxhighlight lang="bash">$ ls -l
total 48
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
-rw-r--r-- 1 jpinon jpinon 344 Aug 5 23:21 resultat.txt</syntaxhighlight>Effectivement on a un nouveau fichier!

SI on regarde ce qu'il i a dedans (cat, vi, nano... chacun sa méthode) mais on y trouve :<syntaxhighlight lang="text">
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
-rw-r--r-- 1 jpinon jpinon 0 Aug 5 23:21 resultat.txt
</syntaxhighlight>On remarque que <code>"resultat.txt"</code> est déjà dedans mais avec une taille nulle. Etrange? pas tant que ça et ca nous montre bien comment ça se passe.

Lors de la commande <code>"ls -l > resultat.txt"</code> le shell (bash ici) voit que la sortie de <code>ls</code> devra aller dans un fichier <code>"resultat.txt"</code> qu'il s'empresse de créer mais, pour le moment, il est vide. Le shell lance alors le <code>"ls -l"</code> qui fait la liste des fichiers, dont resultat.txt qui est vide, et l'envoie dans le fichier "resultat.txt" qui se remplis alors.

A la sortie resultat.txt est donc plein mais, quand il a été lut par ls il était vide!

'''Tout est simple et logique en bash!'''

==== ">>" Pour pas tout casser ====
La redirection > envoie dans un fichier le contenu de la sortie standard d'un process. Cependant si ce fichier existe il sera écrasé par le contenu en question. Ce n'est pas toujours ce que l'on souhaite!

On veut parfois "ajouter à la fin". <syntaxhighlight lang="bash">
echo "Etat des disques" > status.txt
df -h >> status.txt
</syntaxhighlight>On crée un fichier contenant la ligne "etat des disques" et on y ajoute le résultat de <code>df -h</code>.

J'i mon petit script de création de fichier python vide:<syntaxhighlight lang="bash">
# fichier create-py.sh
echo -n "#!" > $1.py
which python3 >> $1.py
echo "" >> $1.py
echo -n "# " >> $1.py
date "+created on %Y-%m-%d@%H:%M by $USER" >> test.py
chmod a+x $1.py

</syntaxhighlight>On l'appelle avec :<syntaxhighlight lang="bash">./create-py test</syntaxhighlight>... et on a un test.py :<syntaxhighlight lang="python3">
#!/usr/bin/python3
# created on 2026-08-06@01:00 by jpinon
</syntaxhighlight>Correctement configuré pour être lancé directement à la ligne de commande. Il reste plus qu'à....

==== "<" rediriger un fichier vers l'entrée standard d'un process. ====
C'est la partie la moins élégante de la syntaxe je trouve mais bon. On peut utiliser un fichier comme l'entrée d'un process.

C'est assez rarement utilisé parce que'à la fois pas clair et pas très utile. Suivez moi bien:<syntaxhighlight lang="bash">
cat
</syntaxhighlight>affiche le résultat de l'entrée standard sur la sortie standard. Le truc le plus inutile possible!<syntaxhighlight lang="bash">
$ cat
hello
hello
bonjour
bonjour
jaquot
jaquot
blabla
blabla
</syntaxhighlight>Ca répète tout ce qu'on tape jusqu'à la fin du texte (EOF ou <Ctrl> D)

si on voulait lui faire écrire ce qu'il y a dans un fichier on sait qu'il faut faire :<syntaxhighlight lang="bash">
cat resultat.txt
</syntaxhighlight>Ca marche mais c'est pas ce que je veux vous montrer. C'est juste le fonctionnement de la commande <code>cat</code>. SI on lui donne un paramètre au lieu de copier l'entrée standard elle prends le paramètre en question, ouvre le fichier disque qui correspond de l'envoie sur la sortie standard. Là c'est le programme <code>cat</code> qui fait le travail.

Si on fait :<syntaxhighlight lang="bash">cat < resultat.txt # Attention un < s'est introduit dans cette commande!</syntaxhighlight>le résultat est exactement le même mais les actions effectuées sont totalement différentes!

Que fait le shell?

* Il ouvre <code>cat</code> sans paramètres qui va alors lire les lignes une par une sur l'entrée standard et les envoyer sur la sortie standard jusqu'à EOF. Il est bête mais on lui en demande pas plus.
* Mais le shell vois aussi que l'entrée standard de cat doit être "alimentée", non pas par le clavier mais par le contenu d'un fichier "resultat.txt"
* doc cat prends ce qu'il a en entrée (le shell lui envoie le contenu de resultat.txt) et l'envoie sur la sortie standard (ici l'écran)

On pourrait envisager un:<syntaxhighlight lang="bash">
cat < resultat.txt > resultat1.txt
</syntaxhighlight>...qui en fait est l'équivalant d'une copie de <code>resultat.txt</code> vers <code>resultat1.txt</code>.<syntaxhighlight lang="bash">
cp resultat1 resultat2
</syntaxhighlight>aurait fait pareil.

Encore plus pervère<syntaxhighlight lang="bash">
cat < resultat.txt | grep jpinon > resultat2.txt
</syntaxhighlight>Le shell traite comme ça:

* ouverture de <code>cat</code> "tout nu" qui lit sur l'entrée et envoie vers la sortie
* son entrée est connectée par shell sur le fichier <code>resultat.txt</code>. Ok, donc cat ne le sait pas mais il lit les lignes de <code>resultat.txt</code> une par une (c'est le shell qui les lui envoie).
* <code>cat</code> ecrit vers sa sortie standars mais le shell la redirrige vers <code>grep</code>.
* <code>grep</code> est presque aussi bête que <code>cat</code>. Il lit des lignes sur son entrée standard et les sort sur la sur la sortie standard pour peu que la ligne contienne la chaine en paramètre
* mais le shell est malin, il lui envoie sur son entrée standard la sortie de <code>cat</code>.
* a la fin le shell détourne la sortie de <code>grep</code> vers <code>resultat2.txt</code>

Tout ca se résume dans :

[[Fichier:Process-bash004.png|sans_cadre|914x914px]]

==== Remarque sur l'usage de "-" ====
Quelquefois il est indispensable de donner un fichier à une commande. dans ce cas là on peut remplacer ne nom du fichier par <code>"-"</code>.

Par exemple :<syntaxhighlight lang="bash">
cat -
</syntaxhighlight>est équivalant à:<syntaxhighlight lang="bash">
cat
</syntaxhighlight>bon pas très utile. Mais pensons au compilateur cc. une option est de lui demander de juste s'arreter au code assembleur mais pas d'aller jusqu'au code machine.<syntaxhighlight lang="bash">
cc -S hello.c
</syntaxhighlight>va, par défaut nous sortir un fichier hello.s qui contient le code assembleur. Imaginons que l'on veuille avoir ce code assembleur pour l'envoyer à un ami mais on le voudrait "gzippé". Problème cc sait sortir dans un fichier texte, on peut lui donner le nom du fichier de sortie par l'option "-o fichier.s" mais il ne sait pas zipper.

On porait faire ça en deux commandes :<syntaxhighlight lang="bash">
cc -o code.s -S hello.c
gzip code.s
</syntaxhighlight>en sortie on aura un fichier code.s.gz tres bien mais on a appris a faire des redirections! Alors on en fait!<syntaxhighlight lang="bash">cc -o - -S hello.c | gzip > code.s.gz</syntaxhighlight>C'est pas beau!

Avec un beau dessin :

[[Fichier:Process-bash005.png|sans_cadre|916x916px]]

On pourrait même l'envoyer directement à notre amis. Ce fichier code.s.gz j'en ai pas besoin moi!<syntaxhighlight lang="bash">cc -o - -S hello.c | gzip | mail -s "le code assembleur de hello.c" monami@gmail.com</syntaxhighlight>[[Fichier:Process-bash006.png|sans_cadre|916x916px]]

Bon comme ça ca parait un peu inutile mais imaginez une tâche [[cron]] qui lance, tous les jours à 4h le matin la commande suivante:<syntaxhighlight lang="bash">
df -h | mail -s "Etat des disques" moi@mondomaine.fr
</syntaxhighlight>Et oui! tous les matin j'aurais l'état de remplissage des disque de ma machine dans mes mails. On pourrait améliorer avec un <code>grep</code> entre <code>df</code> et <code>mail</code> pour ne mentionner que les disques qui posent un problème.

=== Redirection du flux d'erreur ===
Pour le moment on se traine notre (nos) flux d'erreurs qui vont vers la console. C'est bien car, même quand les sortie standards sont redirigées on peut voir que ça s'est mal passé.

Imaginons que les erreurs suivent le même chemin que la sortie avec:<syntaxhighlight lang="bash">
cc -o - -S hello.c | gzip | mail -s "le code assembleur de hello.c" monami@gmail.com
</syntaxhighlight>imaginons une erreur de compilation (j'ai oublié le int devant le main()):<syntaxhighlight lang="bash">
$ cc -S hello.c
hello.c:3:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
3 | main(){
| ^~~~
$
</syntaxhighlight>Dans le cas présent ca m'affiche l'erreur et tout s'arrête après <code>cc</code>. J'aurais mon message et mon ami ne recevra pas de mail.

Si la sortie d'erreur était gérée par le même flux que la sortie standard, je ne m'apercevrais de rien et mon ami recevrait le mail avec le message d'erreur. La loose!

Et bien voila pourquoi la sortie standard est gérée a part.

==== 2> redirection vers un fichier. ====
Pour reprendre l'exemple ci dessus.<syntaxhighlight lang="bash">cc -S -o - hello.c 2> error.txt</syntaxhighlight>ca donne :

[[Fichier:Process-bash007.png|sans_cadre|1019x1019px]]

le code source est généré (par défaut pour <code>cc</code>) dans <code>stdout</code> et la sortie standard est dans <code>error.txt</code>

==== 2>> redirection (avec ajout) dans un fichier. ====
De la même façon que pour la sortie standard <code>>></code> la sortie erreur est redirigée vers un fichier mais en mode "append".<syntaxhighlight lang="bash">
cc -S -o - hello.c 2>> error.txt
</syntaxhighlight>les erreurs s'accumulent dans <code>error.txt</code>

==== Redirection de la sortie d'erreur dans un pipe. ====
La c'est le moment complexe de l'affaire!

Il n'y a pas d'opérateur de redirection 2| mais il y a des opérateurs redirige tel flux vers tel autre. Faut jouer avec.

===== 2>&1 Forcer stderr vers stdout =====
[[Fichier:Process-bash008.png|sans_cadre|1017x1017px]]<syntaxhighlight lang="bash">ls 2>&1</syntaxhighlight>On les erreurs et la sortie standard dans le même flux, ici ca sert pas a grand chose mais:<syntaxhighlight lang="bash">
df -h 2>&1 | mail -s "Etat du disque" moi@mondomaine.fr
</syntaxhighlight>C'est plus utile! On envoie un mail avec l'état des disques. Si il y a une erreur on a l'erreur dans le corps du mail aussi.

[[Fichier:Process-bash009..png|sans_cadre|1017x1017px]]

Le problème est que l'on ne peut plus traiter différemment stderr et stdout dans le flux "violet".

=== x>&x généralisation de l'opérateur ===

Tout d'abord pour tester on va écrire un petit programme en C.<syntaxhighlight lang="c">
// Programme stdtest.c
// On compilera avec cc -o stdtest stdtest.c
#include <stdio.h>

int main(void)
{
fprintf(stdout, "Message sur stdout\n");
fprintf(stderr, "Message sur stderr\n");

return 0;
}
</syntaxhighlight>Est-ce nécessaire de l'expliquer ? On envoie une ligne sur la sortie standard et une autre sur l'erreur standard.

On compile et on teste:<syntaxhighlight lang="bash">
$ ./stdtest
Message sur stdout
Message sur stderr
$ ./stdtest > /dev/null
Message sur stderr
$ ./stdtest 2> /dev/null
Message sur stdout

</syntaxhighlight>Ici j'introduit le fichier <code>/dev/null</code>. Quand on y envoie un flux il va.. nulle part.

Si on envoie <code>stdout</code> sur <code>/dev/null</code>, seul <code>seterr</code> s'affiche et si on y envoie <code>stderr</code> seul <code>stdout</code> s'affiche.

Et si on y envoie les deux :<syntaxhighlight lang="bash">
$ ./stdtest 2> /dev/null > /dev/null
$
</syntaxhighlight>Il ne se passe rien et c'est bien normal.

Maintenant regardons le fonctionnement de <code>grep</code>. Sur ma machine, <code>grep</code> est en fait un alias vers <code>grep --color=auto</code>. dans ce mode grep mets en couleur (rouge) la chaine qu'il a trouvé.

[[Fichier:Grep std.png|sans_cadre]]

Grep a "touché" stdout et on voit le rouge.

[[Fichier:Grep both.png|sans_cadre]]

L'opérateur 2>&1 redirige 2 (stderr vers 1 stdout). le grep lit les deux lignes, les deux sont en rouge.

Logiquement on se dit que 1>&2 devrait rediriger la sortie standard dans la sortie erreur.

[[Fichier:Stderrall.png|sans_cadre]]

Tout est envoyé dans stderr et grep qui est connecté a stdout ne voit rien!

Et le top du top :

[[Fichier:Avecflux3.png|sans_cadre]]

* <code>3>&1</code> : On crée un 3 qui envoie sur 1 (stdout)
* <code>1>&2</code> : On a déjà vu ca redirige la sortie standard dans la sortie erreur
* <code>2>&3</code> : Redirige la sortie d'erreur vers la sortie <code>3</code> qui a été initialisée pour envoyer vers <code>stdout</code> avant qu'on la redirige vers <code>stderr</code>.

On swappe les flux comme pour swapper le contenu de deux variables, il en faut une troisième.

Selon la représentation habituelle ca ferait:

[[Fichier:Process-bash010.png.png|sans_cadre|1017x1017px]]

Où même (vue de près)

[[Fichier:Swapzoom.png.png|sans_cadre|620x620px]]

C'est puissant mais est-ce vraiment clair...

Redirections bash (et en bourne shell en géneral)

2026-08-06T15:18:47Z

Jpinon :

Les redirections c'est la base des batches !

== Echanges standard entre un process et son environnement. ==
Un process (process ou processus en français j'utiliserais les deux mots indéférament) est une suite d'instructions qui sont exécutées par le système les unes après les autres. Il n'y a pas de notion de parallélisme à ce niveau.

A sa création un process possède trois "flux" standard.

* Une entrée
* deux sorties (normal et erreurs)

[[Fichier:Process-bash000.png|sans_cadre|492x492px]]

Si rien n'est précisé l'entrée standard est le clavier et les deux sorties (standard et erreur sont l'écran)

[[Fichier:Process-bash001.png|sans_cadre|750x750px]]

Déjà, de façon, transparente ce clavier et cet écrans sont transformés dans le cas du ssh (ou du telnet). Dans ce cas les entrées sorties sont redirigées vers le réseau lui même ver le client ssh qui... finalement l'envoie à un clavier et un écran même si ce n'est pas celui de ma machine sur laquelle tourne le processus.

Un exemple typique : un simple ls.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
$ ls rrr
ls: cannot access 'rrr': No such file or directory
$
</syntaxhighlight>Le premier ls ci dessus envoie sa sortie standard vers l'écran (le flux en bleu sur le schéma). Dans le cas second ls, il s'agit d'une erreur donc vers la sortie d'erreur (flux en rouge).

Il est impossible, pour le moment, de savoir si ce qui est à l'écran a été envoyé vers la sortie standard ou la sortie d'erreur. (sauf le bon sens)

Pour le cas de l'entrée standard l'exemple est plus subtil, on va utiliser grep. grep est un programme assez simple (bon il a plein d'options mais on en parlera pas là) il lit l'entrée standard ligne par ligne et ne l'affiche sur la sortie que si elle comprends un chaine donnée en paramètre.<syntaxhighlight lang="bash">
$ grep toto
Bonjour toi
Bonjour vous
Hello toto
Hello toto
Ca va toto?
Ca va toto?
au revoir toto
au revoir toto
salut
</syntaxhighlight>le shell envoie aussi à l'écran ce que l'on tape au clavier avant de l'envoyer au programme (il appelle ca l'écho).

que se passe t'il dans notre exemple? On entre le ligne <code>"Bonjour toi"</code>. Le shell l'envoie à l'écran et au process (grep). grep lit la ligne<code>"Bonjour toi"</code>et vérifie si elle contient la chaine qu'on lui a donné en paramètre <code>"toto"</code>. Ce n'est pas le cas, grep ignore la ligne. Il se passe la même chose pour <code>"Bonjour vous"</code>. En revanche pour <code>"Hello toto"</code> le shell l'envoie a l'écran (echo) et à grep. Grep voit qu'elle contient bien la chaine <code>"toto",</code> alors elle écrit la ligne sur la sortie standard.

Donc on voit la ligne en double. D'abord l'echo de ce qu'on tape ensuite la sortie de grep.

== Redirections des flux standards ==
L'un des concepts les puis puissant du shell unix (linux par la suite) est que ces 3 flux peuvent êtres branchées sur n'importe quoi d'autre (on vient d'effleurer le sujet avec ssh).

=== Les types de redirections ===

==== redirection entre process ====
c'est la redirection de la sortie d'un process vers l'entrée d'un autre. Ca s'appelle un 'pipe' (un tube, un tuyau... )

[[Fichier:Process-bash002.png|sans_cadre|916x916px]]

Pour chainer ainsi deux process on utilise le caractère "pipe" soit <code>"|"</code>.
Il s'agit d'une barre verticale qui semble être un tuyau dans le mauvais sens. Il faut connaitre comment les premières machines affichaient ce caractère : pas <code>"|"</code> mais <code>"¦"</code>.

Une barre avec un petit trou pour laisser passer le flux. Ce caractère à été simplifié et maintenant et on ne comprends plus bien.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
$ ls -l | grep toto
$ ls -l | grep "c"
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>La première commande est un bête ls qui donne la liste des fichiers.
La seconde filtre ces lignes pour n'afficher que les lignes contenant la chaine <code>"toto"</code>.. c'est à dire aucune.
La troisième filtre les lignes pour n'afficher que celles contenant <code>"c"</code> c'est a dire deux d'entres elles.

Attention on parle là de flux de caractères. Les redirections et les process de ces exemples ne "comprennent" pas ce qu'on leur envoie dans les flux.
si on avait utilisé grep avec <code>"n":</code><syntaxhighlight lang="bash">
$ ls -l | grep "n"
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>Aucun fichier ne contient de <code>"n"</code> mais grep traite le flux ligne de texte par ligne de texte. Il trouve des <code>"n"</code> dans le nom du user et du groupe il affiche la ligne.
Nous ne sommes pas dans des shell type powershell qui traitent des objets. Ici on traite des flux de caractres est bête et méchants.

'''<big>SECTION Pour les experts</big>''' (qui connaissent [[strace]]).

'''Vous êtes débutant passez cette section vous y reviendrez plus tard!'''<syntaxhighlight lang="bash">strace -e openat grep "toto" resultat.txt</syntaxhighlight>Nous donne bien une ligne:<syntaxhighlight lang="text">
openat(AT_FDCWD, "resultat.txt", O_RDONLY|O_NOCTTY) = 3
</syntaxhighlight>C'est bien le process "grep" qui ouvre le fichier <code>resultat.txt</code>.

Mais si on fait :<syntaxhighlight lang="bash">
cat toto | strace -e openat grep "toto"
</syntaxhighlight>pas de lignes d'ouverture de resultat.txt dans grep. C'est cat qui ouvre le ficher!

SI on trace ce que fait cat et pas ce que fait grep:<syntaxhighlight lang="bash">
strace -e openat cat resultat.txt | grep "toto"
</syntaxhighlight>On récupère bien notre ligne<syntaxhighlight lang="text">
openat(AT_FDCWD, "resultat.txt", O_RDONLY) = 3
</syntaxhighlight>Si on fait :<syntaxhighlight lang="bash">
strace -e openat cat < resultat.txt | grep "toto"
</syntaxhighlight>On ne voit plus rien car c'est bash qui ouvre le fichier pour l'envoyer a cat (voir plus loin)

'''<big>FIN DE SECTION EXPERTS</big>'''

==== Fichiers ====

==== ">" Rediriger la sortie standard vers un fichier ====
Autant <code>"|"</code> dirige la sortie d'un processus vers l'entrée d'un autre processus <code>">"</code> redirige simplement la sortie standard d'un process vers un fichier disque.

Exemple simple un simple ls.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>La commande ls envoie la liste des fichier vers la sortie standard. Jusque là on n'a rien fait!<syntaxhighlight lang="bash">$ ls -l > resultat.txt</syntaxhighlight>Cette commande ne réponds rien et c'est normal. On lui a demandé de rediriger la sortie standard vers un fichier <code>"resultat.txt"</code>

Si on refait un ls.<syntaxhighlight lang="bash">$ ls -l
total 48
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
-rw-r--r-- 1 jpinon jpinon 344 Aug 5 23:21 resultat.txt</syntaxhighlight>Effectivement on a un nouveau fichier!

SI on regarde ce qu'il i a dedans (cat, vi, nano... chacun sa méthode) mais on y trouve :<syntaxhighlight lang="text">
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
-rw-r--r-- 1 jpinon jpinon 0 Aug 5 23:21 resultat.txt
</syntaxhighlight>On remarque que <code>"resultat.txt"</code> est déjà dedans mais avec une taille nulle. Etrange? pas tant que ça et ca nous montre bien comment ça se passe.

Lors de la commande <code>"ls -l > resultat.txt"</code> le shell (bash ici) voit que la sortie de <code>ls</code> devra aller dans un fichier <code>"resultat.txt"</code> qu'il s'empresse de créer mais, pour le moment, il est vide. Le shell lance alors le <code>"ls -l"</code> qui fait la liste des fichiers, dont resultat.txt qui est vide, et l'envoie dans le fichier "resultat.txt" qui se remplis alors.

A la sortie resultat.txt est donc plein mais, quand il a été lut par ls il était vide!

'''Tout est simple et logique en bash!'''

==== ">>" Pour pas tout casser ====
La redirection > envoie dans un fichier le contenu de la sortie standard d'un process. Cependant si ce fichier existe il sera écrasé par le contenu en question. Ce n'est pas toujours ce que l'on souhaite!

On veut parfois "ajouter à la fin". <syntaxhighlight lang="bash">
echo "Etat des disques" > status.txt
df -h >> status.txt
</syntaxhighlight>On crée un fichier contenant la ligne "etat des disques" et on y ajoute le résultat de <code>df -h</code>.

J'i mon petit script de création de fichier python vide:<syntaxhighlight lang="bash">
# fichier create-py.sh
echo -n "#!" > $1.py
which python3 >> $1.py
echo "" >> $1.py
echo -n "# " >> $1.py
date "+created on %Y-%m-%d@%H:%M by $USER" >> test.py
chmod a+x $1.py

</syntaxhighlight>On l'appelle avec :<syntaxhighlight lang="bash">./create-py test</syntaxhighlight>... et on a un test.py :<syntaxhighlight lang="python3">
#!/usr/bin/python3
# created on 2026-08-06@01:00 by jpinon
</syntaxhighlight>Correctement configuré pour être lancé directement à la ligne de commande. Il reste plus qu'à....

==== "<" rediriger un fichier vers l'entrée standard d'un process. ====
C'est la partie la moins élégante de la syntaxe je trouve mais bon. On peut utiliser un fichier comme l'entrée d'un process.

C'est assez rarement utilisé parce que'à la fois pas clair et pas très utile. Suivez moi bien:<syntaxhighlight lang="bash">
cat
</syntaxhighlight>affiche le résultat de l'entrée standard sur la sortie standard. Le truc le plus inutile possible!<syntaxhighlight lang="bash">
$ cat
hello
hello
bonjour
bonjour
jaquot
jaquot
blabla
blabla
</syntaxhighlight>Ca répète tout ce qu'on tape jusqu'à la fin du texte (EOF ou <Ctrl> D)

si on voulait lui faire écrire ce qu'il y a dans un fichier on sait qu'il faut faire :<syntaxhighlight lang="bash">
cat resultat.txt
</syntaxhighlight>Ca marche mais c'est pas ce que je veux vous montrer. C'est juste le fonctionnement de la commande <code>cat</code>. SI on lui donne un paramètre au lieu de copier l'entrée standard elle prends le paramètre en question, ouvre le fichier disque qui correspond de l'envoie sur la sortie standard. Là c'est le programme <code>cat</code> qui fait le travail.

Si on fait :<syntaxhighlight lang="bash">cat < resultat.txt # Attention un < s'est introduit dans cette commande!</syntaxhighlight>le résultat est exactement le même mais les actions effectuées sont totalement différentes!

Que fait le shell?

* Il ouvre <code>cat</code> sans paramètres qui va alors lire les lignes une par une sur l'entrée standard et les envoyer sur la sortie standard jusqu'à EOF. Il est bête mais on lui en demande pas plus.
* Mais le shell vois aussi que l'entrée standard de cat doit être "alimentée", non pas par le clavier mais par le contenu d'un fichier "resultat.txt"
* doc cat prends ce qu'il a en entrée (le shell lui envoie le contenu de resultat.txt) et l'envoie sur la sortie standard (ici l'écran)

On pourrait envisager un:<syntaxhighlight lang="bash">
cat < resultat.txt > resultat1.txt
</syntaxhighlight>...qui en fait est l'équivalant d'une copie de <code>resultat.txt</code> vers <code>resultat1.txt</code>.<syntaxhighlight lang="bash">
cp resultat1 resultat2
</syntaxhighlight>aurait fait pareil.

Encore plus pervère<syntaxhighlight lang="bash">
cat < resultat.txt | grep jpinon > resultat2.txt
</syntaxhighlight>Le shell traite comme ça:

* ouverture de <code>cat</code> "tout nu" qui lit sur l'entrée et envoie vers la sortie
* son entrée est connectée par shell sur le fichier <code>resultat.txt</code>. Ok, donc cat ne le sait pas mais il lit les lignes de <code>resultat.txt</code> une par une (c'est le shell qui les lui envoie).
* <code>cat</code> ecrit vers sa sortie standars mais le shell la redirrige vers <code>grep</code>.
* <code>grep</code> est presque aussi bête que <code>cat</code>. Il lit des lignes sur son entrée standard et les sort sur la sur la sortie standard pour peu que la ligne contienne la chaine en paramètre
* mais le shell est malin, il lui envoie sur son entrée standard la sortie de <code>cat</code>.
* a la fin le shell détourne la sortie de <code>grep</code> vers <code>resultat2.txt</code>

Tout ca se résume dans :

[[Fichier:Process-bash004.png|sans_cadre|914x914px]]

==== Remarque sur l'usage de "-" ====
Quelquefois il est indispensable de donner un fichier à une commande. dans ce cas là on peut remplacer ne nom du fichier par <code>"-"</code>.

Par exemple :<syntaxhighlight lang="bash">
cat -
</syntaxhighlight>est équivalant à:<syntaxhighlight lang="bash">
cat
</syntaxhighlight>bon pas très utile. Mais pensons au compilateur cc. une option est de lui demander de juste s'arreter au code assembleur mais pas d'aller jusqu'au code machine.<syntaxhighlight lang="bash">
cc -S hello.c
</syntaxhighlight>va, par défaut nous sortir un fichier hello.s qui contient le code assembleur. Imaginons que l'on veuille avoir ce code assembleur pour l'envoyer à un ami mais on le voudrait "gzippé". Problème cc sait sortir dans un fichier texte, on peut lui donner le nom du fichier de sortie par l'option "-o fichier.s" mais il ne sait pas zipper.

On porait faire ça en deux commandes :<syntaxhighlight lang="bash">
cc -o code.s -S hello.c
gzip code.s
</syntaxhighlight>en sortie on aura un fichier code.s.gz tres bien mais on a appris a faire des redirections! Alors on en fait!<syntaxhighlight lang="bash">cc -o - -S hello.c | gzip > code.s.gz</syntaxhighlight>C'est pas beau!

Avec un beau dessin :

[[Fichier:Process-bash005.png|sans_cadre|916x916px]]

On pourrait même l'envoyer directement à notre amis. Ce fichier code.s.gz j'en ai pas besoin moi!<syntaxhighlight lang="bash">cc -o - -S hello.c | gzip | mail -s "le code assembleur de hello.c" monami@gmail.com</syntaxhighlight>[[Fichier:Process-bash006.png|sans_cadre|916x916px]]

Bon comme ça ca parait un peu inutile mais imaginez une tâche [[cron]] qui lance, tous les jours à 4h le matin la commande suivante:<syntaxhighlight lang="bash">
df -h | mail -s "Etat des disques" moi@mondomaine.fr
</syntaxhighlight>Et oui! tous les matin j'aurais l'état de remplissage des disque de ma machine dans mes mails. On pourrait améliorer avec un <code>grep</code> entre <code>df</code> et <code>mail</code> pour ne mentionner que les disques qui posent un problème.

=== Redirection du flux d'erreur ===
Pour le moment on se traine notre (nos) flux d'erreurs qui vont vers la console. C'est bien car, même quand les sortie standards sont redirigées on peut voir que ça s'est mal passé.

Imaginons que les erreurs suivent le même chemin que la sortie avec:<syntaxhighlight lang="bash">
cc -o - -S hello.c | gzip | mail -s "le code assembleur de hello.c" monami@gmail.com
</syntaxhighlight>imaginons une erreur de compilation (j'ai oublié le int devant le main()):<syntaxhighlight lang="bash">
$ cc -S hello.c
hello.c:3:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
3 | main(){
| ^~~~
$
</syntaxhighlight>Dans le cas présent ca m'affiche l'erreur et tout s'arrête après <code>cc</code>. J'aurais mon message et mon ami ne recevra pas de mail.

Si la sortie d'erreur était gérée par le même flux que la sortie standard, je ne m'apercevrais de rien et mon ami recevrait le mail avec le message d'erreur. La loose!

Et bien voila pourquoi la sortie standard est gérée a part.

==== 2> redirection vers un fichier. ====
Pour reprendre l'exemple ci dessus.<syntaxhighlight lang="bash">cc -S -o - hello.c 2> error.txt</syntaxhighlight>ca donne :

[[Fichier:Process-bash007.png|sans_cadre|1019x1019px]]

le code source est généré (par défaut pour <code>cc</code>) dans <code>stdout</code> et la sortie standard est dans <code>error.txt</code>

==== 2>> redirection (avec ajout) dans un fichier. ====
De la même façon que pour la sortie standard <code>>></code> la sortie erreur est redirigée vers un fichier mais en mode "append".<syntaxhighlight lang="bash">
cc -S -o - hello.c 2>> error.txt
</syntaxhighlight>les erreurs s'accumulent dans <code>error.txt</code>

==== Redirection de la sortie d'erreur dans un pipe. ====
La c'est le moment complexe de l'affaire!

Il n'y a pas d'opérateur de redirection 2| mais il y a des opérateurs redirige tel flux vers tel autre. Faut jouer avec.

===== 2>&1 Forcer stderr vers stdout =====
[[Fichier:Process-bash008.png|sans_cadre|1017x1017px]]<syntaxhighlight lang="bash">ls 2>&1</syntaxhighlight>On les erreurs et la sortie standard dans le même flux, ici ca sert pas a grand chose mais:<syntaxhighlight lang="bash">
df -h 2>&1 | mail -s "Etat du disque" moi@mondomaine.fr
</syntaxhighlight>C'est plus utile! On envoie un mail avec l'état des disques. Si il y a une erreur on a l'erreur dans le corps du mail aussi.

[[Fichier:Process-bash009..png|sans_cadre|1017x1017px]]

Le problème est que l'on ne peut plus traiter différemment stderr et stdout dans le flux "violet".

=== x>&x généralisation de l'opérateur ===

Tout d'abord pour tester on va écrire un petit programme en C.<syntaxhighlight lang="c">
// Programme stdtest.c
// On compilera avec cc -o stdtest stdtest.c
#include <stdio.h>

int main(void)
{
fprintf(stdout, "Message sur stdout\n");
fprintf(stderr, "Message sur stderr\n");

return 0;
}
</syntaxhighlight>Est-ce nécessaire de l'expliquer ? On envoie une ligne sur la sortie standard et une autre sur l'erreur standard.

On compile et on teste:<syntaxhighlight lang="bash">
$ ./stdtest
Message sur stdout
Message sur stderr
$ ./stdtest > /dev/null
Message sur stderr
$ ./stdtest 2> /dev/null
Message sur stdout

</syntaxhighlight>Ici j'introduit le fichier <code>/dev/null</code>. Quand on y envoie un flux il va.. nulle part.

Si on envoie <code>stdout</code> sur <code>/dev/null</code>, seul <code>seterr</code> s'affiche et si on y envoie <code>stderr</code> seul <code>stdout</code> s'affiche.

Et si on y envoie les deux :<syntaxhighlight lang="bash">
$ ./stdtest 2> /dev/null > /dev/null
$
</syntaxhighlight>Il ne se passe rien et c'est bien normal.

Maintenant regardons le fonctionnement de <code>grep</code>. Sur ma machine, <code>grep</code> est en fait un alias vers <code>grep --color=auto</code>. dans ce mode grep mets en couleur (rouge) la chaine qu'il a trouvé.

[[Fichier:Grep std.png|sans_cadre]]

Grep a "touché" stdout et on voit le rouge.

[[Fichier:Grep both.png|sans_cadre]]

L'opérateur 2>&1 redirige 2 (stderr vers 1 stdout). le grep lit les deux lignes, les deux sont en rouge.

Logiquement on se dit que 1>&2 devrait rediriger la sortie standard dans la sortie erreur.

[[Fichier:Stderrall.png|sans_cadre]]

Tout est envoyé dans stderr et grep qui est connecté a stdout ne voit rien!

Et le top du top :

[[Fichier:Avecflux3.png|sans_cadre]]

* <code>3>&1</code> : On crée un 3 qui envoie sur 1 (stdout)
* <code>1>&2</code> : On a déjà vu ca redirige la sortie standard dans la sortie erreur
* <code>2>&3</code> : Redirige la sortie d'erreur vers la sortie <code>3</code> qui a été initialisée pour envoyer vers <code>stdout</code> avant qu'on la redirige vers <code>stderr</code>.

On swappe les flux comme pour swapper le contenu de deux variables, il en faut une troisième.

Selon la représentation habituelle ca ferait:
[[Fichier:Process-bash010.png.png|sans_cadre|1017x1017px]]
Où même (vue de près)
[[Fichier:Swapzoom.png.png|sans_cadre|620x620px]]
C'est puissant mais est-ce vraiment clair...

Redirections bash (et en bourne shell en géneral)

2026-08-06T15:18:15Z

Jpinon : /* Redirection du flux d'erreur */

Les redirections c'est la base des batches !

== Echanges standard entre un process et son environnement. ==
Un process (process ou processus en français j'utiliserais les deux mots indéférament) est une suite d'instructions qui sont exécutées par le système les unes après les autres. Il n'y a pas de notion de parallélisme à ce niveau.

A sa création un process possède trois "flux" standard.

* Une entrée
* deux sorties (normal et erreurs)

[[Fichier:Process-bash000.png|sans_cadre|492x492px]]

Si rien n'est précisé l'entrée standard est le clavier et les deux sorties (standard et erreur sont l'écran)

[[Fichier:Process-bash001.png|sans_cadre|750x750px]]

Déjà, de façon, transparente ce clavier et cet écrans sont transformés dans le cas du ssh (ou du telnet). Dans ce cas les entrées sorties sont redirigées vers le réseau lui même ver le client ssh qui... finalement l'envoie à un clavier et un écran même si ce n'est pas celui de ma machine sur laquelle tourne le processus.

Un exemple typique : un simple ls.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
$ ls rrr
ls: cannot access 'rrr': No such file or directory
$
</syntaxhighlight>Le premier ls ci dessus envoie sa sortie standard vers l'écran (le flux en bleu sur le schéma). Dans le cas second ls, il s'agit d'une erreur donc vers la sortie d'erreur (flux en rouge).

Il est impossible, pour le moment, de savoir si ce qui est à l'écran a été envoyé vers la sortie standard ou la sortie d'erreur. (sauf le bon sens)

Pour le cas de l'entrée standard l'exemple est plus subtil, on va utiliser grep. grep est un programme assez simple (bon il a plein d'options mais on en parlera pas là) il lit l'entrée standard ligne par ligne et ne l'affiche sur la sortie que si elle comprends un chaine donnée en paramètre.<syntaxhighlight lang="bash">
$ grep toto
Bonjour toi
Bonjour vous
Hello toto
Hello toto
Ca va toto?
Ca va toto?
au revoir toto
au revoir toto
salut
</syntaxhighlight>le shell envoie aussi à l'écran ce que l'on tape au clavier avant de l'envoyer au programme (il appelle ca l'écho).

que se passe t'il dans notre exemple? On entre le ligne <code>"Bonjour toi"</code>. Le shell l'envoie à l'écran et au process (grep). grep lit la ligne<code>"Bonjour toi"</code>et vérifie si elle contient la chaine qu'on lui a donné en paramètre <code>"toto"</code>. Ce n'est pas le cas, grep ignore la ligne. Il se passe la même chose pour <code>"Bonjour vous"</code>. En revanche pour <code>"Hello toto"</code> le shell l'envoie a l'écran (echo) et à grep. Grep voit qu'elle contient bien la chaine <code>"toto",</code> alors elle écrit la ligne sur la sortie standard.

Donc on voit la ligne en double. D'abord l'echo de ce qu'on tape ensuite la sortie de grep.

== Redirections des flux standards ==
L'un des concepts les puis puissant du shell unix (linux par la suite) est que ces 3 flux peuvent êtres branchées sur n'importe quoi d'autre (on vient d'effleurer le sujet avec ssh).

=== Les types de redirections ===

==== redirection entre process ====
c'est la redirection de la sortie d'un process vers l'entrée d'un autre. Ca s'appelle un 'pipe' (un tube, un tuyau... )

[[Fichier:Process-bash002.png|sans_cadre|916x916px]]

Pour chainer ainsi deux process on utilise le caractère "pipe" soit <code>"|"</code>.
Il s'agit d'une barre verticale qui semble être un tuyau dans le mauvais sens. Il faut connaitre comment les premières machines affichaient ce caractère : pas <code>"|"</code> mais <code>"¦"</code>.

Une barre avec un petit trou pour laisser passer le flux. Ce caractère à été simplifié et maintenant et on ne comprends plus bien.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
$ ls -l | grep toto
$ ls -l | grep "c"
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>La première commande est un bête ls qui donne la liste des fichiers.
La seconde filtre ces lignes pour n'afficher que les lignes contenant la chaine <code>"toto"</code>.. c'est à dire aucune.
La troisième filtre les lignes pour n'afficher que celles contenant <code>"c"</code> c'est a dire deux d'entres elles.

Attention on parle là de flux de caractères. Les redirections et les process de ces exemples ne "comprennent" pas ce qu'on leur envoie dans les flux.
si on avait utilisé grep avec <code>"n":</code><syntaxhighlight lang="bash">
$ ls -l | grep "n"
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>Aucun fichier ne contient de <code>"n"</code> mais grep traite le flux ligne de texte par ligne de texte. Il trouve des <code>"n"</code> dans le nom du user et du groupe il affiche la ligne.
Nous ne sommes pas dans des shell type powershell qui traitent des objets. Ici on traite des flux de caractres est bête et méchants.

'''<big>SECTION Pour les experts</big>''' (qui connaissent [[strace]]).

'''Vous êtes débutant passez cette section vous y reviendrez plus tard!'''<syntaxhighlight lang="bash">strace -e openat grep "toto" resultat.txt</syntaxhighlight>Nous donne bien une ligne:<syntaxhighlight lang="text">
openat(AT_FDCWD, "resultat.txt", O_RDONLY|O_NOCTTY) = 3
</syntaxhighlight>C'est bien le process "grep" qui ouvre le fichier <code>resultat.txt</code>.

Mais si on fait :<syntaxhighlight lang="bash">
cat toto | strace -e openat grep "toto"
</syntaxhighlight>pas de lignes d'ouverture de resultat.txt dans grep. C'est cat qui ouvre le ficher!

SI on trace ce que fait cat et pas ce que fait grep:<syntaxhighlight lang="bash">
strace -e openat cat resultat.txt | grep "toto"
</syntaxhighlight>On récupère bien notre ligne<syntaxhighlight lang="text">
openat(AT_FDCWD, "resultat.txt", O_RDONLY) = 3
</syntaxhighlight>Si on fait :<syntaxhighlight lang="bash">
strace -e openat cat < resultat.txt | grep "toto"
</syntaxhighlight>On ne voit plus rien car c'est bash qui ouvre le fichier pour l'envoyer a cat (voir plus loin)

'''<big>FIN DE SECTION EXPERTS</big>'''

==== Fichiers ====

==== ">" Rediriger la sortie standard vers un fichier ====
Autant <code>"|"</code> dirige la sortie d'un processus vers l'entrée d'un autre processus <code>">"</code> redirige simplement la sortie standard d'un process vers un fichier disque.

Exemple simple un simple ls.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>La commande ls envoie la liste des fichier vers la sortie standard. Jusque là on n'a rien fait!<syntaxhighlight lang="bash">$ ls -l > resultat.txt</syntaxhighlight>Cette commande ne réponds rien et c'est normal. On lui a demandé de rediriger la sortie standard vers un fichier <code>"resultat.txt"</code>

Si on refait un ls.<syntaxhighlight lang="bash">$ ls -l
total 48
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
-rw-r--r-- 1 jpinon jpinon 344 Aug 5 23:21 resultat.txt</syntaxhighlight>Effectivement on a un nouveau fichier!

SI on regarde ce qu'il i a dedans (cat, vi, nano... chacun sa méthode) mais on y trouve :<syntaxhighlight lang="text">
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
-rw-r--r-- 1 jpinon jpinon 0 Aug 5 23:21 resultat.txt
</syntaxhighlight>On remarque que <code>"resultat.txt"</code> est déjà dedans mais avec une taille nulle. Etrange? pas tant que ça et ca nous montre bien comment ça se passe.

Lors de la commande <code>"ls -l > resultat.txt"</code> le shell (bash ici) voit que la sortie de <code>ls</code> devra aller dans un fichier <code>"resultat.txt"</code> qu'il s'empresse de créer mais, pour le moment, il est vide. Le shell lance alors le <code>"ls -l"</code> qui fait la liste des fichiers, dont resultat.txt qui est vide, et l'envoie dans le fichier "resultat.txt" qui se remplis alors.

A la sortie resultat.txt est donc plein mais, quand il a été lut par ls il était vide!

'''Tout est simple et logique en bash!'''

==== ">>" Pour pas tout casser ====
La redirection > envoie dans un fichier le contenu de la sortie standard d'un process. Cependant si ce fichier existe il sera écrasé par le contenu en question. Ce n'est pas toujours ce que l'on souhaite!

On veut parfois "ajouter à la fin". <syntaxhighlight lang="bash">
echo "Etat des disques" > status.txt
df -h >> status.txt
</syntaxhighlight>On crée un fichier contenant la ligne "etat des disques" et on y ajoute le résultat de <code>df -h</code>.

J'i mon petit script de création de fichier python vide:<syntaxhighlight lang="bash">
# fichier create-py.sh
echo -n "#!" > $1.py
which python3 >> $1.py
echo "" >> $1.py
echo -n "# " >> $1.py
date "+created on %Y-%m-%d@%H:%M by $USER" >> test.py
chmod a+x $1.py

</syntaxhighlight>On l'appelle avec :<syntaxhighlight lang="bash">./create-py test</syntaxhighlight>... et on a un test.py :<syntaxhighlight lang="python3">
#!/usr/bin/python3
# created on 2026-08-06@01:00 by jpinon
</syntaxhighlight>Correctement configuré pour être lancé directement à la ligne de commande. Il reste plus qu'à....

==== "<" rediriger un fichier vers l'entrée standard d'un process. ====
C'est la partie la moins élégante de la syntaxe je trouve mais bon. On peut utiliser un fichier comme l'entrée d'un process.

C'est assez rarement utilisé parce que'à la fois pas clair et pas très utile. Suivez moi bien:<syntaxhighlight lang="bash">
cat
</syntaxhighlight>affiche le résultat de l'entrée standard sur la sortie standard. Le truc le plus inutile possible!<syntaxhighlight lang="bash">
$ cat
hello
hello
bonjour
bonjour
jaquot
jaquot
blabla
blabla
</syntaxhighlight>Ca répète tout ce qu'on tape jusqu'à la fin du texte (EOF ou <Ctrl> D)

si on voulait lui faire écrire ce qu'il y a dans un fichier on sait qu'il faut faire :<syntaxhighlight lang="bash">
cat resultat.txt
</syntaxhighlight>Ca marche mais c'est pas ce que je veux vous montrer. C'est juste le fonctionnement de la commande <code>cat</code>. SI on lui donne un paramètre au lieu de copier l'entrée standard elle prends le paramètre en question, ouvre le fichier disque qui correspond de l'envoie sur la sortie standard. Là c'est le programme <code>cat</code> qui fait le travail.

Si on fait :<syntaxhighlight lang="bash">cat < resultat.txt # Attention un < s'est introduit dans cette commande!</syntaxhighlight>le résultat est exactement le même mais les actions effectuées sont totalement différentes!

Que fait le shell?

* Il ouvre <code>cat</code> sans paramètres qui va alors lire les lignes une par une sur l'entrée standard et les envoyer sur la sortie standard jusqu'à EOF. Il est bête mais on lui en demande pas plus.
* Mais le shell vois aussi que l'entrée standard de cat doit être "alimentée", non pas par le clavier mais par le contenu d'un fichier "resultat.txt"
* doc cat prends ce qu'il a en entrée (le shell lui envoie le contenu de resultat.txt) et l'envoie sur la sortie standard (ici l'écran)

On pourrait envisager un:<syntaxhighlight lang="bash">
cat < resultat.txt > resultat1.txt
</syntaxhighlight>...qui en fait est l'équivalant d'une copie de <code>resultat.txt</code> vers <code>resultat1.txt</code>.<syntaxhighlight lang="bash">
cp resultat1 resultat2
</syntaxhighlight>aurait fait pareil.

Encore plus pervère<syntaxhighlight lang="bash">
cat < resultat.txt | grep jpinon > resultat2.txt
</syntaxhighlight>Le shell traite comme ça:

* ouverture de <code>cat</code> "tout nu" qui lit sur l'entrée et envoie vers la sortie
* son entrée est connectée par shell sur le fichier <code>resultat.txt</code>. Ok, donc cat ne le sait pas mais il lit les lignes de <code>resultat.txt</code> une par une (c'est le shell qui les lui envoie).
* <code>cat</code> ecrit vers sa sortie standars mais le shell la redirrige vers <code>grep</code>.
* <code>grep</code> est presque aussi bête que <code>cat</code>. Il lit des lignes sur son entrée standard et les sort sur la sur la sortie standard pour peu que la ligne contienne la chaine en paramètre
* mais le shell est malin, il lui envoie sur son entrée standard la sortie de <code>cat</code>.
* a la fin le shell détourne la sortie de <code>grep</code> vers <code>resultat2.txt</code>

Tout ca se résume dans :

[[Fichier:Process-bash004.png|sans_cadre|914x914px]]

==== Remarque sur l'usage de "-" ====
Quelquefois il est indispensable de donner un fichier à une commande. dans ce cas là on peut remplacer ne nom du fichier par <code>"-"</code>.

Par exemple :<syntaxhighlight lang="bash">
cat -
</syntaxhighlight>est équivalant à:<syntaxhighlight lang="bash">
cat
</syntaxhighlight>bon pas très utile. Mais pensons au compilateur cc. une option est de lui demander de juste s'arreter au code assembleur mais pas d'aller jusqu'au code machine.<syntaxhighlight lang="bash">
cc -S hello.c
</syntaxhighlight>va, par défaut nous sortir un fichier hello.s qui contient le code assembleur. Imaginons que l'on veuille avoir ce code assembleur pour l'envoyer à un ami mais on le voudrait "gzippé". Problème cc sait sortir dans un fichier texte, on peut lui donner le nom du fichier de sortie par l'option "-o fichier.s" mais il ne sait pas zipper.

On porait faire ça en deux commandes :<syntaxhighlight lang="bash">
cc -o code.s -S hello.c
gzip code.s
</syntaxhighlight>en sortie on aura un fichier code.s.gz tres bien mais on a appris a faire des redirections! Alors on en fait!<syntaxhighlight lang="bash">cc -o - -S hello.c | gzip > code.s.gz</syntaxhighlight>C'est pas beau!

Avec un beau dessin :

[[Fichier:Process-bash005.png|sans_cadre|916x916px]]

On pourrait même l'envoyer directement à notre amis. Ce fichier code.s.gz j'en ai pas besoin moi!<syntaxhighlight lang="bash">cc -o - -S hello.c | gzip | mail -s "le code assembleur de hello.c" monami@gmail.com</syntaxhighlight>[[Fichier:Process-bash006.png|sans_cadre|916x916px]]

Bon comme ça ca parait un peu inutile mais imaginez une tâche [[cron]] qui lance, tous les jours à 4h le matin la commande suivante:<syntaxhighlight lang="bash">
df -h | mail -s "Etat des disques" moi@mondomaine.fr
</syntaxhighlight>Et oui! tous les matin j'aurais l'état de remplissage des disque de ma machine dans mes mails. On pourrait améliorer avec un <code>grep</code> entre <code>df</code> et <code>mail</code> pour ne mentionner que les disques qui posent un problème.

=== Redirection du flux d'erreur ===
Pour le moment on se traine notre (nos) flux d'erreurs qui vont vers la console. C'est bien car, même quand les sortie standards sont redirigées on peut voir que ça s'est mal passé.

Imaginons que les erreurs suivent le même chemin que la sortie avec:<syntaxhighlight lang="bash">
cc -o - -S hello.c | gzip | mail -s "le code assembleur de hello.c" monami@gmail.com
</syntaxhighlight>imaginons une erreur de compilation (j'ai oublié le int devant le main()):<syntaxhighlight lang="bash">
$ cc -S hello.c
hello.c:3:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
3 | main(){
| ^~~~
$
</syntaxhighlight>Dans le cas présent ca m'affiche l'erreur et tout s'arrête après <code>cc</code>. J'aurais mon message et mon ami ne recevra pas de mail.

Si la sortie d'erreur était gérée par le même flux que la sortie standard, je ne m'apercevrais de rien et mon ami recevrait le mail avec le message d'erreur. La loose!

Et bien voila pourquoi la sortie standard est gérée a part.

==== 2> redirection vers un fichier. ====
Pour reprendre l'exemple ci dessus.<syntaxhighlight lang="bash">cc -S -o - hello.c 2> error.txt</syntaxhighlight>ca donne :

[[Fichier:Process-bash007.png|sans_cadre|1019x1019px]]

le code source est généré (par défaut pour <code>cc</code>) dans <code>stdout</code> et la sortie standard est dans <code>error.txt</code>

==== 2>> redirection (avec ajout) dans un fichier. ====
De la même façon que pour la sortie standard <code>>></code> la sortie erreur est redirigée vers un fichier mais en mode "append".<syntaxhighlight lang="bash">
cc -S -o - hello.c 2>> error.txt
</syntaxhighlight>les erreurs s'accumulent dans <code>error.txt</code>

==== Redirection de la sortie d'erreur dans un pipe. ====
La c'est le moment complexe de l'affaire!

Il n'y a pas d'opérateur de redirection 2| mais il y a des opérateurs redirige tel flux vers tel autre. Faut jouer avec.

===== 2>&1 Forcer stderr vers stdout =====
[[Fichier:Process-bash008.png|sans_cadre|1017x1017px]]<syntaxhighlight lang="bash">ls 2>&1</syntaxhighlight>On les erreurs et la sortie standard dans le même flux, ici ca sert pas a grand chose mais:<syntaxhighlight lang="bash">
df -h 2>&1 | mail -s "Etat du disque" moi@mondomaine.fr
</syntaxhighlight>C'est plus utile! On envoie un mail avec l'état des disques. Si il y a une erreur on a l'erreur dans le corps du mail aussi.

[[Fichier:Process-bash009..png|sans_cadre|1017x1017px]]

Le problème est que l'on ne peut plus traiter différemment stderr et stdout dans le flux "violet".

===== x>&x généralisation de l'opérateur =====
Tout d'abord pour tester on va écrire un petit programme en C.<syntaxhighlight lang="c">
// Programme stdtest.c
// On compilera avec cc -o stdtest stdtest.c
#include <stdio.h>

int main(void)
{
fprintf(stdout, "Message sur stdout\n");
fprintf(stderr, "Message sur stderr\n");

return 0;
}
</syntaxhighlight>Est-ce nécessaire de l'expliquer ? On envoie une ligne sur la sortie standard et une autre sur l'erreur standard.

On compile et on teste:<syntaxhighlight lang="bash">
$ ./stdtest
Message sur stdout
Message sur stderr
$ ./stdtest > /dev/null
Message sur stderr
$ ./stdtest 2> /dev/null
Message sur stdout

</syntaxhighlight>Ici j'introduit le fichier <code>/dev/null</code>. Quand on y envoie un flux il va.. nulle part.

Si on envoie <code>stdout</code> sur <code>/dev/null</code>, seul <code>seterr</code> s'affiche et si on y envoie <code>stderr</code> seul <code>stdout</code> s'affiche.

Et si on y envoie les deux :<syntaxhighlight lang="bash">
$ ./stdtest 2> /dev/null > /dev/null
$
</syntaxhighlight>Il ne se passe rien et c'est bien normal.

Maintenant regardons le fonctionnement de <code>grep</code>. Sur ma machine, <code>grep</code> est en fait un alias vers <code>grep --color=auto</code>. dans ce mode grep mets en couleur (rouge) la chaine qu'il a trouvé.

[[Fichier:Grep std.png|sans_cadre]]

Grep a "touché" stdout et on voit le rouge.

[[Fichier:Grep both.png|sans_cadre]]

L'opérateur 2>&1 redirige 2 (stderr vers 1 stdout). le grep lit les deux lignes, les deux sont en rouge.

Logiquement on se dit que 1>&2 devrait rediriger la sortie standard dans la sortie erreur.

[[Fichier:Stderrall.png|sans_cadre]]

Tout est envoyé dans stderr et grep qui est connecté a stdout ne voit rien!

Et le top du top :

[[Fichier:Avecflux3.png|sans_cadre]]

* <code>3>&1</code> : On crée un 3 qui envoie sur 1 (stdout)
* <code>1>&2</code> : On a déjà vu ca redirige la sortie standard dans la sortie erreur
* <code>2>&3</code> : Redirige la sortie d'erreur vers la sortie <code>3</code> qui a été initialisée pour envoyer vers <code>stdout</code> avant qu'on la redirige vers <code>stderr</code>.

On swappe les flux comme pour swapper le contenu de deux variables, il en faut une troisième.

Selon la représentation habituelle ca ferait:
[[Fichier:Process-bash010.png.png|sans_cadre|1017x1017px]]
Où même (vue de près)
[[Fichier:Swapzoom.png.png|sans_cadre|620x620px]]
C'est puissant mais est-ce vraiment clair...

Fichier:Swapzoom.png.png

2026-08-06T15:17:07Z

Jpinon :

swapzoom

Fichier:Process-bash010.png.png

2026-08-06T15:05:39Z

Jpinon :

swap strem

Fichier:Avecflux3.png

2026-08-06T14:51:56Z

Jpinon :

flux 3

Fichier:Stderrall.png

2026-08-06T14:44:35Z

Jpinon :

tout

Fichier:Grep both.png

2026-08-06T14:41:24Z

Jpinon :

tout

Fichier:Grep std.png

2026-08-06T14:39:03Z

Jpinon :

grep std

Fichier:Process-bash009..png

2026-08-06T14:16:27Z

Jpinon :

2>&1 | mail

Fichier:Process-bash008.png

2026-08-06T14:05:01Z

Jpinon :

2>&1

Fichier:Process-bash007.png

2026-08-06T12:12:47Z

Jpinon :

redirrection stderr vers fichier

Redirections bash (et en bourne shell en géneral)

2026-08-06T11:35:06Z

Jpinon : /* Remarque sur l'usage de "-" */

Les redirections c'est la base des batches !

== Echanges standard entre un process et son environnement. ==
Un process (process ou processus en français j'utiliserais les deux mots indéférament) est une suite d'instructions qui sont exécutées par le système les unes après les autres. Il n'y a pas de notion de parallélisme à ce niveau.

A sa création un process possède trois "flux" standard.

* Une entrée
* deux sorties (normal et erreurs)

[[Fichier:Process-bash000.png|sans_cadre|492x492px]]

Si rien n'est précisé l'entrée standard est le clavier et les deux sorties (standard et erreur sont l'écran)

[[Fichier:Process-bash001.png|sans_cadre|750x750px]]

Déjà, de façon, transparente ce clavier et cet écrans sont transformés dans le cas du ssh (ou du telnet). Dans ce cas les entrées sorties sont redirigées vers le réseau lui même ver le client ssh qui... finalement l'envoie à un clavier et un écran même si ce n'est pas celui de ma machine sur laquelle tourne le processus.

Un exemple typique : un simple ls.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
$ ls rrr
ls: cannot access 'rrr': No such file or directory
$
</syntaxhighlight>Le premier ls ci dessus envoie sa sortie standard vers l'écran (le flux en bleu sur le schéma). Dans le cas second ls, il s'agit d'une erreur donc vers la sortie d'erreur (flux en rouge).

Il est impossible, pour le moment, de savoir si ce qui est à l'écran a été envoyé vers la sortie standard ou la sortie d'erreur. (sauf le bon sens)

Pour le cas de l'entrée standard l'exemple est plus subtil, on va utiliser grep. grep est un programme assez simple (bon il a plein d'options mais on en parlera pas là) il lit l'entrée standard ligne par ligne et ne l'affiche sur la sortie que si elle comprends un chaine donnée en paramètre.<syntaxhighlight lang="bash">
$ grep toto
Bonjour toi
Bonjour vous
Hello toto
Hello toto
Ca va toto?
Ca va toto?
au revoir toto
au revoir toto
salut
</syntaxhighlight>le shell envoie aussi à l'écran ce que l'on tape au clavier avant de l'envoyer au programme (il appelle ca l'écho).

que se passe t'il dans notre exemple? On entre le ligne <code>"Bonjour toi"</code>. Le shell l'envoie à l'écran et au process (grep). grep lit la ligne<code>"Bonjour toi"</code>et vérifie si elle contient la chaine qu'on lui a donné en paramètre <code>"toto"</code>. Ce n'est pas le cas, grep ignore la ligne. Il se passe la même chose pour <code>"Bonjour vous"</code>. En revanche pour <code>"Hello toto"</code> le shell l'envoie a l'écran (echo) et à grep. Grep voit qu'elle contient bien la chaine <code>"toto",</code> alors elle écrit la ligne sur la sortie standard.

Donc on voit la ligne en double. D'abord l'echo de ce qu'on tape ensuite la sortie de grep.

== Redirections des flux standards ==
L'un des concepts les puis puissant du shell unix (linux par la suite) est que ces 3 flux peuvent êtres branchées sur n'importe quoi d'autre (on vient d'effleurer le sujet avec ssh).

=== Les types de redirections ===

==== redirection entre process ====
c'est la redirection de la sortie d'un process vers l'entrée d'un autre. Ca s'appelle un 'pipe' (un tube, un tuyau... )

[[Fichier:Process-bash002.png|sans_cadre|916x916px]]

Pour chainer ainsi deux process on utilise le caractère "pipe" soit <code>"|"</code>.
Il s'agit d'une barre verticale qui semble être un tuyau dans le mauvais sens. Il faut connaitre comment les premières machines affichaient ce caractère : pas <code>"|"</code> mais <code>"¦"</code>.

Une barre avec un petit trou pour laisser passer le flux. Ce caractère à été simplifié et maintenant et on ne comprends plus bien.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
$ ls -l | grep toto
$ ls -l | grep "c"
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>La première commande est un bête ls qui donne la liste des fichiers.
La seconde filtre ces lignes pour n'afficher que les lignes contenant la chaine <code>"toto"</code>.. c'est à dire aucune.
La troisième filtre les lignes pour n'afficher que celles contenant <code>"c"</code> c'est a dire deux d'entres elles.

Attention on parle là de flux de caractères. Les redirections et les process de ces exemples ne "comprennent" pas ce qu'on leur envoie dans les flux.
si on avait utilisé grep avec <code>"n":</code><syntaxhighlight lang="bash">
$ ls -l | grep "n"
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>Aucun fichier ne contient de <code>"n"</code> mais grep traite le flux ligne de texte par ligne de texte. Il trouve des <code>"n"</code> dans le nom du user et du groupe il affiche la ligne.
Nous ne sommes pas dans des shell type powershell qui traitent des objets. Ici on traite des flux de caractres est bête et méchants.

'''<big>SECTION Pour les experts</big>''' (qui connaissent [[strace]]).

'''Vous êtes débutant passez cette section vous y reviendrez plus tard!'''<syntaxhighlight lang="bash">strace -e openat grep "toto" resultat.txt</syntaxhighlight>Nous donne bien une ligne:<syntaxhighlight lang="text">
openat(AT_FDCWD, "resultat.txt", O_RDONLY|O_NOCTTY) = 3
</syntaxhighlight>C'est bien le process "grep" qui ouvre le fichier <code>resultat.txt</code>.

Mais si on fait :<syntaxhighlight lang="bash">
cat toto | strace -e openat grep "toto"
</syntaxhighlight>pas de lignes d'ouverture de resultat.txt dans grep. C'est cat qui ouvre le ficher!

SI on trace ce que fait cat et pas ce que fait grep:<syntaxhighlight lang="bash">
strace -e openat cat resultat.txt | grep "toto"
</syntaxhighlight>On récupère bien notre ligne<syntaxhighlight lang="text">
openat(AT_FDCWD, "resultat.txt", O_RDONLY) = 3
</syntaxhighlight>Si on fait :<syntaxhighlight lang="bash">
strace -e openat cat < resultat.txt | grep "toto"
</syntaxhighlight>On ne voit plus rien car c'est bash qui ouvre le fichier pour l'envoyer a cat (voir plus loin)

'''<big>FIN DE SECTION EXPERTS</big>'''

==== Fichiers ====

==== ">" Rediriger la sortie standard vers un fichier ====
Autant <code>"|"</code> dirige la sortie d'un processus vers l'entrée d'un autre processus <code>">"</code> redirige simplement la sortie standard d'un process vers un fichier disque.

Exemple simple un simple ls.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>La commande ls envoie la liste des fichier vers la sortie standard. Jusque là on n'a rien fait!<syntaxhighlight lang="bash">$ ls -l > resultat.txt</syntaxhighlight>Cette commande ne réponds rien et c'est normal. On lui a demandé de rediriger la sortie standard vers un fichier <code>"resultat.txt"</code>

Si on refait un ls.<syntaxhighlight lang="bash">$ ls -l
total 48
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
-rw-r--r-- 1 jpinon jpinon 344 Aug 5 23:21 resultat.txt</syntaxhighlight>Effectivement on a un nouveau fichier!

SI on regarde ce qu'il i a dedans (cat, vi, nano... chacun sa méthode) mais on y trouve :<syntaxhighlight lang="text">
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
-rw-r--r-- 1 jpinon jpinon 0 Aug 5 23:21 resultat.txt
</syntaxhighlight>On remarque que <code>"resultat.txt"</code> est déjà dedans mais avec une taille nulle. Etrange? pas tant que ça et ca nous montre bien comment ça se passe.

Lors de la commande <code>"ls -l > resultat.txt"</code> le shell (bash ici) voit que la sortie de <code>ls</code> devra aller dans un fichier <code>"resultat.txt"</code> qu'il s'empresse de créer mais, pour le moment, il est vide. Le shell lance alors le <code>"ls -l"</code> qui fait la liste des fichiers, dont resultat.txt qui est vide, et l'envoie dans le fichier "resultat.txt" qui se remplis alors.

A la sortie resultat.txt est donc plein mais, quand il a été lut par ls il était vide!

'''Tout est simple et logique en bash!'''

==== ">>" Pour pas tout casser ====
La redirection > envoie dans un fichier le contenu de la sortie standard d'un process. Cependant si ce fichier existe il sera écrasé par le contenu en question. Ce n'est pas toujours ce que l'on souhaite!

On veut parfois "ajouter à la fin". <syntaxhighlight lang="bash">
echo "Etat des disques" > status.txt
df -h >> status.txt
</syntaxhighlight>On crée un fichier contenant la ligne "etat des disques" et on y ajoute le résultat de <code>df -h</code>.

J'i mon petit script de création de fichier python vide:<syntaxhighlight lang="bash">
# fichier create-py.sh
echo -n "#!" > $1.py
which python3 >> $1.py
echo "" >> $1.py
echo -n "# " >> $1.py
date "+created on %Y-%m-%d@%H:%M by $USER" >> test.py
chmod a+x $1.py

</syntaxhighlight>On l'appelle avec :<syntaxhighlight lang="bash">./create-py test</syntaxhighlight>... et on a un test.py :<syntaxhighlight lang="python3">
#!/usr/bin/python3
# created on 2026-08-06@01:00 by jpinon
</syntaxhighlight>Correctement configuré pour être lancé directement à la ligne de commande. Il reste plus qu'à....

==== "<" rediriger un fichier vers l'entrée standard d'un process. ====
C'est la partie la moins élégante de la syntaxe je trouve mais bon. On peut utiliser un fichier comme l'entrée d'un process.

C'est assez rarement utilisé parce que'à la fois pas clair et pas très utile. Suivez moi bien:<syntaxhighlight lang="bash">
cat
</syntaxhighlight>affiche le résultat de l'entrée standard sur la sortie standard. Le truc le plus inutile possible!<syntaxhighlight lang="bash">
$ cat
hello
hello
bonjour
bonjour
jaquot
jaquot
blabla
blabla
</syntaxhighlight>Ca répète tout ce qu'on tape jusqu'à la fin du texte (EOF ou <Ctrl> D)

si on voulait lui faire écrire ce qu'il y a dans un fichier on sait qu'il faut faire :<syntaxhighlight lang="bash">
cat resultat.txt
</syntaxhighlight>Ca marche mais c'est pas ce que je veux vous montrer. C'est juste le fonctionnement de la commande <code>cat</code>. SI on lui donne un paramètre au lieu de copier l'entrée standard elle prends le paramètre en question, ouvre le fichier disque qui correspond de l'envoie sur la sortie standard. Là c'est le programme <code>cat</code> qui fait le travail.

Si on fait :<syntaxhighlight lang="bash">cat < resultat.txt # Attention un < s'est introduit dans cette commande!</syntaxhighlight>le résultat est exactement le même mais les actions effectuées sont totalement différentes!

Que fait le shell?

* Il ouvre <code>cat</code> sans paramètres qui va alors lire les lignes une par une sur l'entrée standard et les envoyer sur la sortie standard jusqu'à EOF. Il est bête mais on lui en demande pas plus.
* Mais le shell vois aussi que l'entrée standard de cat doit être "alimentée", non pas par le clavier mais par le contenu d'un fichier "resultat.txt"
* doc cat prends ce qu'il a en entrée (le shell lui envoie le contenu de resultat.txt) et l'envoie sur la sortie standard (ici l'écran)

On pourrait envisager un:<syntaxhighlight lang="bash">
cat < resultat.txt > resultat1.txt
</syntaxhighlight>...qui en fait est l'équivalant d'une copie de <code>resultat.txt</code> vers <code>resultat1.txt</code>.<syntaxhighlight lang="bash">
cp resultat1 resultat2
</syntaxhighlight>aurait fait pareil.

Encore plus pervère<syntaxhighlight lang="bash">
cat < resultat.txt | grep jpinon > resultat2.txt
</syntaxhighlight>Le shell traite comme ça:

* ouverture de <code>cat</code> "tout nu" qui lit sur l'entrée et envoie vers la sortie
* son entrée est connectée par shell sur le fichier <code>resultat.txt</code>. Ok, donc cat ne le sait pas mais il lit les lignes de <code>resultat.txt</code> une par une (c'est le shell qui les lui envoie).
* <code>cat</code> ecrit vers sa sortie standars mais le shell la redirrige vers <code>grep</code>.
* <code>grep</code> est presque aussi bête que <code>cat</code>. Il lit des lignes sur son entrée standard et les sort sur la sur la sortie standard pour peu que la ligne contienne la chaine en paramètre
* mais le shell est malin, il lui envoie sur son entrée standard la sortie de <code>cat</code>.
* a la fin le shell détourne la sortie de <code>grep</code> vers <code>resultat2.txt</code>

Tout ca se résume dans :

[[Fichier:Process-bash004.png|sans_cadre|914x914px]]

==== Remarque sur l'usage de "-" ====
Quelquefois il est indispensable de donner un fichier à une commande. dans ce cas là on peut remplacer ne nom du fichier par <code>"-"</code>.

Par exemple :<syntaxhighlight lang="bash">
cat -
</syntaxhighlight>est équivalant à:<syntaxhighlight lang="bash">
cat
</syntaxhighlight>bon pas très utile. Mais pensons au compilateur cc. une option est de lui demander de juste s'arreter au code assembleur mais pas d'aller jusqu'au code machine.<syntaxhighlight lang="bash">
cc -S hello.c
</syntaxhighlight>va, par défaut nous sortir un fichier hello.s qui contient le code assembleur. Imaginons que l'on veuille avoir ce code assembleur pour l'envoyer à un ami mais on le voudrait "gzippé". Problème cc sait sortir dans un fichier texte, on peut lui donner le nom du fichier de sortie par l'option "-o fichier.s" mais il ne sait pas zipper.

On porait faire ça en deux commandes :<syntaxhighlight lang="bash">
cc -o code.s -S hello.c
gzip code.s
</syntaxhighlight>en sortie on aura un fichier code.s.gz tres bien mais on a appris a faire des redirections! Alors on en fait!<syntaxhighlight lang="bash">cc -o - -S hello.c | gzip > code.s.gz</syntaxhighlight>C'est pas beau!

Avec un beau dessin :

[[Fichier:Process-bash005.png|sans_cadre|916x916px]]

On pourrait même l'envoyer directement à notre amis. Ce fichier code.s.gz j'en ai pas besoin moi!<syntaxhighlight lang="bash">cc -o - -S hello.c | gzip | mail -s "le code assembleur de hello.c" monami@gmail.com</syntaxhighlight>[[Fichier:Process-bash006.png|sans_cadre|916x916px]]

Bon comme ça ca parait un peu inutile mais imaginez une tâche [[cron]] qui lance, tous les jours à 4h le matin la commande suivante:<syntaxhighlight lang="bash">
df -h | mail -s "Etat des disques" moi@mondomaine.fr
</syntaxhighlight>Et oui! tous les matin j'aurais l'état de remplissage des disque de ma machine dans mes mails. On pourrait améliorer avec un <code>grep</code> entre <code>df</code> et <code>mail</code> pour ne mentionner que les disques qui posent un problème.

=== Redirection du flux d'erreur ===
Pour le moment on se traine notre (nos) flux d'erreurs qui vont vers la console. C'est bien car, même quand les sortie standards sont redirigées on peut voir que ça s'est mal passé.

Imaginons que les erreurs suivent le même chemin que la sortie avec:<syntaxhighlight lang="bash">
cc -o - -S hello.c | gzip | mail -s "le code assembleur de hello.c" monami@gmail.com
</syntaxhighlight>imaginons une erreur de compilation (j'ai oublié le int devant le main()):<syntaxhighlight lang="bash">
$ cc -S hello.c
hello.c:3:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
3 | main(){
| ^~~~
$
</syntaxhighlight>Dans le cas présent ca m'affiche l'erreur et tout s'arrête après <code>cc</code>. J'aurais mon message et mon ami ne recevra pas de mail.

Si la sortie d'erreur était gérée par le même flux que la sortie standard, je ne m'apercevrais de rien et mon ami recevrait le mail avec le message d'erreur. La loose!

Et bien voila pourquoi la sortie standard est gérée a part.

===== = = = = A FAIRE = = = = =====

Redirections bash (et en bourne shell en géneral)

2026-08-06T11:34:32Z

Jpinon : /* redirection entre process */

Les redirections c'est la base des batches !

== Echanges standard entre un process et son environnement. ==
Un process (process ou processus en français j'utiliserais les deux mots indéférament) est une suite d'instructions qui sont exécutées par le système les unes après les autres. Il n'y a pas de notion de parallélisme à ce niveau.

A sa création un process possède trois "flux" standard.

* Une entrée
* deux sorties (normal et erreurs)

[[Fichier:Process-bash000.png|sans_cadre|492x492px]]

Si rien n'est précisé l'entrée standard est le clavier et les deux sorties (standard et erreur sont l'écran)

[[Fichier:Process-bash001.png|sans_cadre|750x750px]]

Déjà, de façon, transparente ce clavier et cet écrans sont transformés dans le cas du ssh (ou du telnet). Dans ce cas les entrées sorties sont redirigées vers le réseau lui même ver le client ssh qui... finalement l'envoie à un clavier et un écran même si ce n'est pas celui de ma machine sur laquelle tourne le processus.

Un exemple typique : un simple ls.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
$ ls rrr
ls: cannot access 'rrr': No such file or directory
$
</syntaxhighlight>Le premier ls ci dessus envoie sa sortie standard vers l'écran (le flux en bleu sur le schéma). Dans le cas second ls, il s'agit d'une erreur donc vers la sortie d'erreur (flux en rouge).

Il est impossible, pour le moment, de savoir si ce qui est à l'écran a été envoyé vers la sortie standard ou la sortie d'erreur. (sauf le bon sens)

Pour le cas de l'entrée standard l'exemple est plus subtil, on va utiliser grep. grep est un programme assez simple (bon il a plein d'options mais on en parlera pas là) il lit l'entrée standard ligne par ligne et ne l'affiche sur la sortie que si elle comprends un chaine donnée en paramètre.<syntaxhighlight lang="bash">
$ grep toto
Bonjour toi
Bonjour vous
Hello toto
Hello toto
Ca va toto?
Ca va toto?
au revoir toto
au revoir toto
salut
</syntaxhighlight>le shell envoie aussi à l'écran ce que l'on tape au clavier avant de l'envoyer au programme (il appelle ca l'écho).

que se passe t'il dans notre exemple? On entre le ligne <code>"Bonjour toi"</code>. Le shell l'envoie à l'écran et au process (grep). grep lit la ligne<code>"Bonjour toi"</code>et vérifie si elle contient la chaine qu'on lui a donné en paramètre <code>"toto"</code>. Ce n'est pas le cas, grep ignore la ligne. Il se passe la même chose pour <code>"Bonjour vous"</code>. En revanche pour <code>"Hello toto"</code> le shell l'envoie a l'écran (echo) et à grep. Grep voit qu'elle contient bien la chaine <code>"toto",</code> alors elle écrit la ligne sur la sortie standard.

Donc on voit la ligne en double. D'abord l'echo de ce qu'on tape ensuite la sortie de grep.

== Redirections des flux standards ==
L'un des concepts les puis puissant du shell unix (linux par la suite) est que ces 3 flux peuvent êtres branchées sur n'importe quoi d'autre (on vient d'effleurer le sujet avec ssh).

=== Les types de redirections ===

==== redirection entre process ====
c'est la redirection de la sortie d'un process vers l'entrée d'un autre. Ca s'appelle un 'pipe' (un tube, un tuyau... )

[[Fichier:Process-bash002.png|sans_cadre|916x916px]]

Pour chainer ainsi deux process on utilise le caractère "pipe" soit <code>"|"</code>.
Il s'agit d'une barre verticale qui semble être un tuyau dans le mauvais sens. Il faut connaitre comment les premières machines affichaient ce caractère : pas <code>"|"</code> mais <code>"¦"</code>.

Une barre avec un petit trou pour laisser passer le flux. Ce caractère à été simplifié et maintenant et on ne comprends plus bien.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
$ ls -l | grep toto
$ ls -l | grep "c"
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>La première commande est un bête ls qui donne la liste des fichiers.
La seconde filtre ces lignes pour n'afficher que les lignes contenant la chaine <code>"toto"</code>.. c'est à dire aucune.
La troisième filtre les lignes pour n'afficher que celles contenant <code>"c"</code> c'est a dire deux d'entres elles.

Attention on parle là de flux de caractères. Les redirections et les process de ces exemples ne "comprennent" pas ce qu'on leur envoie dans les flux.
si on avait utilisé grep avec <code>"n":</code><syntaxhighlight lang="bash">
$ ls -l | grep "n"
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>Aucun fichier ne contient de <code>"n"</code> mais grep traite le flux ligne de texte par ligne de texte. Il trouve des <code>"n"</code> dans le nom du user et du groupe il affiche la ligne.
Nous ne sommes pas dans des shell type powershell qui traitent des objets. Ici on traite des flux de caractres est bête et méchants.

'''<big>SECTION Pour les experts</big>''' (qui connaissent [[strace]]).

'''Vous êtes débutant passez cette section vous y reviendrez plus tard!'''<syntaxhighlight lang="bash">strace -e openat grep "toto" resultat.txt</syntaxhighlight>Nous donne bien une ligne:<syntaxhighlight lang="text">
openat(AT_FDCWD, "resultat.txt", O_RDONLY|O_NOCTTY) = 3
</syntaxhighlight>C'est bien le process "grep" qui ouvre le fichier <code>resultat.txt</code>.

Mais si on fait :<syntaxhighlight lang="bash">
cat toto | strace -e openat grep "toto"
</syntaxhighlight>pas de lignes d'ouverture de resultat.txt dans grep. C'est cat qui ouvre le ficher!

SI on trace ce que fait cat et pas ce que fait grep:<syntaxhighlight lang="bash">
strace -e openat cat resultat.txt | grep "toto"
</syntaxhighlight>On récupère bien notre ligne<syntaxhighlight lang="text">
openat(AT_FDCWD, "resultat.txt", O_RDONLY) = 3
</syntaxhighlight>Si on fait :<syntaxhighlight lang="bash">
strace -e openat cat < resultat.txt | grep "toto"
</syntaxhighlight>On ne voit plus rien car c'est bash qui ouvre le fichier pour l'envoyer a cat (voir plus loin)

'''<big>FIN DE SECTION EXPERTS</big>'''

==== Fichiers ====

==== ">" Rediriger la sortie standard vers un fichier ====
Autant <code>"|"</code> dirige la sortie d'un processus vers l'entrée d'un autre processus <code>">"</code> redirige simplement la sortie standard d'un process vers un fichier disque.

Exemple simple un simple ls.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>La commande ls envoie la liste des fichier vers la sortie standard. Jusque là on n'a rien fait!<syntaxhighlight lang="bash">$ ls -l > resultat.txt</syntaxhighlight>Cette commande ne réponds rien et c'est normal. On lui a demandé de rediriger la sortie standard vers un fichier <code>"resultat.txt"</code>

Si on refait un ls.<syntaxhighlight lang="bash">$ ls -l
total 48
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
-rw-r--r-- 1 jpinon jpinon 344 Aug 5 23:21 resultat.txt</syntaxhighlight>Effectivement on a un nouveau fichier!

SI on regarde ce qu'il i a dedans (cat, vi, nano... chacun sa méthode) mais on y trouve :<syntaxhighlight lang="text">
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
-rw-r--r-- 1 jpinon jpinon 0 Aug 5 23:21 resultat.txt
</syntaxhighlight>On remarque que <code>"resultat.txt"</code> est déjà dedans mais avec une taille nulle. Etrange? pas tant que ça et ca nous montre bien comment ça se passe.

Lors de la commande <code>"ls -l > resultat.txt"</code> le shell (bash ici) voit que la sortie de <code>ls</code> devra aller dans un fichier <code>"resultat.txt"</code> qu'il s'empresse de créer mais, pour le moment, il est vide. Le shell lance alors le <code>"ls -l"</code> qui fait la liste des fichiers, dont resultat.txt qui est vide, et l'envoie dans le fichier "resultat.txt" qui se remplis alors.

A la sortie resultat.txt est donc plein mais, quand il a été lut par ls il était vide!

'''Tout est simple et logique en bash!'''

==== ">>" Pour pas tout casser ====
La redirection > envoie dans un fichier le contenu de la sortie standard d'un process. Cependant si ce fichier existe il sera écrasé par le contenu en question. Ce n'est pas toujours ce que l'on souhaite!

On veut parfois "ajouter à la fin". <syntaxhighlight lang="bash">
echo "Etat des disques" > status.txt
df -h >> status.txt
</syntaxhighlight>On crée un fichier contenant la ligne "etat des disques" et on y ajoute le résultat de <code>df -h</code>.

J'i mon petit script de création de fichier python vide:<syntaxhighlight lang="bash">
# fichier create-py.sh
echo -n "#!" > $1.py
which python3 >> $1.py
echo "" >> $1.py
echo -n "# " >> $1.py
date "+created on %Y-%m-%d@%H:%M by $USER" >> test.py
chmod a+x $1.py

</syntaxhighlight>On l'appelle avec :<syntaxhighlight lang="bash">./create-py test</syntaxhighlight>... et on a un test.py :<syntaxhighlight lang="python3">
#!/usr/bin/python3
# created on 2026-08-06@01:00 by jpinon
</syntaxhighlight>Correctement configuré pour être lancé directement à la ligne de commande. Il reste plus qu'à....

==== "<" rediriger un fichier vers l'entrée standard d'un process. ====
C'est la partie la moins élégante de la syntaxe je trouve mais bon. On peut utiliser un fichier comme l'entrée d'un process.

C'est assez rarement utilisé parce que'à la fois pas clair et pas très utile. Suivez moi bien:<syntaxhighlight lang="bash">
cat
</syntaxhighlight>affiche le résultat de l'entrée standard sur la sortie standard. Le truc le plus inutile possible!<syntaxhighlight lang="bash">
$ cat
hello
hello
bonjour
bonjour
jaquot
jaquot
blabla
blabla
</syntaxhighlight>Ca répète tout ce qu'on tape jusqu'à la fin du texte (EOF ou <Ctrl> D)

si on voulait lui faire écrire ce qu'il y a dans un fichier on sait qu'il faut faire :<syntaxhighlight lang="bash">
cat resultat.txt
</syntaxhighlight>Ca marche mais c'est pas ce que je veux vous montrer. C'est juste le fonctionnement de la commande <code>cat</code>. SI on lui donne un paramètre au lieu de copier l'entrée standard elle prends le paramètre en question, ouvre le fichier disque qui correspond de l'envoie sur la sortie standard. Là c'est le programme <code>cat</code> qui fait le travail.

Si on fait :<syntaxhighlight lang="bash">cat < resultat.txt # Attention un < s'est introduit dans cette commande!</syntaxhighlight>le résultat est exactement le même mais les actions effectuées sont totalement différentes!

Que fait le shell?

* Il ouvre <code>cat</code> sans paramètres qui va alors lire les lignes une par une sur l'entrée standard et les envoyer sur la sortie standard jusqu'à EOF. Il est bête mais on lui en demande pas plus.
* Mais le shell vois aussi que l'entrée standard de cat doit être "alimentée", non pas par le clavier mais par le contenu d'un fichier "resultat.txt"
* doc cat prends ce qu'il a en entrée (le shell lui envoie le contenu de resultat.txt) et l'envoie sur la sortie standard (ici l'écran)

On pourrait envisager un:<syntaxhighlight lang="bash">
cat < resultat.txt > resultat1.txt
</syntaxhighlight>...qui en fait est l'équivalant d'une copie de <code>resultat.txt</code> vers <code>resultat1.txt</code>.<syntaxhighlight lang="bash">
cp resultat1 resultat2
</syntaxhighlight>aurait fait pareil.

Encore plus pervère<syntaxhighlight lang="bash">
cat < resultat.txt | grep jpinon > resultat2.txt
</syntaxhighlight>Le shell traite comme ça:

* ouverture de <code>cat</code> "tout nu" qui lit sur l'entrée et envoie vers la sortie
* son entrée est connectée par shell sur le fichier <code>resultat.txt</code>. Ok, donc cat ne le sait pas mais il lit les lignes de <code>resultat.txt</code> une par une (c'est le shell qui les lui envoie).
* <code>cat</code> ecrit vers sa sortie standars mais le shell la redirrige vers <code>grep</code>.
* <code>grep</code> est presque aussi bête que <code>cat</code>. Il lit des lignes sur son entrée standard et les sort sur la sur la sortie standard pour peu que la ligne contienne la chaine en paramètre
* mais le shell est malin, il lui envoie sur son entrée standard la sortie de <code>cat</code>.
* a la fin le shell détourne la sortie de <code>grep</code> vers <code>resultat2.txt</code>

Tout ca se résume dans :

[[Fichier:Process-bash004.png|sans_cadre|914x914px]]

==== Remarque sur l'usage de "-" ====
Quelquefois il est indispensable de donner un fichier à une commande. dans ce cas là on peut remplacer ne nom du fichier par <code>"-"</code>.

Par exemple :<syntaxhighlight lang="bash">
cat -
</syntaxhighlight>est équivalant à:<syntaxhighlight lang="bash">
cat
</syntaxhighlight>bon pas très utile. Mais pensons au compilateur cc. une option est de lui demander de juste s'arreter au code assembleur mais pas d'aller jusqu'au code machine.<syntaxhighlight lang="bash">
cc -S hello.c
</syntaxhighlight>va, par défaut nous sortir un fichier hello.s qui contient le code assembleur. Imaginons que l'on veuille avoir ce code assembleur pour l'envoyer à un ami mais on le voudrait "gzippé". Problème cc sait sortir dans un fichier texte, on peut lui donner le nom du fichier de sortie par l'option "-o fichier.s" mais il ne sait pas zipper.

On porait faire ça en deux commandes :<syntaxhighlight lang="bash">
cc -o code.s -S hello.c
gzip code.s
</syntaxhighlight>en sortie on aura un fichier code.s.gz tres bien mais on a appris a faire des redirections! Alors on en fait!<syntaxhighlight lang="bash">cc -o - -S hello.c | gzip > code.s.gz</syntaxhighlight>C'est pas beau!

Avec un beau dessin :

[[Fichier:Process-bash005.png|sans_cadre|916x916px]]

On pourrait même l'envoyer directement à notre amis. Ce fichier code.s.gz j'en ai pas besoin moi!<syntaxhighlight lang="bash">cc -o - -S hello.c | gzip | mail -s "le code assembleur de hello.c" monami@gmail.com</syntaxhighlight>[[Fichier:Process-bash006.png|sans_cadre|916x916px]]

Bon comme ça ca parait un peu inutile mais imaginez une tâche [[cron]] qui lance, tous les jours à 4h le matin la commande suivante:<syntaxhighlight lang="bash">
df -h | mail -s "Etat des disques" moi@mondomaine.fr
</syntaxhighlight>Et oui! tous les matin j'aurais l'état de remplissage des disque de ma machine dans mes mails. On pourrait améliorer avec un <code>grep</code> entre <code>df</code> et <code>mail</code> pour ne mentionner que les disques qui posent un problème.

=== Redirection du flux d'erreur ===
Pour le moment on se traine notre (nos) flux d'erreurs qui vont vers la console. C'est bien car, même quand les sortie standards sont redirigées on peut voir que ça s'est mal passé.

Imaginons que les erreurs suivent le même chemin que la sortie avec:<syntaxhighlight lang="bash">
cc -o - -S hello.c | gzip | mail -s "le code assembleur de hello.c" monami@gmail.com
</syntaxhighlight>imaginons une erreur de compilation (j'ai oublié le int devant le main()):<syntaxhighlight lang="bash">
$ cc -S hello.c
hello.c:3:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
3 | main(){
| ^~~~
$
</syntaxhighlight>Dans le cas présent ca m'affiche l'erreur et tout s'arrête après <code>cc</code>. J'aurais mon message et mon ami ne recevra pas de mail.

Si la sortie d'erreur était gérée par le même flux que la sortie standard, je ne m'apercevrais de rien et mon ami recevrait le mail avec le message d'erreur. La loose!

Et bien voila pourquoi la sortie standard est gérée a part.

===== = = = = A FAIRE = = = = =====

Redirections bash (et en bourne shell en géneral)

2026-08-05T23:25:25Z

Jpinon : /* Les types de redirections */

Les redirections c'est la base des batches !

== Echanges standard entre un process et son environnement. ==
Un process (process ou processus en français j'utiliserais les deux mots indéférament) est une suite d'instructions qui sont exécutées par le système les unes après les autres. Il n'y a pas de notion de parallélisme à ce niveau.

A sa création un process possède trois "flux" standard.

* Une entrée
* deux sorties (normal et erreurs)

[[Fichier:Process-bash000.png|sans_cadre|492x492px]]

Si rien n'est précisé l'entrée standard est le clavier et les deux sorties (standard et erreur sont l'écran)

[[Fichier:Process-bash001.png|sans_cadre|750x750px]]

Déjà, de façon, transparente ce clavier et cet écrans sont transformés dans le cas du ssh (ou du telnet). Dans ce cas les entrées sorties sont redirigées vers le réseau lui même ver le client ssh qui... finalement l'envoie à un clavier et un écran même si ce n'est pas celui de ma machine sur laquelle tourne le processus.

Un exemple typique : un simple ls.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
$ ls rrr
ls: cannot access 'rrr': No such file or directory
$
</syntaxhighlight>Le premier ls ci dessus envoie sa sortie standard vers l'écran (le flux en bleu sur le schéma). Dans le cas second ls, il s'agit d'une erreur donc vers la sortie d'erreur (flux en rouge).

Il est impossible, pour le moment, de savoir si ce qui est à l'écran a été envoyé vers la sortie standard ou la sortie d'erreur. (sauf le bon sens)

Pour le cas de l'entrée standard l'exemple est plus subtil, on va utiliser grep. grep est un programme assez simple (bon il a plein d'options mais on en parlera pas là) il lit l'entrée standard ligne par ligne et ne l'affiche sur la sortie que si elle comprends un chaine donnée en paramètre.<syntaxhighlight lang="bash">
$ grep toto
Bonjour toi
Bonjour vous
Hello toto
Hello toto
Ca va toto?
Ca va toto?
au revoir toto
au revoir toto
salut
</syntaxhighlight>le shell envoie aussi à l'écran ce que l'on tape au clavier avant de l'envoyer au programme (il appelle ca l'écho).

que se passe t'il dans notre exemple? On entre le ligne <code>"Bonjour toi"</code>. Le shell l'envoie à l'écran et au process (grep). grep lit la ligne<code>"Bonjour toi"</code>et vérifie si elle contient la chaine qu'on lui a donné en paramètre <code>"toto"</code>. Ce n'est pas le cas, grep ignore la ligne. Il se passe la même chose pour <code>"Bonjour vous"</code>. En revanche pour <code>"Hello toto"</code> le shell l'envoie a l'écran (echo) et à grep. Grep voit qu'elle contient bien la chaine <code>"toto",</code> alors elle écrit la ligne sur la sortie standard.

Donc on voit la ligne en double. D'abord l'echo de ce qu'on tape ensuite la sortie de grep.

== Redirections des flux standards ==
L'un des concepts les puis puissant du shell unix (linux par la suite) est que ces 3 flux peuvent êtres branchées sur n'importe quoi d'autre (on vient d'effleurer le sujet avec ssh).

=== Les types de redirections ===

==== redirection entre process ====
c'est la redirection de la sortie d'un process vers l'entrée d'un autre. Ca s'appelle un 'pipe' (un tube, un tuyau... )
[[Fichier:Process-bash002.png|sans_cadre|916x916px]]
Pour chainer ainsi deux process on utilise le caractère "pipe" soit <code>"|"</code>.
Il s'agit d'une barre verticale qui semble être un tuyau dans le mauvais sens. Il faut connaitre comment les premières machines affichaient ce caractère : pas <code>"|"</code> mais <code>"¦"</code>.

Une barre avec un petit trou pour laisser passer le flux. Ce caractère à été simplifié et maintenant et on ne comprends plus bien.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
$ ls -l | grep toto
$ ls -l | grep "c"
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>La première commande est un bête ls qui donne la liste des fichiers.
La seconde filtre ces lignes pour n'afficher que les lignes contenant la chaine <code>"toto"</code>.. c'est à dire aucune.
La troisième filtre les lignes pour n'afficher que celles contenant <code>"c"</code> c'est a dire deux d'entres elles.

Attention on parle là de flux de caractères. Les redirections et les process de ces exemples ne "comprennent" pas ce qu'on leur envoie dans les flux.
si on avait utilisé grep avec <code>"n":</code><syntaxhighlight lang="bash">
$ ls -l | grep "n"
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>Aucun fichier ne contient de <code>"n"</code> mais grep traite le flux ligne de texte par ligne de texte. Il trouve des <code>"n"</code> dans le nom du user et du groupe il affiche la ligne.
Nous ne sommes pas dans des shell type powershell qui traitent des objets. Ici on traite des flux de caractres est bête et méchants.

'''<big>SECTION Pour les experts</big>''' (qui connaissent [[strace]]).

'''Vous êtes débutant passez cette section vous y reviendrez plus tard!'''<syntaxhighlight lang="bash">strace -e openat grep "toto" resultat.txt</syntaxhighlight>Nous donne bien une ligne:<syntaxhighlight lang="text">
openat(AT_FDCWD, "resultat.txt", O_RDONLY|O_NOCTTY) = 3
</syntaxhighlight>C'est bien le process "grep" qui ouvre le fichier <code>resultat.txt</code>.

Mais si on fait :<syntaxhighlight lang="bash">
cat toto | strace -e openat grep "toto"
</syntaxhighlight>pas de lignes d'ouverture de resultat.txt dans grep. C'est cat qui ouvre le ficher!

SI on trace ce que fait cat et pas ce que fait grep:<syntaxhighlight lang="bash">
strace -e openat cat resultat.txt | grep "toto"
</syntaxhighlight>On récupère bien notre ligne<syntaxhighlight lang="text">
openat(AT_FDCWD, "resultat.txt", O_RDONLY) = 3
</syntaxhighlight>Si on fait :<syntaxhighlight lang="bash">
strace -e openat cat < resultat.txt | grep "toto"
</syntaxhighlight>On ne voit plus rien car c'est bash qui ouvre le fichier pour l'envoyer a cat (voir plus loin)

'''<big>FIN DE SECTION EXPERTS</big>'''

==== Fichiers ====

==== ">" Rediriger la sortie standard vers un fichier ====
Autant <code>"|"</code> dirige la sortie d'un processus vers l'entrée d'un autre processus <code>">"</code> redirige simplement la sortie standard d'un process vers un fichier disque.

Exemple simple un simple ls.<syntaxhighlight lang="bash">
$ ls -l
total 44
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
</syntaxhighlight>La commande ls envoie la liste des fichier vers la sortie standard. Jusque là on n'a rien fait!<syntaxhighlight lang="bash">$ ls -l > resultat.txt</syntaxhighlight>Cette commande ne réponds rien et c'est normal. On lui a demandé de rediriger la sortie standard vers un fichier <code>"resultat.txt"</code>

Si on refait un ls.<syntaxhighlight lang="bash">$ ls -l
total 48
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
-rw-r--r-- 1 jpinon jpinon 344 Aug 5 23:21 resultat.txt</syntaxhighlight>Effectivement on a un nouveau fichier!

SI on regarde ce qu'il i a dedans (cat, vi, nano... chacun sa méthode) mais on y trouve :<syntaxhighlight lang="text">
-rwxr-xr-x 1 jpinon jpinon 15960 Aug 5 21:48 hello
-rw-r--r-- 1 jpinon jpinon 84 Aug 5 21:48 hello.c
-rw-r--r-- 1 jpinon jpinon 797 Aug 5 21:48 hello.s
-rwxr-xr-x 1 jpinon jpinon 15968 Aug 5 21:50 helloworld
-rw-r--r-- 1 jpinon jpinon 63 Aug 5 21:50 helloworld.c
-rw-r--r-- 1 jpinon jpinon 0 Aug 5 23:21 resultat.txt
</syntaxhighlight>On remarque que <code>"resultat.txt"</code> est déjà dedans mais avec une taille nulle. Etrange? pas tant que ça et ca nous montre bien comment ça se passe.

Lors de la commande <code>"ls -l > resultat.txt"</code> le shell (bash ici) voit que la sortie de <code>ls</code> devra aller dans un fichier <code>"resultat.txt"</code> qu'il s'empresse de créer mais, pour le moment, il est vide. Le shell lance alors le <code>"ls -l"</code> qui fait la liste des fichiers, dont resultat.txt qui est vide, et l'envoie dans le fichier "resultat.txt" qui se remplis alors.

A la sortie resultat.txt est donc plein mais, quand il a été lut par ls il était vide!

'''Tout est simple et logique en bash!'''

==== ">>" Pour pas tout casser ====
La redirection > envoie dans un fichier le contenu de la sortie standard d'un process. Cependant si ce fichier existe il sera écrasé par le contenu en question. Ce n'est pas toujours ce que l'on souhaite!

On veut parfois "ajouter à la fin". <syntaxhighlight lang="bash">
echo "Etat des disques" > status.txt
df -h >> status.txt
</syntaxhighlight>On crée un fichier contenant la ligne "etat des disques" et on y ajoute le résultat de <code>df -h</code>.

J'i mon petit script de création de fichier python vide:<syntaxhighlight lang="bash">
# fichier create-py.sh
echo -n "#!" > $1.py
which python3 >> $1.py
echo "" >> $1.py
echo -n "# " >> $1.py
date "+created on %Y-%m-%d@%H:%M by $USER" >> test.py
chmod a+x $1.py

</syntaxhighlight>On l'appelle avec :<syntaxhighlight lang="bash">./create-py test</syntaxhighlight>... et on a un test.py :<syntaxhighlight lang="python3">
#!/usr/bin/python3
# created on 2026-08-06@01:00 by jpinon
</syntaxhighlight>Correctement configuré pour être lancé directement à la ligne de commande. Il reste plus qu'à....

==== "<" rediriger un fichier vers l'entrée standard d'un process. ====
C'est la partie la moins élégante de la syntaxe je trouve mais bon. On peut utiliser un fichier comme l'entrée d'un process.

C'est assez rarement utilisé parce que'à la fois pas clair et pas très utile. Suivez moi bien:<syntaxhighlight lang="bash">
cat
</syntaxhighlight>affiche le résultat de l'entrée standard sur la sortie standard. Le truc le plus inutile possible!<syntaxhighlight lang="bash">
$ cat
hello
hello
bonjour
bonjour
jaquot
jaquot
blabla
blabla
</syntaxhighlight>Ca répète tout ce qu'on tape jusqu'à la fin du texte (EOF ou <Ctrl> D)

si on voulait lui faire écrire ce qu'il y a dans un fichier on sait qu'il faut faire :<syntaxhighlight lang="bash">
cat resultat.txt
</syntaxhighlight>Ca marche mais c'est pas ce que je veux vous montrer. C'est juste le fonctionnement de la commande <code>cat</code>. SI on lui donne un paramètre au lieu de copier l'entrée standard elle prends le paramètre en question, ouvre le fichier disque qui correspond de l'envoie sur la sortie standard. Là c'est le programme <code>cat</code> qui fait le travail.

Si on fait :<syntaxhighlight lang="bash">cat < resultat.txt # Attention un < s'est introduit dans cette commande!</syntaxhighlight>le résultat est exactement le même mais les actions effectuées sont totalement différentes!

Que fait le shell?

* Il ouvre <code>cat</code> sans paramètres qui va alors lire les lignes une par une sur l'entrée standard et les envoyer sur la sortie standard jusqu'à EOF. Il est bête mais on lui en demande pas plus.
* Mais le shell vois aussi que l'entrée standard de cat doit être "alimentée", non pas par le clavier mais par le contenu d'un fichier "resultat.txt"
* doc cat prends ce qu'il a en entrée (le shell lui envoie le contenu de resultat.txt) et l'envoie sur la sortie standard (ici l'écran)

On pourrait envisager un:<syntaxhighlight lang="bash">
cat < resultat.txt > resultat1.txt
</syntaxhighlight>...qui en fait est l'équivalant d'une copie de <code>resultat.txt</code> vers <code>resultat1.txt</code>.<syntaxhighlight lang="bash">
cp resultat1 resultat2
</syntaxhighlight>aurait fait pareil.

Encore plus pervère<syntaxhighlight lang="bash">
cat < resultat.txt | grep jpinon > resultat2.txt
</syntaxhighlight>Le shell traite comme ça:

* ouverture de <code>cat</code> "tout nu" qui lit sur l'entrée et envoie vers la sortie
* son entrée est connectée par shell sur le fichier <code>resultat.txt</code>. Ok, donc cat ne le sait pas mais il lit les lignes de <code>resultat.txt</code> une par une (c'est le shell qui les lui envoie).
* <code>cat</code> ecrit vers sa sortie standars mais le shell la redirrige vers <code>grep</code>.
* <code>grep</code> est presque aussi bête que <code>cat</code>. Il lit des lignes sur son entrée standard et les sort sur la sur la sortie standard pour peu que la ligne contienne la chaine en paramètre
* mais le shell est malin, il lui envoie sur son entrée standard la sortie de <code>cat</code>.
* a la fin le shell détourne la sortie de <code>grep</code> vers <code>resultat2.txt</code>

Tout ca se résume dans :

[[Fichier:Process-bash004.png|sans_cadre|914x914px]]

==== Remarque sur l'usage de "-" ====
Quelquefois il est indispensable de donner un fichier à une commande. dans ce cas là on peut remplacer ne nom du fichier par <code>"-"</code>.

Par exemple :<syntaxhighlight lang="bash">
cat -
</syntaxhighlight>est équivalant à:<syntaxhighlight lang="bash">
cat
</syntaxhighlight>bon pas très utile. Mais pensons au compilateur cc. une option est de lui demander de juste s'arreter au code assembleur mais pas d'aller jusqu'au code machine.<syntaxhighlight lang="bash">
cc -S hello.c
</syntaxhighlight>va, par défaut nous sortir un fichier hello.s qui contient le code assembleur. Imaginons que l'on veuille avoir ce code assembleur pour l'envoyer à un ami mais on le voudrait "gzippé". Problème cc sait sortir dans un fichier texte, on peut lui donner le nom du fichier de sortie par l'option "-o fichier.s" mais il ne sait pas zipper.

On porait faire ça en deux commandes :<syntaxhighlight lang="bash">
cc -o code.s -S hello.c
gzip code.s
</syntaxhighlight>en sortie on aura un fichier code.s.gz tres bien mais on a appris a faire des redirections! Alors on en fait!<syntaxhighlight lang="bash">cc -o - -S hello.c | gzip > code.s.gz</syntaxhighlight>C'est pas beau!

Avec un beau dessin :

[[Fichier:Process-bash005.png|sans_cadre|916x916px]]

On pourrait même l'envoyer directement à notre amis. Ce fichier code.s.gz j'en ai pas besoin moi!<syntaxhighlight lang="bash">cc -o - -S hello.c | gzip | mail -s "le code assembleur de hello.c" monami@gmail.com</syntaxhighlight>[[Fichier:Process-bash006.png|sans_cadre|916x916px]]

Bon comme ça ca parait un peu inutile mais imaginez une tâche [[cron]] qui lance, tous les jours à 4h le matin la commande suivante:<syntaxhighlight lang="bash">
df -h | mail -s "Etat des disques" moi@mondomaine.fr
</syntaxhighlight>Et oui! tous les matin j'aurais l'état de remplissage des disque de ma machine dans mes mails. On pourrait améliorer avec un <code>grep</code> entre <code>df</code> et <code>mail</code> pour ne mentionner que les disques qui posent un problème.

=== Redirection du flux d'erreur ===
Pour le moment on se traine notre (nos) flux d'erreurs qui vont vers la console. C'est bien car, même quand les sortie standards sont redirigées on peut voir que ça s'est mal passé.

Imaginons que les erreurs suivent le même chemin que la sortie avec:<syntaxhighlight lang="bash">
cc -o - -S hello.c | gzip | mail -s "le code assembleur de hello.c" monami@gmail.com
</syntaxhighlight>imaginons une erreur de compilation (j'ai oublié le int devant le main()):<syntaxhighlight lang="bash">
$ cc -S hello.c
hello.c:3:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
3 | main(){
| ^~~~
$
</syntaxhighlight>Dans le cas présent ca m'affiche l'erreur et tout s'arrête après <code>cc</code>. J'aurais mon message et mon ami ne recevra pas de mail.

Si la sortie d'erreur était gérée par le même flux que la sortie standard, je ne m'apercevrais de rien et mon ami recevrait le mail avec le message d'erreur. La loose!

Et bien voila pourquoi la sortie standard est gérée a part.

===== = = = = A FAIRE = = = = =====

Redirections bash (et en bourne shell en géneral)

2026-08-05T23:10:35Z

Jpinon :

Redirections bash (et en bourne shell en géneral)

2026-08-05T22:49:08Z

Jpinon :

Fichier:Process-bash006.png

2026-08-05T22:43:24Z

Jpinon :

send mail

Fichier:Process-bash005.png

2026-08-05T22:35:13Z

Jpinon :

compile en assembleur puis gzippe

Fichier:Process-bash004.png

2026-08-05T22:13:42Z

Jpinon :

file > cat | grep > file

Fichier:Process-bash002.png

2026-08-05T20:40:40Z

Jpinon :

redirection de base

Redirections bash (et en bourne shell en géneral)

2026-08-05T20:26:48Z

Jpinon :

Fichier:Process-bash000.png

2026-08-05T20:26:36Z

Jpinon : Jpinon a téléversé une nouvelle version de Fichier:Process-bash000.png

process la base des flux