totof2000 a écrit 9656 commentaires

On reconnait là la patte des gros débiles de la SNCF : on a la meme chose en gare avec les nouveaux écrans dans les grandes gares (ex : gare du Nord). du scrolling dans touis les sens qui font perdre du temps : sympa de rater son train parce que l'affichage en gare met des plombes à indiquer que le train en voie n s'arrête bien à ta gare de destination. Avant, on avait une surface énorme, visible de loin, ou tu voyais de façon claire et sans que ça bouge les gares ou s'arrêtent les trains. Maintenant, on a des surfaces toutes petites, que tu ne peux voir de loin avec un scrolling pourri qui cache les informations essentielles.

On a vraiment affaire à une bande d'abrutis à la SNCF. Le pire c'est que je vois bien ces idiots s'auto-congratuler parce qu'ils ont payé leur truc bien cher, et être content justement de ce scrolling pourri parce que ça fait un bel effet.

Par contre l' affichage noir et orange de certaines gares est beaucoup mieux : ça reste petit pour voir de loin, mais on a pas un scrolling pourri comme sur les autres écrans (a moins que je n'en ai pas encore vu).

C'est quand même dommage d'en arriver là. C'était tellement plus simple lorsque j'avais ça en page d'accueil lors de l'ouvertue de firefox.

les développeurs ont souvent tendance à vouloir que les utilisateurs passent par le silo dédié pour aller d'un point A à un point B dans leur application, sans s'imaginer que les utilisateurs voudraient faire autrement

Remarque que ça peut avoir son utilité (éviter de valider deux fois une commande par exemple). Par contre mettre ça partout, c'est la plaie.

Vu comment ils se sont pris le bec sur un autre fil, je pense que ça ne risque pas … ;)

Au fait c'est bien du C ou du shell ?

J'ai peut-être des barrettes qui trainent ici, et qui pourraient te servir (avant que je ne m'en débarasse à la benne). Tu peux me dire ce que tu as, que je vois si c'est compatible avec ce que j'ai ?

Si j'en cros http://www.ramfinder.com/memory-for-brand-name-pc/packard-bell-memory/packard-bell-ixtreme-memory/packard-bell-ixtreme-7862i-memory/packard-bell-ixtreme-7862i-memory.html tu as 4 slots mémoire dispo, et tu peux aller jusqu'a 4 Gb de RAM. Est-ce que tu confirmes?

Je ne sais pas si je pourrai te trover 4 Gb de RAM, mais peut-être 1 GB. T'as combien de barretes actuellement? Et important, tu es dans quelle région ? (pour moi c'est la région parisienne).

tu aurais du écrire autre chose que "Tout à fait totof2000…" : j'ai cru que par cette phrase, tu indiquais que tu t'étais ttrompé de sujet … J'imagine que le sujet a changé par rapport à ce que mequeline a indiqué. toutes mes excuses pour le "gonflé" dans ce cas. Celà dit, à l'avenir, essaie d'être un peu plus précis quand tu réponds, ça évitera les malentendus.

Juste une correstion car il semble que tu ne connais pas le Mac App Store

C'est vrai. En fait je pensais plutôt aux applis pour mobiles.

Les paquets Mac App Store sont testés par Apple.

Je ne dis pas le contraire, mais tu ne fais pas les mêmes tests si une appli touche aux fondements du système.

Tu ne fais que confirmé qu'Apple prend l'idée et la rend utilisable.

Tout dépend de ce que tu entends par utilisable : j'ai une ubuntu sur mon portable qui est parfaitement utilisable.

Le problème est donc bien "Linux" (= la "communauté"), on ne peut que s'en prendre qu'à soit-même

mais c'est quoi ce langage "va-t-en guerre" ? Qui veut s'en prendre à quelqu'un ?

Le sujet du journal, "l'opensource qui ne réussit pas à se défaire de ses démons" avec le même résultat (le bénéfice de la chose est pour l'autre, de sa propre faute à ne pas s'être intéressé à l'utilisateur).

C'est que la cible d'utilisateur n'est pas forcément la même. Sinon, pour info, ma belle-soeur, mon épouse et d'autres personnes qui ne sont pas geek s'en sortent très bien pour installer des applis avec Ubuntu.

méqueline donne nous alors des explications toi qui a bien compris ce qu'il fallait faire au lieu de tourner en rond en étalant tous les exos ou publier des codes sans interet ce qui n'apportera rien

Je te trouve plutôt gonflé sur ce coup : si il/elle n'avait pas publié ça, on n'aurait jamais compris que tu t'étais planté. Personnellement, j'arrête là. Tu as tout ce qu'il te faut ici pour faire toi-même. Je ne ferai pas tes exos à ta place.

euh. Slack, c'est assez lourd à l'utilisation … ça rame !!!

Apple a pris l'idée, a viré les limitations des "développeurs qui pensent à leurs délires sans réfléchir plus loin" (par exemple : permettre à quiconque de proposer un logiciel du moment où il respecte les règles sans se faire jeter parce qu'on n'aurait pas trouvé un mentor ni devoir passer 1 an entre la demande et l’acceptation, ne pas rejeter par principe le non libre "caca ça pue on n'en veut pas"…) et en a fait un super business (30% du prix de vente quand même…).
C'est que maintenant que par exemple Ubuntu pense à faire un Store plus tolérant, mais en attendant ce n'est plus l'écosystème Linux qui a le plus d'application facilement accessibles, c'est Mac. La grosse honte (pas comme si Apple s'était jeté dessus tout de suite, les libristes ont eu des années pour offrir une chose utilisable).

Le problème, c'est que les distributions Linux ne font pas de distinction entre l'os "basique" et l'userland : de ce fait tu es obligé de faire le gendarme pour éviter de casser tout le système via un paquet qui n'a pas été validé en amont. La distinction entre os et userland, par des arborescences distinctes, ou les paquets devant toucher à l'OS seraient contrôlés de façon stricte, et une arborescence pour les applis userland (dans lequel on serait moins strict sur les contrôles) serait plus pratique.

OK, donc le posteur initial n'aurait pas compris le sujet de l'exercice (et a posé sa question dans le mauvais forum), ou alors, cette année, le sujet a changé ;)

Tu aurais pu le préciser de suite : ça m'aurait éviter d'étaler une tartine sur les processus shell pour rien.

C'est vachement plus dur que de choisir un opérateur téléphonique, un assureur, un concessionnaire, ….

Faut arrêter avec ça : les gens, lorsqu'ils le veulent, savent choisir.

N'importe quoi.

On parle de script shell, pas de programme C.

En C, tu es obligé d'utiliser l'appel système fork. Mais en shell tu ne l'utilises pas directement, c'est le shell qui le fait pour toi.

Ce n'est pas t'aider que de résoudre les problèmes à ta place : -1 pour celui qui t'a donné la réponse.

Si c'est du C, je laisse la main : ça fait trop longtemps que je n'ai pas fait ce genre de truc. Mais en gros, une fois que tu as récupéré tes commandes à lancer :
- tu forkes (man fork, et plein d'exemples sur le net pour comprendre ce que tu fais).
Après le fork, tu vas te retrouver avec 2 processus : un processus père, et un processus fils. Le processus fils aura une copie des variables du processus père. Pour savoir si tu es dans le processus fils ou le processus père, il faut tester le code retour de fork.
- si tu es dans le processus fils, tu lances la première commande à l'aide de l'appel système exec (man exec + plein d'exemples sur le net).
- lors du second fork, si tu es dansle processus fils, tu lances la seconde commande, et normalement c'est fini.
- Si tu es dans le processus père, tu attends la fin d'exécution du procesus fils. Une fois qu'il a fini, tu ne fais plus rien.

Question : tu dois faire un script shell ou un programme en C? parce que là je n'y comprends plus rien: tu postes dans le forum Programmation.shell, donc j'en ai déduit que tu devais le faire en shell … Si ce n'est pas le cas, dis-le de suite parce que là j'ai l'impression d'avoir tout fait pour rien.

Ce n'est pas un programme qu'il te faut mais un script.

Je t'ai donné toutes les infos (variables $1, $2, … avec des exemples).

tu écris le script mon-if qui t'affiche les paramètres passé sur la ligne de commande. Quand tu exécutes mon-if param1 'param 2', il doit t'afficher premier paramètre : param1, 2eme paramètre : param 2.

J'avais expliqué ça dans un de mes message avec un exeple. J'ai l'impression de l'avoir fait pour rien.

Oups, au temps pour moi, j'ai lu/répondu trop vite …

J'avais testé chez moi avec :

if $var1; then $var2; fi

Et ça, ça marche.

if $var1 -eq 0; then $var2; fi

Ca ça a l'air bon. Tu dois juste récupérer les commandes passées en paramètre à ton script.

true et 'echo réussi' doivent être passé en paramètre sur la ligne de commande.

Sinon on pourrait faire un truc très condensé mais je ne suis pas sur que tu comprennes, alors il vaut mieux découper les diverses choses à faire. Il faut que tu exécutes ton script de la façon suivante :

mon-if 'true' 'réussi'.
Ton script doit :
* récupérer les paramètres de la ligne de commande
* exécuter la première commande
* si elle réussit, exécuter la seconde

Commence par écrire un script qui récupère 'true' et 'echo reussi' sur la ligne de commande et qui l'affiche.
Poste ici. Ensuite on passe à l'étape suivante.

Une fois que tu auras compris, je te montrerai un moyen de faire plus condensé.

Ben c'est simple:
"écrire une commande qui lancera un processus, puis en lancera un second si le premier a réussi"

mon-if 'true' 'echo reussi' affiche 'réussi'
mon-if 'false' 'echo raté' n'affichera rien

tu edites le script mon-if.

Tu récupères le premier argument, tu l'exécutes.
S'il réussit (test du code retour), tu exécutes le second argument.

Petite précision, si tu as une variable qui contient une commande à exécuter (par exemple VAR='echo Réussi'), tu l'exécutes en mettant $VAR en début de ligne (en shell, le premier terme d'une ligne correspond à une commande à exécuter, en dehors des cas d'affectation)

Exemple :
$ VAR='echo Ca marche'
$ $VAR
Ca marche

Essaie de faire quelque chose avec tout ça, et montre le nous si tu n'y arrives pas.

Si j'en crois l'énoncé :

mon-if 'true' 'echo reussi' affichera reussi alors que mon-if 'false' 'echo raté' n'affichera rien

tu dois appeler la commande mon-if avec le paramètre 'true' ou mon-if avec les 2 paramètres 'false' 'echo raté'.

Pour récupérer les paramètres passés à ton script, tu disposes :
- des variables $1 à $9 qui contiennent respectivement ,e 1er jusqu'au 9eme paramètre passé à ton script.
- la variable $* contenant tous les paramètres passés à ton script
- la variable ~# qui contient le nombre d'arguments passés à ton script.

Pour info, tu peux utiliser la commande shift qui te décalera tous tes paramètres : la valeur de $2 est passée ) $1, la valeur de $3 est passée à $2, etc … et le $1 d'origine est perdu.

Exemple :

#!/bin/bash

echo "Nombre de paramètres passé en ligne de commande : $#"
echo "Premier paramètre passé en ligne de commande : $1"
echo "Premier paramètre passé en ligne de commande : $2"
echo " les paramètres passés par la ligne de commande :  $*"

shift
echo "Nombre de paramètres après shift :  $#"
echo " premier paramètre après shift :  $*"
echo " les paramètres passés par la ligne de commande après shift :  $*"

A l'exécution :

sans paramètres :

$ ./essai.sh 
Nombre de paramètres passé en ligne de commande : 0
Premier paramètre passé en ligne de commande : 
Premier paramètre passé en ligne de commande : 
les paramètres passés par la ligne de commande :  
Nombre de paramètres après shift :  0
premier paramètre après shift :  
les paramètres passés par la ligne de commande après shift :  

avec 1 paramètre :

$ ./essai.sh param1
Nombre de paramètres passé en ligne de commande : 1
Premier paramètre passé en ligne de commande : param1
Premier paramètre passé en ligne de commande : 
les paramètres passés par la ligne de commande :  param1
Nombre de paramètres après shift :  0
premier paramètre après shift :  
les paramètres passés par la ligne de commande après shift :  

avec 2 paramètres :

$ ./essai.sh param1 param2
Nombre de paramètres passé en ligne de commande : 2 
Premier paramètre passé en ligne de commande : param1
Premier paramètre passé en ligne de commande : param2
les paramètres passés par la ligne de commande :  param1 param2
Nombre de paramètres après shift :  1
premier paramètre après shift :  param2
les paramètres passés par la ligne de commande après shift :  param2

avec 2 paramètres toujours :

$ ./essai.sh param1 'param 2'
Nombre de paramètres passé en ligne de commande : 2
Premier paramètre passé en ligne de commande : param1
Premier paramètre passé en ligne de commande : param 2
les paramètres passés par la ligne de commande :  param1 param 2
Nombre de paramètres après shift :  1
premier paramètre après shift :  param 2
les paramètres passés par la ligne de commande après shift :  param 2

Est-ce que tu sais récupérer les paramètres passées à la ligne de commande (variables $1, *, …) ?

Hello.

Quand tu exécutes une commande en shell, le système te retourne un code retour. La convention sous Unix veut qu'un processus qui a réussi retourne le code 0. Ce code retour est accessible via la variable d'environnement $?

Exemple :

$ mkdir toto
$ cd toto
$ ls
$ echo $?
0

Quand une commande échoue, elle retourne un code différent de 0 (le code retour est en général documenté dans les pages man). Exemple : je vais lister un fichier/repertoire qui n'existe pas :

ls ./titi
ls: impossible d'accéder à ./titi: Aucun fichier ou dossier de ce type
echo $?
2

En ce qui concerne les tests avec if, voir ce cours qui est assez bien fait. En testant le code de retour de la variable d'environnement $?, tu devrais pouvoir t'en sortir.

Ah, petit détail : j'ai pour habitude dans mes scripts de sauvegarder le code retour de la commande à tester juste après que celle-ci ait été exécuté. En effet, la variable $? est mise à jour à chaque exécution de commande. en gros, je fais un truc du genre :

ls ./titi
ret=$?
if [ $ret != 0 ]
then 
 ...

Sinon, il faut tester de suite la variable $? et être sur que personne n'ajoutera de commande entre la commande que tu veux tester et le test if.