Mkdir avec variable contenant un espace

beral · 28/08/2008, 21h50

Bonjour a tous, je patauge pour un truc qui doit etre simple:
Je récupère des variables 'nom prenom' qui contiennent donc un espace.
Et je dois les passer en argument d'un script:

Code :

./script.sh $variable

Et ce script sert dans un premier temps a créer un dossier du nom de cette variable:

Code :

#!/bin/bash
mkdir $1

Cela ne fonctionne pas, meme si je mets des ' ' autour de $variable.
Si je fais

Code :

./script.sh 'nom prenom'

Ca me crée 2 dossiers: 'nom' ET 'prenom'

Alors que

Code :

mkdir 'nom prenom'

Crée bien un seul dossier 'nom prenom'

J'ai fait le test de mettre echo $1 dans mon script
et ca affiche bien nom prenom
Je pense donc que la variable $1 contient bien l'espace, ce doit être mkdir dans le script qui ne la gère pas.

Alors que faire?
Merci par avance de vos conseils

frp31 · 29/08/2008, 08h23

faire un espace est tjrs une betise pourquoi ?
tout simplement parceque rien ne garantie que 100% des programmes le gereront.

donc il est interdit de faire des espaces !

si ça te pose des problemes un jour ne viens pas t'en plaindre ici

tu peux forcer l'espace avec "\ " donc un espace précédé d'un backslash

aussi ajoutes trois choses à ton script
avant le mkdir : voir si $i est vide si oui quitter
avant le mkdir : voir si le repertoir existe si oui quitter
apres le mkdir : voir si le repertoire existe si oui quitter sinon informer de l'echec et quitter.

dtrosset · 29/08/2008, 08h33

Il est aussi possible de mettre des apostrophes double autour de $1 dans le script, comme tu le fais sur la ligne de commande. Cela donne :

Code :

!#/bin/bash
mkdir "$1"

Toutefois, je seconde fortement le conseil de ne pas utiliser d'espaces dans les noms de fichiers et de répertoires. Sinon, pourquoi pas aussi un retour à la ligne dans le nom de fichier ?

Tchetch · 29/08/2008, 12h11

Citation:

Envoyé par dtrosset

Toutefois, je seconde fortement le conseil de ne pas utiliser d'espaces dans les noms de fichiers et de répertoires. Sinon, pourquoi pas aussi un retour à la ligne dans le nom de fichier ?

Mets autant d'espace et de caractères spéciaux que tu le souhaites, l'UTF -8 est là pour ça et on est en 2008, les restrictions de 1970 faut arrêter.

Citation:

Envoyé par frp31

avant le mkdir : voir si $i est vide si oui quitter
avant le mkdir : voir si le repertoir existe si oui quitter
apres le mkdir : voir si le repertoire existe si oui quitter sinon informer de l'echec et quitter.

Tu utilises l'options "-p" comme ça il gère la création des parents et ne produit pas d'erreur si le répertoire existe.
Je penses que tester la valeur de retour de 'mkdir' est suffisant comme test, mais c'est une bonne idée de faire ce test.

dtrosset · 29/08/2008, 12h45

Citation:

Envoyé par Tchetch

Mets autant d'espace et de caractères spéciaux que tu le souhaites, l'UTF -8 est là pour ça et on est en 2008, les restrictions de 1970 faut arrêter.

Bine sûr. C'est beaucoup plus joli avec tous les caractères Unicode, en UTF-8. Surtout dans un explorateur graphique montrant tous ces répertoires et fichiers.

Mais dès qu'il va s'agir d'écrire des shell scripts (on en fait encore beaucoup) ou même de taper quelques commandes sur la ligne de commande d'un shell, les soucis vont arriver. L'espace y est utilisé comme séparateur d'arguments. Rien que le couple find/xargs ne fonctionne pas bien dès qu'il y a des espaces dans les noms de fichiers.

Une solution serait peut-être d'utiliser un caractère Unicode qui serait un caractère d'espacement mais qui ne serait pas 0x20. Il y a l'espace insécable 0xA0, pourquoi ne pas l'utiliser.

Tchetch · 29/08/2008, 13h46

Citation:

Envoyé par dtrosset

Bine sûr. C'est beaucoup plus joli avec tous les caractères Unicode, en UTF-8. Surtout dans un explorateur graphique montrant tous ces répertoires et fichiers.

Mais dès qu'il va s'agir d'écrire des shell scripts (on en fait encore beaucoup) ou même de taper quelques commandes sur la ligne de commande d'un shell, les soucis vont arriver. L'espace y est utilisé comme séparateur d'arguments. Rien que le couple find/xargs ne fonctionne pas bien dès qu'il y a des espaces dans les noms de fichiers.

Une solution serait peut-être d'utiliser un caractère Unicode qui serait un caractère d'espacement mais qui ne serait pas 0x20. Il y a l'espace insécable 0xA0, pourquoi ne pas l'utiliser.

En perl, en bash, en C, ... il est possible de supporté les noms de fichiers à espace. Les utilisateurs de ton réseau (généralement windows) utilise de toute façon les espaces et tes scripts doivent le supporter, donc pourquoi je vais m'interdire à moi de ne pas mettre des espaces. On est en 2008, j'ai de toutes façons des utilisateurs qui font comme bon leur semble et l'UTF-8 est là pour ça.

Et je ne mets pas d'interface graphique sur mes serveurs.

frp31 · 29/08/2008, 13h52

rares sont les machines par défaut en utf-8 dans la réalité tous unix confondus...dans la réalité

et les scripts sont souvent surtout si il viennent d'un éditeur applicatif complétement bidons et ecris à la va-vite

et les emmerdes commencent...

croies moi quand je dis qu'il est interdit de faire des espaces pour par foutre la merde, je parle d'experience et encore c'est juste la façon poli de dire qu'il faut tuer sans procés tous les fils de $*# de leur race de $*1§% à la $# qui en font...

en 8 ans que suis en exploit/admin chez les clients j'ai jamais vu un cas ou un répertoir contenant un espace n'a pas un jour finni par foutre la merde en production.

j'ai bien dit jamais.

par contre pour les programmes ou scripts provenants des études ou des autres admin là oui d'accord c'est l'inverse j'en ai vu mais jamais vu un poser problème...

Tchetch · 29/08/2008, 15h38

Citation:

Envoyé par frp31

rares sont les machines par défaut en utf-8 dans la réalité tous unix confondus...dans la réalité

C'est mon travail de tenir à jour les serveurs, je suis payé pour, donc il supporte tous (si techniquement possible) UTF-8. Pour ceux qui n'ont pas le support, on trouve une solution par cas.

Citation:

Envoyé par frp31

et les scripts sont souvent surtout si il viennent d'un éditeur applicatif complétement bidons et ecris à la va-vite

et les emmerdes commencent...

En général je les corriges si je peux. Sinon on trouve un solution pour contourner le problème. Bon en même temps j'évite comme la peste les logiciels où je n'ai pas accès aux sources, mais des fois y'a pas le choix (IBM particulièrement ...)

Citation:

Envoyé par frp31

croies moi quand je dis qu'il est interdit de faire des espaces pour par foutre la merde, je parle d'experience et encore c'est juste la façon poli de dire qu'il faut tuer sans procés tous les fils de $*# de leur race de $*1§% à la $# qui en font...

Mais les utilisateurs font ce qu'il veulent (surtout le boss). Donc les espaces dans les noms de fichiers sont là et il faut les gérer. Et si eux le font, je vais pas me l'interdire à moi. Pour être honnête je les mets uniquement sur mes données personnelles, pas sur les serveurs ...

frp31 · 29/08/2008, 16h24

moi je part du principe que le boss à tjrs tors

Tchetch · 29/08/2008, 16h35

Citation:

Envoyé par frp31

moi je part du principe que le boss à tjrs tors

Ouais, mais même en caleçon, c'est le boss !

28/08/2008, 21h50	#1 (permalink)
beral Futur Membre du Club Date d'inscription: janvier 2006 Messages: 38	Mkdir avec variable contenant un espace Bonjour a tous, je patauge pour un truc qui doit etre simple: Je récupère des variables 'nom prenom' qui contiennent donc un espace. Et je dois les passer en argument d'un script: Code : ./script.sh $variable Et ce script sert dans un premier temps a créer un dossier du nom de cette variable: Code : #!/bin/bash mkdir $1 Cela ne fonctionne pas, meme si je mets des ' ' autour de $variable. Si je fais Code : ./script.sh 'nom prenom' Ca me crée 2 dossiers: 'nom' ET 'prenom' Alors que Code : mkdir 'nom prenom' Crée bien un seul dossier 'nom prenom' J'ai fait le test de mettre echo $1 dans mon script et ca affiche bien nom prenom Je pense donc que la variable $1 contient bien l'espace, ce doit être mkdir dans le script qui ne la gère pas. Alors que faire? Merci par avance de vos conseils Dernière modification par beral ; 28/08/2008 à 22h58

29/08/2008, 08h23	#2 (permalink)
frp31 Membre Expert Date d'inscription: juillet 2006 Localisation: toulouse Messages: 1 474	faire un espace est tjrs une betise pourquoi ? tout simplement parceque rien ne garantie que 100% des programmes le gereront. donc il est interdit de faire des espaces ! si ça te pose des problemes un jour ne viens pas t'en plaindre ici tu peux forcer l'espace avec "\ " donc un espace précédé d'un backslash aussi ajoutes trois choses à ton script avant le mkdir : voir si $i est vide si oui quitter avant le mkdir : voir si le repertoir existe si oui quitter apres le mkdir : voir si le repertoire existe si oui quitter sinon informer de l'echec et quitter. __________________ Bye @+ (\__/) (o..o) (") (") Soutenez le logiciel libre Dernière modification par frp31 ; 29/08/2008 à 08h37

29/08/2008, 08h33	#3 (permalink)
dtrosset Rédacteur Date d'inscription: juillet 2008 Localisation: Pays de Gex, Genève Messages: 70	Il est aussi possible de mettre des apostrophes double autour de $1 dans le script, comme tu le fais sur la ligne de commande. Cela donne : Code : !#/bin/bash mkdir "$1" Toutefois, je seconde fortement le conseil de ne pas utiliser d'espaces dans les noms de fichiers et de répertoires. Sinon, pourquoi pas aussi un retour à la ligne dans le nom de fichier ?

29/08/2008, 13h52	#7 (permalink)
frp31 Membre Expert Date d'inscription: juillet 2006 Localisation: toulouse Messages: 1 474	rares sont les machines par défaut en utf-8 dans la réalité tous unix confondus...dans la réalité et les scripts sont souvent surtout si il viennent d'un éditeur applicatif complétement bidons et ecris à la va-vite et les emmerdes commencent... croies moi quand je dis qu'il est interdit de faire des espaces pour par foutre la merde, je parle d'experience et encore c'est juste la façon poli de dire qu'il faut tuer sans procés tous les fils de $# de leur race de $1§% à la $# qui en font... en 8 ans que suis en exploit/admin chez les clients j'ai jamais vu un cas ou un répertoir contenant un espace n'a pas un jour finni par foutre la merde en production. j'ai bien dit jamais. par contre pour les programmes ou scripts provenants des études ou des autres admin là oui d'accord c'est l'inverse j'en ai vu mais jamais vu un poser problème... __________________ Bye @+ (\__/) (o..o) (") (") Soutenez le logiciel libre Dernière modification par frp31 ; 29/08/2008 à 13h54 Motif: fautes... je suis pas bien reveillé

29/08/2008, 16h24	#9 (permalink)
frp31 Membre Expert Date d'inscription: juillet 2006 Localisation: toulouse Messages: 1 474	moi je part du principe que le boss à tjrs tors __________________ Bye @+ (\__/) (o..o) (") (") Soutenez le logiciel libre

		Forum des développeurs > Hardware, Systèmes et Logiciels > Linux > Applications
Mkdir avec variable contenant un espace

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email