Je souhaite intégrer dans un script d'installation (install.sh) une
méthode le plus portable possible pour transformer des fichiers *.ini du
format 'DOS' (CR/LF) au format 'Unix' (LF). Pour le moment, j'utilise le
bout de script suivant qui fonctionne très bien sous Linux :
Cela ne fonctionne pas sous AIX 4.3 car le 'joker' {} n'est pas
substitué dans ce cas là. Je recherche donc un moyen hyper portable pour
effectuer cette bête transformation, sans utiliser perl, avec les moyens
posix du bord (find, sed, sh)
Auriez vous une idée ?
Merci
--
Stéphane Gibier <stephane@gibier.org>
Le maniement réitéré des fonds multiplie les mouvements de caisse
Yr znavrzrag eévgéeé qrf pbaf zhygvcyvr yrf zbhirzragf qr srffr
Donc: 1 fork pour le find n forks pour les sh n forks pour les cp n forks pour les tr ---- 1+3n forks
Mais certains shells ne forkent pas pour la dernière commande. C'est au moins le cas de ksh93, (bash et zsh aussi, mais apparemment pas dans ce cas particulier du cmd && cmd) tr est executé dans le meme processus que sh, il y a un "exec tr" implicit, si tu veux.
Donc: 1 fork pour le find
n forks pour les sh
n forks pour les cp
n forks pour les tr
----
1+3n forks
Mais certains shells ne forkent pas pour la dernière commande.
C'est au moins le cas de ksh93, (bash et zsh aussi, mais
apparemment pas dans ce cas particulier du cmd && cmd) tr est
executé dans le meme processus que sh, il y a un "exec tr"
implicit, si tu veux.
Donc: 1 fork pour le find n forks pour les sh n forks pour les cp n forks pour les tr ---- 1+3n forks
Mais certains shells ne forkent pas pour la dernière commande. C'est au moins le cas de ksh93, (bash et zsh aussi, mais apparemment pas dans ce cas particulier du cmd && cmd) tr est executé dans le meme processus que sh, il y a un "exec tr" implicit, si tu veux.
Le 08 Oct 2003 01:10:22 +0200, Pascal Bourguignon écrivait : [...]
| awk ' { if (NR > 1) { printf("%s", line) if ($0 !~ //.//) printf("") print "" } line = $0 } END { print line }' | [...]
Oulala! Mais il y a des sacrés différences avec les awk, gawk, nawk... Je me demande si c'est pas pire que les sh A B ou sh A A...
Oui, mais là, ya rien que meme le premier awk ne reconnaisse pas. Par contre, certains awk ont des limitations assez basses. Ça pourrait ne pas marcher sous HPUX par exemple avec des noms de fichiers qui contiennent plus de 100 (?) espaces (enfin fields).
il reste toujours encore la solution du:
a='file=$f; continue' find ./. ... | sed 's//&&/g' | while IFS= read f; do eval "$a"; a case "$f" in */./*) cp ... && tr ...; file=$f;; *) file="$file $f";; esac done ${a:+":"} eval 'cp ... && tr ...'
(pas testé, ça devrait faire du 2,3 + 2n et pas trop de commandes lancées).
L'idée d'utiliser find ./. a été piquée dans une page de man d'xargs d'outils qui viennent juste de sortir basés sur les sources d'Unix libérées par Caldera (http://heirloom.berlios.de).
-- Stéphane
Le 08 Oct 2003 01:10:22 +0200, Pascal Bourguignon <spam@thalassa.informatimago.com> écrivait :
[...]
| awk '
{
if (NR > 1) {
printf("%s", line)
if ($0 !~ //\.\//)
printf("\")
print ""
}
line = $0
}
END {
print line
}' |
[...]
Oulala! Mais il y a des sacrés différences avec les awk, gawk, nawk...
Je me demande si c'est pas pire que les sh A B ou sh A A...
Oui, mais là, ya rien que meme le premier awk ne reconnaisse
pas. Par contre, certains awk ont des limitations assez basses.
Ça pourrait ne pas marcher sous HPUX par exemple avec des noms
de fichiers qui contiennent plus de 100 (?) espaces (enfin
fields).
il reste toujours encore la solution du:
a='file=$f; continue'
find ./. ... | sed 's/\/&&/g' | while IFS= read f; do
eval "$a"; a case "$f" in
*/./*) cp ... && tr ...; file=$f;;
*) file="$file
$f";;
esac
done
${a:+":"} eval 'cp ... && tr ...'
(pas testé, ça devrait faire du 2,3 + 2n et pas trop de
commandes lancées).
L'idée d'utiliser find ./. a été piquée dans une page de man
d'xargs d'outils qui viennent juste de sortir basés sur les
sources d'Unix libérées par Caldera
(http://heirloom.berlios.de).
Le 08 Oct 2003 01:10:22 +0200, Pascal Bourguignon écrivait : [...]
| awk ' { if (NR > 1) { printf("%s", line) if ($0 !~ //.//) printf("") print "" } line = $0 } END { print line }' | [...]
Oulala! Mais il y a des sacrés différences avec les awk, gawk, nawk... Je me demande si c'est pas pire que les sh A B ou sh A A...
Oui, mais là, ya rien que meme le premier awk ne reconnaisse pas. Par contre, certains awk ont des limitations assez basses. Ça pourrait ne pas marcher sous HPUX par exemple avec des noms de fichiers qui contiennent plus de 100 (?) espaces (enfin fields).
il reste toujours encore la solution du:
a='file=$f; continue' find ./. ... | sed 's//&&/g' | while IFS= read f; do eval "$a"; a case "$f" in */./*) cp ... && tr ...; file=$f;; *) file="$file $f";; esac done ${a:+":"} eval 'cp ... && tr ...'
(pas testé, ça devrait faire du 2,3 + 2n et pas trop de commandes lancées).
L'idée d'utiliser find ./. a été piquée dans une page de man d'xargs d'outils qui viennent juste de sortir basés sur les sources d'Unix libérées par Caldera (http://heirloom.berlios.de).
-- Stéphane
Pascal Bourguignon
Stephane CHAZELAS writes:
Le 08 Oct 2003 04:52:15 +0200, Pascal Bourguignon écrivait : [...]
Donc: 1 fork pour le find n forks pour les sh n forks pour les cp n forks pour les tr ---- 1+3n forks
Mais certains shells ne forkent pas pour la dernière commande. C'est au moins le cas de ksh93, (bash et zsh aussi, mais apparemment pas dans ce cas particulier du cmd && cmd) tr est executé dans le meme processus que sh, il y a un "exec tr" implicit, si tu veux.
Donc: 1 fork pour le find
n forks pour les sh
n forks pour les cp
n forks pour les tr
----
1+3n forks
Mais certains shells ne forkent pas pour la dernière commande.
C'est au moins le cas de ksh93, (bash et zsh aussi, mais
apparemment pas dans ce cas particulier du cmd && cmd) tr est
executé dans le meme processus que sh, il y a un "exec tr"
implicit, si tu veux.
Donc: 1 fork pour le find n forks pour les sh n forks pour les cp n forks pour les tr ---- 1+3n forks
Mais certains shells ne forkent pas pour la dernière commande. C'est au moins le cas de ksh93, (bash et zsh aussi, mais apparemment pas dans ce cas particulier du cmd && cmd) tr est executé dans le meme processus que sh, il y a un "exec tr" implicit, si tu veux.
