Existe-t-il une instruction qui permettrait de modifier la date de
création d'un fichier ?
Ce n'est pas précisément le sujet mais à tout hasard j'explique pour
quoi c'est faire : j'ai enregistré des mails dans un dossiers et pour
des raisons que je ne tiens pas à connaître (soyons modestes) cela
marche mais pas d'une façon très habituelle. Les noms de fichiers sont
plutôt bizarre (franchement long), et les dates de création sont
devenues la date du jour de la copie (ce qui ne m'arrange pas pour les
opérations de tri par exemple).
le 08/05/2013 à 23:39, lionmarron a écrit dans le message <kmegmb$i28$ :
Python est un langage typiquement mauvais à mon avis, sauf si on l'utilise sans appeler de mode graphique ce qui aurait été le cas ici (peut-être à la façon dont on utilise Perl, enfin je peux me tromper), mais c'est le seul langage actuel que j'ai "raisonnablement un peu" utilisé.
Perl peut très bien faire des interfaces graphiques au même titre que Python.
Sinon mon intention serait d'apprendre C (ou peut-être C++), et avant de le faire je pensais qu'il valait mieux commencer par un shell, ou par bash disons. (Je modifie pas mon programme donc.)
Connaître le shell n'apporte pas grand chose à l'apprentissage du C. En revanche, c'est un très bon allier dans la vie de tout les jours.
Si tu veux apprendre le C et que tu débutes en programmation, tu as plutôt intérêt à être très motivé sinon tu risques de te décourager rapidement. Mais ça se fait et je pense c'est plutôt une bonne chose pour aborder d'autres langages par la suite.
-- Benoit Izac
Bonjour,
le 08/05/2013 à 23:39, lionmarron a écrit dans le message
<kmegmb$i28$1@shakotay.alphanet.ch> :
Python est un langage typiquement mauvais à mon avis, sauf si on
l'utilise sans appeler de mode graphique ce qui aurait été le cas ici
(peut-être à la façon dont on utilise Perl, enfin je peux me tromper),
mais c'est le seul langage actuel que j'ai "raisonnablement un peu"
utilisé.
Perl peut très bien faire des interfaces graphiques au même titre que
Python.
Sinon mon intention serait d'apprendre C (ou peut-être C++), et avant
de le faire je pensais qu'il valait mieux commencer par un shell, ou
par bash disons. (Je modifie pas mon programme donc.)
Connaître le shell n'apporte pas grand chose à l'apprentissage du C. En
revanche, c'est un très bon allier dans la vie de tout les jours.
Si tu veux apprendre le C et que tu débutes en programmation, tu as
plutôt intérêt à être très motivé sinon tu risques de te décourager
rapidement. Mais ça se fait et je pense c'est plutôt une bonne chose
pour aborder d'autres langages par la suite.
le 08/05/2013 à 23:39, lionmarron a écrit dans le message <kmegmb$i28$ :
Python est un langage typiquement mauvais à mon avis, sauf si on l'utilise sans appeler de mode graphique ce qui aurait été le cas ici (peut-être à la façon dont on utilise Perl, enfin je peux me tromper), mais c'est le seul langage actuel que j'ai "raisonnablement un peu" utilisé.
Perl peut très bien faire des interfaces graphiques au même titre que Python.
Sinon mon intention serait d'apprendre C (ou peut-être C++), et avant de le faire je pensais qu'il valait mieux commencer par un shell, ou par bash disons. (Je modifie pas mon programme donc.)
Connaître le shell n'apporte pas grand chose à l'apprentissage du C. En revanche, c'est un très bon allier dans la vie de tout les jours.
Si tu veux apprendre le C et que tu débutes en programmation, tu as plutôt intérêt à être très motivé sinon tu risques de te décourager rapidement. Mais ça se fait et je pense c'est plutôt une bonne chose pour aborder d'autres langages par la suite.
-- Benoit Izac
Benoit Izac
Bonjour,
le 09/05/2013 à 01:05, Francois Lafont a écrit dans le message <518ada1c$0$2234$ :
Si tu veux apprendre le C et que tu débutes en programmation, tu as plutôt intérêt à être très motivé sinon tu risques de te décourager rapidement. Mais ça se fait et je pense c'est plutôt une bonne chose pour aborder d'autres langages par la suite.
Je ne sais pas si c'est une bonne chose d'apprendre le C (sûrement que oui car en informatique plus on en sait mieux c'est) mais en tout cas je confirme que c'est vraiment difficile. Perso, j'avais tenté puis abandonné après quelques semaines. On peut voir sur les forums des experts qui arrivent quand même à se prendre le chou sur des pages et des pages de messages à grand coup de citations de ladite norme pour juste arriver à savoir si telle ou telle ligne respecte la norme machin-truc ou bien si c'est un "undefined behaviour" potentiel etc. etc.
C'est la même chose dans n'importe quel langage, qu'il soit informatique ou humain.
Pour quelqu'un qui a à c½ur de faire du code portable, le C donne l'impression d'être un puits sans fond. Bon, c'est juste une impression perso vu de loin.
Faire du shell portable est tout autant compliqué.
Avec un shell par exemple, c'est plus facile et en plus on arrive plus rapidement à faire de choses qui nous sert vraiment. Alors qu'en C, avant d'arriver à faire des choses qui nous servent vraiment, il me semble qu'il faut un peu de temps.
L'usage n'est pas le même. Le shell sert à lancer des programmes existants sur le système, le C permet de créer ces programmes ; certains argueront que l'on peut lancer des programmes en C ou créer des programmes en shell, c'est vrai mais ce n'est pas le principal usage. Le shell, c'est pour la vie de tous les jours, le C pour des programmes à plus long terme.
-- Benoit Izac
Bonjour,
le 09/05/2013 à 01:05, Francois Lafont a écrit dans le message
<518ada1c$0$2234$426a34cc@news.free.fr> :
Si tu veux apprendre le C et que tu débutes en programmation, tu as
plutôt intérêt à être très motivé sinon tu risques de te décourager
rapidement. Mais ça se fait et je pense c'est plutôt une bonne chose
pour aborder d'autres langages par la suite.
Je ne sais pas si c'est une bonne chose d'apprendre le C (sûrement que
oui car en informatique plus on en sait mieux c'est) mais en tout cas
je confirme que c'est vraiment difficile. Perso, j'avais tenté puis
abandonné après quelques semaines. On peut voir sur les forums des
experts qui arrivent quand même à se prendre le chou sur des pages et
des pages de messages à grand coup de citations de ladite norme pour
juste arriver à savoir si telle ou telle ligne respecte la norme
machin-truc ou bien si c'est un "undefined behaviour" potentiel etc.
etc.
C'est la même chose dans n'importe quel langage, qu'il soit informatique
ou humain.
Pour quelqu'un qui a à c½ur de faire du code portable, le C donne
l'impression d'être un puits sans fond. Bon, c'est juste une
impression perso vu de loin.
Faire du shell portable est tout autant compliqué.
Avec un shell par exemple, c'est plus facile et en plus on arrive plus
rapidement à faire de choses qui nous sert vraiment. Alors qu'en C,
avant d'arriver à faire des choses qui nous servent vraiment, il me
semble qu'il faut un peu de temps.
L'usage n'est pas le même. Le shell sert à lancer des programmes
existants sur le système, le C permet de créer ces programmes ; certains
argueront que l'on peut lancer des programmes en C ou créer des
programmes en shell, c'est vrai mais ce n'est pas le principal usage. Le
shell, c'est pour la vie de tous les jours, le C pour des programmes
à plus long terme.
le 09/05/2013 à 01:05, Francois Lafont a écrit dans le message <518ada1c$0$2234$ :
Si tu veux apprendre le C et que tu débutes en programmation, tu as plutôt intérêt à être très motivé sinon tu risques de te décourager rapidement. Mais ça se fait et je pense c'est plutôt une bonne chose pour aborder d'autres langages par la suite.
Je ne sais pas si c'est une bonne chose d'apprendre le C (sûrement que oui car en informatique plus on en sait mieux c'est) mais en tout cas je confirme que c'est vraiment difficile. Perso, j'avais tenté puis abandonné après quelques semaines. On peut voir sur les forums des experts qui arrivent quand même à se prendre le chou sur des pages et des pages de messages à grand coup de citations de ladite norme pour juste arriver à savoir si telle ou telle ligne respecte la norme machin-truc ou bien si c'est un "undefined behaviour" potentiel etc. etc.
C'est la même chose dans n'importe quel langage, qu'il soit informatique ou humain.
Pour quelqu'un qui a à c½ur de faire du code portable, le C donne l'impression d'être un puits sans fond. Bon, c'est juste une impression perso vu de loin.
Faire du shell portable est tout autant compliqué.
Avec un shell par exemple, c'est plus facile et en plus on arrive plus rapidement à faire de choses qui nous sert vraiment. Alors qu'en C, avant d'arriver à faire des choses qui nous servent vraiment, il me semble qu'il faut un peu de temps.
L'usage n'est pas le même. Le shell sert à lancer des programmes existants sur le système, le C permet de créer ces programmes ; certains argueront que l'on peut lancer des programmes en C ou créer des programmes en shell, c'est vrai mais ce n'est pas le principal usage. Le shell, c'est pour la vie de tous les jours, le C pour des programmes à plus long terme.
-- Benoit Izac
Tonton Th
On 2013-05-08, Benoit Izac wrote:
~$ d=$(grep '^Date: ' fichier.eml | cut -d' ' -f'2-') ~$ touch -d "$d" titi ~$ ls --full-time titi -rw-r--r-- 1 francois francois 0 2013-03-16 19:25:35.000000000 +0100 titi
Non ?
Non car si le mail contient un /^Date: / dans le corps du mail, ton ordinateur peut exploser. ;-)
Le Thu, 09 May 2013 09:43:38 +0200, Benoit Izac a écrit :
L'usage n'est pas le même. Le shell sert à lancer des programmes existants sur le système, le C permet de créer ces programmes ; certains argueront que l'on peut lancer des programmes en C ou créer des programmes en shell, c'est vrai mais ce n'est pas le principal usage. Le shell, c'est pour la vie de tous les jours, le C pour des programmes à plus long terme.
Pas toujours...
Tu peux m'expliquer pourquoi (sur ma machine, mais je suppose chez tout le monde) : /usr/bin/firefox est un lien symbolique vers /usr/lib/firefox/firefox.sh qui est bien sûr un script shell qui finit par lancer un binaire (/usr/ lib/firefox/firefox).
(idem pour d'autres logiciels...)
Le Thu, 09 May 2013 09:43:38 +0200, Benoit Izac a écrit :
L'usage n'est pas le même. Le shell sert à lancer des programmes
existants sur le système, le C permet de créer ces programmes ; certains
argueront que l'on peut lancer des programmes en C ou créer des
programmes en shell, c'est vrai mais ce n'est pas le principal usage. Le
shell, c'est pour la vie de tous les jours, le C pour des programmes à
plus long terme.
Pas toujours...
Tu peux m'expliquer pourquoi (sur ma machine, mais je suppose chez tout
le monde) :
/usr/bin/firefox est un lien symbolique vers /usr/lib/firefox/firefox.sh
qui est bien sûr un script shell qui finit par lancer un binaire (/usr/
lib/firefox/firefox).
Le Thu, 09 May 2013 09:43:38 +0200, Benoit Izac a écrit :
L'usage n'est pas le même. Le shell sert à lancer des programmes existants sur le système, le C permet de créer ces programmes ; certains argueront que l'on peut lancer des programmes en C ou créer des programmes en shell, c'est vrai mais ce n'est pas le principal usage. Le shell, c'est pour la vie de tous les jours, le C pour des programmes à plus long terme.
Pas toujours...
Tu peux m'expliquer pourquoi (sur ma machine, mais je suppose chez tout le monde) : /usr/bin/firefox est un lien symbolique vers /usr/lib/firefox/firefox.sh qui est bien sûr un script shell qui finit par lancer un binaire (/usr/ lib/firefox/firefox).
(idem pour d'autres logiciels...)
Nicolas George
Sergio , dans le message <518b8dc9$0$2299$, a écrit :
Pas toujours...
En quoi ce que tu écris contredit le message de Benoit ?
Tu peux m'expliquer pourquoi (sur ma machine, mais je suppose chez tout le monde) : /usr/bin/firefox est un lien symbolique vers /usr/lib/firefox/firefox.sh qui est bien sûr un script shell qui finit par lancer un binaire (/usr/ lib/firefox/firefox).
Qu'est-ce qui te chiffonne là-dedans ?
Sergio , dans le message <518b8dc9$0$2299$426a74cc@news.free.fr>, a
écrit :
Pas toujours...
En quoi ce que tu écris contredit le message de Benoit ?
Tu peux m'expliquer pourquoi (sur ma machine, mais je suppose chez tout
le monde) :
/usr/bin/firefox est un lien symbolique vers /usr/lib/firefox/firefox.sh
qui est bien sûr un script shell qui finit par lancer un binaire (/usr/
lib/firefox/firefox).
Sergio , dans le message <518b8dc9$0$2299$, a écrit :
Pas toujours...
En quoi ce que tu écris contredit le message de Benoit ?
Tu peux m'expliquer pourquoi (sur ma machine, mais je suppose chez tout le monde) : /usr/bin/firefox est un lien symbolique vers /usr/lib/firefox/firefox.sh qui est bien sûr un script shell qui finit par lancer un binaire (/usr/ lib/firefox/firefox).
Qu'est-ce qui te chiffonne là-dedans ?
Benoit Izac
Bonjour,
le 09/05/2013 à 13:51, Sergio a écrit dans le message <518b8dc9$0$2299$ :
L'usage n'est pas le même. Le shell sert à lancer des programmes existants sur le système, le C permet de créer ces programmes ; certains argueront que l'on peut lancer des programmes en C ou créer des programmes en shell, c'est vrai mais ce n'est pas le principal usage. Le shell, c'est pour la vie de tous les jours, le C pour des programmes à plus long terme.
Pas toujours...
Tu peux m'expliquer pourquoi (sur ma machine, mais je suppose chez tout le monde) : /usr/bin/firefox est un lien symbolique vers /usr/lib/firefox/firefox.sh qui est bien sûr un script shell qui finit par lancer un binaire (/usr/ lib/firefox/firefox).
Tu supposes mal, pas chez moi (Archlinux) : % file $(command -v firefox) /usr/bin/firefox: symbolic link to `/usr/lib/firefox/firefox' % file /usr/lib/firefox/firefox /usr/lib/firefox/firefox: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1] d0063bf90ac5ab434576b26aff1f5277794c82, stripped
(idem pour d'autres logiciels...)
Ce sont des lanceurs, je ne pense pas que firefox soit écrit en shell ;-) (C++ majoritairement).
Je viens de regarder sur une Ubuntu c'est effectivement une script shell : #!/bin/sh set -e # Firefox launcher containing a Profile migration helper for # temporary profiles used during alpha and beta phases. [...]
-- Benoit Izac
Bonjour,
le 09/05/2013 à 13:51, Sergio a écrit dans le message
<518b8dc9$0$2299$426a74cc@news.free.fr> :
L'usage n'est pas le même. Le shell sert à lancer des programmes
existants sur le système, le C permet de créer ces programmes ; certains
argueront que l'on peut lancer des programmes en C ou créer des
programmes en shell, c'est vrai mais ce n'est pas le principal usage. Le
shell, c'est pour la vie de tous les jours, le C pour des programmes à
plus long terme.
Pas toujours...
Tu peux m'expliquer pourquoi (sur ma machine, mais je suppose chez tout
le monde) :
/usr/bin/firefox est un lien symbolique vers /usr/lib/firefox/firefox.sh
qui est bien sûr un script shell qui finit par lancer un binaire (/usr/
lib/firefox/firefox).
Tu supposes mal, pas chez moi (Archlinux) :
% file $(command -v firefox)
/usr/bin/firefox: symbolic link to `/usr/lib/firefox/firefox'
% file /usr/lib/firefox/firefox
/usr/lib/firefox/firefox: ELF 64-bit LSB executable, x86-64, version
1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1] d0063bf90ac5ab434576b26aff1f5277794c82, stripped
(idem pour d'autres logiciels...)
Ce sont des lanceurs, je ne pense pas que firefox soit écrit en
shell ;-) (C++ majoritairement).
Je viens de regarder sur une Ubuntu c'est effectivement une script
shell :
#!/bin/sh
set -e
# Firefox launcher containing a Profile migration helper for
# temporary profiles used during alpha and beta phases.
[...]
le 09/05/2013 à 13:51, Sergio a écrit dans le message <518b8dc9$0$2299$ :
L'usage n'est pas le même. Le shell sert à lancer des programmes existants sur le système, le C permet de créer ces programmes ; certains argueront que l'on peut lancer des programmes en C ou créer des programmes en shell, c'est vrai mais ce n'est pas le principal usage. Le shell, c'est pour la vie de tous les jours, le C pour des programmes à plus long terme.
Pas toujours...
Tu peux m'expliquer pourquoi (sur ma machine, mais je suppose chez tout le monde) : /usr/bin/firefox est un lien symbolique vers /usr/lib/firefox/firefox.sh qui est bien sûr un script shell qui finit par lancer un binaire (/usr/ lib/firefox/firefox).
Tu supposes mal, pas chez moi (Archlinux) : % file $(command -v firefox) /usr/bin/firefox: symbolic link to `/usr/lib/firefox/firefox' % file /usr/lib/firefox/firefox /usr/lib/firefox/firefox: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1] d0063bf90ac5ab434576b26aff1f5277794c82, stripped
(idem pour d'autres logiciels...)
Ce sont des lanceurs, je ne pense pas que firefox soit écrit en shell ;-) (C++ majoritairement).
Je viens de regarder sur une Ubuntu c'est effectivement une script shell : #!/bin/sh set -e # Firefox launcher containing a Profile migration helper for # temporary profiles used during alpha and beta phases. [...]
-- Benoit Izac
Benoit Izac
Bonjour,
le 09/05/2013 à 15:11, Francois Lafont a écrit dans le message <518ba08a$0$3726$ :
Je ne sais pas si c'est une bonne chose d'apprendre le C (sûrement que oui car en informatique plus on en sait mieux c'est) mais en tout cas je confirme que c'est vraiment difficile. Perso, j'avais tenté puis abandonné après quelques semaines. On peut voir sur les forums des experts qui arrivent quand même à se prendre le chou sur des pages et des pages de messages à grand coup de citations de ladite norme pour juste arriver à savoir si telle ou telle ligne respecte la norme machin-truc ou bien si c'est un "undefined behaviour" potentiel etc. etc.
C'est la même chose dans n'importe quel langage, qu'il soit informatique ou humain.
Je suis d'accord, mais si on reste dans l'informatique, cette problématique me semble particulièrement présente dans le C, voire largement plus présente quand dans d'autres langages que j'ai eu l'occasion de connaître *un minimum*, à savoir le shell UniX, Python, Java, Eiffel (bon, c'est juste le point de vue que quelqu'un qui a une connaissance en langages de programmation assez limitée).
C'est normal puisque les langages que tu cites sont de plus haut niveau. Le C te fournit les briques et le ciment, les autres te donnent directement les murs ; en C tu vas devoir calculer le nombre de briques nécessaires par rang, déposer la bonne quantité de ciments, etc. Dans un langage de plus haut niveau, tu n'as juste qu'à préciser les dimensions du mur. Par conséquent, il y a infiniment moins de choses à discuter.
Pour quelqu'un qui a à c½ur de faire du code portable, le C donne l'impression d'être un puits sans fond. Bon, c'est juste une impression perso vu de loin.
Faire du shell portable est tout autant compliqué.
Je suis d'accord que faire du shell portable est compliqué mais il me semble, là aussi, qu'en C c'est beaucoup plus compliqué. En fait, en shell, il me semble que ça sera plus au niveau des commandes externes (sed, awk, find etc.) que l'on va appeler qu'il est difficile de connaître et de se limiter aux options qui rendront le script portable, mais au niveau du langage lui-même ça me semble bien plus facile de faire quelque chose de portable qu'en C. Mais là aussi, je peux me tromper.
Le C est parfaitement portable dans le sens où le même programme peut tourner de la même façon sur toutes les machines disposant d'un compilateur C. Ce qui n'est pas portable, c'est par exemple de faire la supposition qu'un int fait 32 bit ou un char fait 8 bit ; si l'on s'en tient à ce qui est écrit par exemple dans le K&R (donc à fortiori dans la norme), il n'y a pas de raison que ça se passe mal. Encore une fois, le C étant un langage de bas niveau, il est naturel qu'il y ait plus de détails à assimiler.
-- Benoit Izac
Bonjour,
le 09/05/2013 à 15:11, Francois Lafont a écrit dans le message
<518ba08a$0$3726$426a74cc@news.free.fr> :
Je ne sais pas si c'est une bonne chose d'apprendre le C (sûrement que
oui car en informatique plus on en sait mieux c'est) mais en tout cas
je confirme que c'est vraiment difficile. Perso, j'avais tenté puis
abandonné après quelques semaines. On peut voir sur les forums des
experts qui arrivent quand même à se prendre le chou sur des pages et
des pages de messages à grand coup de citations de ladite norme pour
juste arriver à savoir si telle ou telle ligne respecte la norme
machin-truc ou bien si c'est un "undefined behaviour" potentiel etc.
etc.
C'est la même chose dans n'importe quel langage, qu'il soit informatique
ou humain.
Je suis d'accord, mais si on reste dans l'informatique, cette
problématique me semble particulièrement présente dans le C, voire
largement plus présente quand dans d'autres langages que j'ai eu
l'occasion de connaître *un minimum*, à savoir le shell UniX, Python,
Java, Eiffel (bon, c'est juste le point de vue que quelqu'un qui a une
connaissance en langages de programmation assez limitée).
C'est normal puisque les langages que tu cites sont de plus haut
niveau. Le C te fournit les briques et le ciment, les autres te donnent
directement les murs ; en C tu vas devoir calculer le nombre de briques
nécessaires par rang, déposer la bonne quantité de ciments, etc. Dans un
langage de plus haut niveau, tu n'as juste qu'à préciser les dimensions
du mur. Par conséquent, il y a infiniment moins de choses à discuter.
Pour quelqu'un qui a à c½ur de faire du code portable, le C donne
l'impression d'être un puits sans fond. Bon, c'est juste une
impression perso vu de loin.
Faire du shell portable est tout autant compliqué.
Je suis d'accord que faire du shell portable est compliqué mais il me
semble, là aussi, qu'en C c'est beaucoup plus compliqué. En fait, en
shell, il me semble que ça sera plus au niveau des commandes externes
(sed, awk, find etc.) que l'on va appeler qu'il est difficile de
connaître et de se limiter aux options qui rendront le script
portable, mais au niveau du langage lui-même ça me semble bien plus
facile de faire quelque chose de portable qu'en C. Mais là aussi, je
peux me tromper.
Le C est parfaitement portable dans le sens où le même programme peut
tourner de la même façon sur toutes les machines disposant d'un
compilateur C. Ce qui n'est pas portable, c'est par exemple de faire la
supposition qu'un int fait 32 bit ou un char fait 8 bit ; si l'on s'en
tient à ce qui est écrit par exemple dans le K&R (donc à fortiori dans la
norme), il n'y a pas de raison que ça se passe mal. Encore une fois, le
C étant un langage de bas niveau, il est naturel qu'il y ait plus de
détails à assimiler.
le 09/05/2013 à 15:11, Francois Lafont a écrit dans le message <518ba08a$0$3726$ :
Je ne sais pas si c'est une bonne chose d'apprendre le C (sûrement que oui car en informatique plus on en sait mieux c'est) mais en tout cas je confirme que c'est vraiment difficile. Perso, j'avais tenté puis abandonné après quelques semaines. On peut voir sur les forums des experts qui arrivent quand même à se prendre le chou sur des pages et des pages de messages à grand coup de citations de ladite norme pour juste arriver à savoir si telle ou telle ligne respecte la norme machin-truc ou bien si c'est un "undefined behaviour" potentiel etc. etc.
C'est la même chose dans n'importe quel langage, qu'il soit informatique ou humain.
Je suis d'accord, mais si on reste dans l'informatique, cette problématique me semble particulièrement présente dans le C, voire largement plus présente quand dans d'autres langages que j'ai eu l'occasion de connaître *un minimum*, à savoir le shell UniX, Python, Java, Eiffel (bon, c'est juste le point de vue que quelqu'un qui a une connaissance en langages de programmation assez limitée).
C'est normal puisque les langages que tu cites sont de plus haut niveau. Le C te fournit les briques et le ciment, les autres te donnent directement les murs ; en C tu vas devoir calculer le nombre de briques nécessaires par rang, déposer la bonne quantité de ciments, etc. Dans un langage de plus haut niveau, tu n'as juste qu'à préciser les dimensions du mur. Par conséquent, il y a infiniment moins de choses à discuter.
Pour quelqu'un qui a à c½ur de faire du code portable, le C donne l'impression d'être un puits sans fond. Bon, c'est juste une impression perso vu de loin.
Faire du shell portable est tout autant compliqué.
Je suis d'accord que faire du shell portable est compliqué mais il me semble, là aussi, qu'en C c'est beaucoup plus compliqué. En fait, en shell, il me semble que ça sera plus au niveau des commandes externes (sed, awk, find etc.) que l'on va appeler qu'il est difficile de connaître et de se limiter aux options qui rendront le script portable, mais au niveau du langage lui-même ça me semble bien plus facile de faire quelque chose de portable qu'en C. Mais là aussi, je peux me tromper.
Le C est parfaitement portable dans le sens où le même programme peut tourner de la même façon sur toutes les machines disposant d'un compilateur C. Ce qui n'est pas portable, c'est par exemple de faire la supposition qu'un int fait 32 bit ou un char fait 8 bit ; si l'on s'en tient à ce qui est écrit par exemple dans le K&R (donc à fortiori dans la norme), il n'y a pas de raison que ça se passe mal. Encore une fois, le C étant un langage de bas niveau, il est naturel qu'il y ait plus de détails à assimiler.
