Programme en C et sortie à l'écran

Nicolas George a écrit :

Mais bougre d'andouille, ce que j'essaie de te faire comprendre depuis le
début, c'est que s'il avait pensé au fait que test était une comm ande
système au moment d'appeler son programme test, il n'aurait à la ba se pas eu
de problème du tout.

J'ai dit le contraire triple buse?

A+
JF

Le Mon, 01 Jun 2009 15:19:53 +0200, Vivien Moreau a écrit :

Noex <c@c.c> a écrit :

Cumbalero a présenté l'énoncé suivant :

Parce que tu as oublié de lire cette phrase "un mec qui veut
programmer sous Unix mais qui ne connait pas test devrait lire
quelques ko de docs"

RTFM.

A+
JF

J'ai commencé à lire "le système Unix" par Steve Bourne. J'ai bon ?

Jamais lu ce livre, mais comme c'est par le type ayant écrit le Bourne
Shell ( dont « descend » ton bash ), y'a de grandes chances que ça
soit une bonne référence.

un peu comme le Kernigan/Ritchie

Benoit Izac a écrit :

Faut quand même pas pousser. L'OP a posé une question qui peut paraître
trivial pour un initié mais ce problème est arrivé à beaucoup de
personnes (au moins à moi en tout cas). Jeter la pierre à quelqu'un car
il ne connaît pas un détail de son shell fait preuve de bien peu de
tolérance. Lui expliquer d'où vient son erreur, ça prend deux minutes.

Ca a été fait.

Ca n'empêche pas de passer du temps à donner quelques idées de bonnes
pratiques pour que ça ne se reproduise plus.

Il me semble que lui suggérer quelques lectures pour ne plus tomber dans
le même piège soit à l'opposé de l'intolérance.

Maintenant, si tu parles de la rivalité plus ou moins folklorique en
Nicolas et moi... c'est que tu ne fréquentes pas depuis assez longtemps
les groupes usenet parlant de Linux.

Je te fais le résumé de l'homme pressé: je respecte beaucoup Nicolas,
ses interventions sur le plan technique sont très souvent
irréprochables, j'ai appris beaucoup en lisant certaines de ces
interventions (j'ai en bookmark un de ses posts sur ALSA et sa conf qui
m'ont bien dépanné lors de mes débuts en MAO sous Linux par exemple). De
même, si un jour j'ai une question à poser en terme de compression
vidéo, je sais à qui la poser. Ca n'empêche que je trouve que la
condescendance dont il fait preuve envers de très nombreux intervenants
me déplait (doux euphémisme) et que de la part de quelqu'un qui est prof
dans l'institution où il est, j'attends un minimum de pédagogie. Pas
nécessairement à mon endroit, les échanges qu'on a pu avoir laissant des
traces dans ce que j'appelle dans ce post le folklore.

Et pour en revenir à l'OP, désolé, mais lancer un programme qui
s'appelle test dans un bash, il n'a pas eu de bol, mais s'il s'était
documenté sur le shell dans lequel il lançait son programme, il n'aurait
pas eu de souci.

Et en tant qu'ingénieur de prod info, ne pas se documenter avant sur son
environnement, son logiciel... est une faute. Déformation
professionnelle peut-être, mais l'apprentissage par essais et erreurs en
informatique, je n'y crois plus depuis fort longtemps, la seule règle
reste RTFM.

A+
JF

Noex a écrit :

[Un tiny programme]

J'ai programme, il y a longtemps sous Spix, l'Unix de Bull a cote de
Gcos, mais bon, j'avais des erreurs du genre "core dumped".

Ce qui m'interesserait, c'est de voir le source de ton programme, pour
voir les divergences, biensur, si tu ne veux pas, je comprendrais. J'ai
biensur des sources, mais trop compliqués, puis ca utilise ./configure,
make, make install... et ca j'ai jamais fait.

Je serais juste interesse par un noyau de programme, simplement un int
main(void) avec quelques commandes simples.

Vu que je ne programme plus en C, j'ai perdu de gros acquis, il me reste
bien des bouquins sur le C et le C++, mais ils datent...

Donc si tu es d'accord pour me preter quelques unes de tes
connaissances, j'en serais heureux ;-)

Merci d'avance,

--

Regis a écrit :

[Un tiny programme]

J'ai programme, il y a longtemps sous Spix, l'Unix de Bull a cote de
Gcos, mais bon, j'avais des erreurs du genre "core dumped".

vieux souvenirs :-)

Ce qui m'interesserait, c'est de voir le source de ton programme, pour
voir les divergences, biensur, si tu ne veux pas, je comprendrais. J'ai
biensur des sources, mais trop compliqués, puis ca utilise ./configure,
make, make install... et ca j'ai jamais fait.

"make" existait déjà sous Spix. En gros, dès que tu veux faire un peu
plus que "hello world", make te permet (à l'aide du fichier "Makefile")
de définir les dépendances (ton exécutable dépend de plusieurs sources,
il faut lancer les compilations, les éditions de lien adhoc etc.).
Ensuite make a servi un peu à tout, dont lancer l'installation par "make
install:
l'installation dépend des exécutables, il faut donc les compilés, puis
les copier dans les répertoires adhoc, initialiser les fichiers de
configuration etc.

./configure est un script qui bêtement configure la compilation et
l'installation en fonction du système et de tes préférences.

Voir : http://doc.ubuntu-fr.org/projets/paquets/compiler_un_programme


--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org

Regis a pensé très fort :

Noex a écrit :

[Un tiny programme]

J'ai programme, il y a longtemps sous Spix, l'Unix de Bull a cote de
Gcos, mais bon, j'avais des erreurs du genre "core dumped".

Ce qui m'interesserait, c'est de voir le source de ton programme, pour
voir les divergences, biensur, si tu ne veux pas, je comprendrais. J'ai
biensur des sources, mais trop compliqués, puis ca utilise ./configure,
make, make install... et ca j'ai jamais fait.

Je serais juste interesse par un noyau de programme, simplement un int
main(void) avec quelques commandes simples.

Vu que je ne programme plus en C, j'ai perdu de gros acquis, il me reste
bien des bouquins sur le C et le C++, mais ils datent...

Donc si tu es d'accord pour me preter quelques unes de tes
connaissances, j'en serais heureux ;-)

Merci d'avance,

Avec plaisir! C'est un premier jet mais ça marche.



#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/io.h>
#include <time.h>

#define base 0x378
#define value 255

int data,etat,cont,octet,sortie,vu;

int main ()
{
printf ("Scrute file USB. n");

if (ioperm(base,1,1))
printf ("pige pas. n");

outb(value,base);

do
{

unsigned int lu;

data=0x378;
etat=0x379;
cont=0x37a;

char * fichier="/home/dossier/usb";
char * pfich="/home/dossier/fin";

if (access (pfich,W_OK) ==0) {
sortie =2;
}

if (access (fichier,W_OK) ==0) {

if (vu!=1) {
time_t seconds;
seconds = time (NULL);

printf ("%1d USB actif. n",seconds/3600);
octet =0xFF;
outb (octet,base);
vu=1;
}

}
else
{
if (vu!=2) {

printf ("USB arret. n");
octet =0x00;
outb (octet,base);
vu=2;
}
}

sleep(2);

}
while (sortie < 1);
}

Bonjour,

le 04/06/2009 à 10:13, Cumbalero <cumbalero@nospam.yahoo.fr> a écrit
dans le message <4a278242$0$6713$426a74cc@news.free.fr> :

Faut quand même pas pousser. L'OP a posé une question qui peut paraître
trivial pour un initié mais ce problème est arrivé à beaucoup de
personnes (au moins à moi en tout cas). Jeter la pierre à quelqu'un car
il ne connaît pas un détail de son shell fait preuve de bien peu de
tolérance. Lui expliquer d'où vient son erreur, ça prend deux minutes.

Ca a été fait.

Ca n'empêche pas de passer du temps à donner quelques idées de bonnes
pratiques pour que ça ne se reproduise plus.

Se taper la lecture de la page de manuel de bash comme bonne pratique,
je ne suis pas sûr que ce soit une bonne idée...

Il me semble que lui suggérer quelques lectures pour ne plus tomber
dans le même piège soit à l'opposé de l'intolérance.

Lorsque l'on sait où chercher, c'est effectivement très facile. Passer
son temps à lire des pages de manuel dans l'éventualité d'éviter un
problème à l'avenir, je ne suis pas certain de l'efficacité.

Lorsque j'ouvre une page de manuel, je sais déjà ce que je cherche : une
option pour une commande, la valeur de retour d'une fonction, la syntaxe
d'un fichier de configuration, le fonctionnement d'un démon, etc. Il ne
m'est jamais arrivé de lire une page de manuel conséquente (>500 lignes)
d'une seule traite. D'une part ça me prendrait trop de temps, d'autre
part c'est fatiguant (je préfère le papier) et surtout je suis incapable
de tout retenir ; d'ailleurs je n'en vois pas l'intérêt car cette page
de manuel est justement disponible pour être consultée lorsque j'en ai
besoin.

Maintenant, si tu parles de la rivalité plus ou moins folklorique en
Nicolas et moi... c'est que tu ne fréquentes pas depuis assez
longtemps les groupes usenet parlant de Linux.

Je lis Usenet depuis 1999...

[...]

Et en tant qu'ingénieur de prod info, ne pas se documenter avant sur
son environnement, son logiciel... est une faute. Déformation
professionnelle peut-être, mais l'apprentissage par essais et erreurs
en informatique, je n'y crois plus depuis fort longtemps, la seule
règle reste RTFM.

Non, RTFM c'est pour le gars qui te demande « comment demander à ls
d'afficher la date d'accès d'un fichier ? ». Dans les cas comme celui de
ce fil, je pense que c'est en forgeant que l'on devient forgeron et je
suis persuadé que l'OP se souviendra bien plus longtemps de l'existence
de test que quiconque qui sort de la lecture de la page de manuel de
bash.

Je souhaite me lancer dans la programmation, je vais partir avec de
bonnes bases :
% man zshall gcc | grep -v '^ *$' | wc -l
30353
Je vais ensuite m'ajouter une petite lecture de la norme C et de Single
Unix Specification et je finirai par la partie documentation de mon
noyau juste au cas où j'en ai besoin. Le tout bien sûr avant de taper la
moindre ligne de code car peut-être qu'une erreur pourrait faire
exploser ma bécane. Ah mince ! J'utilise Emacs pour taper mon code. Bon
c'est pas grave :
% info emacs 2>/dev/null | grep -v '^ *$' | wc -l
36573
;-)

--
Benoit Izac

Bonjour,

le 04/06/2009 à 10:13, Cumbalero <cumbalero@nospam.yahoo.fr> a écrit
dans le message <4a278242$0$6713$426a74cc@news.free.fr> :

Faut quand même pas pousser. L'OP a posé une question qui peut paraître
trivial pour un initié mais ce problème est arrivé à beaucoup de
personnes (au moins à moi en tout cas). Jeter la pierre à quelqu'un car
il ne connaît pas un détail de son shell fait preuve de bien peu de
tolérance. Lui expliquer d'où vient son erreur, ça prend deux minutes.

Ca a été fait.

Ca n'empêche pas de passer du temps à donner quelques idées de bonnes
pratiques pour que ça ne se reproduise plus.

Se taper la lecture de la page de manuel de bash comme bonne pratique,
je ne suis pas sûr que ce soit une bonne idée...

Il me semble que lui suggérer quelques lectures pour ne plus tomber
dans le même piège soit à l'opposé de l'intolérance.

Lorsque l'on sait où chercher, c'est effectivement très facile. Passer
son temps à lire des pages de manuel dans l'éventualité d'éviter un
problème à l'avenir, je ne suis pas certain de l'efficacité.

Lorsque j'ouvre une page de manuel, je sais déjà ce que je cherche : une
option pour une commande, la valeur de retour d'une fonction, la syntaxe
d'un fichier de configuration, le fonctionnement d'un démon, etc. Il ne
m'est jamais arrivé de lire une page de manuel conséquente (>500 lignes)
d'une seule traite. D'une part ça me prendrait trop de temps, d'autre
part c'est fatiguant (je préfère le papier) et surtout je suis incapable
de tout retenir ; d'ailleurs je n'en vois pas l'intérêt car cette page
de manuel est justement disponible pour être consultée lorsque j'en ai
besoin.

Maintenant, si tu parles de la rivalité plus ou moins folklorique en
Nicolas et moi... c'est que tu ne fréquentes pas depuis assez
longtemps les groupes usenet parlant de Linux.

Je lis Usenet depuis 1999...

[...]

Et en tant qu'ingénieur de prod info, ne pas se documenter avant sur
son environnement, son logiciel... est une faute. Déformation
professionnelle peut-être, mais l'apprentissage par essais et erreurs
en informatique, je n'y crois plus depuis fort longtemps, la seule
règle reste RTFM.

Non, RTFM c'est pour le gars qui te demande « comment demander à ls
d'afficher la date d'accès d'un fichier ? ». Dans les cas comme celui de
ce fil, je pense que c'est en forgeant que l'on devient forgeron et je
suis persuadé que l'OP se souviendra bien plus longtemps de l'existence
de test que quiconque qui sort de la lecture de la page de manuel de
bash.

Je souhaite me lancer dans la programmation, je vais partir avec de
bonnes bases :
% man zshall gcc | grep -v '^ *$' | wc -l
30353
Je vais ensuite m'ajouter une petite lecture de la norme C et de Single
Unix Specification et je finirai par la partie documentation de mon
noyau juste au cas où j'en ai besoin. Le tout bien sûr avant de taper la
moindre ligne de code car peut-être qu'une erreur pourrait faire
exploser ma bécane. Ah mince ! J'utilise Emacs pour taper mon code. Bon
c'est pas grave :
% info emacs 2>/dev/null | grep -v '^ *$' | wc -l
36573
;-)

--
Benoit Izac

Bonjour,

le 04/06/2009 à 10:13, Cumbalero <cumbalero@nospam.yahoo.fr> a écrit
dans le message <4a278242$0$6713$426a74cc@news.free.fr> :

Faut quand même pas pousser. L'OP a posé une question qui peut paraître
trivial pour un initié mais ce problème est arrivé à beaucoup de
personnes (au moins à moi en tout cas). Jeter la pierre à quelqu'un car
il ne connaît pas un détail de son shell fait preuve de bien peu de
tolérance. Lui expliquer d'où vient son erreur, ça prend deux minutes.

Ca a été fait.

Ca n'empêche pas de passer du temps à donner quelques idées de bonnes
pratiques pour que ça ne se reproduise plus.

Se taper la lecture de la page de manuel de bash comme bonne pratique,
je ne suis pas sûr que ce soit une bonne idée...

Il me semble que lui suggérer quelques lectures pour ne plus tomber
dans le même piège soit à l'opposé de l'intolérance.

Lorsque l'on sait où chercher, c'est effectivement très facile. Passer
son temps à lire des pages de manuel dans l'éventualité d'éviter un
problème à l'avenir, je ne suis pas certain de l'efficacité.

Lorsque j'ouvre une page de manuel, je sais déjà ce que je cherche : une
option pour une commande, la valeur de retour d'une fonction, la syntaxe
d'un fichier de configuration, le fonctionnement d'un démon, etc. Il ne
m'est jamais arrivé de lire une page de manuel conséquente (>500 lignes)
d'une seule traite. D'une part ça me prendrait trop de temps, d'autre
part c'est fatiguant (je préfère le papier) et surtout je suis incapable
de tout retenir ; d'ailleurs je n'en vois pas l'intérêt car cette page
de manuel est justement disponible pour être consultée lorsque j'en ai
besoin.

Maintenant, si tu parles de la rivalité plus ou moins folklorique en
Nicolas et moi... c'est que tu ne fréquentes pas depuis assez
longtemps les groupes usenet parlant de Linux.

Je lis Usenet depuis 1999...

[...]

Et en tant qu'ingénieur de prod info, ne pas se documenter avant sur
son environnement, son logiciel... est une faute. Déformation
professionnelle peut-être, mais l'apprentissage par essais et erreurs
en informatique, je n'y crois plus depuis fort longtemps, la seule
règle reste RTFM.

Non, RTFM c'est pour le gars qui te demande « comment demander à ls
d'afficher la date d'accès d'un fichier ? ». Dans les cas comme celui de
ce fil, je pense que c'est en forgeant que l'on devient forgeron et je
suis persuadé que l'OP se souviendra bien plus longtemps de l'existence
de test que quiconque qui sort de la lecture de la page de manuel de
bash.

Je souhaite me lancer dans la programmation, je vais partir avec de
bonnes bases :
% man zshall gcc | grep -v '^ *$' | wc -l
30353
Je vais ensuite m'ajouter une petite lecture de la norme C et de Single
Unix Specification et je finirai par la partie documentation de mon
noyau juste au cas où j'en ai besoin. Le tout bien sûr avant de taper la
moindre ligne de code car peut-être qu'une erreur pourrait faire
exploser ma bécane. Ah mince ! J'utilise Emacs pour taper mon code. Bon
c'est pas grave :
% info emacs 2>/dev/null | grep -v '^ *$' | wc -l
36573
;-)

--
Benoit Izac

Benoit Izac wrote in message <w53tz2u7j0a@message.id>:

d'ailleurs je n'en vois pas l'intérêt car cette page
de manuel est justement disponible pour être consultée lorsque j'en ai
besoin.

Parfois, lire ou au moins survoler une page de man de bout en bout peut être
utile pour découvrir des fonctions qu'on ne cherchait pas mais qui peuvent
s'avérer bien utile une fois qu'on les a découvertes.

À part ça, je suis globalement très d'accord avec ce que tu as écrit.