Coucou la liste.

Je suppose que c'est une FAQ, mais je n'ai pas réussit à mettre la main
sur la FAQ du groupe.

Donc, question :

Sous zsh, on peut faire :

$ toto="valeur de toto"
$ titi=toto
$ echo ${(P)titi}
valeur de toto
$ youpi
command not found: youpi

J'aimerai savoir s'il n'y a pas moyen de faire cela en shell portable.
Genre quelquechose qui fonctionnerait aussi bien avec bash, zsh, tcsh...
Et pourquoi pas aussi en shell POSIX.

rixed <rixed@happyleptic.org> writes:

> Coucou la liste.
>
> Je suppose que c'est une FAQ, mais je n'ai pas réussit à mettre la main
> sur la FAQ du groupe.
>
> Donc, question :
>
> Sous zsh, on peut faire :
>
> $ toto="valeur de toto"
> $ titi=toto
> $ echo ${(P)titi}
> valeur de toto
> $ youpi
> command not found: youpi
>
> J'aimerai savoir s'il n'y a pas moyen de faire cela en shell portable.
> Genre quelquechose qui fonctionnerait aussi bien avec bash, zsh, tcsh...
> Et pourquoi pas aussi en shell POSIX.

Moi, ce que j'aimerai savoir, c'est pourquoi tu ne lis pas:
man bash
?


--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay

2006-02-27, 23:11(+00), rixed:
[...]
> Donc, question :
>
> Sous zsh, on peut faire :
>
> $ toto="valeur de toto"
> $ titi=toto
> $ echo ${(P)titi}
> valeur de toto
> $ youpi
> command not found: youpi
>
> J'aimerai savoir s'il n'y a pas moyen de faire cela en shell portable.

Et tu l'aimeras quand?

> Genre quelquechose qui fonctionnerait aussi bien avec bash, zsh, tcsh...
> Et pourquoi pas aussi en shell POSIX.
[...]

eval "star_titi=\$$titi"
printf '%s\n' "$star_titi"

(en shell portable, on n'utilise pas echo).

Note que ca ne fait pas de sens d'ecrire du code qui marche a la
fois en shell bourne-like et en csh-like, ce sont deux familles
completement incompatibles.

--
Stéphane

On 2006-02-28, Pascal Bourguignon <usenet@informatimago.com> wrote:
> Moi, ce que j'aimerai savoir, c'est pourquoi tu ne lis pas:
> man bash
> ?

Qu'est-ce qui te fait croire que je ne l'ai pas lu ?

On 2006-02-28, Stephane Chazelas <cette.adresse@est.invalid> wrote:
> Et tu l'aimeras quand?

Qui donc ?

>> Genre quelquechose qui fonctionnerait aussi bien avec bash, zsh, tcsh...
>> Et pourquoi pas aussi en shell POSIX.
> [...]
>
> eval "star_titi=\$$titi"

Bon sang mais c'est bien sur !
Merci beaucoup !

> (en shell portable, on n'utilise pas echo).

man echo m'informe que :

STANDARDS
The echo utility conforms to IEEE Std 1003.1-2001 (``POSIX.1'') as
amended by Cor. 1-2002.

C'est l'amendement qui pose problème ?

Quoi qu'il en soit, la portabilité est une grandeur analogique.
Echo est largement assez portable pour mon besoin.

> Note que ca ne fait pas de sens d'ecrire du code qui marche a la
> fois en shell bourne-like et en csh-like, ce sont deux familles
> completement incompatibles.

OK.

On 28 Feb 2006 10:11:44 GMT, ccellier@evistel.com wrote:
[...]
>> (en shell portable, on n'utilise pas echo).
>
> man echo m'informe que :
>
> STANDARDS
> The echo utility conforms to IEEE Std 1003.1-2001 (``POSIX.1'') as
> amended by Cor. 1-2002.

Et un autre echo te dira autre chose. POSIX et Unix en
particulier ont des divergences. POSIX est suffisemment vague
pour permettre n'importe quoi.

echo -n
echo '\\'

En particulier, selon Unix (SUSv3, XSI extension) doit afficher
"-n" et "\". D'apres POSIX, le premier est "unspecified" et le
deuxieme peut afficher "\" ou "\\".

Dans tous les cas, echo ne doit pas etre utilisé pour afficher
des choses "variables".

En particulier GNU echo et le echo de bash ne sont pas POSIX
(encore moins Unix).

[...]
> Quoi qu'il en soit, la portabilité est une grandeur analogique.
> Echo est largement assez portable pour mon besoin.

C'est surtout qu'il n'est pas fiable et qu'il est deprecated.

POSIX recommande de ne pas l'utiliser:

SUSv3> It is not possible to use echo portably across all POSIX
SUSv3> systems unless both -n (as the first argument) and escape
SUSv3> sequences are omitted.

donc, pas pour des donnees variables (a moins qu'il y ait une
contrainte qui impose qu'elles ne contiennent pas de backslash
et qui interdit "-n").

SUSv3> [...]
SUSv3> New applications are encouraged to use printf instead of
SUSv3> echo.
SUSv3> [...]
SUSv3> The echo utility has not been made obsolescent because of
SUSv3> its extremely widespread use in historical applications.
SUSv3> Conforming applications that wish to do prompting without
SUSv3> <newline>s or that could possibly be expecting to echo a
SUSv3> -n, should use the printf utility derived from the Ninth
SUSv3> Edition system.

--
Stephane

Pascal Bourguignon wrote in message
<877j7g6o3p.fsf@thalassa.informatimago.com>:
> Moi, ce que j'aimerai savoir, c'est pourquoi tu ne lis pas:
> man bash
> ?

Parce que quitte à utiliser des fonctionnalités non-standard de shells,
autant utiliser celles de zsh, qui sont plus intéressantes.

OK, merci de ces précisions.

J'essaierai de prendre l'habitude d'utiliser printf (qui existe aussi,
sans doute, sous de nombreuses variantes qui permettent des choses plus
ou moins standard j'imagine...)

On 28 Feb 2006 12:11:35 GMT, ccellier@evistel.com wrote:
> OK, merci de ces précisions.
>
> J'essaierai de prendre l'habitude d'utiliser printf (qui existe aussi,
> sans doute, sous de nombreuses variantes qui permettent des choses plus
> ou moins standard j'imagine...)
[...]

Il y a aussi des problemes.

Mais:

printf '%s\n' "$var"

et:

printf %s "$var"

feront toujours ce qu'ils sont censés faire (contrairement a
echo "$var" et echo -n "$var").

Il y a des zones pas clair dans la specification, des zones
/unspecified/. Mais a l'aide de la specification, on peut
ecrire du code portable.

Il y a des bugs de conformance dans certaines implementations
mais ca se situe plus au niveau de: printf '\351' vs '\0351', des
multibyte characters avec %<n>s, de la localisation des nombres,
du "--", de printf '%d\n' "'A"... et ces bugs sont en general
fixés au fur et a mesure qu'ils sont decouverts, ce n'est pas
comme pour echo ou il y a deux (voire plus) familles distinctes
et incompatibles et pour certaines implementations, aucun moyen
d'afficher le contenu d'une variable tel quel (typiquement,
avec les echo Unix, pas moyen).

--
Stephane

Stephane Chazelas <cette.adresse@est.invalid> writes:
> Note que ca ne fait pas de sens d'ecrire du code qui marche a la
> fois en shell bourne-like et en csh-like, ce sont deux familles
> completement incompatibles.

Pas tant que ça:

------(happy.source)----------------------------------------------------
cat /*dev/null; echo "Happy New Year"\!
cat <<c*/ /*dev/null | cat > /dev/null
c */ () {} /*
c */ main() { cat(); printf("Happy New Year!\n"); } /*
17 format('Happy New Year!')
write (6,17)
stop
end
c*/
------(Makefile)--------------------------------------------------------
all: happy-c happy-f happy-sh happy-csh

happy-c:happy.source Makefile
@ cp happy.source happy-c.c
@ gcc -o happy-c happy-c.c
@ echo -n '(C) '
@ ./happy-c || true

happy-f:happy.source Makefile
@ cp happy.source happy-f.f
@ f77 -o happy-f happy-f.f 2> /dev/null
@ echo -n '(FORTRAN) '
@ ./happy-f

happy-sh:happy.source Makefile
@ cp happy.source happy-sh
@ echo -n '(Bourne Shell) '
@ chmod 755 happy-sh
@ sh ./happy-sh

happy-csh:happy.source Makefile
@ cp happy.source happy-csh
@ chmod 755 happy-csh
@ echo -n '(C Shell) '
@ csh ./happy-csh

clean:
-rm -f *.o *~ happy-csh happy-sh happy-f happy-f.f happy-c happy-c.c
------------------------------------------------------------------------

--
__Pascal Bourguignon__ http://www.informatimago.com/

"Specifications are for the weak and timid!"

ccellier@evistel.com writes:

> On 2006-02-28, Pascal Bourguignon <usenet@informatimago.com> wrote:
>> Moi, ce que j'aimerai savoir, c'est pourquoi tu ne lis pas:
>> man bash
>> ?
>
> Qu'est-ce qui te fait croire que je ne l'ai pas lu ?

Tu aurais trouvé tout seul eval et ${!toto}.


--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush

On Tue, 28 Feb 2006 18:14:12 +0100, Pascal Bourguignon wrote:
> Stephane Chazelas <cette.adresse@est.invalid> writes:
>> Note que ca ne fait pas de sens d'ecrire du code qui marche a la
>> fois en shell bourne-like et en csh-like, ce sont deux familles
>> completement incompatibles.
>
> Pas tant que ça:
>
> ------(happy.source)----------------------------------------------------
> cat /*dev/null; echo "Happy New Year"\!
> cat <<c*/ /*dev/null | cat > /dev/null
[...]

Ou http://stchaz.free.fr/which_interpreter

--
Stephane

On 2006-02-28, Pascal Bourguignon <usenet@informatimago.com> wrote:
> ccellier@evistel.com writes:
>>> man bash
>>
>> Qu'est-ce qui te fait croire que je ne l'ai pas lu ?
>
> Tu aurais trouvé tout seul eval et ${!toto}.

${!toto}, d'une part j'ai été trop bète pour le faire marcher
(je backslashais le !, trop habitué à zsh), et d'autre part ca
ne m'allait pas, car en fait dans mon cas la variable 'toto' ne
contient que la partie variable du nom d'une autre variable
(c'est DEFFILE_MIME ou DEFFILE_NODE, toto valant "MIME" ou "NODE").

Mais eval fonctionne parfaitement. Je ne l'ai pas vu dans la page
de manuel car il n'y est pas fait référence dans le chapitre sur
les parameters expansions (amis francophones bonsoir).

rixed <rixed@happyleptic.org> writes:

> On 2006-02-28, Pascal Bourguignon <usenet@informatimago.com> wrote:
>> ccellier@evistel.com writes:
>>>> man bash
>>>
>>> Qu'est-ce qui te fait croire que je ne l'ai pas lu ?
>>
>> Tu aurais trouvé tout seul eval et ${!toto}.
>
> ${!toto}, d'une part j'ai été trop bète pour le faire marcher
> (je backslashais le !, trop habitué à zsh), et d'autre part ca
> ne m'allait pas, car en fait dans mon cas la variable 'toto' ne
> contient que la partie variable du nom d'une autre variable
> (c'est DEFFILE_MIME ou DEFFILE_NODE, toto valant "MIME" ou "NODE").

for toto in MIME NODE ; do
titi=DEFFILE_$toto
echo ${!titi}
done

> Mais eval fonctionne parfaitement. Je ne l'ai pas vu dans la page
> de manuel car il n'y est pas fait référence dans le chapitre sur
> les parameters expansions (amis francophones bonsoir).


--
__Pascal Bourguignon__ http://www.informatimago.com/

2006-03-01, 00:46(+01), Pascal Bourguignon:
> rixed <rixed@happyleptic.org> writes:
>
>> On 2006-02-28, Pascal Bourguignon <usenet@informatimago.com> wrote:
>>> ccellier@evistel.com writes:
>>>>> man bash
>>>>
>>>> Qu'est-ce qui te fait croire que je ne l'ai pas lu ?
>>>
>>> Tu aurais trouvé tout seul eval et ${!toto}.
>>
>> ${!toto}, d'une part j'ai été trop bète pour le faire marcher
>> (je backslashais le !, trop habitué à zsh), et d'autre part ca
>> ne m'allait pas, car en fait dans mon cas la variable 'toto' ne
>> contient que la partie variable du nom d'une autre variable
>> (c'est DEFFILE_MIME ou DEFFILE_NODE, toto valant "MIME" ou "NODE").
>
> for toto in MIME NODE ; do
> titi=DEFFILE_$toto
> echo ${!titi}
> done
[...]

Note l'objet de l'enfilade. (le subject du thread)

${!...} n'est pas standard. C'est ksh93/bash specific, ca ne
marche meme pas pareil dans ces deux shells (pour les arrays par
exemple).

--
Stéphane

Stephane Chazelas <cette.adresse@est.invalid> writes:

> 2006-03-01, 00:46(+01), Pascal Bourguignon:
>> rixed <rixed@happyleptic.org> writes:
>>
>>> On 2006-02-28, Pascal Bourguignon <usenet@informatimago.com> wrote:
>>>> ccellier@evistel.com writes:
>>>>>> man bash
>>>>>
>>>>> Qu'est-ce qui te fait croire que je ne l'ai pas lu ?
>>>>
>>>> Tu aurais trouvé tout seul eval et ${!toto}.
>>>
>>> ${!toto}, d'une part j'ai été trop bète pour le faire marcher
>>> (je backslashais le !, trop habitué à zsh), et d'autre part ca
>>> ne m'allait pas, car en fait dans mon cas la variable 'toto' ne
>>> contient que la partie variable du nom d'une autre variable
>>> (c'est DEFFILE_MIME ou DEFFILE_NODE, toto valant "MIME" ou "NODE").
>>
>> for toto in MIME NODE ; do
>> titi=DEFFILE_$toto
>> echo ${!titi}
>> done
> [...]
>
> Note l'objet de l'enfilade. (le subject du thread)
>
> ${!...} n'est pas standard. C'est ksh93/bash specific, ca ne
> marche meme pas pareil dans ces deux shells (pour les arrays par
> exemple).

Non, ce n'est pas standard. Mais ce n'est pas grave:

indirection () {
var="$1"
case "$SHELL" in
*/bash) value="${!var}" ; printf "%s" ${!value} ;;
...) ... ;;
*) printf "Désolé, je ne connais pas ce shell %s\n" "$SHELL" ; exit 1 ;;
esac
}

titi=abc
toto=titi
printf "toto^ = %s\n" $(indirection toto)




Bien sur, si on a beaucoup de choses qui dépendent du shell on factorisera:

case "$SHELL" in
*/bash)
indirection () {
var="$1" ; value="${!var}" ; printf "%s" ${!value}
}
truc () {
...
}
machin () {
...
}
;;
....)
indirection () {
...
}
truc () {
...
}
machin () {
...
}
;;
)
printf "Désolé, je ne connais pas ce shell %s\n" "$SHELL"
exit 1
;;
esac


Ainsi, on profite des primitives optimisées de chaque shell, au lieu
d'écrire un code générique, alambiqué, et qui fonctionne mal partout.

--
__Pascal Bourguignon__ http://www.informatimago.com/

"You can tell the Lisp programmers. They have pockets full of punch
cards with close parentheses on them." --> http://tinyurl.com/8ubpf

On Wed, 01 Mar 2006 10:36:27 +0100, Pascal Bourguignon wrote:
[...]
>> ${!...} n'est pas standard. C'est ksh93/bash specific, ca ne
>> marche meme pas pareil dans ces deux shells (pour les arrays par
>> exemple).
>
> Non, ce n'est pas standard. Mais ce n'est pas grave:
>
> indirection () {
> var="$1"
> case "$SHELL" in
> */bash) value="${!var}" ; printf "%s" ${!value} ;;
> ...) ... ;;
> *) printf "Désolé, je ne connais pas ce shell %s\n" "$SHELL" ; exit 1 ;;
> esac
> }
[...]

En quoi verifier $SHELL aide-t-il $SHELL contient le shell
interactif de preference de l'utilisateur (par defaut, son shell
de login), ca n'a rien a voir avec le shell courant (qui
interprete le code courant).

--
Stephane

Stephane Chazelas <stephane_chazelas@yahoo.fr> writes:

> On Wed, 01 Mar 2006 10:36:27 +0100, Pascal Bourguignon wrote:
> [...]
>>> ${!...} n'est pas standard. C'est ksh93/bash specific, ca ne
>>> marche meme pas pareil dans ces deux shells (pour les arrays par
>>> exemple).
>>
>> Non, ce n'est pas standard. Mais ce n'est pas grave:
>>
>> indirection () {
>> var="$1"
>> case "$SHELL" in
>> */bash) value="${!var}" ; printf "%s" ${!value} ;;
>> ...) ... ;;
>> *) printf "Désolé, je ne connais pas ce shell %s\n" "$SHELL" ; exit 1 ;;
>> esac
>> }
> [...]
>
> En quoi verifier $SHELL aide-t-il $SHELL contient le shell
> interactif de preference de l'utilisateur (par defaut, son shell
> de login), ca n'a rien a voir avec le shell courant (qui
> interprete le code courant).

Ah. Dans ce cas, il faudrait effectivement tester autre chose. Il
semble que dans le cas de bash, on pourrait peut être tester:

if [ -n "${BASH}" ] ; then
do bash stuff
fi


--
__Pascal Bourguignon__ http://www.informatimago.com/

CONSUMER NOTICE: Because of the "uncertainty principle," it is
impossible for the consumer to simultaneously know both the precise
location and velocity of this product.

On Wed, 01 Mar 2006 12:05:52 +0100, Pascal Bourguignon wrote:
[...]
> Ah. Dans ce cas, il faudrait effectivement tester autre chose. Il
> semble que dans le cas de bash, on pourrait peut être tester:
>
> if [ -n "${BASH}" ] ; then
> do bash stuff
> fi
[...]

[ -n "$BASH_VERSION" ]

mais je ne vois pas trop l'interet.

Suffit de mettre un

#! /usr/bin/env bash

en haut du script si on veut utiliser des features specific a
bash.

Par contre, en suite, il faudra sans doute ajouter un:

case $BASH_VERSION in
1.*|2.0.[0-2]*)
echo "you need this or that version" >&2
exit 1;;
[3-9]*|[1-9][0-9]*)
echo "warning: it is not guaranteed to work with that shell.
This script has not been tested with that shell and we use
non-standard features that tend to work differently with
different versions" >&2;;
esac

--
Stephane

Stephane Chazelas <stephane_chazelas@yahoo.fr> writes:

> On Wed, 01 Mar 2006 12:05:52 +0100, Pascal Bourguignon wrote:
> [...]
>> Ah. Dans ce cas, il faudrait effectivement tester autre chose. Il
>> semble que dans le cas de bash, on pourrait peut être tester:
>>
>> if [ -n "${BASH}" ] ; then
>> do bash stuff
>> fi
> [...]
>
> [ -n "$BASH_VERSION" ]
>
> mais je ne vois pas trop l'interet.
>
> Suffit de mettre un
>
> #! /usr/bin/env bash
>
> en haut du script si on veut utiliser des features specific a
> bash.

Je suis bien d'accord.
Je trouve bien plus facile de commencer un script par:


wget ftp://ftp.gnu.org/gnu/bash/bash-2.05.tar.bz2
tar jxf bash-2.05.tar.bz2
cd bash-2.05
../configure
make
make install
bash script.bash

que de s'embêter à faire des scripts "portables"...


--
__Pascal Bourguignon__ http://www.informatimago.com/

Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.

Pascal Bourguignon wrote:
> Stephane Chazelas <stephane_chazelas@yahoo.fr> writes:
>
>> On Wed, 01 Mar 2006 12:05:52 +0100, Pascal Bourguignon wrote:
>> [...]
>>> Ah. Dans ce cas, il faudrait effectivement tester autre chose. Il
>>> semble que dans le cas de bash, on pourrait peut être tester:
>>>
>>> if [ -n "${BASH}" ] ; then
>>> do bash stuff
>>> fi
>> [...]
>>
>> [ -n "$BASH_VERSION" ]
>>
>> mais je ne vois pas trop l'interet.
>>
>> Suffit de mettre un
>>
>> #! /usr/bin/env bash
>>
>> en haut du script si on veut utiliser des features specific a
>> bash.
>
> Je suis bien d'accord.
> Je trouve bien plus facile de commencer un script par:
>
>
> wget ftp://ftp.gnu.org/gnu/bash/bash-2.05.tar.bz2
> tar jxf bash-2.05.tar.bz2
> cd bash-2.05
> ../configure
> make
> make install
> bash script.bash
>
> que de s'embêter à faire des scripts "portables"...
>
>

"tar jxf" n'est pas portable ...

Jean-Louis Liagre <jlliagre@localhost.fr> writes:
>>> #! /usr/bin/env bash
>>>
>>> en haut du script si on veut utiliser des features specific a
>>> bash.
>> Je suis bien d'accord.
>> Je trouve bien plus facile de commencer un script par:
>> wget ftp://ftp.gnu.org/gnu/bash/bash-2.05.tar.bz2
>> tar jxf bash-2.05.tar.bz2
>> cd bash-2.05
>> ./configure
>> make
>> make install
>> bash script.bash
>> que de s'embêter à faire des scripts "portables"...
>>
>
> "tar jxf" n'est pas portable ...

Bien sur que si:

wget ftp://ftp.gnu.org/gnu/tar/tar-1.15.tar.gz
gzip -d < tar-1.15.tar.gz | tar -xf -
cd tar-1.15
../configure
make
make install

et après, on peut utiliser tar zxf ou tar jxf comme on veut. (On peut
avoir à installer bzip2 et gzip avant si ce n'est pas déjà fait).
Voir Fink sur MacOSX, ports sur *BSD, etc...

--
__Pascal Bourguignon__ http://www.informatimago.com/

"You can tell the Lisp programmers. They have pockets full of punch
cards with close parentheses on them." --> http://tinyurl.com/8ubpf

Pascal Bourguignon wrote:
> Jean-Louis Liagre <jlliagre@localhost.fr> writes:
>>>> #! /usr/bin/env bash
>>>>
>>>> en haut du script si on veut utiliser des features specific a
>>>> bash.
>>> Je suis bien d'accord.
>>> Je trouve bien plus facile de commencer un script par:
>>> wget ftp://ftp.gnu.org/gnu/bash/bash-2.05.tar.bz2
>>> tar jxf bash-2.05.tar.bz2
>>> cd bash-2.05
>>> ./configure
>>> make
>>> make install
>>> bash script.bash
>>> que de s'embêter à faire des scripts "portables"...
>>>
>> "tar jxf" n'est pas portable ...
>
> Bien sur que si:

gnu tar est bien sûr portable, l'option j est une extension non POSIX absente de
la plupart des autres implémentations de tar (mais présente dans star).

> wget ftp://ftp.gnu.org/gnu/tar/tar-1.15.tar.gz
> gzip -d < tar-1.15.tar.gz | tar -xf -
> cd tar-1.15
> ../configure
> make
> make install

make install peut échouer si /usr/local est en read-only.
>
> et après, on peut utiliser tar zxf ou tar jxf comme on veut.

Seulement en mettant son chemin complet ou si on a /usr/local/bin en premier
dans son PATH.