[Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

Hizoka · Le 18/01/2023, à 12:08

J'y ai cru !!

ls -d /media/hizoka/PointDeMontage/DoSSiEr/FiChIeR.Pdf*
/media/hizoka/PointDeMontage/DoSSiEr/Fichier.pdf

Le nom du fichier est OK mais pas celui des dossiers !!

C'était franchement bien tenté !
Je regarde s'il y a moyen de boucler sur chaque dossier de l'arborescence pour vérifier qu'il existe vraiment...
Ca complique pas mal les choses car en utilisant l'étoile, je me retrouve parfois avec plusieurs dossiers...

Dernière modification par Hizoka (Le 18/01/2023, à 12:08)

iznobe · Le 18/01/2023, à 12:12

Salut , Arf , dommage , je n' ai plus de cartouche

iznobe · Le 18/01/2023, à 12:19

finalement peut etre que si

la solution dans ce post https://stackoverflow.com/questions/321 … nsensitive qui date de 12 ans en arriere , faut aller chercher loin parfois

je n' ai pas testé cela dit . et ca risque d' etre bien plus long ( traitement ) ... d ' apres l ' explication du donneur de la solution .

Dernière modification par iznobe (Le 18/01/2023, à 12:22)

Hizoka · Le 18/01/2023, à 12:22

J'en suis arrivé à ça :

# Exemple de casse pourrie
$path="/media/hizoka/PointDeMontage/DoSSiEr/FichiER.PdF"

# Conversion en tableau en séparant chaque niveau
Elements=( $(IFS='/'; echo $path) )

# Variable qui contiendra l'adresse finale
new=""

# Boucle sur les niveaux à partir du Point de montage, inutile de travailler sur les dossiers /media/hizoka/PointDeMontage/
for el in "${Elements[@]:4}"
do
    # Recherche l'élement $el sans prise en compte de lacasse dans le dossier old qui par défaut vaut /media/hizoka/PointDeMontage/
    new=$(find "${old:-/media/hizoka/PointDeMontage/}" -maxdepth 1 -iname "$el")
done

# Nouvelle adresse
echo "new : $new"
# /media/hizoka/PointDeMontage/Dossier/Fichier.pdf

Mais c'est plus pour le fun car tous ces find rajoute plus de temps que de faire un grep -i depuis php.
En effet, il y a des milliers de sous dossiers même si on ne descend que de 2 ou 3 niveaux.

Je passe par find pour éviter d'avoir plusieurs retours que me donne ls que je dois coupler à un head...

Et find, comme ls ne corrige que le dernier niveau donc impossible de faire :

find "/media/hizoka/PointDeMontage/DoSSiEr/" -iname "FichiER.PdF"
# /media/hizoka/PointDeMontage/DoSSiEr/Fichier.pdf

Dernière modification par Hizoka (Le 18/01/2023, à 12:30)

iznobe · Le 18/01/2023, à 12:26

et avec la " solution " indiquée dans le lien de mon message precedent , tu as pu voir si tu arrivais a tes fins ?
ca correspond pile a ce que tu cherches a faire d' apres l' ennoncé .

peut etre faudra t il supprimer le parametre " -maxdepth 1 " afin d' explorer plusieurs sous-repertoires dans ton cas .

EDIT : ou pas :

BUTunless you want to search everything from '/' on down, you must check component of the path individually. There is no way around this; you can't magically check a whole path for case-insensitive matches on a case-sensitive filesystem!

Dernière modification par iznobe (Le 18/01/2023, à 12:31)

Hizoka · Le 18/01/2023, à 12:30

Bah, je l'avais vu ce truc, mais comme je dis, le find ne met à jour que le nom du fichier, pas de l'arborescence.

Il va me dire que le fichier existe mais me renverra pas la bonne casse pour autant.

find "/media/hizoka/PointDeMontage/DoSSiEr/" -iname "FichiER.PdF"
# /media/hizoka/PointDeMontage/DoSSiEr/Fichier.pdf

Dernière modification par Hizoka (Le 18/01/2023, à 12:31)

iznobe · Le 18/01/2023, à 12:33

effectivement , il dit que c ' est impossible :

BUTunless you want to search everything from '/' on down, you must check component of the path individually. There is no way around this; you can't magically check a whole path for case-insensitive matches on a case-sensitive filesystem!

d ' apres ceque j' ai compris , ca ne prend que sur un repertoire precis .

Peut etre faudrait il voir dans un autre langage , peut etre avec python ?

Hizoka · Le 18/01/2023, à 13:01

Ma soluce fonctionne mais pas très réactive

Au final mon find global de 5 min puis un grep -i au besoin depuis php est bien plus efficient.

Je viens de tester :
- Chargement du fichier Fichiers.txt dans un array
- Nouvel array avec toutes les valeurs en minuscule
- Recherche de l'adresse en minuscule dans ce nouvel array
- Avec la clé, on recherche la valeur du 1er array
via :

$Fichiers = file("Fichiers.txt", FILE_IGNORE_NEW_LINES);
$FichiersLower = array_map('strtolower', $Fichiers);
$Cle = array_search(strtolower($path), $FichiersLower);
if($Cle !== false) echo $Fichiers[$Cle];

Mais la recherche prend 4x plus de temps qu'en appelant grep.

Très intéressant tout ça, ça montre qu'un appel externe peut être plus adapté.

Je suis pas trop chaud pour commencer à partir sur d'autres langages XD

En tout cas, un grand merci à vous, ça permet d'apprendre de nouvelles choses.

Je vais valider le sujet

Dernière modification par Hizoka (Le 18/01/2023, à 13:06)

iznobe · Le 18/01/2023, à 13:56

sinon dans le lien , le gars qui a ecrit le dernier commentaire utilise une fonction :

Then, if the command:

regfile=$(find $mnt -iwholename "$mnt/window*/system32/config/software")

do the job, as this command is based on $mnt, find will stupidely scan the whole filesystem and take a lot of time.

My pure bash function

For this, I wrote this ipath function:

ipath() {
    if [[ $1 == -v ]]; then local -n _res=$2; shift 2; else local _res; fi
    local _path _i _chr
    _res=
    for ((_i=0;_i<${#1};_i++));do
        _chr=${1:_i:1} _chr=${_chr,}
        [[ $_chr != ${_chr^} ]] && _path+="[$_chr${_chr^}]" ||
                _path+=$_chr
    done
    _path=($_path)
    [[ -e ${_path[0]} ]] || return 1
    if [[ ${_res@A} == _res=* ]] ;then
        printf "%s\n" "${_path[@]}"
    else
        _res=("${_path[@]}")
    fi
}

Then for testing:

$ ipath "$mnt/window*/system32/config/software"
/tmp/tmp.Q2czvPDs5m/Windows/System32/config/SOFTWARE

$ ipath ~/desktop
/home/user/Desktop

for use as a variable:

$ ipath -v regfile "$mnt/window*/system32/config/software"
$ echo $regfile 
/tmp/tmp.Q2czvPDs5m/Windows/System32/config/SOFTWARE

$ ipath -v DeskDir ~/desktop
echo $DeskDir
/home/user/Desktop

Another test with multiple answer and spaced path:

$ ipath $mnt/program\*/int\*er
/tmp/tmp.jVs5mPGbJm/Program Files/Internet Explorer
/tmp/tmp.jVs5mPGbJm/Program Files (x86)/Internet Explorer

$ ipath -v iedirs "$mnt/program*/int*er"
$ declare -p iedirs
declare -a iedirs=([0]="/tmp/tmp.jVs5mPGbJm/Program Files/Internet Explorer" [1]="/tmp/tmp.jVs5mPGbJm/Program Files (x86)/Internet Explorer")

mais mes faible competences ne peuvent rien a ce niveau là .

Cependant je sais que toi tu touches bien ta bille en bash peut etre est ce exploitable .

iznobe · Le 18/01/2023, à 14:31

sinon , un autre possibilité pour afficher tous les noms de fichiers avec leur aborescence :

sudo apt install tree; man tree

et donc la commande :

tree /media/hizoka/PointDeMontage/ -fi

t ' affichera le chemin absolu de chaque fichiers sans rien d' autres avec la casse exacte

un exemple de retour chez moi :

tree "/datas/iznobe/VirtualBox VMs" -fi
/datas/iznobe/VirtualBox VMs
/datas/iznobe/VirtualBox VMs/ubuntu_22.10
/datas/iznobe/VirtualBox VMs/ubuntu_22.10/Logs
/datas/iznobe/VirtualBox VMs/ubuntu_22.10/Logs/VBox.log
/datas/iznobe/VirtualBox VMs/ubuntu_22.10/Logs/VBox.log.1
/datas/iznobe/VirtualBox VMs/ubuntu_22.10/Logs/VBox.log.2
/datas/iznobe/VirtualBox VMs/ubuntu_22.10/Logs/VBox.log.3
/datas/iznobe/VirtualBox VMs/ubuntu_22.10/Snapshots
/datas/iznobe/VirtualBox VMs/ubuntu_22.10/Snapshots/2022-11-18T08-27-38-351321000Z.sav
/datas/iznobe/VirtualBox VMs/ubuntu_22.10/Snapshots/2022-11-18T13-25-20-456254000Z.sav
/datas/iznobe/VirtualBox VMs/ubuntu_22.10/Snapshots/{b42a8f54-b2e2-4636-93da-f3c6ca232b22}.vdi
/datas/iznobe/VirtualBox VMs/ubuntu_22.10/Snapshots/{dd8edb3a-38c1-4b0b-aa76-cecaaa23afeb}.vdi
/datas/iznobe/VirtualBox VMs/ubuntu_22.10/ubuntu_22.10.vbox
/datas/iznobe/VirtualBox VMs/ubuntu_22.10/ubuntu_22.10.vbox-prev
/datas/iznobe/VirtualBox VMs/ubuntu_22.10/ubuntu_22.10.vdi

3 directories, 11 files
iznobe@iznobe-PC:~$

plus simple y a pas et tu es sur que le fichier existe . il est aussi possible de ne pas avoir les dossiers dans le retour . cela dit la commande n' est pas des plus rapides . sur 650000 fichiers je ne sais pas ce que ca donnerait .

chez moi , 25 secondes pour : 115441 directories, 1299447 files , ce me parait pas si vilain finalement

Dernière modification par iznobe (Le 18/01/2023, à 14:41)

Watael · Le 18/01/2023, à 16:12

j'ai mis quelques commentaires :

ipath() {
    if [[ $1 == -v ]]; then local -n _res=$2; shift 2; else local _res; fi
    local _path _i _chr
    _res= #donc, quoi qu'il se soit passé dans le test précédent, on efface la variable
    for ((_i=0;_i<${#1};_i++));do
        _chr=${1:_i:1} _chr=${_chr,} #on passe la lettre en minuscule, il y a donc peu de chances que le test suivant soit `vrai'
        [[ $_chr != ${_chr^} ]] && _path+="[$_chr${_chr^}]" || _path+=$_chr
    done
    _path=($_path) #je ne comprend pas la nécessité de ce tableau
    [[ -e ${_path[0]} ]] || return 1 #s'il n'y a pas de `_path', c'est qu'il n'y a pas de troisième argument; autant commencer par là
    if [[ ${_res@A} == _res=* ]] ;then #je rappelle que `_res' a été effacée
        printf "%s\n" "${_path[@]}"
    else
        _res=("${_path[@]}")
    fi
}

mais, ça fonctionne ?

iznobe · Le 18/01/2023, à 16:19

Bonjour Watael , si tu me poses la question a moi , je te repondrais que je ne teste pas des codes que je comprends pas ( et vu mes competences a ce niveau , j' en teste pas des masses du coup )

Dernière modification par iznobe (Le 18/01/2023, à 16:21)

iznobe · Le 18/01/2023, à 16:45

Bon je suppose que " tree " est une reponse a coté de la plaque

mais je ne comprends toujours pas pourquoi la casse ne correspond pas entre ton point de montage et le serveur windows .

Si dans ton point de montage tu as un fichier nommé par exemple "/media/hizoka/PointDeMontage/DoSSiEr/Fichier.pdf "
sur le serveur la casse est différente ? ( excuse mon ignorance , mais je ne pratique jamais dans ce sens là ) .

ca ne serait pas un soucis dans le montage ?

Coeur Noir a écrit :

geole a écrit :
Coeur Noir a écrit :
Doit bien y avoir moyen de demander à Samba de n'accepter que des noms de fichiers/dossiers compatibles Win ?
Bonjour
Il faut monter le répertoire avec l'option windows_names
D'une part je supposais que c'était déjà fait.
Et d'autre part ça n'est valable que si le montage a lieu dans un système Linux. Dans ce cas c'est le pilote ntfs qui agit, pas Samba.
Iznobe c'est donc à vérifier, si le partage Samba est dans un système Linux, les options de son montage devraient inclure windows_names et pourquoi pas utf8 ou locale=fr_FR.UTF-8 ça devrait limiter la possibilité de produire des noms de fichiers incompatibles Windows.

Dernière modification par iznobe (Le 18/01/2023, à 16:49)

Hizoka · Le 18/01/2023, à 18:57

@iznobe

tree -fi /media/hizoka/PointDeMontage/DoSSiEr/
/media/hizoka/PointDeMontage/DoSSiEr/Fichier.pdf

Donc le dossier n'a pas sa casse correcte

tree -fi /media/hizoka/PointDeMontage/ > Fichiers.txt

remplace ma commande find de base, le tree met 30sec de moins à priori lors de la génération du fichier contenant les 650 000 adresses.

mais je ne comprends toujours pas pourquoi la casse ne correspond pas entre ton point de montage et le serveur windows .

Bah si, elle correspond...
Ce sont les URI contenues dans la base de données que j'extraie qui ne foutent de la casse.
Sous windows, le lien est toujours bon car la casse n'est pas prise en compte.

Windows : E:/Dossier/Fichier.pdf
Linux : /media/hizoka/PointDeMontage/Dossier/Fichier.pdf
URI pourrie : e:/DOSSIER/fichier.PDF
Sous windows, si tu colles cette URI dans le navigateur de fichier, il te l'ouvre.
Sous Linux, tu peux toujours courir car casse oblige, cet URI (une fois convertie) ne mène nulle part.

@Watael
J'ai un peu de mal à piger ce qu'il se passe mais oui, ça fonctionne, ça prend 1/2 seconde.

Tawal · Le 18/01/2023, à 19:49

Edit2: Au sujet du message #36

Watael a écrit :

_res= #donc, quoi qu'il se soit passé dans le test précédent, on efface la variable

Oui, mais il reste le fait que la variable _res n'a pas les même attributs.
Soit tu utilises la fonction "avec option -v var_globale", soit sans.
Dans le 1er cas, on récupère le résultat dans la variable globale, dans le deuxième, il est affiché (récupérable dans une variable, pipe, paramètre ...).

Edit:
Par contre son test ne devrait pas être :

[[ ${_res@A} == _res='*' ]]

?
Edit3:
Quoique non, ce n'est pas une erreur, mais les apostrophes sont inutiles. Son test est bon
J'ai compris ce qu'il ce passe dans ce script
Edit4:
Pour la compréhension :
Si la variable _res est une référence à $2 ('local -n _res=$2), alors ${_res@A} donne $2=contenu de la variable portant le nom contenu dans $2.
Sinon, ${_res@A} donne _res=''

Edit5:

Watael a écrit :

_chr=${1:_i:1} _chr=${_chr,} #on passe la lettre en minuscule, il y a donc peu de chances que le test suivant soit `vrai'
        [[ $_chr != ${_chr^} ]] && _path+="[$_chr${_chr^}]" || _path+=$_ch

Pas tout à fait, il est toujours vrai.
$_chr ==> minuscule
!= ==> n'est pas égal à
${_chr^} ==> majuscule

Edit6:
En gros, la fonction change un chemin de la sorte :
a/B/c ==> [aA]/[bB]/[cC]

Dernière modification par Tawal (Le 18/01/2023, à 20:29)

Watael · Le 18/01/2023, à 20:28

étant donné que la variable _res est effacée, la variable indiquée à laquelle _res fait référence est aussi effacée

$ maFonc() { local -n v=$1; v=;}
$ var=321
$ maFonc var
$ echo "$var"

$

Attention! _res est une référence locale au nom de la variable passée en deuxième argument si le premier argument est -v
sinon, elle est définie globalement (dans le script, je suppose), mais elle est quand même purgée dans la fonction, et donc dans le script.

des trucs avec des machins bizarres et inutiles, mais qui fonctionnent, c'est entre le steampunk et la magie.

--
edit: toujours vrai parce que c'est une négation.

Dernière modification par Watael (Le 18/01/2023, à 20:29)

Tawal · Le 18/01/2023, à 20:34

Alors je suis partagé.
En effet, le fait d'initialiser "à rien" la variable _res touche directement la variable globale.
Sauf que :

$ maFonc() { local -n v=$1; local v2= ; v= ; echo "${v@A}"; echo "${v2@A}"; v=321; }
$ var=123
$ maFonc var
var=''
v2=''
$ echo "$var"
321
$

Edit:
tu remarqueras le résultat :

var=''

et non

v=''

Edit:
En fait, la variable _res est initialisée à une valeur ($_path) si c'est une référence à une autre variable, sinon, affichage du résultat ($_path)

Edit:
Ajout d'une variable locale v2 et modification du résultat

Dernière modification par Tawal (Le 18/01/2023, à 20:54)

iznobe · Le 18/01/2023, à 20:39

hizoka a écrit :

Ce sont les URI contenues dans la base de données que j'extraie qui ne foutent de la casse.

ok , j' avais zappé ce point .
Pourquoi ne pas demander au mainteneur du serveur d ' inscrire ces adresses tout en minuscules dans le champ correspondant de la BDD ... ca serait tellement plus simple

je suis content d ' avoir trouvé une fonction qui vous fait travailler les méninges et en plus vous dites qu ' elle fonctionne pour traduire les urls de la BDD du coup ?

Dernière modification par iznobe (Le 18/01/2023, à 20:40)

Hizoka · Le 18/01/2023, à 21:06

Pourquoi ne pas demander au mainteneur du serveur d ' inscrire ces adresses tout en minuscules dans le champ correspondant de la BDD ...

Bah non, si je modifie les URI de la base de données, ça change rien, la casse sera toujours pas bonne
Il faudrait aussi renommer les 650 000 fichiers en minuscules.
Mais je me vois pas demander ça XD

Watael · Le 18/01/2023, à 21:11

comment ils font pour ne pas inscrire les chemins/fichiers avec la bonne casse ?
parce que si on sait ça, on peut peut-être faire l'inverse...

Dernière modification par Watael (Le 18/01/2023, à 21:12)

Hizoka · Le 18/01/2023, à 22:18

Je ne sais pas du tout comment ils en arrivent à faire ça... et c'est jamais personne XD
Heureusement, c'est une minorité des URI...
Mais je vais voir si y a moyen que je mette à jour les URI dans la base de données, ça me fera gagner du temps pour les prochaines utilisations.

En tout cas, merci à vous

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 18/01/2023, à 12:08

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#27 Le 18/01/2023, à 12:12

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#28 Le 18/01/2023, à 12:19

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#29 Le 18/01/2023, à 12:22

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#30 Le 18/01/2023, à 12:26

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#31 Le 18/01/2023, à 12:30

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#32 Le 18/01/2023, à 12:33

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#33 Le 18/01/2023, à 13:01

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#34 Le 18/01/2023, à 13:56

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#35 Le 18/01/2023, à 14:31

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#36 Le 18/01/2023, à 16:12

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#37 Le 18/01/2023, à 16:19

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#38 Le 18/01/2023, à 16:45

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#39 Le 18/01/2023, à 18:57

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#40 Le 18/01/2023, à 19:49

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#41 Le 18/01/2023, à 20:28

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#42 Le 18/01/2023, à 20:34

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#43 Le 18/01/2023, à 20:39

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#44 Le 18/01/2023, à 21:06

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#45 Le 18/01/2023, à 21:11

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

#46 Le 18/01/2023, à 22:18

Re : [Résolu] Vérifier l'existence d'un fichier quelle que soit la casse

Pied de page des forums