avec (pd)ksh (/bin/ksh de NetBSD), j'ai ca :
i=0
cat file | while read line
do
i=$(expr $i + 1)
done
echo "$i"
et j'obtiens... 0 !
Avec le ksh de Solaris 9 (ksh88 si je ne m'abuse), j'ai bien le nombre
de lignes dans file. La ou je commence a (encore) moins comprendre,
c'est que bash me fait pareil... tandis que zsh donne le resultat que
j'attends.
A cote de cela, le code suivant est evidemment ok avec bash, (pd)ksh et
zsh :
i=0
while (( $i < 10 ))
do
i=$(expr $i + 1)
done
echo $i
avec (pd)ksh (/bin/ksh de NetBSD), j'ai ca : i=0 cat file | while read line do i=$(expr $i + 1) done echo "$i" et j'obtiens... 0 !
Avec le ksh de Solaris 9 (ksh88 si je ne m'abuse), j'ai bien le nombre de lignes dans file. La ou je commence a (encore) moins comprendre, c'est que bash me fait pareil... tandis que zsh donne le resultat que j'attends.
A cote de cela, le code suivant est evidemment ok avec bash, (pd)ksh et zsh : i=0 while (( $i < 10 )) do i=$(expr $i + 1) done echo $i
Ou est-ce que je peche ?
Bonsoir,
avec (pd)ksh (/bin/ksh de NetBSD), j'ai ca : i=0 cat file | while read line do i=$(expr $i + 1) done echo "$i" et j'obtiens... 0 !
Avec le ksh de Solaris 9 (ksh88 si je ne m'abuse), j'ai bien le nombre de lignes dans file. La ou je commence a (encore) moins comprendre, c'est que bash me fait pareil... tandis que zsh donne le resultat que j'attends.
A cote de cela, le code suivant est evidemment ok avec bash, (pd)ksh et zsh : i=0 while (( $i < 10 )) do i=$(expr $i + 1) done echo $i
Ou est-ce que je peche ?
Dans le man du bash au paragraphe Pipelines:
Pipelines A pipeline is a sequence of one or more commands separated by the character |. The format for a pipeline is:
[time [-p]] [ ! ] command [ | command2 ... ]
GNU Bash-3.0 2004 June 26 5
BASH(1) BASH(1)
The standard output of command is connected via a pipe to the standard input of command2. This connection is per- formed before any redirections specified by the command (see REDIRECTION below).
... Each command in a pipeline is executed as a separate pro- cess (i.e., in a subshell).
Ca ressemble à ça, non ?
Marc
Bonsoir
Bonsoir,
avec (pd)ksh (/bin/ksh de NetBSD), j'ai ca :
i=0
cat file | while read line
do
i=$(expr $i + 1)
done
echo "$i"
et j'obtiens... 0 !
Avec le ksh de Solaris 9 (ksh88 si je ne m'abuse), j'ai bien le nombre
de lignes dans file. La ou je commence a (encore) moins comprendre,
c'est que bash me fait pareil... tandis que zsh donne le resultat que
j'attends.
A cote de cela, le code suivant est evidemment ok avec bash, (pd)ksh et
zsh :
i=0
while (( $i < 10 ))
do
i=$(expr $i + 1)
done
echo $i
Ou est-ce que je peche ?
Bonsoir,
avec (pd)ksh (/bin/ksh de NetBSD), j'ai ca :
i=0
cat file | while read line
do
i=$(expr $i + 1)
done
echo "$i"
et j'obtiens... 0 !
Avec le ksh de Solaris 9 (ksh88 si je ne m'abuse), j'ai bien le nombre
de lignes dans file. La ou je commence a (encore) moins comprendre,
c'est que bash me fait pareil... tandis que zsh donne le resultat que
j'attends.
A cote de cela, le code suivant est evidemment ok avec bash, (pd)ksh et
zsh :
i=0
while (( $i < 10 ))
do
i=$(expr $i + 1)
done
echo $i
Ou est-ce que je peche ?
Dans le man du bash au paragraphe Pipelines:
Pipelines
A pipeline is a sequence of one or more commands separated
by the character |. The format for a pipeline is:
[time [-p]] [ ! ] command [ | command2 ... ]
GNU Bash-3.0 2004 June 26 5
BASH(1) BASH(1)
The standard output of command is connected via a pipe to
the standard input of command2. This connection is per-
formed before any redirections specified by the command
(see REDIRECTION below).
...
Each command in a pipeline is executed as a separate pro-
cess (i.e., in a subshell).
avec (pd)ksh (/bin/ksh de NetBSD), j'ai ca : i=0 cat file | while read line do i=$(expr $i + 1) done echo "$i" et j'obtiens... 0 !
Avec le ksh de Solaris 9 (ksh88 si je ne m'abuse), j'ai bien le nombre de lignes dans file. La ou je commence a (encore) moins comprendre, c'est que bash me fait pareil... tandis que zsh donne le resultat que j'attends.
A cote de cela, le code suivant est evidemment ok avec bash, (pd)ksh et zsh : i=0 while (( $i < 10 )) do i=$(expr $i + 1) done echo $i
Ou est-ce que je peche ?
Bonsoir,
avec (pd)ksh (/bin/ksh de NetBSD), j'ai ca : i=0 cat file | while read line do i=$(expr $i + 1) done echo "$i" et j'obtiens... 0 !
Avec le ksh de Solaris 9 (ksh88 si je ne m'abuse), j'ai bien le nombre de lignes dans file. La ou je commence a (encore) moins comprendre, c'est que bash me fait pareil... tandis que zsh donne le resultat que j'attends.
A cote de cela, le code suivant est evidemment ok avec bash, (pd)ksh et zsh : i=0 while (( $i < 10 )) do i=$(expr $i + 1) done echo $i
Ou est-ce que je peche ?
Dans le man du bash au paragraphe Pipelines:
Pipelines A pipeline is a sequence of one or more commands separated by the character |. The format for a pipeline is:
[time [-p]] [ ! ] command [ | command2 ... ]
GNU Bash-3.0 2004 June 26 5
BASH(1) BASH(1)
The standard output of command is connected via a pipe to the standard input of command2. This connection is per- formed before any redirections specified by the command (see REDIRECTION below).
... Each command in a pipeline is executed as a separate pro- cess (i.e., in a subshell).
Ca ressemble à ça, non ?
Marc
Jean-Louis Liagre
Marc Dilasser wrote:
Bonsoir
Bonsoir,
avec (pd)ksh (/bin/ksh de NetBSD), j'ai ca : i=0 cat file | while read line do i=$(expr $i + 1) done echo "$i" et j'obtiens... 0 !
Avec le ksh de Solaris 9 (ksh88 si je ne m'abuse), j'ai bien le nombre de lignes dans file. La ou je commence a (encore) moins comprendre, c'est que bash me fait pareil... tandis que zsh donne le resultat que j'attends.
A cote de cela, le code suivant est evidemment ok avec bash, (pd)ksh et zsh : i=0 while (( $i < 10 )) do i=$(expr $i + 1) done echo $i
Ou est-ce que je peche ?
Bonsoir,
avec (pd)ksh (/bin/ksh de NetBSD), j'ai ca : i=0 cat file | while read line do i=$(expr $i + 1) done echo "$i" et j'obtiens... 0 !
Avec le ksh de Solaris 9 (ksh88 si je ne m'abuse), j'ai bien le nombre de lignes dans file. La ou je commence a (encore) moins comprendre, c'est que bash me fait pareil... tandis que zsh donne le resultat que j'attends.
A cote de cela, le code suivant est evidemment ok avec bash, (pd)ksh et zsh : i=0 while (( $i < 10 )) do i=$(expr $i + 1) done echo $i
Ou est-ce que je peche ?
Dans le man du bash au paragraphe Pipelines:
Pipelines A pipeline is a sequence of one or more commands separated by the character |. The format for a pipeline is:
[time [-p]] [ ! ] command [ | command2 ... ]
GNU Bash-3.0 2004 June 26 5
BASH(1) BASH(1)
The standard output of command is connected via a pipe to the standard input of command2. This connection is per- formed before any redirections specified by the command (see REDIRECTION below).
.... Each command in a pipeline is executed as a separate pro- cess (i.e., in a subshell).
Ca ressemble à ça, non ?
Marc
Apparement, sous ksh, l'exécution dans le shell courant de la dernière commande n'est pas garantie ...
User Commands ksh93(1)
...
A pipeline is a sequence of one or more commands separated by |. The standard output of each command but the last is connected by a pipe(2) to the standard input of the next command. Each command, except possibly the last, is run as a separate process; the shell waits for the last command to terminate.
Marc Dilasser wrote:
Bonsoir
Bonsoir,
avec (pd)ksh (/bin/ksh de NetBSD), j'ai ca :
i=0
cat file | while read line
do
i=$(expr $i + 1)
done
echo "$i"
et j'obtiens... 0 !
Avec le ksh de Solaris 9 (ksh88 si je ne m'abuse), j'ai bien le nombre
de lignes dans file. La ou je commence a (encore) moins comprendre,
c'est que bash me fait pareil... tandis que zsh donne le resultat que
j'attends.
A cote de cela, le code suivant est evidemment ok avec bash, (pd)ksh
et zsh :
i=0
while (( $i < 10 ))
do
i=$(expr $i + 1)
done
echo $i
Ou est-ce que je peche ?
Bonsoir,
avec (pd)ksh (/bin/ksh de NetBSD), j'ai ca :
i=0
cat file | while read line
do
i=$(expr $i + 1)
done
echo "$i"
et j'obtiens... 0 !
Avec le ksh de Solaris 9 (ksh88 si je ne m'abuse), j'ai bien le nombre
de lignes dans file. La ou je commence a (encore) moins comprendre,
c'est que bash me fait pareil... tandis que zsh donne le resultat que
j'attends.
A cote de cela, le code suivant est evidemment ok avec bash, (pd)ksh
et zsh :
i=0
while (( $i < 10 ))
do
i=$(expr $i + 1)
done
echo $i
Ou est-ce que je peche ?
Dans le man du bash au paragraphe Pipelines:
Pipelines
A pipeline is a sequence of one or more commands separated
by the character |. The format for a pipeline is:
[time [-p]] [ ! ] command [ | command2 ... ]
GNU Bash-3.0 2004 June 26 5
BASH(1) BASH(1)
The standard output of command is connected via a pipe to
the standard input of command2. This connection is per-
formed before any redirections specified by the command
(see REDIRECTION below).
....
Each command in a pipeline is executed as a separate pro-
cess (i.e., in a subshell).
Ca ressemble à ça, non ?
Marc
Apparement, sous ksh, l'exécution dans le shell courant de la
dernière commande n'est pas garantie ...
User Commands ksh93(1)
...
A pipeline is a sequence of one or more commands separated
by |. The standard output of each command but the last is
connected by a pipe(2) to the standard input of the next
command. Each command, except possibly the last, is run as
a separate process; the shell waits for the last command to
terminate.
avec (pd)ksh (/bin/ksh de NetBSD), j'ai ca : i=0 cat file | while read line do i=$(expr $i + 1) done echo "$i" et j'obtiens... 0 !
Avec le ksh de Solaris 9 (ksh88 si je ne m'abuse), j'ai bien le nombre de lignes dans file. La ou je commence a (encore) moins comprendre, c'est que bash me fait pareil... tandis que zsh donne le resultat que j'attends.
A cote de cela, le code suivant est evidemment ok avec bash, (pd)ksh et zsh : i=0 while (( $i < 10 )) do i=$(expr $i + 1) done echo $i
Ou est-ce que je peche ?
Bonsoir,
avec (pd)ksh (/bin/ksh de NetBSD), j'ai ca : i=0 cat file | while read line do i=$(expr $i + 1) done echo "$i" et j'obtiens... 0 !
Avec le ksh de Solaris 9 (ksh88 si je ne m'abuse), j'ai bien le nombre de lignes dans file. La ou je commence a (encore) moins comprendre, c'est que bash me fait pareil... tandis que zsh donne le resultat que j'attends.
A cote de cela, le code suivant est evidemment ok avec bash, (pd)ksh et zsh : i=0 while (( $i < 10 )) do i=$(expr $i + 1) done echo $i
Ou est-ce que je peche ?
Dans le man du bash au paragraphe Pipelines:
Pipelines A pipeline is a sequence of one or more commands separated by the character |. The format for a pipeline is:
[time [-p]] [ ! ] command [ | command2 ... ]
GNU Bash-3.0 2004 June 26 5
BASH(1) BASH(1)
The standard output of command is connected via a pipe to the standard input of command2. This connection is per- formed before any redirections specified by the command (see REDIRECTION below).
.... Each command in a pipeline is executed as a separate pro- cess (i.e., in a subshell).
Ca ressemble à ça, non ?
Marc
Apparement, sous ksh, l'exécution dans le shell courant de la dernière commande n'est pas garantie ...
User Commands ksh93(1)
...
A pipeline is a sequence of one or more commands separated by |. The standard output of each command but the last is connected by a pipe(2) to the standard input of the next command. Each command, except possibly the last, is run as a separate process; the shell waits for the last command to terminate.
Stephane Chazelas
2006-02-23, 08:20(+01), Jean-Louis Liagre: [...]
Apparement, sous ksh, l'exécution dans le shell courant de la dernière commande n'est pas garantie ...
Et POSIX ou la specification UNIX te diront aussi que ce n'est pas garanti, qu'un shell peut faire ce qu'il veut et qu'un script ne doit pas faire d'assumption dans un sens ou dans l'autre.
Moi, je rajouterais que "while read" dans un script indique en general un script mal ecrit.
User Commands ksh93(1)
...
A pipeline is a sequence of one or more commands separated by |. The standard output of each command but the last is connected by a pipe(2) to the standard input of the next command. Each command, except possibly the last, is run as a separate process; the shell waits for the last command to terminate.
-- Stéphane
2006-02-23, 08:20(+01), Jean-Louis Liagre:
[...]
Apparement, sous ksh, l'exécution dans le shell courant de la
dernière commande n'est pas garantie ...
Et POSIX ou la specification UNIX te diront aussi que ce n'est
pas garanti, qu'un shell peut faire ce qu'il veut et qu'un
script ne doit pas faire d'assumption dans un sens ou dans
l'autre.
Moi, je rajouterais que "while read" dans un script indique en
general un script mal ecrit.
User Commands ksh93(1)
...
A pipeline is a sequence of one or more commands separated
by |. The standard output of each command but the last is
connected by a pipe(2) to the standard input of the next
command. Each command, except possibly the last, is run as
a separate process; the shell waits for the last command to
terminate.
Apparement, sous ksh, l'exécution dans le shell courant de la dernière commande n'est pas garantie ...
Et POSIX ou la specification UNIX te diront aussi que ce n'est pas garanti, qu'un shell peut faire ce qu'il veut et qu'un script ne doit pas faire d'assumption dans un sens ou dans l'autre.
Moi, je rajouterais que "while read" dans un script indique en general un script mal ecrit.
User Commands ksh93(1)
...
A pipeline is a sequence of one or more commands separated by |. The standard output of each command but the last is connected by a pipe(2) to the standard input of the next command. Each command, except possibly the last, is run as a separate process; the shell waits for the last command to terminate.
-- Stéphane
lhabert
Stephane Chazelas :
Moi, je rajouterais que "while read" dans un script indique en general un script mal ecrit.
Pouet!
Stephane Chazelas :
Moi, je rajouterais que "while read" dans un script indique en
general un script mal ecrit.
Moi, je rajouterais que "while read" dans un script indique en general un script mal ecrit.
Pouet!
Nicolas George
2006-02-23, 08:20(+01), Jean-Louis Liagre:
Apparement, sous ksh, l'exécution dans le shell courant de la dernière commande n'est pas garantie ...
Je pense qu'il faut interpréter ça tout simplement pour le cas des commandes externes : dans « foo | bar », bar est exécuté dans un sous-process quand ce n'est pas un builtin.
Stephane Chazelas wrote in message :
Et POSIX ou la specification UNIX te diront aussi que ce n'est pas garanti
Non : ni POSIX ni Single Unix ne disent quoi que ce soit sur ksh. Heureusement d'ailleurs.
2006-02-23, 08:20(+01), Jean-Louis Liagre:
Apparement, sous ksh, l'exécution dans le shell courant de la
dernière commande n'est pas garantie ...
Je pense qu'il faut interpréter ça tout simplement pour le cas des commandes
externes : dans « foo | bar », bar est exécuté dans un sous-process quand ce
n'est pas un builtin.
Stephane Chazelas wrote in message
<slrndvqu7l.4oi.stephane.chazelas@spam.is.invalid>:
Et POSIX ou la specification UNIX te diront aussi que ce n'est
pas garanti
Non : ni POSIX ni Single Unix ne disent quoi que ce soit sur ksh.
Heureusement d'ailleurs.
Apparement, sous ksh, l'exécution dans le shell courant de la dernière commande n'est pas garantie ...
Je pense qu'il faut interpréter ça tout simplement pour le cas des commandes externes : dans « foo | bar », bar est exécuté dans un sous-process quand ce n'est pas un builtin.
Stephane Chazelas wrote in message :
Et POSIX ou la specification UNIX te diront aussi que ce n'est pas garanti
Non : ni POSIX ni Single Unix ne disent quoi que ce soit sur ksh. Heureusement d'ailleurs.
Stephane Chazelas
On Thu, 23 Feb 2006 11:49:33 +0000 (UTC), Nicolas George wrote:
2006-02-23, 08:20(+01), Jean-Louis Liagre:
Apparement, sous ksh, l'exécution dans le shell courant de la dernière commande n'est pas garantie ...
Je pense qu'il faut interpréter ça tout simplement pour le cas des commandes externes : dans « foo | bar », bar est exécuté dans un sous-process quand ce n'est pas un builtin.
On peut s'attendre a tout avec ksh. Ca peut tres bien dependre de plein de facteurs. Par exemple, si on a affaire a une fonction, il peut peut-etre y avoir des cas ou elle sera executee dans un sous-shell, la page de man ne se mouille pas.
Stephane Chazelas wrote in message :
Et POSIX ou la specification UNIX te diront aussi que ce n'est pas garanti
Non : ni POSIX ni Single Unix ne disent quoi que ce soit sur ksh. Heureusement d'ailleurs.
Bien sur, je parlais des shells POSIX et des scripts POSIX, ca va de soi.
-- Stephane
On Thu, 23 Feb 2006 11:49:33 +0000 (UTC), Nicolas George wrote:
2006-02-23, 08:20(+01), Jean-Louis Liagre:
Apparement, sous ksh, l'exécution dans le shell courant de la
dernière commande n'est pas garantie ...
Je pense qu'il faut interpréter ça tout simplement pour le cas des commandes
externes : dans « foo | bar », bar est exécuté dans un sous-process quand ce
n'est pas un builtin.
On peut s'attendre a tout avec ksh. Ca peut tres bien dependre
de plein de facteurs. Par exemple, si on a affaire a une
fonction, il peut peut-etre y avoir des cas ou elle sera
executee dans un sous-shell, la page de man ne se mouille pas.
Stephane Chazelas wrote in message
<slrndvqu7l.4oi.stephane.chazelas@spam.is.invalid>:
Et POSIX ou la specification UNIX te diront aussi que ce n'est
pas garanti
Non : ni POSIX ni Single Unix ne disent quoi que ce soit sur ksh.
Heureusement d'ailleurs.
Bien sur, je parlais des shells POSIX et des scripts POSIX, ca
va de soi.
On Thu, 23 Feb 2006 11:49:33 +0000 (UTC), Nicolas George wrote:
2006-02-23, 08:20(+01), Jean-Louis Liagre:
Apparement, sous ksh, l'exécution dans le shell courant de la dernière commande n'est pas garantie ...
Je pense qu'il faut interpréter ça tout simplement pour le cas des commandes externes : dans « foo | bar », bar est exécuté dans un sous-process quand ce n'est pas un builtin.
On peut s'attendre a tout avec ksh. Ca peut tres bien dependre de plein de facteurs. Par exemple, si on a affaire a une fonction, il peut peut-etre y avoir des cas ou elle sera executee dans un sous-shell, la page de man ne se mouille pas.
Stephane Chazelas wrote in message :
Et POSIX ou la specification UNIX te diront aussi que ce n'est pas garanti
Non : ni POSIX ni Single Unix ne disent quoi que ce soit sur ksh. Heureusement d'ailleurs.
Bien sur, je parlais des shells POSIX et des scripts POSIX, ca va de soi.
-- Stephane
Nicolas George
Stephane Chazelas wrote in message :
Bien sur, je parlais des shells POSIX et des scripts POSIX, ca va de soi.
Non, ça ne va pas de soi, pas en réponse à un paragraphe qui parle spécifiquement de ksh, justement. En réponse à un paragraphe qui parle de ksh, on parle implicitement de ksh, c'est ça qui va de soi.
Stephane Chazelas wrote in message
<slrndvr9uf.218.stephane_chazelas@duey.spider.com>:
Bien sur, je parlais des shells POSIX et des scripts POSIX, ca
va de soi.
Non, ça ne va pas de soi, pas en réponse à un paragraphe qui parle
spécifiquement de ksh, justement. En réponse à un paragraphe qui parle de
ksh, on parle implicitement de ksh, c'est ça qui va de soi.
Bien sur, je parlais des shells POSIX et des scripts POSIX, ca va de soi.
Non, ça ne va pas de soi, pas en réponse à un paragraphe qui parle spécifiquement de ksh, justement. En réponse à un paragraphe qui parle de ksh, on parle implicitement de ksh, c'est ça qui va de soi.
Jean-Louis Liagre
Nicolas George wrote:
2006-02-23, 08:20(+01), Jean-Louis Liagre:
Apparement, sous ksh, l'exécution dans le shell courant de la dernière commande n'est pas garantie ...
Je pense qu'il faut interpréter ça tout simplement pour le cas des commandes externes : dans « foo | bar », bar est exécuté dans un sous-process quand ce n'est pas un builtin.
Ca se tient, ça m'étonnait aussi ce "possibly".
Nicolas George wrote:
2006-02-23, 08:20(+01), Jean-Louis Liagre:
Apparement, sous ksh, l'exécution dans le shell courant de la
dernière commande n'est pas garantie ...
Je pense qu'il faut interpréter ça tout simplement pour le cas des commandes
externes : dans « foo | bar », bar est exécuté dans un sous-process quand ce
n'est pas un builtin.
Apparement, sous ksh, l'exécution dans le shell courant de la dernière commande n'est pas garantie ...
Je pense qu'il faut interpréter ça tout simplement pour le cas des commandes externes : dans « foo | bar », bar est exécuté dans un sous-process quand ce n'est pas un builtin.