gaaaaaAab a écrit 1387 commentaires

tiens, d'ailleurs, ça peut se faire tout simplement au niveau de la résolution de noms en redirigeant toutes les urls inopportune sur 127.0.0.1 ou autre

fiou, on s'engage sur un terrain éthique glissant ...
Comme je n'ai pas tous les éléments de la situation, je ne juge pas les choix faits sur ton réseau. De mon expérience, j'ai plutôt tendance à croire que la responsabilité des citoyens/internautes/êtres humains est un denrée rare. Je pense que je préférerais filtrer les urls d'une blacklist plutôt que laisser la porte ouverte aux inévitables abus et faire de la répression ensuite. Mais d'autres paramètres sont à prendre en compte comme le nombre d'utilisateurs, leur compréhension du fonctionnement des réseaux, leur motivation à l'utilisation du réseau, le coût du filtrage en termes de performances, et autres critères pertinents.

bon, une façon de faire dans la réponse de netsurfeur, donc ma réaction, c'est plus du coupage de cheveux en quatre qu'autre chose :-)

je me suis super relu pour essayer de pas tomber dans le troll sur ces sujets délicats. J'espère que je me suis pas trop raté ... Dans le doute, je le redis: je ne juge pas les choix fait sur ton réseau. C'est plus une réflexion à voi^W clavier haut ;-)

question con, mais dans quel contexte tu fais ça ?
parce que je soutiens pas plus le porno que ça, mais si c'est pour du flicage en entreprise ... je passe mon tour ... :)

<i> c'est surtout que je suis pas fan de java</i>

ben on voit vraiment pas pourquoi tu te tortures le cerveau alors. En fait, t'as sacrément envie d'aller bosser dans ta ch'tite boite sympa, et tu te demandes si c'est bien raisonnable.
Alors déjà, tu commences à bosser, c'est pas un choix de carrière définitif que tu fais là. Même si finalement, aller faire du C s'avérerait être une erreur, t'auras toujours moyen de rebondir.
D'autre part, si l'informatique, c'est vraiment ton truc, les technologies importent peu. Tu seras toujours capable de te remettre à niveau sur les technos que tu connais pas au moment ou t'en auras besoin. Je dis pas que tu vas être J2E lead architect après avoir repris ton java dans ton coin pendant deux petites semaines, mais tu seras suffisament au point intégrer une équipe de développement java. Et à partir de là, pour utiliser un terme cher aux managers, tu montes en compétence en java et tu peux faire d'autres trucs après.
Si t'es un peu curieux, une bonne part de l'expérience que tu vas acquérir sur ton projet en C est directement applicable à pleins d'autres contexte. Un algo, ça reste un algo. Les enjeux de la gestion d'erreur, de la gestion de conf ou des tests, c'est les même partout (même si les façons de faire diffèrent). L'expérience, c'est pas que des trucs techniques.

Aussi, tu te fais des idées sur le marché du travail je crois :) Un recruteur, ce qu'il veut savoir, c'est pas si tu connais l'api swing sur le bout des doigts. Certes, il y a un minimum technique à avoir, mais ce qui l'intéresse vraiment, c'est de savoir qui tu es, s'il va pouvoir bosser avec toi, si tu vas t'intégrer dans l'équipe, si t'es autonome, si tu sais t'exprimer, ...

et en plus, cerise sur le gateau dans cette argumentation implacable : le java, ça pue :)

killall qui sait tuer un groupe de process à partir du nom.
Si tu veux faire des trucs plus rafiinés, tu peux aussi regarder du côté de pidof

man killall
man pidof

ouala :)

on peut aussi taper moins de caractère et faire un truc genre
rm `ls | grep -v mon_fichier.txt`

à part que les backquote sont un peu chiant à choper sur un azerty :)

sinon, doit y avoir moyen de faire ça avec l'expansion du shell aussi.
D'ailleurs, quelques minutes de man et quelques essais plus tard, en bash,

shopt -s extglob
rm !(mon_fichier.txt)

ça doit le faire

ca doit être parce que ton seuil de lecture est pas à -1.
Vu que je poste pas super souvent, je me retrouve régulièrement à poster à 1, et je passe sous le radar ;-)

tu me coupes l'herbe sous le pied ! :-)

je vote pour sort aussi si l'ordre des lignes n'est pas important.
On peux aussi utiliser l'option -u de sort et virer le cat qui sert à rien

sort -u fich1 fich2 > fich

Oui, mais à priori, t'auras difficilement mieux.
Soit bien conscient que de toute façon, tu n'obtiendras jamais une réponse fiable à tous les coups, puisque l'encodage n'est pas une information contenue dans le fichier mais déduite.

J'avais le même genre de souci avec la freebox qui venait changer mon resolv.conf pour mettre les dns de free alors que je voulais utiliser mon dns à moi que j'ai. J'ai fini par m'en sortir en rajoutant

dns-nameservers <ip du dns>

dans le fichier interfaces pour l'interface concernée par le dhcp.

Dans ce cas là, le client dhcp va toujours modifier le resolv.conf, mais il préserve le dns que tu veux.

ben c'est pas bien ;-)

UUOC

grep -n "hello" fichier.txt
suffit.
Laissez le chat tranquille !!!

ouaip, pas loin Mais en l'occurence, le tolower (ou le toupper), tu veux l'appliquer à la donnée de ton fichier, et pas à la valeur en dur de référence. Ce serait plutôt

awk 'tolower($4) ~/machin/'

Sinon, je connaissais pas IGNORECASE. Ca a l'air bien aussi. A priori, d'après la doc, il faut que tu le positionnes à autre chose que 0 pour ignore la casse.
Ca serait donc plutot
awk -v IGNORECASE=1 '(...)'

Contrairement à mes posts précédents, j'ai pas testé ce que je dis là. C'est direct tiré de la doc. A vérifier donc :)

man awk ! :)

Je te laisse faire joujou avec tolower et toupper. Plutôt toupper en fait, ça t'évitera des problèmes d'accent.

Sinon, tu peux aussi remplacer /deck54/ par /[dD][eE][cC][kK]54/ puisqu'il s'agit d'une regex, mais c'est plus long et nettement moins drole à utiliser :)

c'est pas du shell, mais awk fait ça super bien

$ awk < file ' $3~/deck54/'

$3, c'est pour comparer sur le troisième champ (comme dans ton exemple)
et print $0 (affichage de la ligne) est l'action par défaut.

pour lier FF et KDE, je vois pas. Peut-être une extension ?

sinon, pour qu'il repropose la sauvegarde des mots de passe, ça doit être dans
Préférences --> Vie Privée --> Mots de passe enregistrés --> Voir les mots de passe enregistrés --> Mots de passe jamais enregistrés.

hmmm, c'est peut-etre un ifcfg-sit0 en fait ...

dans /etc/sysconfig/network-scripts, tu dois avoir un fichier ifcfg-eth0
Y a des trucs à configurer dedans aussi. C'est même principalement dans ce fichier que se fait la configuration de l'interface.

Ton /etc/resolv.conf sera renseigné automatiquement par DHCP avec les NS de ton fournisseur d'accès. Et comme tu n'as pas de réseau, normal que tu n'aies pas beaucoup de routes :)

post ton ifcfg-eth0, et on pourra surement aller plus loin.

oui, c'était pas explicite, mais c'était le sens de mon "grep bien choisi". Par exemple avec une petite regex histoire d'aller taper dans le bon champ.

déjà, tu voulais surement taper fichier1 dans ta ligne de awk. A mon avis, c'est une typo.
Sinon, tu as un problème sur le system("`$i`"). $i n'est pas défini pour awk. Vu que awk est un nouveau process, il n'hérite pas de la variable $i. Pour que awk connaisse $i, il faut que tu rajoutes "export i" dans ta boucle.

Je ne sais pas si ça suffit (pas testé), mais ça ne peut que améliorer les choses :)

bon, ça répond pas à la question en awk, mais vu que tu fais déjà une boucle sur tous les éléments de fichier2, pourquoi ne pas remplacer ton awk par un grep bien choisi ? (à mon avis plus performant)

"J'avais pas précisé que numclient est pas ds commande"

erreur ! c'est un point essentiel !
Le problème principal de ta requête initiale, c'est que tu ne fais aucun lien entre la ligne de la table commande que tu es en train de mettre à jour et le select de la valeur. Il y a bien la table commande dans les deux cas, mais ton select travaille sur toute la table commande, au lieu de ne travailler que sur la ligne intéressante.

Il faut que tu explicites le lien entre une commande et un client.
S'il n'y a pas de numclient dans commande, comment tu lies une commande et un client ? (la table affaire ?)

Les requêtes d'update un peu complexe, c'est le truc que j'ai mis le plus de temps à intégrer. Pour bien comprendre ce que je fais, je travaille séparément sur les clauses WHERE. La clause WHERE sur la table commande (la seconde ici) sert à limiter le nombre de lignes qu'on va traiter. Ce qu'il faut arriver à se mettre dans le crâne, c'est que quand on travaille sur la clause WHERE dans le SET (la première), on ne travaille plus sur toute la table commande, mais sur une seul des lignes sélectionnée par le WHERE sur la table commande.
Pour que la valeur qu'on met dans le SET corresponde à quelquechose, il faut absolument faire le lien avec la table commande qu'on update, et pas avec la table commande en général. Un truc du genre

update commande C -- nommer la table pour pouvoir l'utiliser après
set activitecmde = (select t.valeur
from table t
where T.un_champ = C.un_champ -- la relation entre la table et le select
... -- le reste de la clause WHERE)
where c.activitecmde < 20;

Pour répondre plus précisément à ta situation, il faut que tu explicites le lien entre une commande et un client.

parce que sans plus d'infos, ça va être duraille.
Dans les classiques, un firewall qui bloquerait le mauvais port ?
sinon, des fichiers de logs ?

accessoirement, le deuxième système, c'est un linux aussi ou un windows ?

des précisions sur la nature de la base de données ?
Si c'est une base type mysql, postgres, oracle ou autre, je vois pas bien ce qui fait le lien entre awk et la base ...
Si la base de données est stockée dans des fichiers plats, ça a déjà plus de sens. Mais même comme ça, awk serait pas mon langage de choix pour bosser là dessus ...

je viens de demander à copain google, et PFE, c'est pour faire du Forth.
Il faudrait surement faire s/AWK/FORTH dans le sujet ;)

je connais un peu awk, mais pas du tout Forth ...

pffff j'ai mis le temps, mais j'ai retrouvé : http://linuxfr.org/forums/26/5986.html(...)