Message d'erreur pendant un script

"Oleane Newsgroup" :

avec KSH, j'utilise la commande 'cp /usr1/appli/data /export/donnees' pour
faire une copie du répertoire data vers le répertoire donnees. cela
fonctionne très bien !

mais dans un script, la même commande génère un message d'erreur :
exdata[6]: /bin/cp: 0403-027 Liste de paramètres trop longue.

Tu es sur de ne pas avoir une * quelque part?

2006-11-27, 17:54(+01), Oleane Newsgroup:

Bonjour !

avec KSH, j'utilise la commande 'cp /usr1/appli/data /export/donnees' pour
faire une copie du répertoire data vers le répertoire donnees. cela
fonctionne très bien !

mais dans un script, la même commande génère un message d'erreur :
exdata[6]: /bin/cp: 0403-027 Liste de paramètres trop longue.
[...]

Peut-etre que l'environnement est plein.

Essaie d'eviter d'exporter les variables qui n'ont pas besoin
d'etre exportees.

--
Stéphane

"Luc Habert" <lhabert@clipper.ens.fr> a écrit dans le message de news:
ekf5bd$14is$1@nef.ens.fr...

"Oleane Newsgroup" :

mais dans un script, la même commande génère un message d'erreur :
exdata[6]: /bin/cp: 0403-027 Liste de paramètres trop longue.

Tu es sur de ne pas avoir une * quelque part?

Si bien sur ! Désolé !
La commande c'est 'cp /usr1/appli/data/!(*.*||HF*) /export/donnees' car je
ne veux ni les fichiers avec extension ni ceux commençant par HF... La
commande fonctionne parfaitement en manuel mais pas dans le script !

"Stephane Chazelas" <cette.adresse@est.invalid> a écrit dans le message de
news: slrnemm775.9jf.stephane.chazelas@spam.is.invalid...

2006-11-27, 17:54(+01), Oleane Newsgroup:

Peut-etre que l'environnement est plein.

Essaie d'eviter d'exporter les variables qui n'ont pas besoin
d'etre exportees.

Salut !
J'ai mal écrit ma commande, désolé, c'est : 'cp /usr1/appli/data/!(*.*||HF*)
/export/donnees'
Mais tu parles de variables ? Je suis assez nul sur unix alors de là à
utiliser des variables, j'en suis pas encore là !
Merci

2006-11-28, 08:05(+01), Oleane Newsgroup:

"Stephane Chazelas" <cette.adresse@est.invalid> a écrit dans le message de
news: slrnemm775.9jf.stephane.chazelas@spam.is.invalid...

2006-11-27, 17:54(+01), Oleane Newsgroup:

Peut-etre que l'environnement est plein.

Essaie d'eviter d'exporter les variables qui n'ont pas besoin
d'etre exportees.

Salut !
J'ai mal écrit ma commande, désolé, c'est : 'cp /usr1/appli/data/!(*.*||HF*)
/export/donnees'
Mais tu parles de variables ? Je suis assez nul sur unix alors de là à
utiliser des variables, j'en suis pas encore là !
[...]

L'erreur que tu obtiens arrive quand la taille combinee des
arguments et de l'environnement passés a une commande depasse un
maximum autorisé.

C'est une erreur retournee par l'appel systeme execve() que le
shell utilise pour executer une commande. execve prend comme
argument le chemin de la commande a executer, la liste des
arguments et la liste des variables d'environnement.

Typiquement, la liste des variables d'environnement sera la
liste que le shell lui-meme aura recue quand il a ete executé
plus les variables du shell que tu as marquées exportables par
la commande "export".

--
Stéphane

As-tu essayé la commande xargs ?

ls -1 * | xargs -0 cp -t "target_directory"

N'ayant pas d'unix sous la main, je ne connais pas la portabilité de
"cp -t" cependant.

fabrice.gonton@gmail.com :

ls -1 * | xargs -0

N'importe quoi...

find . -print0 | xargs -0

Pour ce qui est de l'option « -t » de cp, j'ai essayé linux et solaris,
aucun des deux ne connait. Ça peut se contourner ainsi :

find . -print0 | xargs -0 sh -c 'exec cp "$@" cible' sblurbquiprenddelaplace

Mais le monsieur est sous AIX, il y a des chances que son find ne supporte
pas le -print0, pas plus que son xargs le -0.

Bref, je conseillerais plutôt un

for f in *; do cp "$f" cible; done

. Mais comme je l'ai déjà dit, il faut absolument que seul root ait le droit
d'écrire dans le répertoire cible, sinon on est vulnérable aux symlinks.

(Si on tient à faire les appels à cp par gros paquets, on peut s'en sortir
avec :

find . -exec sh -c 'exec cp "$@" cible' sblurbquiprenddelaplace '{}' +

, qui est conforme à la norme Single Unix, mais pas supporté partout pour
autant...)

avec KSH, j'utilise la commande 'cp /usr1/appli/data /export/donnees' pour
faire une copie du répertoire data vers le répertoire donnees. cela
fonctionne très bien !
mais dans un script, la même commande génère un message d'erreur :
exdata[6]: /bin/cp: 0403-027 Liste de paramètres trop longue.

le shell de login et le script shell ne
sont pas les mêmes

ksh != sh
même si ce sont des bournes, ils peuvent réagir différement

2006-12-11, 22:52(+01), Moi:

avec KSH, j'utilise la commande 'cp /usr1/appli/data /export/donnees' pour
faire une copie du répertoire data vers le répertoire donnees. cela
fonctionne très bien !
mais dans un script, la même commande génère un message d'erreur :
exdata[6]: /bin/cp: 0403-027 Liste de paramètres trop longue.

le shell de login et le script shell ne
sont pas les mêmes

ksh != sh
même si ce sont des bournes, ils peuvent réagir différement
[...]

Sur la plupart des Unix commerciaux, ksh == sh
ksh est une implementation du sh standard.

Le Bourne shell est un vieux shell qu'on ne trouve aujourd'hui
que sous tres peu d'OS et encore que pour backward compatibility
pour des tres vieux scripts. Le Bourne shell n'est d'ailleurs
pas un sh standard.


--
Stéphane

ksh != sh
même si ce sont des bournes, ils peuvent réagir différement

Sur la plupart des Unix commerciaux, ksh == sh
ksh est une implementation du sh standard.

Sur les Unix à deux balles, style *.BSD, sh c'est sh.

Le Bourne shell est un vieux shell qu'on ne trouve aujourd'hui
que sous tres peu d'OS et encore que pour backward compatibility
pour des tres vieux scripts. Le Bourne shell n'est d'ailleurs
pas un sh standard.

Pourquoi, bash c'est "standard" peut-être ?

Mais qu'est donc un "sh" standard ?
Un sh PC (posixtly correct) ?
Un lien "bash" à la Linux ?