Je vais finir par croire qu'il y a une invasion de marseillais sur Usenet depuis quelques temps. ;-)
il y a plus léger que le perl
Mais moins portable et moins à la portée de tous.
euh, printf, stat, lstat et getpwuid ça doit trainer dans toutes les libc [...]
Mais cc ne traine pas sur tous les systemes et ecrire un script qui compile un programme pour l'executer ensuite, ce n'est pas beaucoup plus leger que perl.
-- Stéphane
2006-12-15, 18:50(+01), Moi:
Dans le message <news:elsbqm$fm7$2@gyptis.org>,
*Moi* tapota sur f.c.o.unix :
Je vais finir par croire qu'il y a une invasion de marseillais sur
Usenet depuis quelques temps. ;-)
il y a plus léger que le perl
Mais moins portable et moins à la portée de tous.
euh, printf, stat, lstat et getpwuid ça doit trainer dans
toutes les libc
[...]
Mais cc ne traine pas sur tous les systemes et ecrire un script
qui compile un programme pour l'executer ensuite, ce n'est pas
beaucoup plus leger que perl.
Je vais finir par croire qu'il y a une invasion de marseillais sur Usenet depuis quelques temps. ;-)
il y a plus léger que le perl
Mais moins portable et moins à la portée de tous.
euh, printf, stat, lstat et getpwuid ça doit trainer dans toutes les libc [...]
Mais cc ne traine pas sur tous les systemes et ecrire un script qui compile un programme pour l'executer ensuite, ce n'est pas beaucoup plus leger que perl.
-- Stéphane
Sébastien Monbrun aka TiChou
Dans le message <news:, *Stephane Chazelas* tapota sur f.c.o.unix :
Moi:
euh, printf, stat, lstat et getpwuid ça doit trainer dans toutes les libc
Nous sommes sur fr.comp.lang.c ?
Mais cc ne traine pas sur tous les systemes et ecrire un script qui compile un programme pour l'executer ensuite, ce n'est pas beaucoup plus leger que perl.
Et, je me répète, ce n'est pas à la portée de tous.
-- Sébastien Monbrun aka TiChou
Dans le message <news:slrneo5p56.gdq.stephane.chazelas@spam.is.invalid>,
*Stephane Chazelas* tapota sur f.c.o.unix :
Moi:
euh, printf, stat, lstat et getpwuid ça doit trainer dans
toutes les libc
Nous sommes sur fr.comp.lang.c ?
Mais cc ne traine pas sur tous les systemes et ecrire un script
qui compile un programme pour l'executer ensuite, ce n'est pas
beaucoup plus leger que perl.
Et, je me répète, ce n'est pas à la portée de tous.
Dans le message <news:, *Stephane Chazelas* tapota sur f.c.o.unix :
Moi:
euh, printf, stat, lstat et getpwuid ça doit trainer dans toutes les libc
Nous sommes sur fr.comp.lang.c ?
Mais cc ne traine pas sur tous les systemes et ecrire un script qui compile un programme pour l'executer ensuite, ce n'est pas beaucoup plus leger que perl.
Et, je me répète, ce n'est pas à la portée de tous.
-- Sébastien Monbrun aka TiChou
Moi
Par exemple ls -l toto -rwxrwxrwx NUM owner ...... toto
OWNER=` proprio toto` echo $OWNER ---> owner
Merci
On peut utiliser cut man cut
mais bien sur
ls -l foo | cut -d ' ' -f4
c'est mieux que 4 tonnes de perl
Par exemple
ls -l toto
-rwxrwxrwx NUM owner ...... toto
Par exemple ls -l toto -rwxrwxrwx NUM owner ...... toto
OWNER=` proprio toto` echo $OWNER ---> owner
Merci
On peut utiliser cut man cut
mais bien sur
ls -l foo | cut -d ' ' -f4
c'est mieux que 4 tonnes de perl
Moi
Moi:
euh, printf, stat, lstat et getpwuid ça doit trainer dans toutes les libc
Nous sommes sur fr.comp.lang.c ?
D'abord ils nous auraient viré puisque c'est pas du C99 (sauf printf) Secondo il doit bien trainer une libc sur la machine de l'intervenant
Mais cc ne traine pas sur tous les systemes et ecrire un script qui compile un programme pour l'executer ensuite, ce n'est pas beaucoup plus leger que perl.
Et, je me répète, ce n'est pas à la portée de tous.
et ça c'est plus à la portée de tous que perl si toutefois /bin/sh traine sur la machine
#!/bin/sh foo=$1 owner=`ls -l ${foo} | cut -d ' ' -f4` echo $owner is the owner of $foo
résultat :
root is the owner of /etc/passwd root is the owner of /etc/rc.conf root is the owner of /usr/libexec/sendmail
désolé, j'ai plus de linux
Moi:
euh, printf, stat, lstat et getpwuid ça doit trainer dans
toutes les libc
Nous sommes sur fr.comp.lang.c ?
D'abord ils nous auraient viré puisque c'est pas du C99 (sauf printf)
Secondo il doit bien trainer une libc sur la machine de l'intervenant
Mais cc ne traine pas sur tous les systemes et ecrire un script
qui compile un programme pour l'executer ensuite, ce n'est pas
beaucoup plus leger que perl.
Et, je me répète, ce n'est pas à la portée de tous.
et ça c'est plus à la portée de tous que perl si toutefois
/bin/sh traine sur la machine
#!/bin/sh
foo=$1
owner=`ls -l ${foo} | cut -d ' ' -f4`
echo $owner is the owner of $foo
résultat :
root is the owner of /etc/passwd
root is the owner of /etc/rc.conf
root is the owner of /usr/libexec/sendmail
euh, printf, stat, lstat et getpwuid ça doit trainer dans toutes les libc
Nous sommes sur fr.comp.lang.c ?
D'abord ils nous auraient viré puisque c'est pas du C99 (sauf printf) Secondo il doit bien trainer une libc sur la machine de l'intervenant
Mais cc ne traine pas sur tous les systemes et ecrire un script qui compile un programme pour l'executer ensuite, ce n'est pas beaucoup plus leger que perl.
Et, je me répète, ce n'est pas à la portée de tous.
et ça c'est plus à la portée de tous que perl si toutefois /bin/sh traine sur la machine
#!/bin/sh foo=$1 owner=`ls -l ${foo} | cut -d ' ' -f4` echo $owner is the owner of $foo
résultat :
root is the owner of /etc/passwd root is the owner of /etc/rc.conf root is the owner of /usr/libexec/sendmail
désolé, j'ai plus de linux
Stephane Chazelas
2006-12-15, 19:55(+01), Moi: [...]
Et, je me répète, ce n'est pas à la portée de tous.
et ça c'est plus à la portée de tous que perl si toutefois /bin/sh traine sur la machine
#!/bin/sh foo=$1 owner=`ls -l ${foo} | cut -d ' ' -f4` echo $owner is the owner of $foo [...]
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"
-- Stéphane
2006-12-15, 19:55(+01), Moi:
[...]
Et, je me répète, ce n'est pas à la portée de tous.
et ça c'est plus à la portée de tous que perl si toutefois
/bin/sh traine sur la machine
#!/bin/sh
foo=$1
owner=`ls -l ${foo} | cut -d ' ' -f4`
echo $owner is the owner of $foo
[...]
Mais ce n'est pas correct
owner=`
ls -ld -- "$foo" |
head -n 1 |
cut -d ' ' -f4
`
#!/bin/sh foo=$1 owner=`ls -l ${foo} | cut -d ' ' -f4` echo $owner is the owner of $foo [...]
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"
disons que c'est écrit à la vite mais qu'est ce qui n'est pas correct ?
Ce script appliqué au fichier '.' fout la pagaille. OK Remplacer echo par printf ? On en a déja parlé.OK
Et après ?
Sébastien Monbrun aka TiChou
Dans le message <news:em189d$o9m$, *Ego* tapota sur f.c.o.unix :
owner=`ls -l ${foo} | cut -d ' ' -f4`
owner=` ls -ld -- "$foo" | head -n 1 | cut -d ' ' -f4 `
mais qu'est ce qui n'est pas correct ?
Ce script appliqué au fichier '.' fout la pagaille. OK Remplacer echo par printf ? On en a déja parlé.OK
Et après ?
Le script aurait aussi foutu la pagaille dans les cas suivants :
- fichier contenant, entre autre, des espaces => "$foo" ; - un répertoire => -d ; - fichier contenant un retour à la ligne => head -n 1 ; - fichier commençant par un - => -- ; - et j'en oublie peut-être.
À 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.
-- Sébastien Monbrun aka TiChou
Dans le message <news:em189d$o9m$1@gyptis.org>,
*Ego* tapota sur f.c.o.unix :
owner=`ls -l ${foo} | cut -d ' ' -f4`
owner=`
ls -ld -- "$foo" |
head -n 1 |
cut -d ' ' -f4
`
mais qu'est ce qui n'est pas correct ?
Ce script appliqué au fichier '.' fout
la pagaille. OK
Remplacer echo par printf ? On en a déja parlé.OK
Et après ?
Le script aurait aussi foutu la pagaille dans les cas suivants :
- fichier contenant, entre autre, des espaces => "$foo" ;
- un répertoire => -d ;
- fichier contenant un retour à la ligne => head -n 1 ;
- fichier commençant par un - => -- ;
- et j'en oublie peut-être.
À 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.
Dans le message <news:em189d$o9m$, *Ego* tapota sur f.c.o.unix :
owner=`ls -l ${foo} | cut -d ' ' -f4`
owner=` ls -ld -- "$foo" | head -n 1 | cut -d ' ' -f4 `
mais qu'est ce qui n'est pas correct ?
Ce script appliqué au fichier '.' fout la pagaille. OK Remplacer echo par printf ? On en a déja parlé.OK
Et après ?
Le script aurait aussi foutu la pagaille dans les cas suivants :
- fichier contenant, entre autre, des espaces => "$foo" ; - un répertoire => -d ; - fichier contenant un retour à la ligne => head -n 1 ; - fichier commençant par un - => -- ; - et j'en oublie peut-être.
À 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.
-- Sébastien Monbrun aka TiChou
Ego
Ce script appliqué au fichier '.' fout la pagaille. OK
Le script aurait aussi foutu la pagaille dans les cas suivants : - un répertoire => -d ;
je l'ai signalé. Ca merde avec le '.'
À 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.
je n'ai pas de LS_OPTIONS
bon, ya mieux c'est sur
Ce script appliqué au fichier '.' fout
la pagaille. OK
Le script aurait aussi foutu la pagaille dans les cas suivants :
- un répertoire => -d ;
je l'ai signalé. Ca merde avec le '.'
À 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.
Ce script appliqué au fichier '.' fout la pagaille. OK
Le script aurait aussi foutu la pagaille dans les cas suivants : - un répertoire => -d ;
je l'ai signalé. Ca merde avec le '.'
À 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.
Dans le message <news:em189d$o9m$, *Ego* tapota sur f.c.o.unix :
owner=`ls -l ${foo} | cut -d ' ' -f4`
owner=` ls -ld -- "$foo" | head -n 1 | cut -d ' ' -f4 `
mais qu'est ce qui n'est pas correct ?
Ce script appliqué au fichier '.' fout la pagaille. OK Remplacer echo par printf ? On en a déja parlé.OK
Et après ?
Le script aurait aussi foutu la pagaille dans les cas suivants :
- fichier contenant, entre autre, des espaces => "$foo" ;
Oui, ou ?, *, [... Une variable sans ces quotes est une sorte tres particuliere de liste en sh, ksh, bash...
- un répertoire => -d ; - fichier contenant un retour à la ligne => head -n 1 ; - fichier commençant par un - => -- ; - et j'en oublie peut-être.
À 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?
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.
$ ls -l total 8 -rw-r--r-- 1 chazelas chazelas 0 Dec 16 16:22 * -rwxr-xr-x 1 chazelas chazelas 88 Dec 16 16:24 -n drwxr-xr-x 2 chazelas chazelas 4096 Dec 16 16:24 2 -rw-r--r-- 1 chazelas chazelas 0 Dec 16 16:22 a?b -rw-r--r-- 1 chazelas chazelas 0 Dec 16 18:25 a b $ -n -n sh-3.1$ exit sh-3.1$ exit sh-3.1$ exit $ -n '*' $ -n ls /bin/ls: /bin/ls: cannot execute binary file $ ./-n -n 1000 1000 1000 1000 b 1000 is the owner of -n $ ./-n '*' 1000 1000 b 1000 2: 1000 1000 1000 1000 1000 is the owner of * -n 2 a b a b $ ./-n 'a b' ls: a: No such file or directory ls: b: No such file or directory is the owner of a b $ ./-n 2 chazelas chazelas chazelas chazelas chazelas is the owner of 2 $ ./-n $'anb' ls: a: No such file or directory ls: b: No such file or directory is the owner of a b $ ./-n 'a[[:cntrl:]]b' chazelas b is the owner of a b $
Dans le message <news:em189d$o9m$1@gyptis.org>,
*Ego* tapota sur f.c.o.unix :
owner=`ls -l ${foo} | cut -d ' ' -f4`
owner=`
ls -ld -- "$foo" |
head -n 1 |
cut -d ' ' -f4
`
mais qu'est ce qui n'est pas correct ?
Ce script appliqué au fichier '.' fout
la pagaille. OK
Remplacer echo par printf ? On en a déja parlé.OK
Et après ?
Le script aurait aussi foutu la pagaille dans les cas suivants :
- fichier contenant, entre autre, des espaces => "$foo" ;
Oui, ou ?, *, [... Une variable sans ces quotes est une sorte
tres particuliere de liste en sh, ksh, bash...
- un répertoire => -d ;
- fichier contenant un retour à la ligne => head -n 1 ;
- fichier commençant par un - => -- ;
- et j'en oublie peut-être.
À 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?
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.
$ ls -l
total 8
-rw-r--r-- 1 chazelas chazelas 0 Dec 16 16:22 *
-rwxr-xr-x 1 chazelas chazelas 88 Dec 16 16:24 -n
drwxr-xr-x 2 chazelas chazelas 4096 Dec 16 16:24 2
-rw-r--r-- 1 chazelas chazelas 0 Dec 16 16:22 a?b
-rw-r--r-- 1 chazelas chazelas 0 Dec 16 18:25 a b
$ -n -n
sh-3.1$ exit
sh-3.1$ exit
sh-3.1$ exit
$ -n '*'
$ -n ls
/bin/ls: /bin/ls: cannot execute binary file
$ ./-n -n
1000 1000 1000 1000 b 1000 is the owner of -n
$ ./-n '*'
1000 1000 b 1000 2: 1000 1000 1000 1000 1000 is the owner of * -n 2 a
b a b
$ ./-n 'a b'
ls: a: No such file or directory
ls: b: No such file or directory
is the owner of a b
$ ./-n 2
chazelas chazelas chazelas chazelas chazelas is the owner of 2
$ ./-n $'anb'
ls: a: No such file or directory
ls: b: No such file or directory
is the owner of a b
$ ./-n 'a[[:cntrl:]]b'
chazelas b is the owner of a
b
$
Dans le message <news:em189d$o9m$, *Ego* tapota sur f.c.o.unix :
owner=`ls -l ${foo} | cut -d ' ' -f4`
owner=` ls -ld -- "$foo" | head -n 1 | cut -d ' ' -f4 `
mais qu'est ce qui n'est pas correct ?
Ce script appliqué au fichier '.' fout la pagaille. OK Remplacer echo par printf ? On en a déja parlé.OK
Et après ?
Le script aurait aussi foutu la pagaille dans les cas suivants :
- fichier contenant, entre autre, des espaces => "$foo" ;
Oui, ou ?, *, [... Une variable sans ces quotes est une sorte tres particuliere de liste en sh, ksh, bash...
- un répertoire => -d ; - fichier contenant un retour à la ligne => head -n 1 ; - fichier commençant par un - => -- ; - et j'en oublie peut-être.
À 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?
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.
$ ls -l total 8 -rw-r--r-- 1 chazelas chazelas 0 Dec 16 16:22 * -rwxr-xr-x 1 chazelas chazelas 88 Dec 16 16:24 -n drwxr-xr-x 2 chazelas chazelas 4096 Dec 16 16:24 2 -rw-r--r-- 1 chazelas chazelas 0 Dec 16 16:22 a?b -rw-r--r-- 1 chazelas chazelas 0 Dec 16 18:25 a b $ -n -n sh-3.1$ exit sh-3.1$ exit sh-3.1$ exit $ -n '*' $ -n ls /bin/ls: /bin/ls: cannot execute binary file $ ./-n -n 1000 1000 1000 1000 b 1000 is the owner of -n $ ./-n '*' 1000 1000 b 1000 2: 1000 1000 1000 1000 1000 is the owner of * -n 2 a b a b $ ./-n 'a b' ls: a: No such file or directory ls: b: No such file or directory is the owner of a b $ ./-n 2 chazelas chazelas chazelas chazelas chazelas is the owner of 2 $ ./-n $'anb' ls: a: No such file or directory ls: b: No such file or directory is the owner of a b $ ./-n 'a[[:cntrl:]]b' chazelas b is the owner of a b $
