xargs et noms de fichiers complexes

Le lun 17 nov 2003 à 13:00, Stephane Chazelas a tapoté :
| 2003/11/17, 11:30(+00), Thomas Nemeth:
| [...]
| >| >| Il me vient un doute: es-tu passé par l'étape "compinstall"
| [...]
| > Non. S'il y a des menus je ne l'ai pas fait, je m'en souviendrais.
|
| Tu dois probablement passer à côté de plein de trucs, alors.

Ah ?
Sans doute, mais ça ne me manque pas :)


| [...]
| > Oui. Enfin normalement les gens ne redéfinissent pas IFS sans
| > avoir de bonnes raisons de le faire et la valeur par défaut
| > permet de fonctionner normalement.
|
| Les gens qui programment proprement le redéfinissent à chaque

Oh. Mon trollomètre vient de passer dans le rouge-oranger :)


| fois qu'ils l'utilisent, même si la valeur par défaut convient
| tout au long du script pour des raisons évidentes de
| maintenabilité (si un jour, en rajoutant une fonctionnalité, on
| a besoin d'une autre valeur d'IFS, il faudrait soit aller fixer
| IFS à tous les endroits où il est utilisé ou faire des trucs
| crades comme:
[...]

Pourquoi faire des trucs crades alors qu'il suffit de le redéfinir ?


| En plus, la valeur par défaut (qui contient " ") pose de plus en

Juste " " ? Tu en es sûr ? Il me semble qu'il contient :
- espace
- tab
- newline


| plus de problèmes vue la recrudescence des noms de fichiers qui
| contiennent des espaces (heureusement, on ne voit pas encore

Oui... D'un autre côté, le séparateur de champs entre les
arguments des commandes, c'est aussi l'espace, donc bon...
Faudrait virer tous les fichiers avec des espaces dans le
nom.
De totues façons, les espaces dans un nom de ficheir ça perturbe
la lecture de ls :)


| trop de noms de fichiers qui contiennent des n).

Il y en a qui osent faire ça ?


Thomas
--
BOFH excuse #384:
T's an ID-10-T error.

2003/11/17, 13:14(+00), Thomas Nemeth:
[...]

| Les gens qui programment proprement le redéfinissent à chaque

Oh. Mon trollomètre vient de passer dans le rouge-oranger :)

| fois qu'ils l'utilisent, même si la valeur par défaut convient
| tout au long du script pour des raisons évidentes de
| maintenabilité (si un jour, en rajoutant une fonctionnalité, on
| a besoin d'une autre valeur d'IFS, il faudrait soit aller fixer
| IFS à tous les endroits où il est utilisé ou faire des trucs
| crades comme:
[...]

Pourquoi faire des trucs crades alors qu'il suffit de le redéfinir ?

Nous sommes donc d'accord, il faut le redéfinir à chaque fois
qu'on l'utilise.

| En plus, la valeur par défaut (qui contient " ") pose de plus en

Juste " " ? Tu en es sûr ? Il me semble qu'il contient :
- espace
- tab
- newline

Je n'ai pas dit "juste" ni "ne ... que".
Par contre, s'il ne contenait que newline, ça éviterait pas mal
de problèmes on en éviterait encore plus s'il était vide par
défaut.

D'ailleurs, je cite David Korn himself (voir les archives de la
ML ast-users@research.att.com) :

| > This "conformance" thing seems to be a bit annoying, isn't it?
|
| Yes, in some cases it is.
|
| > In zsh (a non-conforming shell), you use ${~flag} wherever you
| > want glob substitution to occur, this makes things clearer.
|
| Yes it does.
|
| > (and you use ${=var} when you want word splitting to occur, you
|
| Since word splitting (other than for read) is pretty uncommon,
| $(wsplit $var)
|
| > generally don't want it to occur, too bad it's the default in
| > ksh).
|
| Yes, this was a terible default. The earliest version of ksh
| back in the early '80s only did word splitting on read and set.
| Rob Pike reported that one of the scripts in his book didn't
| run with this version so I backed it out. If I had not done
| this I would have been in a postion to argue for it when
| the shell was standardized. A good programming practice is
| to put
| IFS | at the beginning of each script and in your $ENV file so
| that word splitting is disabled by default.
|
| Another big mistake was not to expand sequences inside "..."
| rather than have them interpreted by echo. ksh93 added $'...'
| for this purpose, but it would have been a lot more natural
| to just have this in "...".
|
| Anyway, the damage has been done and compatibility is more
| important that inventing a slightly improved language.


[...]

Oui... D'un autre côté, le séparateur de champs entre les
arguments des commandes, c'est aussi l'espace, donc bon...

Ça n'a rien à voir. Dans la syntaxe C, le séparateur d'arguments
est ",", je ne crois pas qu'il y ait pour autant des problèmes
avec les variables qui contiennent des "," pour faire une
comparaison extrème (on n'est plus au temps des premiers shells
Bourne où IFS avait une influence sur le parsing de la syntaxe).

Faudrait virer tous les fichiers avec des espaces dans le
nom.

Pour contourner les erreurs de design des shells ? Si Microsoft
adoptait ce genre de philosophie pour contourner les bugs de ses
outils, on ne pourrait plus faire grand chose sous Windows ;)

De totues façons, les espaces dans un nom de ficheir ça perturbe
la lecture de ls :)

ls ? À quoi ça sert quand on a la complétion en couleur ;) ?

--
Stéphane ["Stephane.Chazelas" arobase "free.fr"]

Le lun 17 nov 2003 à 15:14, Stephane Chazelas a tapoté :
| 2003/11/17, 13:14(+00), Thomas Nemeth:
| [...]
[IFS]
| > Pourquoi faire des trucs crades alors qu'il suffit de le redéfinir ?
|
| Nous sommes donc d'accord, il faut le redéfinir à chaque fois
| qu'on l'utilise.

s/l'utilise/en a besoin/ :)
On peut l'utiliser sans avoir besoin de le modifier... Mais je
pinaille...


| >| En plus, la valeur par défaut (qui contient " ") pose de plus en
| >
| > Juste " " ? Tu en es sûr ? Il me semble qu'il contient :
| > - espace
| > - tab
| > - newline
|
| Je n'ai pas dit "juste" ni "ne ... que".

'scuse. C'est la fatigue. Le sport, contrairement à ce que l'on
dit, ça n'aide pas a garder l'esprit clair :)


| D'ailleurs, je cite David Korn himself (voir les archives de la
| ML ast-users@research.att.com) :
[snip]

Hum. Pas tout compris. cf plus loin.


| [...]
| > Oui... D'un autre côté, le séparateur de champs entre les
| > arguments des commandes, c'est aussi l'espace, donc bon...
|
| Ça n'a rien à voir. Dans la syntaxe C, le séparateur d'arguments
| est ",", je ne crois pas qu'il y ait pour autant des problèmes
| avec les variables qui contiennent des "," pour faire une

C'est un peu normal : je n'ai jamais vu de variable telle que
var = ,;
Mais
var = ",";
ne pose pas de pb puisque la vigule est entre double quotes.
Pareil que pour les espaces pour les shells.


| comparaison extrème (on n'est plus au temps des premiers shells
| Bourne où IFS avait une influence sur le parsing de la syntaxe).

Explique-toi : comment la suppression de l'espace dans IFS n'influe
pas sur la séparation des arguments des commandes et la combinaison
de plusieurs commandes ?
Un fichier que tu passes en paramètre n'est pas une variable, mais
un élément à parser. C'est comme ça que je le vois. Pour extraire
les éléments de la ligne de commande je vois bien l'utilisation de
strtok/strtok_r avec IFS en séparateur de champs (comme ses initiales
l'indique --- je n'ai pas regardé pour voir comment c'était fait).


| > Faudrait virer tous les fichiers avec des espaces dans le
| > nom.
|
| Pour contourner les erreurs de design des shells ?

Effectivement. Mais bon quand j'ai dit ça je ne pensais pas que
c'était une erreur de design, mais un effet de bord de l'analyse
de la ligne de commande.


| Si Microsoft
| adoptait ce genre de philosophie pour contourner les bugs de ses
| outils, on ne pourrait plus faire grand chose sous Windows ;)

On peut faire quelquechose sous Windows :) ?
De toutes façons il ne fonctionne pas sur les véritables
ordinateurs.


| > De totues façons, les espaces dans un nom de ficheir ça perturbe
| > la lecture de ls :)
|
| ls ? À quoi ça sert quand on a la complétion en couleur ;) ?

Oh ?


Thomas
--
# Basic IBM dingbats, some of which will never have a purpose clear
# to mankind
2.4.0 linux/drivers/char/cp437.uni

2003/11/17, 17:26(+00), Thomas Nemeth:
[...]

| Nous sommes donc d'accord, il faut le redéfinir à chaque fois
| qu'on l'utilise.

s/l'utilise/en a besoin/ :)
On peut l'utiliser sans avoir besoin de le modifier... Mais je
pinaille...

Ce que je veux dire c'est que tout seul

cmd $(other cmd)

n'a pas de sens sauf si on connait la valeur d'IFS. Pour des
raisons de maintenabilité, il convient donc, chaque fois qu'on
utilise le word splitting (command or variable subsitution non
quotée [oui, je fais pas mal de franglais]) de permettre à celui
qui va reprendre le code de savoir quelle valeur d'IFS est
utilisée. Si la définition d'IFS n'est pas juste avant, ou s'il
n'y a pas une politique stricte et cohérente de définition
d'IFS, la vie du "mainteneur" est un cauchemard.

Enfin bon, aujourd'hui que perl est installé partout, la vie du
maintainer s'est beaucoup améliorée puisqu'il lui suffit de
quelques minutes pour réécrire un script shell (personne n'est à
l'aise en programmation shell, vous n'arriverez pas à me prouver
le contraire) en perl (certes, perl n'est pas la panacée, mais
c'est déjà mieux ; pour de vrais shells, voyez du côté de "rc").

[...]

| Ça n'a rien à voir. Dans la syntaxe C, le séparateur d'arguments
| est ",", je ne crois pas qu'il y ait pour autant des problèmes
| avec les variables qui contiennent des "," pour faire une

C'est un peu normal : je n'ai jamais vu de variable telle que
var = ,;

Qui donne un "syntax error" explicite.

Mais
var = ",";
ne pose pas de pb puisque la vigule est entre double quotes.
Pareil que pour les espaces pour les shells.

À ceci près que c'est beaucoup plus confus en shell, il faut
vraiment être "postgraduate" en shell pour cerner l'ampleur des
dégats...

| comparaison extrème (on n'est plus au temps des premiers shells
| Bourne où IFS avait une influence sur le parsing de la syntaxe).

Explique-toi : comment la suppression de l'espace dans IFS n'influe
pas sur la séparation des arguments des commandes et la combinaison
de plusieurs commandes ?

Dans le premier Bourne shell (Unix V7, 1975)

IFS=i
edit

lancait "ed" avec argument "t" (ça éditait le fichier "t").

Aujourd'hui non. Le parsing de la syntaxe est a priori
indépendant de l'exécution (à part quand les alias rentrent en
jeu ce qui fait une bonne raison de ne pas utiliser les alias).

Donc, une ligne écrite de syntaxe shell veut dire ce qu'elle
veut dire, il n'y a pas d'embrouille.

ls a b

veut dire lister le fichier a et le fichier b.

ls "a b"
veut dire lister le fichier "a b"

ls $a
veut sûrement dire quelque chose si on connais IFS, le
positionnement du flag -f et le contenu de $a.
mais au moment où on l'a écrite, c'est très clair, ça vaut dire
passer à ls une liste d'arguments générée à partir de
l'expansion de $a (qui implique word splitting,
filename/brace... expansion, mais on n'est plus au niveau de
l'analyse de la syntaxe mais au niveau de l'exécution)

ls -- "$a"
veut dire lister le fichier dont le nom est dans la variable
"a".

Un fichier que tu passes en paramètre n'est pas une variable, mais
un élément à parser. C'est comme ça que je le vois. Pour extraire
les éléments de la ligne de commande je vois bien l'utilisation de
strtok/strtok_r avec IFS en séparateur de champs (comme ses initiales
l'indique --- je n'ai pas regardé pour voir comment c'était fait).

Je ne comprends pas trop ta phrase. Sur les shells modernes IFS
n'intervient que sur la "variable expansion", la "command
substitution", et les "$*" et "${array[*]}" (et deux trois
autres trucs parce qu'il ne sera pas dit que la syntaxe d'un
shell est aussi limpide que ça).

[...]

On peut faire quelquechose sous Windows :) ?

J'y ai installé zsh sans trop de problème.

[...]

| ls ? À quoi ça sert quand on a la complétion en couleur ;) ?

Oh ?

Toujours pas lancé compinstall hein ? ;).

--
Stéphane ["Stephane.Chazelas" arobase "free.fr"]

Le lun 17 nov 2003 à 19:49, Stephane Chazelas a tapoté :
| 2003/11/17, 17:26(+00), Thomas Nemeth:
| [...]
| >| Nous sommes donc d'accord, il faut le redéfinir à chaque fois
| >| qu'on l'utilise.
| >
| > s/l'utilise/en a besoin/ :)
| > On peut l'utiliser sans avoir besoin de le modifier... Mais je
| > pinaille...
|
| Ce que je veux dire c'est que tout seul
|
| cmd $(other cmd)
|
| n'a pas de sens sauf si on connait la valeur d'IFS. Pour des

Aaahhh okok.
J'avais pas compris ça. Il faut dire que j'utilise rarement
cette forme : plus souvent var=`cmd1 | cmd2` puis cmd $var


| quotée [oui, je fais pas mal de franglais]) de permettre à celui

Pas grave.


| qui va reprendre le code de savoir quelle valeur d'IFS est
| utilisée. Si la définition d'IFS n'est pas juste avant, ou s'il
| n'y a pas une politique stricte et cohérente de définition
| d'IFS, la vie du "mainteneur" est un cauchemard.

Effectivement.


| Enfin bon, aujourd'hui que perl est installé partout, la vie du

Beurk :)


| [...]
| >| Ça n'a rien à voir. Dans la syntaxe C, le séparateur d'arguments
| >| est ",", je ne crois pas qu'il y ait pour autant des problèmes
| >| avec les variables qui contiennent des "," pour faire une
| >
| > C'est un peu normal : je n'ai jamais vu de variable telle que
| > var = ,;
|
| Qui donne un "syntax error" explicite.

Oui.


| > Mais
| > var = ",";
| > ne pose pas de pb puisque la vigule est entre double quotes.
| > Pareil que pour les espaces pour les shells.
|
| À ceci près que c'est beaucoup plus confus en shell, il faut
| vraiment être "postgraduate" en shell pour cerner l'ampleur des
| dégats...

Ok :)


| > Explique-toi : comment la suppression de l'espace dans IFS n'influe
| > pas sur la séparation des arguments des commandes et la combinaison
| > de plusieurs commandes ?
|
| Dans le premier Bourne shell (Unix V7, 1975)
|
| IFS=i
| edit
|
| lancait "ed" avec argument "t" (ça éditait le fichier "t").

Oui. Normal.


| Aujourd'hui non. Le parsing de la syntaxe est a priori
| indépendant de l'exécution (à part quand les alias rentrent en
| jeu ce qui fait une bonne raison de ne pas utiliser les alias).

Hum. Tu veux dire que le parsing n'utilise pas IFS ?


| Donc, une ligne écrite de syntaxe shell veut dire ce qu'elle
| veut dire, il n'y a pas d'embrouille.
|
| ls a b
|
| veut dire lister le fichier a et le fichier b.

Oui.


| ls "a b"
| veut dire lister le fichier "a b"

Oui.


| ls $a
| veut sûrement dire quelque chose si on connais IFS, le
| positionnement du flag -f et le contenu de $a.

Ok.
C'est clair.


| > Un fichier que tu passes en paramètre n'est pas une variable, mais
| > un élément à parser. C'est comme ça que je le vois. Pour extraire
| > les éléments de la ligne de commande je vois bien l'utilisation de
| > strtok/strtok_r avec IFS en séparateur de champs (comme ses initiales
| > l'indique --- je n'ai pas regardé pour voir comment c'était fait).
|
| Je ne comprends pas trop ta phrase. Sur les shells modernes IFS
| n'intervient que sur la "variable expansion", la "command
| substitution", et les "$*" et "${array[*]}" (et deux trois
| autres trucs parce qu'il ne sera pas dit que la syntaxe d'un
| shell est aussi limpide que ça).

C'est justement tout le point de notre incompréhension mutuelle
sur le sujet : c'était un dialogue de sourds :)


| [...]
| > On peut faire quelquechose sous Windows :) ?
|
| J'y ai installé zsh sans trop de problème.

Je parle de trucs utiles pour _produire_ directement quelquechose ;)


| >| ls ? À quoi ça sert quand on a la complétion en couleur ;) ?
| >
| > Oh ?
|
| Toujours pas lancé compinstall hein ? ;).

Non :)
Je vais d'abord lire sa page de man...


Thomas
--
Dans tout calcul compliqué, un facteur du numérateur passera
toujours au dénominateur.

2003/11/17, 19:01(+00), Thomas Nemeth:
[...]

| cmd $(other cmd)
|
| n'a pas de sens sauf si on connait la valeur d'IFS. Pour des

Aaahhh okok.
J'avais pas compris ça. Il faut dire que j'utilise rarement
cette forme : plus souvent var=`cmd1 | cmd2` puis cmd $var

Qui est identique sauf si on utilise zsh.

`...` est la même chose que $(...) aux problèmes de nesting près
de `...`

Il se pourrait qu'il te faille relire la page de man de bash
encore une fois (t'inquiète, on passe passe tous par là avant de
le laisser tomber définitivement ;).

[...]

| Aujourd'hui non. Le parsing de la syntaxe est a priori
| indépendant de l'exécution (à part quand les alias rentrent en
| jeu ce qui fait une bonne raison de ne pas utiliser les alias).

Hum. Tu veux dire que le parsing n'utilise pas IFS ?

Oui, et heureusement !

[...]

| > On peut faire quelquechose sous Windows :) ?
|
| J'y ai installé zsh sans trop de problème.

Je parle de trucs utiles pour _produire_ directement quelquechose ;)

Je sais pas, là dernière fois que je l'ai utilisé, c'était pour
mon service militaire il y a quelques années maintenant. Donc,
évidemment le mot "utile" perds un peu de son sens dans ces
circonstances.

--
Stéphane ["Stephane.Chazelas" arobase "free.fr"]

Le lun 17 nov 2003 à 20:38, Stephane Chazelas a tapoté :
| 2003/11/17, 19:01(+00), Thomas Nemeth:
| [...]
| >| cmd $(other cmd)
| >|
| >| n'a pas de sens sauf si on connait la valeur d'IFS. Pour des
| >
| > Aaahhh okok.
| > J'avais pas compris ça. Il faut dire que j'utilise rarement
| > cette forme : plus souvent var=`cmd1 | cmd2` puis cmd $var
|
| Qui est identique sauf si on utilise zsh.
|
| `...` est la même chose que $(...) aux problèmes de nesting près
| de `...`

Ok.


| Il se pourrait qu'il te faille relire la page de man de bash
| encore une fois (t'inquiète, on passe passe tous par là avant de
| le laisser tomber définitivement ;).

Bouh.
Je l'aie lue... Il y a 6 ou 7 ans. Depuis je ne l'ouvre que
pour des besoins particuliers, donc sans la parcourir en
entier.


| [...]
| >| > On peut faire quelquechose sous Windows :) ?
| >|
| >| J'y ai installé zsh sans trop de problème.
| >
| > Je parle de trucs utiles pour _produire_ directement quelquechose ;)
|
| Je sais pas, là dernière fois que je l'ai utilisé, c'était pour
| mon service militaire il y a quelques années maintenant. Donc,
| évidemment le mot "utile" perds un peu de son sens dans ces
| circonstances.

Héhéhé.
À mon service militaire, je faisait de l'administration réseau :
passer la serpillère dans la salle netware !
(bon, on a aussi fait quelques trucs comme des bidouilles sur
les machines des gradés pour les faire marcher).


Thomas
--
Quequette en décembre, layette en septembre... (Desproges)