gaaaaaAab a écrit 1399 commentaires

ah ? tu trouves que ça a fonctionné toi ? :D

Bon, on en est tous passé par là ... ton message m'a fait penser à
http://www.gnurou.org/writing/smartquestionsfr que j'en ai profité pour relire.

sinon, il semblerait que antlr sache générer du code dans les langages définis là : http://www.antlr.org/wiki/display/ANTLR3/Code+Generation+Tar(...)
ce qui ne veut pas forcément dire qu'antlr est inutilisable, mais qu'il va y avoir plus de boulot.
pour écrire des parsers, j'ai souvent entendu parler de lex et yacc (ou flex et bison), c'est peut-être une piste à creuser.

Je pense qu'il y a des gens ici qui en connaissent plus que moi sur les grammaires formelles, du coup, il y a p-e des outils mieux adaptés à ton problème ... encore faut-il que tu le précises un peu plus.

pour la discussion sur le H264, un article sur osnews sur le sujet :

http://www.osnews.com/story/23031/Mozilla_Stick_to_Your_Idea(...)

et nous te saurons gré de ne pas faire attention qu'à l'orthographe, parce que là, tu fais quand même deux fautes pour en corriger une :)

en inversant le critère (éliminer toutes les valeurs <= 100), ça donne un truc comme ça :

~$ cat bla
-35
-100
-1000
38943
$ grep -v -- "-[0-9]\{3,\}" bla
-35
38943


à adapter s'il y a plusieurs champs par ligne de fichier.

oops, copié/collé la mauvaise ligne de l'historique du shell ...

sed -n 's/user_pref("mail.server.server\([0-9]*\)\.type.*/\1/p' prefs.js |sort -n | tail -1

ok, je me demandais si un simple wc -l suffisait (mais grep -c, c'était incontestablement mieux), mais vu ce commentaire, la réponse est non.

ton xargs | awk pour récupérer la dernière ligne peut se remplacer par un tail

et grep | awk | cut par un sed

Du coup :
grep mail.server.server'.*'.type prefs.js | sort -n |tail -1 | sed 's/.\{29\}\([0-9]*\).*/\1/'

sed '/keyword1\|keyword2/ { s/keyword3//g}'

raisonnement logique, mais le monde de l'entreprise n'est pas toujours rationnel.
Il arrive que des choix technologiques soient fait pour des raisons purement arbitraires. Ca va du "le patron de cette boite c'est mon copain alors on choisit sa technologie" à "on ne peut pas dépendre d'un seul fournisseur alors on va prendre le produit de machin même s'il est moins bien que celui de bidule".

sur le principe, avec un makefile du genre:


$ cat makefile

all: cmd1 cmd2

cmd1:
while [ 1 ]; do echo "hu"; sleep 5; done

cmd2:
while [ 1 ]; do echo "ha"; sleep 3; done
.PHONY: cmd1 cmd2


ensuite:
$ make -j 2
while [ 1 ]; do echo "hu"; sleep 5; done
hu
while [ 1 ]; do echo "ha"; sleep 3; done
ha
ha
hu
ha
ha
hu


en oubliant pas que make exige des tabulations en début des lignes de commande (ici, devant chaque while), mais je ne sais pas comment faire apparaitre ça proprement sur linuxfr.
pour toi, ça sera make -j 8 (man make)

yapuka(c) écrire une moulinette pour générer le makefile (parce que se cogner les 400 commandes à la main, c'est pas glop) et roule :)

je me répète, mais comme tu sembles n'avoir pas lu mon autre commentaire, mettre de l'eau sur un livre ne le rend pas inutilisable.
Je comprends que ça t'embêtes pour ta démonstration, mais un livre, c'est pas *si* fragile que ça. Quant à la pérennité des livres électroniques, je veux bien te suivre sur le plan théorique, mais admet qu'on manque un petit peux de recul sur la question.

Une fois qu'on aura bien trollé pour décider si le livre électronique est mieux que le livre papier, ça nous dira pas si le grand public suivra.

D'après ce que je vois sur le grand 'Ternet, sont considérés comme gros lecteurs les gens qui lisent plus de 20 livre par ans [1]. Chiffre non recoupé, j'ai vu le chiffre de 12 ailleurs (mais je ne sais plus ou).

Je ne sais pas quelle est la proportion de gros lecteur dans la population. Ca demanderait plus de recherche documentaire.
En tout cas, si on se réfère au premier paragraphe de [2] citant une étude de TNS Sofres (Mars 2008):
le nombre de livres lus est en baisse : si 42 % des Français lisaient plus de cinq livres en 1983, ils ne sont plus que 34 % aujourd'hui

Les gens vont-il vraiment acheter des ebooks en masse pour s'en servir 5 fois par an ?

A tempérer, puisque d'après [3], la lecture ne serait pas en perte de vitesse. Mais comme le contenu est payant, on a pas le détail.

[1] http://www.grinzane.net/Osservatorio2003/Osservatorio2003_FR(...)
[2] http://www.actualitte.com/actualite/1315-lecture-France-habi(...)
[3] http://www.scienceshumaines.com/index.php?id_article=4988&am(...)

Hop un verre d'eau et tu perds ton livre.
il est hyper-dépendant d'un verre d'eau mal placé

heu ... non. D'après mon expérience, même avec une bouteille d'eau complète (mal refermée qui se vide dans tout le sac à dos), le livre résiste.
Certes, il est gondolé à mort, mais l'encre et le papier tiennent bien.

en plus, le livre, il résiste probablement au micro onde, alors que pas l'e book.
Alors, on fait moins le malin ? :o)

--> []

effectivement, les systèmes de fichiers habituellement utilisés sous Unix stockent la date de dernière modification, et pas la date de création. Et effectivement, c'est parfois génant.

Pour répondre aux autres questions du message de départ, la date de dernier accès à un fichier (le atime) est disponible. On peut la voir avec la commande
stat fichier
ou avec ls (mais probablement pas du tout portable)
ls -l --time atime fichier

Attention cependant, pour gagner quelques pouillèmes en performance en lecture (sur les gros systèmes très sollicités, ça peut faire des gros pouillèmes), les systèmes de fichiers sont parfois montés avec l'option noatime. Dans ce cas, les dates d'accès ne sont pas mis à jour dans les inodes des fichiers.
Tant que j'y suis, les atime, en fait, osef. En tout cas, je n'en ai jamais eu besoin jusqu'à présent, et je ne connais (en tout cas, pour l'instant) aucun soft qui s'en serve.

Pour finir, les outils habituels d'archivage sont sympas, ils préservent les dates des fichiers, donc pas la peine de s'embêter à fabriquer une liste à côté. Les fichiers sauvegardés auront les mêmes attributs fonctionnels que les fichiers originaux (uid, gid, permissions, dates diverses et variées).
Même la commande cp peut préserver ces attributs si on lui demande gentiment (man cp) !

Mais ça, avec quelques tests de ton côté, t'aurais pu répondre tout seul ;)

Le protocole SMS était à l'origine un système interne pour tester la ligne.

heu ... non. Le protocole SMS sert à pleins d'autres trucs que d'échanger des messages de type texte.

Par contre, possible que ça devienne vrai si on transforme la phrase en :
les SMS au format texte était à l'origine un système interne pour tester la ligne
mais il faudrait des gens dans le secteur depuis plus longtemps que moi pour confirmer.

... désolai pour les fôtes

(et qui semble être mal implémenté)

en fait, il y a plusieurs classes de SMS. Parmi les SMS affichables, il y en a deux sortes, ceux interprétés par le mobile qui s'affiche une fois et ne sont pas stockés, et ceux à destination de la carte SIM qui peut en stocker un certain nombre (défini au moment de la personnalisation de la carte). Vu le format du système de fichier GSM, le maximum théorique est de 255 SMS. Les anciennes cartes à puce ne supportent souvent pas le stockage de plus de 10 SMS (parce que ça prend de la place et les opérateurs veulent réduire le coup des cartes SIM en payant des composants de moindre capacité, donc moins chers).

Pour les SMS concaténés, il y a aussi une limitation au niveau de la carte. Les différents fragments sont stockés dans un tampon qui fait n * 133 (140 ou 160 en fait, avec les en-tête, la flemme de chercher), mais n vaut rarement 255 (aussi un paramètre de personnalisation).

Pour pallier les limitations des cartes SIM là dessus, les téléphones modernes permettent aussi de gérer les SMS reçus et envoyés dans la mémoire du téléphone. Avantage : on peut en stocker pleins. Inconvénient, quand on change la SIM de tél, on ne transporte pas l'historique.

Pour conclure, c'est globalement le gros bins, parce que le nombre max de fragments d'un SMS concaténé dépend du modèle de la carte (et il y a une tripotée de modèle et chaque modèle est décliné suivant une tripotée de personnalisation) et des capacités du tél.

Je comprends du coup que les opérateurs ne communiquent pas trop là dessus, parce qu'ils ne peuvent pas garantir un fonctionnement homogène pour tous leurs abonnés.

oui, bien vu.
Moment nostalgie : en prépa, sur les PCs, l'environnement Windows était très très limité. Par contre, l'IDE qu'on utilisait (ça devait être du Borland Pascal, ça nous rajeunit pas) avait une chouette menu pour ouvrir un shell dos =)

ok, j'en déduis que tu as rencontré des problèmes (probablement contournables en y passant un peu de temps) dans l'implémentation d'un script particulier, mais pas de critique de fond sur le mécanisme.
merci pour les précisions

heu ... ça m'arrive de faire ça et je ne vois pas quels problèmes ça soulève. Au contraire même, je trouve ça très bien :)
Du coup, ça m'intéresserait que tu développes sur ce que tu vois de négatif là dedans.

ah ... manifestement, je suis total à côté de la plaque là :
cf http://linuxfr.org/comments/1091331.html#1091331

donc 4100 € ? ;-)

de ce que j'en avais compris, l'idée du port knocking part du constat que les méchants pirates^w script kiddies tentent de casser les mots de passe faibles pour les utilisateurs habituels sur les ports standards (genre le mdp root/admin/www-data ou autre sur ssh).

L'idée du port knocking est que le port 22 soit fermé par défaut, et que seule une combinaison de ping sur des ports dans un ordre déterminé l'ouvre pendant quelques minutes.
Ensuite, c'est une connexion ssh classique avec authentification classique.
Au bout d'un certain temps (configuré quelque part), le port 22 se referme.

Pour tout attaquant scannant les ports en dehors de cette plage de quelque minutes, la probabilité qu'il scan les ports dans le bon ordre étant faible, le service ssh n'est pas accessible (donc pas troutable)

ce que tu décris (grosso modo, l'envoi d'un challenge), c'est finalement l'authentification par clefs . Ca existe aussi, mais c'est pas du port knocking.

je suis pas sûr que ça répond à la question de départ, mais ce que tu écris là, ça serait plus joli comme ça:

SELECT t1.id
FROM table_contenant_toutes_les_ids t1
WHERE NOT EXISTS (SELECT 1 FROM table_des_ids_réservés t2 WHERE t1.id = t2.id)


;-)
sur ce coup là, je n'aurais pas pu écrire ça sans ton commentaire.

Le hold space, c'est le genre de trucs ou on se demande après coup comment on a pu passer à côté si longtemps ...
Je compte plus le nombre de trucs que j'ai appris sur programmation.shell, je l'aime bien ce forum :)

et en élaborant encore un peu (pour couper les blocs incomplets en fin de fichier, même si ce n'était pas demandé) :

sed -n '/TIMESTAMP/,/OUT/{
/TIMESTAMP/ { h }
/IN/ { H }
/OUT/ {
H
x
p
}
}' ./path/to/file


a y est, je suis fan du hold space :)