j'ai ceci: for FIC in `ls /temp/toto*|grep -v old 2>>/dev/null` do echo "$FIC" done
même avec la redirection de l'erreur, j'ai quand même l'erreur suivant : ls : 0653-341 Le fichier /temp/toto* n'existe pas.
Comment faire pour ne pas avoir de message d'erreur ?
set -f # on veut que le shell expande /temp/toto*, mais pas # qu'il expande chaque mot resultat du splitting de `...` IFS=' ' # le splitting de `...` doit etre fait sur les sauts de ligne
for FIC in `set +f; ls -d /temp/toto* 2> /dev/null |grep -v old` do printf '%sn' "$FIC" done
(tu redirigeais la sortie d'erreur de grep, pas celle de ls).
Mais pourquoi pas:
for FIC in /tmp/toto*; do case $FIC in *old*) continue;; esac printf '%sn' "$FIC" done
Avec zsh:
print -rl /tmp/toto*~*old*
(il faut peut-etre l'option extendedglob).
-- Stephane
On 28 Feb 2006 02:57:06 -0800, ozzii wrote:
Bonjour,
j'ai ceci:
for FIC in `ls /temp/toto*|grep -v old 2>>/dev/null`
do
echo "$FIC"
done
même avec la redirection de l'erreur, j'ai quand même l'erreur
suivant :
ls : 0653-341 Le fichier /temp/toto* n'existe pas.
Comment faire pour ne pas avoir de message d'erreur ?
set -f # on veut que le shell expande /temp/toto*, mais pas
# qu'il expande chaque mot resultat du splitting de `...`
IFS='
' # le splitting de `...` doit etre fait sur les sauts de ligne
for FIC in `set +f; ls -d /temp/toto* 2> /dev/null |grep -v old`
do
printf '%sn' "$FIC"
done
(tu redirigeais la sortie d'erreur de grep, pas celle de ls).
Mais pourquoi pas:
for FIC in /tmp/toto*; do
case $FIC in
*old*) continue;;
esac
printf '%sn' "$FIC"
done
j'ai ceci: for FIC in `ls /temp/toto*|grep -v old 2>>/dev/null` do echo "$FIC" done
même avec la redirection de l'erreur, j'ai quand même l'erreur suivant : ls : 0653-341 Le fichier /temp/toto* n'existe pas.
Comment faire pour ne pas avoir de message d'erreur ?
set -f # on veut que le shell expande /temp/toto*, mais pas # qu'il expande chaque mot resultat du splitting de `...` IFS=' ' # le splitting de `...` doit etre fait sur les sauts de ligne
for FIC in `set +f; ls -d /temp/toto* 2> /dev/null |grep -v old` do printf '%sn' "$FIC" done
(tu redirigeais la sortie d'erreur de grep, pas celle de ls).
Mais pourquoi pas:
for FIC in /tmp/toto*; do case $FIC in *old*) continue;; esac printf '%sn' "$FIC" done
Avec zsh:
print -rl /tmp/toto*~*old*
(il faut peut-etre l'option extendedglob).
-- Stephane
Nicolas George
Stephane Chazelas wrote in message :
Avec zsh:
print -rl /tmp/toto*~*old*
/tmp/toto*~*old*(N) pour ne pas avoir d'erreur quand aucun fichier n'est trouvé.
(il faut peut-etre l'option extendedglob).
Oui, pour l'opérateur ~.
Stephane Chazelas wrote in message
<slrne08efj.nsr.stephane_chazelas@duey.spider.com>:
Avec zsh:
print -rl /tmp/toto*~*old*
/tmp/toto*~*old*(N) pour ne pas avoir d'erreur quand aucun fichier n'est
trouvé.
On Tue, 28 Feb 2006 11:59:16 +0000 (UTC), Nicolas George wrote:
Stephane Chazelas wrote in message :
Avec zsh:
print -rl /tmp/toto*~*old*
/tmp/toto*~*old*(N) pour ne pas avoir d'erreur quand aucun fichier n'est trouvé.
Ben, je prefere avoir une erreur qu'une ligne vide, c'est plus parlant.
OK pour:
for f in /tmp/toto*~*old*(N); do
ou
files=(/tmp/toto*~*old*(N))
par contre.
(il faut peut-etre l'option extendedglob).
Oui, pour l'opérateur ~.
-- Stephane
Etienne de Tocqueville
"ozzii" a écrit sur fr.comp.os.unix :
Bonjour,
j'ai ceci: for FIC in `ls /temp/toto*|grep -v old 2>>/dev/null` do echo "$FIC" done
même avec la redirection de l'erreur, j'ai quand même l'erreur suivant : ls : 0653-341 Le fichier /temp/toto* n'existe pas.
Comment faire pour ne pas avoir de message d'erreur ?
C'est pas le grep qui fait l'erreur, mais le ls. De plus, le ">>" n'a pas d'avantage par rapport au ">" quand c'est pour rediriger vers /dev/null, donc :
for FIC in `ls /temp/toto* 2>/dev/null |grep -v old` do echo "$FIC" done
"ozzii" <ozzii23@gmail.com> a écrit sur fr.comp.os.unix :
Bonjour,
j'ai ceci:
for FIC in `ls /temp/toto*|grep -v old 2>>/dev/null`
do
echo "$FIC"
done
même avec la redirection de l'erreur, j'ai quand même l'erreur
suivant :
ls : 0653-341 Le fichier /temp/toto* n'existe pas.
Comment faire pour ne pas avoir de message d'erreur ?
C'est pas le grep qui fait l'erreur, mais le ls. De plus, le ">>" n'a
pas d'avantage par rapport au ">" quand c'est pour rediriger vers
/dev/null, donc :
for FIC in `ls /temp/toto* 2>/dev/null |grep -v old`
do
echo "$FIC"
done
j'ai ceci: for FIC in `ls /temp/toto*|grep -v old 2>>/dev/null` do echo "$FIC" done
même avec la redirection de l'erreur, j'ai quand même l'erreur suivant : ls : 0653-341 Le fichier /temp/toto* n'existe pas.
Comment faire pour ne pas avoir de message d'erreur ?
C'est pas le grep qui fait l'erreur, mais le ls. De plus, le ">>" n'a pas d'avantage par rapport au ">" quand c'est pour rediriger vers /dev/null, donc :
for FIC in `ls /temp/toto* 2>/dev/null |grep -v old` do echo "$FIC" done
Stephane Dupille
Comment faire pour ne pas avoir de message d'erreur ? C'est pas le grep qui fait l'erreur, mais le ls.
Non, ce n'est pas ls qui fait l'erreur, c'est le shell qui fait l'expansion des *.
De plus, le ">>" n'a pas d'avantage par rapport au ">" quand c'est pour rediriger vers /dev/null,
Oui.
donc : for FIC in `ls /temp/toto* 2>/dev/null |grep -v old` do echo "$FIC" done
Non : [gimli] ~> ls /temp/toto* 2>/dev/null zsh: no matches found: /temp/toto*
-- DM> J'arrive seulement sur ce groupe de discussion .Que faut il faire ? Rien, il n'y a absolument rien d'autres à faire que taper son message en répondant au groupe, ou pourquoi pas un nouveau message. Rien d'autres -+- E in Guide du Neuneu Usenet - Mais où ce qu'il est-il donc ? -+-
Comment faire pour ne pas avoir de message d'erreur ?
C'est pas le grep qui fait l'erreur, mais le ls.
Non, ce n'est pas ls qui fait l'erreur, c'est le shell qui fait
l'expansion des *.
De plus, le ">>" n'a
pas d'avantage par rapport au ">" quand c'est pour rediriger vers
/dev/null,
Oui.
donc :
for FIC in `ls /temp/toto* 2>/dev/null |grep -v old`
do
echo "$FIC"
done
Non :
[gimli] ~> ls /temp/toto* 2>/dev/null
zsh: no matches found: /temp/toto*
--
DM> J'arrive seulement sur ce groupe de discussion .Que faut il faire ?
Rien, il n'y a absolument rien d'autres à faire que taper son message en
répondant au groupe, ou pourquoi pas un nouveau message. Rien d'autres
-+- E in Guide du Neuneu Usenet - Mais où ce qu'il est-il donc ? -+-
Comment faire pour ne pas avoir de message d'erreur ? C'est pas le grep qui fait l'erreur, mais le ls.
Non, ce n'est pas ls qui fait l'erreur, c'est le shell qui fait l'expansion des *.
De plus, le ">>" n'a pas d'avantage par rapport au ">" quand c'est pour rediriger vers /dev/null,
Oui.
donc : for FIC in `ls /temp/toto* 2>/dev/null |grep -v old` do echo "$FIC" done
Non : [gimli] ~> ls /temp/toto* 2>/dev/null zsh: no matches found: /temp/toto*
-- DM> J'arrive seulement sur ce groupe de discussion .Que faut il faire ? Rien, il n'y a absolument rien d'autres à faire que taper son message en répondant au groupe, ou pourquoi pas un nouveau message. Rien d'autres -+- E in Guide du Neuneu Usenet - Mais où ce qu'il est-il donc ? -+-
Etienne de Tocqueville
Stephane Dupille a écrit sur fr.comp.os.unix :
Non : [gimli] ~> ls /temp/toto* 2>/dev/null zsh: no matches found: /temp/toto*
Chez moi ça marche !
Cela dit, j'utilise des shell normaux, style "sh" et compatibles ! ;-)
Stephane Dupille <sdupille@NOSPAM.fr.eu.org> a écrit sur fr.comp.os.unix :
Non :
[gimli] ~> ls /temp/toto* 2>/dev/null
zsh: no matches found: /temp/toto*
Chez moi ça marche !
Cela dit, j'utilise des shell normaux, style "sh" et compatibles ! ;-)
Désolé pour le délai. Je test tout à l'heure et je vous dis. P.S. Je suis sous AIX et Solaris.
Stephane Dupille
Non, ce n'est pas ls qui fait l'erreur, c'est le shell qui fait l'expansion des *. Je n'avais pas vu ça, j'y réponds avec un peu de retard :
C'est bien le shell qui effectue l'expension des "*", mais si rien ne correspond, il laisse le masque et ne génère pas d'erreur. Je parle du shell "sh" standard, et des shells compatibles, dans leur configuration par défaut.
Il y a peu de chances que ton sh soit un vrai sh. A mon avis, et au pif, ce doit plutôt être un bash en mode réduit.
C'est donc le ls qui indique ne pas trouver le fichier "/temp/toto*", et pas sh qui dit ne pas trouver de fichier correspondant à /temp/toto*
Beuark ! Complètement cradingue comme comportement. Il laisse passer des * sans les quoter. Ce qui fait que le comportement de la commande en général, et de l'expansion en particulier n'est pas cohérent.
Au moins, zsh est cohérent.
Pour le zsh, tu as raison, ce qui prouve que c'est un mauvais shell qu'il ne faut surtout pas conseiller si on souhaite faire quelque chose de portable.
C'est un bon shell : il est configurable. Par exemple, on peut décider de ne pas générer d'erreur, mais de ne pas exécuter du tout la commande lorsque l'expansion échoue. Ce qui est plus propre que de lancer n'importe quoi au petit bonheur la chance.
-- Je parie un poste que t'as jamais news reader dedans alors stp arrete parler d'un groupe que tu ne lis pas... Super argument ca fait vachement le debat... -+- CA in : Guide du Neuneu Usenet - Tu t'es vu quand t'as bu -+-
Non, ce n'est pas ls qui fait l'erreur, c'est le shell qui fait
l'expansion des *.
Je n'avais pas vu ça, j'y réponds avec un peu de retard :
C'est bien le shell qui effectue l'expension des "*", mais si rien ne
correspond, il laisse le masque et ne génère pas d'erreur. Je parle du
shell "sh" standard, et des shells compatibles, dans leur configuration
par défaut.
Il y a peu de chances que ton sh soit un vrai sh. A mon avis, et au
pif, ce doit plutôt être un bash en mode réduit.
C'est donc le ls qui indique ne pas trouver le fichier "/temp/toto*", et
pas sh qui dit ne pas trouver de fichier correspondant à /temp/toto*
Beuark ! Complètement cradingue comme comportement. Il laisse passer
des * sans les quoter. Ce qui fait que le comportement de la commande
en général, et de l'expansion en particulier n'est pas cohérent.
Au moins, zsh est cohérent.
Pour le zsh, tu as raison, ce qui prouve que c'est un mauvais shell
qu'il ne faut surtout pas conseiller si on souhaite faire quelque chose
de portable.
C'est un bon shell : il est configurable. Par exemple, on peut
décider de ne pas générer d'erreur, mais de ne pas exécuter du tout la
commande lorsque l'expansion échoue. Ce qui est plus propre que de
lancer n'importe quoi au petit bonheur la chance.
--
Je parie un poste que t'as jamais news reader dedans alors stp arrete
parler d'un groupe que tu ne lis pas... Super argument ca fait
vachement le debat...
-+- CA in : Guide du Neuneu Usenet - Tu t'es vu quand t'as bu -+-
Non, ce n'est pas ls qui fait l'erreur, c'est le shell qui fait l'expansion des *. Je n'avais pas vu ça, j'y réponds avec un peu de retard :
C'est bien le shell qui effectue l'expension des "*", mais si rien ne correspond, il laisse le masque et ne génère pas d'erreur. Je parle du shell "sh" standard, et des shells compatibles, dans leur configuration par défaut.
Il y a peu de chances que ton sh soit un vrai sh. A mon avis, et au pif, ce doit plutôt être un bash en mode réduit.
C'est donc le ls qui indique ne pas trouver le fichier "/temp/toto*", et pas sh qui dit ne pas trouver de fichier correspondant à /temp/toto*
Beuark ! Complètement cradingue comme comportement. Il laisse passer des * sans les quoter. Ce qui fait que le comportement de la commande en général, et de l'expansion en particulier n'est pas cohérent.
Au moins, zsh est cohérent.
Pour le zsh, tu as raison, ce qui prouve que c'est un mauvais shell qu'il ne faut surtout pas conseiller si on souhaite faire quelque chose de portable.
C'est un bon shell : il est configurable. Par exemple, on peut décider de ne pas générer d'erreur, mais de ne pas exécuter du tout la commande lorsque l'expansion échoue. Ce qui est plus propre que de lancer n'importe quoi au petit bonheur la chance.
-- Je parie un poste que t'as jamais news reader dedans alors stp arrete parler d'un groupe que tu ne lis pas... Super argument ca fait vachement le debat... -+- CA in : Guide du Neuneu Usenet - Tu t'es vu quand t'as bu -+-
Stephane Chazelas
On 02 Mar 2006 07:21:23 +0100, Etienne de Tocqueville wrote: [...]
Par exemple :
$ sh # /bin/echo /temp/toto* /temp/toto*
C'est donc le ls qui indique ne pas trouver le fichier "/temp/toto*", et pas sh qui dit ne pas trouver de fichier correspondant à /temp/toto*
Pour le zsh, tu as raison, ce qui prouve que c'est un mauvais shell qu'il ne faut surtout pas conseiller si on souhaite faire quelque chose de portable.
zsh se comporte POSIXement (c'est a dire non correctement de mon point de vue), quand il est appelé "sh" (ou "ksh"), et se correctement quand il est appelé zsh.
Avec les shells autres que zsh (et (t)csh)
rm [ab]*
Effacera un fichier appelé "[ab]*" sans aucun warning s'il n'y a pas de fichier dont le nom commence par "a" ou "b" dans le repertoire courant.
Si on ecrit un script avec
#! /bin/zsh -
alors on peut utiliser des specificités zsh, il n'est pas question de portabilité (a part peut-etre entres versions de zsh).
Si on ecrit un script sans ligne "#!".
alors on utilise une syntaxe POSIX et zsh comme tout autre shell qui essaie d'etre POSIX (ou d'avoir un mode POSIX) sauront l'interpreter de la facon standard.
Si on ecrit un script avec "#! /bin/sh -" alors ca va dependre des systemes, certains on encore un Bourne shell en /bin/sh donc on ne peut pas forcement utiliser une syntaxe Unix/POSIX dans son script si on veut etre portable, il faut se contenter d'une syntax Bourne (en evitant les points de conflit entre Bourne et POSIX). Et encore une fois, si /bin/sh est zsh, alors il saura interpréter un script Bourne, a la maniere standard.
-- Stephane
On 02 Mar 2006 07:21:23 +0100, Etienne de Tocqueville wrote:
[...]
Par exemple :
$ sh
# /bin/echo /temp/toto*
/temp/toto*
C'est donc le ls qui indique ne pas trouver le fichier "/temp/toto*", et
pas sh qui dit ne pas trouver de fichier correspondant à /temp/toto*
Pour le zsh, tu as raison, ce qui prouve que c'est un mauvais shell
qu'il ne faut surtout pas conseiller si on souhaite faire quelque chose
de portable.
zsh se comporte POSIXement (c'est a dire non correctement de mon
point de vue), quand il est appelé "sh" (ou "ksh"), et se
correctement quand il est appelé zsh.
Avec les shells autres que zsh (et (t)csh)
rm [ab]*
Effacera un fichier appelé "[ab]*" sans aucun warning s'il n'y a
pas de fichier dont le nom commence par "a" ou "b" dans le
repertoire courant.
Si on ecrit un script avec
#! /bin/zsh -
alors on peut utiliser des specificités zsh, il n'est pas
question de portabilité (a part peut-etre entres versions de
zsh).
Si on ecrit un script sans ligne "#!".
alors on utilise une syntaxe POSIX et zsh comme tout autre shell
qui essaie d'etre POSIX (ou d'avoir un mode POSIX) sauront
l'interpreter de la facon standard.
Si on ecrit un script avec "#! /bin/sh -" alors ca va dependre
des systemes, certains on encore un Bourne shell en /bin/sh
donc on ne peut pas forcement utiliser une syntaxe Unix/POSIX
dans son script si on veut etre portable, il faut se contenter
d'une syntax Bourne (en evitant les points de conflit entre
Bourne et POSIX). Et encore une fois, si /bin/sh est zsh, alors
il saura interpréter un script Bourne, a la maniere standard.
On 02 Mar 2006 07:21:23 +0100, Etienne de Tocqueville wrote: [...]
Par exemple :
$ sh # /bin/echo /temp/toto* /temp/toto*
C'est donc le ls qui indique ne pas trouver le fichier "/temp/toto*", et pas sh qui dit ne pas trouver de fichier correspondant à /temp/toto*
Pour le zsh, tu as raison, ce qui prouve que c'est un mauvais shell qu'il ne faut surtout pas conseiller si on souhaite faire quelque chose de portable.
zsh se comporte POSIXement (c'est a dire non correctement de mon point de vue), quand il est appelé "sh" (ou "ksh"), et se correctement quand il est appelé zsh.
Avec les shells autres que zsh (et (t)csh)
rm [ab]*
Effacera un fichier appelé "[ab]*" sans aucun warning s'il n'y a pas de fichier dont le nom commence par "a" ou "b" dans le repertoire courant.
Si on ecrit un script avec
#! /bin/zsh -
alors on peut utiliser des specificités zsh, il n'est pas question de portabilité (a part peut-etre entres versions de zsh).
Si on ecrit un script sans ligne "#!".
alors on utilise une syntaxe POSIX et zsh comme tout autre shell qui essaie d'etre POSIX (ou d'avoir un mode POSIX) sauront l'interpreter de la facon standard.
Si on ecrit un script avec "#! /bin/sh -" alors ca va dependre des systemes, certains on encore un Bourne shell en /bin/sh donc on ne peut pas forcement utiliser une syntaxe Unix/POSIX dans son script si on veut etre portable, il faut se contenter d'une syntax Bourne (en evitant les points de conflit entre Bourne et POSIX). Et encore une fois, si /bin/sh est zsh, alors il saura interpréter un script Bourne, a la maniere standard.
-- Stephane
Stephane Chazelas
On Thu, 02 Mar 2006 11:21:35 +0100, Stephane Dupille wrote:
Non, ce n'est pas ls qui fait l'erreur, c'est le shell qui fait l'expansion des *. Je n'avais pas vu ça, j'y réponds avec un peu de retard :
C'est bien le shell qui effectue l'expension des "*", mais si rien ne correspond, il laisse le masque et ne génère pas d'erreur. Je parle du shell "sh" standard, et des shells compatibles, dans leur configuration par défaut.
Il y a peu de chances que ton sh soit un vrai sh. A mon avis, et au pif, ce doit plutôt être un bash en mode réduit. [...]
Ca ne veut rien dire, "un vrai sh".
La commande "sh" a été au court des ans sous Unix un Thomson shell, parfois mashey, puis un Bourne shell, puis un Almquist shell (BSD) ou un SysV shell (la suite du Bourne shell, SysV), puis des variations sur ksh, bash, ash ou zsh.
Aujourd'hui "sh" est standardisé par la Single Unix Specification. bash, ksh et zsh implementent (parfois dans un mode specific) ce standard avec plus ou moins de success (ce qui ne les empeche pas d'avoir des extensions propres, que la SUS autorise). Il faut bien noter que le Bourne shell n'est pas conformant, donc n'est pas un shell Unix compliant dans le monde Unix d'aujourd'hui.
-- Stephane
On Thu, 02 Mar 2006 11:21:35 +0100, Stephane Dupille wrote:
Non, ce n'est pas ls qui fait l'erreur, c'est le shell qui fait
l'expansion des *.
Je n'avais pas vu ça, j'y réponds avec un peu de retard :
C'est bien le shell qui effectue l'expension des "*", mais si rien ne
correspond, il laisse le masque et ne génère pas d'erreur. Je parle du
shell "sh" standard, et des shells compatibles, dans leur configuration
par défaut.
Il y a peu de chances que ton sh soit un vrai sh. A mon avis, et au
pif, ce doit plutôt être un bash en mode réduit.
[...]
Ca ne veut rien dire, "un vrai sh".
La commande "sh" a été au court des ans sous Unix un Thomson
shell, parfois mashey, puis un Bourne shell, puis un Almquist
shell (BSD) ou un SysV shell (la suite du Bourne shell, SysV),
puis des variations sur ksh, bash, ash ou zsh.
Aujourd'hui "sh" est standardisé par la Single Unix
Specification. bash, ksh et zsh implementent (parfois dans un
mode specific) ce standard avec plus ou moins de success (ce qui
ne les empeche pas d'avoir des extensions propres, que la SUS
autorise). Il faut bien noter que le Bourne shell n'est pas
conformant, donc n'est pas un shell Unix compliant dans le monde
Unix d'aujourd'hui.
On Thu, 02 Mar 2006 11:21:35 +0100, Stephane Dupille wrote:
Non, ce n'est pas ls qui fait l'erreur, c'est le shell qui fait l'expansion des *. Je n'avais pas vu ça, j'y réponds avec un peu de retard :
C'est bien le shell qui effectue l'expension des "*", mais si rien ne correspond, il laisse le masque et ne génère pas d'erreur. Je parle du shell "sh" standard, et des shells compatibles, dans leur configuration par défaut.
Il y a peu de chances que ton sh soit un vrai sh. A mon avis, et au pif, ce doit plutôt être un bash en mode réduit. [...]
Ca ne veut rien dire, "un vrai sh".
La commande "sh" a été au court des ans sous Unix un Thomson shell, parfois mashey, puis un Bourne shell, puis un Almquist shell (BSD) ou un SysV shell (la suite du Bourne shell, SysV), puis des variations sur ksh, bash, ash ou zsh.
Aujourd'hui "sh" est standardisé par la Single Unix Specification. bash, ksh et zsh implementent (parfois dans un mode specific) ce standard avec plus ou moins de success (ce qui ne les empeche pas d'avoir des extensions propres, que la SUS autorise). Il faut bien noter que le Bourne shell n'est pas conformant, donc n'est pas un shell Unix compliant dans le monde Unix d'aujourd'hui.
