eval is evil? Mais encore...

sputnick · Le 07/05/2023, à 21:15

Salut,

j'ai une variable

subdir="subdir{1..5}/subdir{1..5}/subdir{1..5}/subdir{1..5}"

Comment puis-je créer la hiérarchie?

Cela me donne:

mkdir -p $subdir
tree
.
└── subdir{1..5}
    └── subdir{1..5}
        └── subdir{1..5}
            └── subdir{1..5}

(Je connais la réponse, c'est juste une discussion autour d'un sujet précis...).

Dernière modification par sputnick (Le 07/05/2023, à 22:32)

soshy · Le 07/05/2023, à 22:21

eval mkdir -p "$subdir"

Mais si tu connais la réponse, je sais pas où tu veux en venir

sputnick · Le 07/05/2023, à 22:30

Non, juste que dans certains cas précis, on a besoin d'

eval

.

Un autre exemple est

eval $(ssh-agent)

, on est obligé d'utiliser eval.

Juste mentionner qu'il ne faut pas utiliser eval dans un contexte où c'est un user random qui entre des entrées par read ou via CGI, car c'est un risque de sécurité. Il y a donc des cas où eval est légit'.

Autre chose, dans le même genre, mais moins connu, quand on traite des nombres en contexte arithmétique en bash, il peut aussi y avoir injection de code:

read -p 'Type an integer >>> ' x
Type an integer >>> a[$(date >&2)]+42
((x++))
dim. 07 mai 2023 23:29:49 CEST

Voir https://www.vidarholen.net/contents/blog/?p=716

soshy · Le 08/05/2023, à 07:44

C'est la base de ce qu'on apprend en informatique:
- ne jamais faire confiance aux input user
- valider que les saisies utilisateur sont conformes à ce qu'on attend

Et éviter (car il y a parfois des cas legit) d'exécuter la saisie de l'utilisateur directement. Dans un autre domaine, ça donne les injections sql.

Dernière modification par soshy (Le 08/05/2023, à 07:44)

Watael · Le 09/05/2023, à 16:59

sputnick a écrit :

j'ai une variable
subdir="subdir{1..5}/subdir{1..5}/subdir{1..5}/subdir{1..5}"
Comment puis-je créer la hiérarchie?

là, on quitte le domaine du simple codage, et on aborde le méta-codage, où le langage "s'auto-programme".

Évidemment, les recommandations qui s'appliquent au codage ne peuvent plus s'appliquer à la méta-programmation.

j'ai une variable

subdir="subdir{1..5}/subdir{1..5}/subdir{1..5}/subdir{1..5}"

si je devais en arriver là, c'est que je serais allé trop loin, et je rétro-pédalerais pour chercher comment faire autrement.

Dernière modification par Watael (Le 09/05/2023, à 17:13)

sputnick · Le 10/05/2023, à 02:07

Dans certains cas, quand il n'y a pas d'interactions avec les utilisateurs, on peut très bien utiliser eval.

Cela évite d'inutiles complication.

Faut juste savoir s'en servir proprement, c'est comme un couteau.

On n'interdit pas les couteaux, pourtant, ça tue des gens.

Si on interdit eval, il faut aussi interdire les calculs arithmétiques si on a pas assainit ('sanitized' plus parlant en Anglais) les entrées.

C'est le même souci que les injections SQL.

Watael · Le 10/05/2023, à 04:08

on n'interdit pas, on prévient son utilisation.

On n'interdit pas les couteaux, pourtant, ça tue des gens.

si, si. le port d'un couteau (catégorie D) est interdit sans motif légitime.
En gros, porter un couteau, c'est mal.

et puis, on ne donne pas un couteau acéré et aiguisé à un enfant avant qu'il ait acquis certaines compétences.
En gros, un couteau, c'est dangereux, et donc c'est mal.

quant aux "inutiles complications" : « l'important, ce n'est pas la destination, c'est le voyage. »

pour les évaluations arithmétiques, bash peut typer des entiers.

« autre chose ? je peux ?... »

sputnick · Le 10/05/2023, à 04:26

De la rhétorique tout ça. Je dit juste qu'il faut savoir l’utiliser, à bon escient. Certes pas pour tout et n'importe quoi.

Que veut tu dire par typer des entiers ?

Il n'y pas pas moins typé que le shell, en tout cas bash, en l'espèce.

Watael · Le 10/05/2023, à 04:32

$ declare -i x
$ x=foo
$ echo $x
0
$

sputnick · Le 10/05/2023, à 04:37

Wé, c'est un bon moyen de récupérer une entrée utilisateur quand on s'attend à un entier et pas autre chose:

declare -i var
read -p 'Entrer un entier >>> ' var
echo $var

sputnick · Le 12/05/2023, à 00:39

Cette discussion est tellement dérisoire à coté de ce que ChatGPT change...

Je lui demande:

Given a Python Selenium 'WebElement' element 'images', generate a list comprehension to get all 'src' attributes

Réponse:

src_list = [img.get_attribute('src') for img in images]

diesel · Le 12/05/2023, à 07:14

Ouairf..., il a donné le code.

Watael, en plus, il t'explique pourquoi.

Amicalement.

Jean-Marie

bruno · Le 12/05/2023, à 07:52

sputnick a écrit :

, generate a list comprehension to get all 'src' attributes

Oui c'est vrai que c'est étonnant cette capacité de chatGPT à comprendre du mauvais anglais

Blague à part quel rapport avec le sujet initial ?

sputnick · Le 13/05/2023, à 03:24

En fait, l'utilisation de

declare -i

est considéré par les pro de bash comme n'étant pas fiable.

Exemple:

$ declare -i x; y=z; z=10+30; read x <<<'y'; declare -p x
declare -i x="40"

Une manière fiable de faire des tests sur les entrées utilisateur: https://mywiki.wooledge.org/BashFAQ/054

Cette page est LA référence en matière de bash et de bonnes pratiques.

Watael · Le 13/05/2023, à 03:43

En fait, l'utilisation de
declare -i
est considéré par les pro de bash comme n'étant pas fiable.

donne tes sources.
parce que faire de telles assertions et renvoyer vers d'autres "vérités", ça c'est de la rhétorique.

que x fasse l'évaluation arithmétique ne me choque pas, je fais souvent x+=1 en ayant déclaré x comme nombre.
ce qui me chagrine, c'est le passage de "variables" y=z et read x <<<'y'

bruno · Le 13/05/2023, à 08:29

sputnick a écrit :

En fait, l'utilisation de
declare -i
est considéré par les pro de bash comme n'étant pas fiable.

C'est parfaitement fiable pour ce que c'est censé faire : s'assurer que la variable ainsi définie soit bien évaluée comme un entier dans la suite du script. Ce n'est pas destiné à vérifier ou à valider les entrées des utilisateurs.

sputnick · Le 13/05/2023, à 13:49

bruno a écrit :

C'est parfaitement fiable pour ce que c'est censé faire : s'assurer que la variable ainsi définie soit bien évaluée comme un entier dans la suite du script. Ce n'est pas destiné à vérifier ou à valider les entrées des utilisateurs.

Dans ce cas on est d'accord.

Pour une vraie vérification:

case "$x" in
    '' | *[!0123456789]*)
        printf '%s\n' "$0: $x: invalid digit" >&2; exit 1;;
esac

Tawal · Le 13/05/2023, à 14:45

Hello,

Je suis surpris que [0-9] et [:digit:] peuvent contenir autre chose que des chiffres selon les locales !
Je comprends pour les langues "graphiques" (chinois, arabe ...).
Mais pour les langues "occidentales" ?

Postmortem · Le 26/05/2023, à 14:39

Tawal a écrit :

Je suis surpris que [0-9] et [:digit:] peuvent contenir autre chose que des chiffres selon les locales !

Salut,
Que « [0-9] » contienne autre chose que des chiffres, je pige pas...
Par contre, pour « [:digit:] », je me dis que c'est pas délirant dans le cas où on est en hexadécimal (sauf si tu inclus déjà les "lettres/chiffres" dans ce que tu appelles chiffres ! )

bruno · Le 26/05/2023, à 15:23

Tawal a écrit :

Je suis surpris que [0-9] et [:digit:] peuvent contenir autre chose que des chiffres selon les locales !

Un exemple ?

Tawal a écrit :

Je comprends pour les langues "graphiques" (chinois, arabe ...).
Mais pour les langues "occidentales" ?

C'est quoi des langues graphiques ? Toute langue écrite est forcément graphique…
Que je sache toutes les langues utilisent maintenant le système de numération indo-arabe.

Postmortem a écrit :

Par contre, pour « [:digit:] », je me dis que c'est pas délirant dans le cas où on est en hexadécimal (sauf si tu inclus déjà les "lettres/chiffres" dans ce que tu appelles chiffres ! tongue )

Dans la norme POSIX [:digit:] correspond strictement à [0-9] et pour l'hexadécimal on a [:xdigit:] qui correspond strictement à [0-9A-Fa-f] (Réf.)

Dernière modification par bruno (Le 26/05/2023, à 15:24)

Postmortem · Le 26/05/2023, à 15:43

bruno a écrit :

Dans la norme POSIX [:digit:] correspond strictement à [0-9] et pour l'hexadécimal on a [:xdigit:] qui correspond strictement à [0-9A-Fa-f] (Réf.)

J'avais oublié « [:xdigit:] », merci !
Mais sinon, je faisais juste une supposition, ne comprenant pas trop comment « [0-9] » pouvait matcher autre chose que des chiffres.

sputnick · Le 26/05/2023, à 15:49

Postmortem, je pense que tu a mal suivi.

Le code

' | *[!0123456789]*)
      ^
  negation

N’autorise que les digits. Pas un espace, pas une lettre.

Tout est dans la négation: !

Dernière modification par sputnick (Le 26/05/2023, à 15:51)

Postmortem · Le 26/05/2023, à 16:51

@sputnick,oui oui, je répondais par rapport au message de Tawal :

Tawal a écrit :

Je suis surpris que [0-9] et [:digit:] peuvent contenir autre chose que des chiffres selon les locales !

Je comprends qu'il dit que « [0-9] » pourrait sortir autre chose que des chiffres. D'où mon interrogation/suggestion.

LeoMajor · Le 26/05/2023, à 17:58

salut,
ramener au contexte declare -i x, et regex [[ ]], natif au bash
1/ cela signifie que x n'est pas un vrai integer, mais juste un string qui ressemble à un integer.
Un regex attend en stdin/input un string mais certainement pas un vrai integer/float ..., qui retourne une erreur de typage, sémantique.

2/declare -i est en contradiction avec printf '%d' $x
$ declare -i a="chocolat"; declare -p a
declare -i a="0"

le bash n'est ni un langage déclaratif, ni typé, ni objet.
Il ne sait pas faire d'inférence, auto c++/ variant /équivalence python.

à adapter
cat ./declarei.bash

#!/bin/bash
#Type mismatch: wanted Integer, got anything: Semantic Error

stopit() {
father=$(ps h -o ppid -p $$)
if [ -n "$father" ]; then
    kill -s SIGINT $$ -term "$father"
else
    kill -term $$
fi
}

if [ $# -ne  1 ]; then echo  "one argument only or missing" >&2; stopit; fi
tmp=$(sed 's/^"//;s/"$//' <<<"$1")
printf '%d' $tmp &>/dev/null ||  { echo  "Type mismatch: wanted Integer" >&2; stopit;}
declare -i ret # ne sert strictement à rien
ret=$(printf '%d' $tmp &2>/dev/null)
echo -n "$ret"
exit 0

while true; do read -rp "A quel âge peut-on vôter ? " age; [ $(./declarei.bash "$age") -ge 18 ] && echo "ok" || echo "ko"; done

Watael · Le 26/05/2023, à 18:05

koi?! comment, mais kOa !?
une regex attend ce qu'elle déclare·
une chaîne n'est pas un nombre, et en tant que nombre une chaîne vaut 0·

oulala! les codeurs ne sont pas des programmeurs. pfff, le vieux troll!

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 07/05/2023, à 21:15

eval is evil? Mais encore...

#2 Le 07/05/2023, à 22:21

Re : eval is evil? Mais encore...

#3 Le 07/05/2023, à 22:30

Re : eval is evil? Mais encore...

#4 Le 08/05/2023, à 07:44

Re : eval is evil? Mais encore...

#5 Le 09/05/2023, à 16:59

Re : eval is evil? Mais encore...

#6 Le 10/05/2023, à 02:07

Re : eval is evil? Mais encore...

#7 Le 10/05/2023, à 04:08

Re : eval is evil? Mais encore...

#8 Le 10/05/2023, à 04:26

Re : eval is evil? Mais encore...

#9 Le 10/05/2023, à 04:32

Re : eval is evil? Mais encore...

#10 Le 10/05/2023, à 04:37

Re : eval is evil? Mais encore...

#11 Le 12/05/2023, à 00:39

Re : eval is evil? Mais encore...

#12 Le 12/05/2023, à 07:14

Re : eval is evil? Mais encore...

#13 Le 12/05/2023, à 07:52

Re : eval is evil? Mais encore...

#14 Le 13/05/2023, à 03:24

Re : eval is evil? Mais encore...

#15 Le 13/05/2023, à 03:43

Re : eval is evil? Mais encore...

#16 Le 13/05/2023, à 08:29

Re : eval is evil? Mais encore...

#17 Le 13/05/2023, à 13:49

Re : eval is evil? Mais encore...

#18 Le 13/05/2023, à 14:45

Re : eval is evil? Mais encore...

#19 Le 26/05/2023, à 14:39

Re : eval is evil? Mais encore...

#20 Le 26/05/2023, à 15:23

Re : eval is evil? Mais encore...

#21 Le 26/05/2023, à 15:43

Re : eval is evil? Mais encore...

#22 Le 26/05/2023, à 15:49

Re : eval is evil? Mais encore...

#23 Le 26/05/2023, à 16:51

Re : eval is evil? Mais encore...

#24 Le 26/05/2023, à 17:58

Re : eval is evil? Mais encore...

#25 Le 26/05/2023, à 18:05

Re : eval is evil? Mais encore...

Pied de page des forums