$ screenfetch
           /:-------------:\          user@host
        :-------------------::        OS: Fedora 30 Thirty
      :-----------/shhOHbmp---:\      Kernel: x86_64 Linux 5.3.16-200.fc30.x86_64
    /-----------omMMMNNNMMD  ---:     Uptime: 13h 27m
   :-----------sMMMMNMNMP.    ---:    Packages: 2531
  :-----------:MMMdP-------    ---\   Shell: python3.8
 ,------------:MMMd--------    ---:   Resolution: 1920x1080
 :------------:MMMd-------    .---:   DE: GNOME 
 :----    oNMMMMMMMMMNho     .----:   WM: GNOME Shell
 :--     .+shhhMMMmhhy++   .------/   WM Theme: Adwaita
 :-    -------:MMMd--------------:    GTK Theme: Adwaita [GTK2/3]
 :-   --------/MMMd-------------;     Icon Theme: Adwaita
 :-    ------/hMMMy------------:      Font: Cantarell 11
 :-- :dMNdhhdNMMNo------------;       CPU: Intel Core i7-8550U @ 8x 4GHz
 :---:sdNMMMMNds:------------:        GPU: Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2) 
 :------:://:-------------::          RAM: 6817MiB / 15779MiB
 :---------------------://

Shell: Comme vous pouvez le voir, c'est un peu triste. Comment screenfetch prend-il un shell en premier lieu? J'ai pensé, alors je l'ai lu. Si possible, veuillez afficher Xonsh.

Lire screenfetch

screenfetch:GitHub

screenfetch est un script shell ... effrayant Apparemment, screenfetch-dev est comme le corps principal.

Donc, je veux connaître la relation shell, donc Ctrl + F avec shell.

Ensuite, detectshell () sur la 1843ème ligne est suspect à cause de la condition jaune.

Lisons-le pour le moment

La première moitié est affichée pour le moment.

detectshell () {
	if [[ ! "${shell_type}" ]]; then
		if [[ "${distro}" == "Cygwin" || "${distro}" == "Msys" || "${distro}" == "Haiku" || "${distro}" == "Alpine Linux" ||
			"${distro}" == "Mac OS X" || "${distro}" == "TinyCore" || "${distro}" == "Raspbian" || "${OSTYPE}" == "gnu" ]]; then
			shell_type=$(echo "$SHELL" | awk -F'/' '{print $NF}')
		elif readlink -f "$SHELL" 2>&1 | grep -q -i 'busybox'; then
			shell_type="BusyBox"
		else
			if [[ "${OSTYPE}" =~ "linux" ]]; then
				shell_type=$(tr '\0' '\n' </proc/$PPID/cmdline | head -1)
			elif [[ "${distro}" =~ "BSD" ]]; then
				shell_type=$(ps -p $PPID -o command | tail -1)
			else
				shell_type=$(ps -p "$(ps -p $PPID | awk '$1 !~ /PID/ {print $1}')" | awk 'FNR>1 {print $1}')
			fi
			shell_type=${shell_type/-}
			shell_type=${shell_type//*\/}
		fi
	fi

        .....

	myShell=${shell_type}
	verboseOut "Finding current shell...found as '$myShell'"
}

En fait, si vous le regardez avec l'option -v, vous pouvez voir que la ligne verboseOut" Trouver le shell actuel ... trouvé comme '$ myShell' " bouge.

Tout d'abord, regardons à l'intérieur du premier si.

$ shell_type est comme une variable shell_type (comme Shinjiro Koizumi). Tout d'abord, après avoir regardé le type d'OS, il semble que le shell soit acquis selon l'OS. Puisque le type de système d'exploitation est linux, regardons le bloc de ʻif [["$ {OSTYPE}" = ~ "linux"]] . Au fait, = ~` semble être une comparaison d'expressions régulières. Je savais juste.

Eh bien, comme vous pouvez le voir, tr '\ 0' '\ n' </ proc / $ PPID / cmdline | head -1 est le shell_type. Je le traite un peu en retard, mais c'est plus tard.

/ proc / $ PPPID / cmdline est la commande du processus de $ PPPID, comme vous pouvez le deviner à partir du nom. Je ne sais pas ce qu'est le pid $ PPPID, mais c'est probablement un shell. N'est-il pas pris avec un autre code? Nous allons jeter un coup d'oeil.

$  ps
  PID TTY          TIME CMD
20316 pts/5    00:00:01 xonsh
21745 pts/5    00:00:00 ps

$  cat /proc/20316/cmdline                                                          
/home/tia/.pyenv/versions/3.8.1/bin/python3.8-u/home/tia/.pyenv/versions/3.8.1/bin/xonsh--login

Oui. Eh bien comme prévu. J'ai pensé, mais quelque chose est étrange. python3.8-u ??? J'ai pensé cela, mais j'ai regardé le côté droit. Il n'y a pas d'espace. Pourquoi. peu importe.

xonsh ne lance pas directement le binaire xonsh, il lance python. Non, c'est vrai. C'est naturel.

Mais bon, j'ai en quelque sorte compris la cause. Puisque screenfetch obtient la commande qui démarre le shell et récupère le nom du shell, xonsh qui démarre python au lieu du shell directement est vu comme python au lieu de xonsh.

Jetons un coup d'œil à la commande tr et à la commande head. Parce que je ne sais pas.

... gg temps ...

tr est le remplacement des caractères. str.replace (). ʻEcho hoge | tr'hoge''fuga'signifie'hoge'.replace (' hoge ',' fuga ')`. En python

head récupère la ligne spécifiée. str.splitlines (False) [n]. ʻEcho "hoge \ nfuga" | head -1signifie'hoge \ nfuga'.splitlines (False) [0]`.

Ainsi, le contenu de cmdline est tr '\ 0' '\ n'. Eh bien, quand j'ai pensé que l'espace manquait, il se peut qu'il y ait \ 0 au lieu de l'espace. Eh bien, savez-vous si vous l'avez réellement frappé?

$  tr '\0' '\n'  < /proc/20316/cmdline
/home/tia/.pyenv/versions/3.8.1/bin/python3.8
-u
/home/tia/.pyenv/versions/3.8.1/bin/xonsh
--login

D'accord. C'est peut-être comme ça. La ligne se brise correctement.

Et comme il s'agit de «head -1», la première ligne est supprimée. Autrement dit, / home / tia / .pyenv / versions / 3.8.1 / bin / python3.8. C'est complètement ça.

et enfin

shell_type=${shell_type/-}
shell_type=${shell_type//*\/}

.. Peut-être que je retire le plus à droite de /.

Vous connaissez maintenant le shell_type.

Eh bien, la seconde moitié.


detectshell () {

        ......

	case $shell_type in
		bash)
			shell_version_data=$( detectshell_ver "$shell_type" "^GNU.bash,.version" "4" )
			;;
		BusyBox)
			shell_version_data=$( busybox | head -n1 | cut -d ' ' -f2 )
			;;
		csh)
			shell_version_data=$( detectshell_ver "$shell_type" "$shell_type" "3" )
			;;
		dash)
			shell_version_data=$( detectshell_ver "$shell_type" "$shell_type" "3" )
			;;
		ksh)
			shell_version_data=$( detectshell_ver "$shell_type" "version" "5" )
			;;
		tcsh)
			shell_version_data=$( detectshell_ver "$shell_type" "^tcsh" "2" )
			;;
		zsh)
			shell_version_data=$( detectshell_ver "$shell_type" "^zsh" "2" )
			;;
		fish)
			shell_version_data=$( fish --version | awk '{print $3}' )
			;;
	esac

	if [[ -n $shell_version_data ]];then
		shell_type="$shell_type $shell_version_data"
	fi

	myShell=${shell_type}
	verboseOut "Finding current shell...found as '$myShell'"
}

Ceci est ... complètement ignoré. Si $ shell_type est l'un des bash, BusyBox, csh, dash, ksh, tcsh, zsh, fish, il semble lire la version. Ignorer Ignorer.

Maintenant, la conclusion est atteinte.

Puisque xonsh n'appelle pas bash directement comme bash, mais s'exécute sur python xonsh et python, le pytohn directement appelé est détecté comme un shell. c'est tout.

Contre-mesures

Jetons un œil à la première ligne de detectshell ().

detectshell () {
    if [[ ! "${shell_type}" ]]; then
...

Oui, regardez d'abord si $ shell_type est déjà défini. En d'autres termes, comme contre-mesure

$ $shell_type = $(xonsh -V).strip()
$ screenfetch

c'est tout!

           /:-------------:\          user@host
        :-------------------::        OS: Fedora 30 Thirty
      :-----------/shhOHbmp---:\      Kernel: x86_64 Linux 5.3.16-200.fc30.x86_64
    /-----------omMMMNNNMMD  ---:     Uptime: 14h 28m
   :-----------sMMMMNMNMP.    ---:    Packages: 2531
  :-----------:MMMdP-------    ---\   Shell: xonsh/0.9.13.dev1
 ,------------:MMMd--------    ---:   Resolution: 1920x1080
 :------------:MMMd-------    .---:   DE: GNOME 
 :----    oNMMMMMMMMMNho     .----:   WM: GNOME Shell
 :--     .+shhhMMMmhhy++   .------/   WM Theme: Adwaita
 :-    -------:MMMd--------------:    GTK Theme: Adwaita [GTK2/3]
 :-   --------/MMMd-------------;     Icon Theme: Adwaita
 :-    ------/hMMMy------------:      Font: Cantarell 11
 :-- :dMNdhhdNMMNo------------;       CPU: Intel Core i7-8550U @ 8x 4GHz
 :---:sdNMMMMNds:------------:        GPU: Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2) 
 :------:://:-------------::          RAM: 6954MiB / 15779MiB
 :---------------------://

Quand je screenfetch avec xonsh, python x.x sort et c'est triste

Lire screenfetch

Contre-mesures