Dans le message <news:, *Stephane Chazelas* tapota sur f.c.o.unix :
À noter que les deux scripts risquent aussi de foutre la pagaille dans le cas où la commande ls lirait la variable d'environnement LS_OPTIONS avec des options qui modifieraient le rendu de l'affichage.
Sous quel systeme y a-t'il un ls qui prend en compte une telle variable d'environnement?
À vrai dire, je ne sais pas. Curieusement, le man de GNU ls indique dans la partie consacrée aux variables d'environnement :
The variable LS_COLORS is used to specify the colors used. The variable LS_OPTIONS gives default options.
Mais à l'usage, LS_OPTIONS est ignorée par la commande GNU ls.
-- Sébastien Monbrun aka TiChou
Dans le message <news:slrneo8fdi.6eb.stephane.chazelas@spam.is.invalid>,
*Stephane Chazelas* tapota sur f.c.o.unix :
À noter que les deux scripts risquent aussi de foutre la pagaille dans
le cas où la commande ls lirait la variable d'environnement LS_OPTIONS
avec des options qui modifieraient le rendu de l'affichage.
Sous quel systeme y a-t'il un ls qui prend en compte une telle
variable d'environnement?
À vrai dire, je ne sais pas. Curieusement, le man de GNU ls indique dans la
partie consacrée aux variables d'environnement :
The variable LS_COLORS is used to specify the colors used. The variable
LS_OPTIONS gives default options.
Mais à l'usage, LS_OPTIONS est ignorée par la commande GNU ls.
Dans le message <news:, *Stephane Chazelas* tapota sur f.c.o.unix :
À noter que les deux scripts risquent aussi de foutre la pagaille dans le cas où la commande ls lirait la variable d'environnement LS_OPTIONS avec des options qui modifieraient le rendu de l'affichage.
Sous quel systeme y a-t'il un ls qui prend en compte une telle variable d'environnement?
À vrai dire, je ne sais pas. Curieusement, le man de GNU ls indique dans la partie consacrée aux variables d'environnement :
The variable LS_COLORS is used to specify the colors used. The variable LS_OPTIONS gives default options.
Mais à l'usage, LS_OPTIONS est ignorée par la commande GNU ls.
-- Sébastien Monbrun aka TiChou
Ego
Sous quel systeme y a-t'il un ls qui prend en compte une telle variable d'environnement?
À vrai dire, je ne sais pas. Curieusement, le man de GNU ls indique dans la partie consacrée aux variables d'environnement : The variable LS_COLORS is used to specify the colors used. The variable LS_OPTIONS gives default options. Mais à l'usage, LS_OPTIONS est ignorée par la commande GNU ls.
oui, mais GNU is not Unix.
Sous quel systeme y a-t'il un ls qui prend en compte une telle
variable d'environnement?
À vrai dire, je ne sais pas. Curieusement, le man de GNU ls indique dans
la partie consacrée aux variables d'environnement :
The variable LS_COLORS is used to specify the colors used. The variable
LS_OPTIONS gives default options.
Mais à l'usage, LS_OPTIONS est ignorée par la commande GNU ls.
Sous quel systeme y a-t'il un ls qui prend en compte une telle variable d'environnement?
À vrai dire, je ne sais pas. Curieusement, le man de GNU ls indique dans la partie consacrée aux variables d'environnement : The variable LS_COLORS is used to specify the colors used. The variable LS_OPTIONS gives default options. Mais à l'usage, LS_OPTIONS est ignorée par la commande GNU ls.
oui, mais GNU is not Unix.
Ego
Oui, ou ?, *, [... Une variable sans ces quotes est une sorte tres particuliere de liste en sh, ksh, bash...
Donc : la solution scripting en shell est à proscrire
Sous quel systeme y a-t'il un ls qui prend en compte une telle variable d'environnement?
j'aurais plutôt demandé de quelle race de ls il s'agissait.
La localisation (LC_*, LANG) peut avoir une influence (mais je pense que les premiers champs seront en general les memes). Il peut arriver que des champs soient collés, et il peut arriver que des usernames contiennent des espaces.
effectivement, il y a trop d'aleas.
finalement la solution des appels système stat, lstat ou getpwuid est la meilleure. quelle soit faite en perl ou autre
Oui, ou ?, *, [... Une variable sans ces quotes est une sorte
tres particuliere de liste en sh, ksh, bash...
Donc : la solution scripting en shell est à proscrire
Sous quel systeme y a-t'il un ls qui prend en compte une telle
variable d'environnement?
j'aurais plutôt demandé de quelle race
de ls il s'agissait.
La localisation (LC_*, LANG) peut avoir une influence (mais je
pense que les premiers champs seront en general les memes). Il
peut arriver que des champs soient collés, et il peut arriver
que des usernames contiennent des espaces.
effectivement, il y a trop d'aleas.
finalement la solution des appels système stat, lstat ou getpwuid
est la meilleure. quelle soit faite en perl ou autre
Oui, ou ?, *, [... Une variable sans ces quotes est une sorte tres particuliere de liste en sh, ksh, bash...
Donc : la solution scripting en shell est à proscrire
Sous quel systeme y a-t'il un ls qui prend en compte une telle variable d'environnement?
j'aurais plutôt demandé de quelle race de ls il s'agissait.
La localisation (LC_*, LANG) peut avoir une influence (mais je pense que les premiers champs seront en general les memes). Il peut arriver que des champs soient collés, et il peut arriver que des usernames contiennent des espaces.
effectivement, il y a trop d'aleas.
finalement la solution des appels système stat, lstat ou getpwuid est la meilleure. quelle soit faite en perl ou autre
Stephane Chazelas
2006-12-17, 10:50(+01), Ego:
Oui, ou ?, *, [... Une variable sans ces quotes est une sorte tres particuliere de liste en sh, ksh, bash...
Donc : la solution scripting en shell est à proscrire
Pas forcement. Il faut juste connaitre la syntaxe.
Sous quel systeme y a-t'il un ls qui prend en compte une telle variable d'environnement?
j'aurais plutôt demandé de quelle race de ls il s'agissait.
La localisation (LC_*, LANG) peut avoir une influence (mais je pense que les premiers champs seront en general les memes). Il peut arriver que des champs soient collés, et il peut arriver que des usernames contiennent des espaces.
effectivement, il y a trop d'aleas.
finalement la solution des appels système stat, lstat ou getpwuid est la meilleure. quelle soit faite en perl ou autre [...]
Note que getpwuid n'est pas un appel systeme. Le systeme n'a aucune notion de user name, c'est juste au niveau des applications. ls fait des lstats et getpwuid. C'est l'interface shell a stat/lstat comme le stat() de perl est l'interface a stat(2). Le probleme de ls est que l'info qu'il produit n'est pas facilement et fiablement post-processable. D'ou des commandes "stat(1)" ou le -printf de GNU find non-standard qu'on voit apparaitre sur differents systemes.
-- Stéphane
2006-12-17, 10:50(+01), Ego:
Oui, ou ?, *, [... Une variable sans ces quotes est une sorte
tres particuliere de liste en sh, ksh, bash...
Donc : la solution scripting en shell est à proscrire
Pas forcement. Il faut juste connaitre la syntaxe.
Sous quel systeme y a-t'il un ls qui prend en compte une telle
variable d'environnement?
j'aurais plutôt demandé de quelle race
de ls il s'agissait.
La localisation (LC_*, LANG) peut avoir une influence (mais je
pense que les premiers champs seront en general les memes). Il
peut arriver que des champs soient collés, et il peut arriver
que des usernames contiennent des espaces.
effectivement, il y a trop d'aleas.
finalement la solution des appels système stat, lstat ou getpwuid
est la meilleure. quelle soit faite en perl ou autre
[...]
Note que getpwuid n'est pas un appel systeme. Le systeme n'a
aucune notion de user name, c'est juste au niveau des
applications. ls fait des lstats et getpwuid. C'est l'interface
shell a stat/lstat comme le stat() de perl est l'interface a
stat(2). Le probleme de ls est que l'info qu'il produit n'est
pas facilement et fiablement post-processable. D'ou des
commandes "stat(1)" ou le -printf de GNU find non-standard qu'on
voit apparaitre sur differents systemes.
Oui, ou ?, *, [... Une variable sans ces quotes est une sorte tres particuliere de liste en sh, ksh, bash...
Donc : la solution scripting en shell est à proscrire
Pas forcement. Il faut juste connaitre la syntaxe.
Sous quel systeme y a-t'il un ls qui prend en compte une telle variable d'environnement?
j'aurais plutôt demandé de quelle race de ls il s'agissait.
La localisation (LC_*, LANG) peut avoir une influence (mais je pense que les premiers champs seront en general les memes). Il peut arriver que des champs soient collés, et il peut arriver que des usernames contiennent des espaces.
effectivement, il y a trop d'aleas.
finalement la solution des appels système stat, lstat ou getpwuid est la meilleure. quelle soit faite en perl ou autre [...]
Note que getpwuid n'est pas un appel systeme. Le systeme n'a aucune notion de user name, c'est juste au niveau des applications. ls fait des lstats et getpwuid. C'est l'interface shell a stat/lstat comme le stat() de perl est l'interface a stat(2). Le probleme de ls est que l'info qu'il produit n'est pas facilement et fiablement post-processable. D'ou des commandes "stat(1)" ou le -printf de GNU find non-standard qu'on voit apparaitre sur differents systemes.
Dans le message <news:, *Stephane Chazelas* tapota sur f.c.o.unix :
À noter que les deux scripts risquent aussi de foutre la pagaille dans le cas où la commande ls lirait la variable d'environnement LS_OPTIONS avec des options qui modifieraient le rendu de l'affichage.
Sous quel systeme y a-t'il un ls qui prend en compte une telle variable d'environnement?
À vrai dire, je ne sais pas. Curieusement, le man de GNU ls indique dans la partie consacrée aux variables d'environnement :
The variable LS_COLORS is used to specify the colors used. The variable LS_OPTIONS gives default options.
Mais à l'usage, LS_OPTIONS est ignorée par la commande GNU ls.
Rien de tel dans ma page de man de GNU ls ni dans les sources de GNU ls.
Peut-etre c'est ta distribution qui ajoute un alias ls='ls "${LS_OPTIONS[@]}"' dans /etc/zshrc, /etc/bashrc...
Dans le message <news:slrneo8fdi.6eb.stephane.chazelas@spam.is.invalid>,
*Stephane Chazelas* tapota sur f.c.o.unix :
À noter que les deux scripts risquent aussi de foutre la pagaille dans
le cas où la commande ls lirait la variable d'environnement LS_OPTIONS
avec des options qui modifieraient le rendu de l'affichage.
Sous quel systeme y a-t'il un ls qui prend en compte une telle
variable d'environnement?
À vrai dire, je ne sais pas. Curieusement, le man de GNU ls indique dans la
partie consacrée aux variables d'environnement :
The variable LS_COLORS is used to specify the colors used. The variable
LS_OPTIONS gives default options.
Mais à l'usage, LS_OPTIONS est ignorée par la commande GNU ls.
Rien de tel dans ma page de man de GNU ls ni dans les sources de
GNU ls.
Peut-etre c'est ta distribution qui ajoute un
alias ls='ls "${LS_OPTIONS[@]}"' dans /etc/zshrc, /etc/bashrc...
Dans le message <news:, *Stephane Chazelas* tapota sur f.c.o.unix :
À noter que les deux scripts risquent aussi de foutre la pagaille dans le cas où la commande ls lirait la variable d'environnement LS_OPTIONS avec des options qui modifieraient le rendu de l'affichage.
Sous quel systeme y a-t'il un ls qui prend en compte une telle variable d'environnement?
À vrai dire, je ne sais pas. Curieusement, le man de GNU ls indique dans la partie consacrée aux variables d'environnement :
The variable LS_COLORS is used to specify the colors used. The variable LS_OPTIONS gives default options.
Mais à l'usage, LS_OPTIONS est ignorée par la commande GNU ls.
Rien de tel dans ma page de man de GNU ls ni dans les sources de GNU ls.
Peut-etre c'est ta distribution qui ajoute un alias ls='ls "${LS_OPTIONS[@]}"' dans /etc/zshrc, /etc/bashrc...
-- Stéphane
Nicolas George
Stephane Chazelas wrote in message :
Mais ce n'est pas correct
owner=` ls -ld -- "$foo" | head -n 1 | cut -d ' ' -f4 `
printf '%s is the owner of %sn' "$owner" "$foo"
Chez moi, ça donne le groupe.
Stephane Chazelas wrote in message
<slrneo844b.4kj.stephane.chazelas@spam.is.invalid>:
Mais ce n'est pas correct
owner=`
ls -ld -- "$foo" |
head -n 1 |
cut -d ' ' -f4
`
