je suis allé regarder le man de g++. Effectivement, -permissive permet de compiler du code non conforme. Donc, un point pour toi, et je suis surpris :-) Je ne dirais donc plus que C est un sous-ensemble de C++.
Ça peut avoir du sens de regrouper C et C++ dans certains contextes.
Ça m'étonnerait un peu si c'était pas du C++ valide, parce que il me semble que la compatibilité avec le C était un principe très significatif lors de la conception du C++.
Mais comme je pratique pas beaucoup le C++, je ne sais pas trop. En tout cas, avec le drapeau -fpermissive, g++ considère que c'est un warning, et accepte de compiler.
bien vu !
Je me suis arrêté à "le compilo donne le même warning pour les deux", mais c'est vrai que ça ne suffit pas.
Cela dit, même entre deux versions d'un seul compilateur sur un seul langage, on pourrait aussi avoir des comportements différents (surtout sur des comportements non définis).
Dans l'absolu, il faudrait en fait préciser le couple (langage, compilo) pour chaque exemple, mais ça devient vite vachement moins facile à appréhender.
Sur le fond du journal, c'est un détail, mais si le C est du C++ valide, le contraire n'est pas vrai. Pour avoir un exemple en C/C++, il aurait fallu préférer une version en C avec du bon vieux stdio.h et du printf :-)
Avec la suite gcc/g++ 6.3, le warning est identique en C (ce qui n'est pas du tout surprenant).
sinon, dans cette exemple, tu as écrit un décalage à gauche au lieu d'un décalage à droite (j'imagine que tu t'es laissé embarquer par l'opérateur du cout)
J'avais vu passer SEUM, mais je n'ai pas pris le temps de regarder de près. Pour moi, c'est vraiment la qualité du level design qui fait la richesse de Deadcore. Mais, trop se renseigner avant sur ce que ce genre de jeu propose en la matière, ça peut casser un peu le plaisir de la découverte des niveaux. Cela-dit, tu fais bien de me remettre SEUM en tête, je vais creuser un peu, ça peut effectivement me plaire !
Oui. Je n'ai pas retenu shadowrun. D'une part parce que je ne voulais faire une liste de plusieurs dizaines de titre. Et aussi parce qu'au delà des aspects RPG (progression, quêtes) et du thème (cyberpunk) qui contribuent à rendre ces jeux sympas, je trouve les mécaniques de combat moins riches et moins profondes que les deux que j'ai cité.
Je n'avais pas fini shadowrun returns, mais dragonfall était incontestablement meilleur, et j'ai bien apprécié hong-kong aussi.
il y a aussi d'autres bons jeux indés. Je me restreins volontairement à une poignée. Liste évidemment subjective, et contenant des titres vraiment de niche. Si ça vous fait de l'oeil, renseignez vous un peu pour voir si ça peut vous plaire (en dehors du fait qu'un seul de cette liste soit libre). Je met des "genre" pour donner une idée, mais ça correspond objectivement pas à grand chose.
tactique tour par tour : darkest dungeon et invisible Inc (y'en a deux, c'est mon genre de prédilection)
super hexagon : open hexagon : clone libre de super hexagon
platforme FPS : deadcore (assez orienté speedrun, par un studio français)
twin stick shooter : the binding of isaac
shmup : steredenn (parce que j'aime la bande son, la direction artistique, le gameplay, et par un studio français aussi)
WTF: The Stanley Parable
et j'ai envie de citer sunless sea pour l'ambiance lovecraftienne. mais je pense que les mécaniques de jeu ne plairont pas à tout le monde. En tout cas, la première fois, je n'ai pas trop accroché. Et c'est seulement en lui redonnant sa chance un an plus tard que je me suis vraiment plongé dedans.
en gros apache n'attend pas assez longtemps que ton process wsgi.py renvoie ses reponses
soit faut que ton python tourne plus vite, soit qu'apache soit plus patient
pas forcément. apache attend des données sur la sortie standard du process fils. Si apache n'a pas de réponse, ça peut aussi être parce que le fils s'est vautré, ou ne produit pas une sortie au format attendu par apache (manque de saut de ligne après les en-tête http, lignes de log du process redirigées vers la sortie standard, …). Et bien sûr, ça peut être que le traitement est trop long comme tu le mentionnes.
Le fait qu'il y ait des messages d'erreur différents selon les cas, ça pourrait aussi être que le process fils renvoie du junk, mais que de temps en temps, ça ressemble suffisamment à ce qu'apache attend pour qu'il lise une taille random (et du coup, ça marche pas).
Ça serait intéressant de voir le détail de ce que le process wsgi produit comme sortie.
Histoire de pinailler un peu, les deux commandes sont fonctionnellement équivalentes, mais à choisir, je prendrais toujours le "sort -u". Il me parait préférable d'utiliser une seule commande au lieu de deux : un fork en moins, et une gestion d'erreur plus facile si on décide d'en faire. Sur un script utiliser une fois, on s'en fout un peu, mais si ça doit atterrir dans un truc lancé régulièrement, c'est bien d'avoir ces considérations en tête.
J'étais tombé sur un post d'un blog qui présentait less +F, et c'est de la grosse balle. Ça permet de se mettre en attente sur un fichier (comme tail -f), mais on peut aussi interrompre l'attente pour se balader dans le fichier, puis se remettre en attente sur le fichier. Ça remplace très avantageusement tail -f /var/log/messages par exemple.
$ while [ 1 ]; do date >> log_file; sleep 1 ; done &
[1] 12294
# je coupe des lignes, la commande suivante affiche en fait less sur tout le terminal
$ less +F ./log_file
Tue Oct 11 13:31:37 CEST 2016
Tue Oct 11 13:31:38 CEST 2016
Waiting for data... (interrupt to abort)
# sur pression de Ctrl-C
Tue Oct 11 13:32:15 CEST 2016
Tue Oct 11 13:32:16 CEST 2016
Tue Oct 11 13:32:17 CEST 2016
Tue Oct 11 13:32:18 CEST 2016
Tue Oct 11 13:32:19 CEST 2016
./log_file (END)
# on peut naviguer dans le fichier de log comme on fait habituellement dans less.
# pour reprendre la mise à jour du fichier, il suffit de se déplacer en fin de fichier (touche F)
Tue Oct 11 13:33:34 CEST 2016
Tue Oct 11 13:33:35 CEST 2016
Tue Oct 11 13:33:36 CEST 2016
Tue Oct 11 13:33:37 CEST 2016
Waiting for data... (interrupt to abort)
# et hop, de retour sur le lecture des nouvelles entrées dans le fichier
ils ont fait ça longtemps, mais depuis que ça a été racheté, les repreneurs ont immédiatement arrêté ça. En tout cas, ils ont communiqué dessus très vite, et depuis, les quelques fois ou j'ai regardé un truc hébergé chez eux, ça avait l'air ok.
je me réponds tout seul, parce que pourquoi pas. Dans ce que j'ai écrit, j'ai conclus un peu vite que les infos du whois sont publiques. Il faudrait voir si "exiger que des infos soient publiquement disponibles" en fait des informations publiques. Perso, je pense que oui, mais je reconnais que ça pourrait ce discuter.
Je suis moi-même propriétaire d'un nom de domaine,
pas tout à fait, tu en es plus le locataire que le propriétaire ;-)
Toutes les informations accessibles via un whois sont publiques
Or nous avons obtenues ces informations via un whois
Donc ces informations sont publiques.
J'avoue que pour moi, il était acquis que les infos d'enregistrements de noms de domaine étaient publiques. Du coup, je suis allé jeter un œil sur wikipedia, et dans le paragraphe criticism, il y a :
Currently the Internet Corporation for Assigned Names and Numbers (ICANN) broadly requires that the mailing address, phone number and e-mail address of those owning or administrating a domain name to be made publicly available through the "WHOIS" directories
traduction suivant la méthode rache :
Pour le moment, l'ICANN exige que l'adresse postale, le numéro de téléphone et l'adresse e-mail des détenteurs ou administrateurs de noms de domaine soient publiquement disponibles dans les répertoires WHOIS.
Ce qui m'inspire deux commentaires :
- aujourd'hui, le contenu du whois est bien une information publique,
- beaucoup de gens (dont l'ICANN) considèrent que c'est un problème (cf ce paragraphe )
Je comprends l'intérêt (voire la nécessité) de protéger les informations personnelles. D'un autre côté, l'espace des noms de domaine est un espace commun. Quand quelqu'un s'en approprie temporairement un morceau (en enregistrant un nom de domaine), ça ne me paraît pas non plus totalement illégitime d'avoir un moyen de l'identifier.
Bref, pour citer encore wikipedia, mais la page française ce coup-ci :
Le choix de ce qu'on publie reste une des questions politiques les plus brûlantes pour un registre Internet.
L'argument de reflets.info est que ces informations ne sont pas privées car elles ont été récupérées par un whois.
non, la question du moyen de les récupérer n'est absolument pas la justification avancée. Dans le paragraphe qui commence par "Pour ceux qui ne savent pas ce que c’est, nous allons l’expliquer." , je cite :
Ces informations sont publiques et une simple recherche permet de les afficher. Celui qui les fournit sait qu’elles seront publiques.
Ils n'ont pas écrit que ces infos sont publiques parce que faciles à obtenir, mais et faciles à obtenir.
En règle générale, ça serait vraiment bien de poster les sorties correspondant effectivement au script décrit. Là, vu le script, dans la ligne générée, archive.tar.gz devrait plutôt ressembler à archive_2016-09September-18_002627 (curieux format de date). D'autre part,
'--newer-mtime="2016-09-18''00:26:27"'
ne correspond pas non plus à $g tel que g est défini.
Sinon, le calcul de ddate peut être légèrement amélioré.
On peut identifier l'entrée qu'on veut garder avec ls avant de transmettre le résultat à stat (du coup, stat ne traite qu'un seul fichier au lieu d'une liste).
Pour garder la première ligne d'une liste, sed -n '1 p' fonctionne, mais parcourt toute la liste. Il vaut mieux utiliser head (ce qui améliore également la lisibilité).
Sur le plan cosmétique, je préfère évaluer avec $(…) plutôt que \'…\', mais là, c'est plus une question de préférence personnelle.
Au final, le nombre de commande lancées est le même, mais seul ls travaille sur une liste, les autres commandes ne traitent qu'une seule entrée. Sur des répertoires avec de nombreux fichiers, la différence en temps d'exécution peut être significative.
Bien vu la commande rename, j'avais oublié que ça existait :-)
Pour peaufiner, comme rename peut prendre une liste de fichiers à renommer, on peut combiner find avec xargs, ce qui permet de lancer une seule instance de rename au lieu de le lancer pour chaque résultat de find. Comme les fichiers contiennent éventuellement des espaces il faut alors utiliser l'option -print0 (resp. -0) de find (resp. xargs) pour remplacer l'espace par le caractère nul comme séparateur de champs en sortie (resp. en entrée)
On peut aussi rendre la regex de rename un peu plus précise en évitant de remplacer les pdfout en milieu de noms de fichier avec 's/pdfout$/pdf/'
Il faut aussi protéger l'utilisation du caractère * dans le -iname (en tout cas, chez moi, ça ne marche pas sinon)
Effectivement, la majorité des applications aurait peut-être du mal à remplir 8G de /tmp, mais ces 8Go représente aussi ta RAM. Du coup, si les applis qui tournent sont un peu gourmandes en RAM, tu n'as pas forcément autant d'espace dispo que ça pour ton /tmp. Tu n'es pas non plus à l'abri d'une appli qui déconne et qui blinde /tmp.
Par exemple, sur ma machine, il y a quelques années, en sortant d'une mise en sommeil, il arrivait que mon gestionnaire de fenêtre se mette à pondre des lignes de log en continu dans un fichier dans /tmp, jusqu'à saturation de la partition.
Dans l'absolu, à moins d'auditer dans le moindre détail l'intégralité des trucs qui tournent sur ta bécane, tu ne pourras jamais garantir à 100% que ton /tmp n'épuisera pas ta réserve de RAM. Du coup, il faut regarder ce qui se passe dans le pire des cas. Si tmp est sur le FS, tu blindes ton FS. A priori, c'est pas trop grave. Tu perds des logs, il y a p-e des applis qui se plantent un peu, mais le système d'exploitation continue à fonctionner. Par contre, si tu épuises ta RAM, si tu as du swap, ça va commencer à swapper (un bon coup dans les dents des performances), et à épuisement de RAM+swap, il y a des risques importants que le système crash.
Sur une machine perso, si tu as beaucoup de RAM et que tu veux réduire l'utilisation du SSD, monter /tmp en RAM peut-être une bonne idée. Si ça sature, un reboot et c'est réglé. Sur un serveur, il vaut probablement mieux monter /tmp sur un FS dédié.
Si python et mail ne sont pas dans le même endroit la sortie de l'un ne correspond pas à l'entrée de l'autre.
La question n'est pas vraiment sur le répertoire dans lequel se trouve les différentes commandes, mais plutôt le répertoire de travail au moment ou elles sont lancées. En l'occurrence, les deux commandes étaient lancées par cron, donc dans le même répertoire de travail (le home de l'utilisateur pour lequel cron exécute ces commandes).
Si au lieu d'une redirection, les commandes python et mail prenait un nom de fichier comme paramètre, alors, oui, la question de savoir ou chaque commande pense que ce fichier se trouve serait très importante.
Ceci dit, si on a besoin d'accéder à un fichier particulier, ça peut être pertinent d'utiliser des chemins absolus dans le contexte de cron. J'attire toutefois ton attention sur le fait qu'en ayant ajouté un "." au début de tes chemins, tu en as fait des chemins relatifs plutôt que des chemins absolus. Du coup, tel que tu l'as écrit, c'est similaire à la solution initiale. Ta proposition souffre aussi du fait que si le répertoire local "tmp" n'existe pas, il n'est pas créé par la redirection ">" et du coup, les deux commandes échouent.
Bref, dans le détail et sur ce cas précis, ta proposition est incorrecte en l'état, mais dans l'absolu, c'est bien de se poser la question des emplacements de fichier (et plus généralement de l'environnement) quand on travaille avec cron.
Merci aussi à GaaaaaAaab (j'ai pas oublié un "a" là ?:) ).
Il y en a un de trop :-)
Sinon, pour revenir sur ton problème, je re-précise que je suspecte que ça venait de la différence de temps de traitement entre ton programme Python et la commande mail, mais il faudrait tester pour en être vraiment sûr. Ce n'est pas spécialement nécessaire de le faire, mais c'est important de garder en tête que ça reste une hypothèse non confirmée.
En prenant un peu de hauteur, même si ta solution initiale avait fonctionné, il restait un défaut fondamental: ton traitement est basé sur une séquence logique (la sortie d'une commande est l'entrée de la suivante), mais cron applique une séquence chronologique. Du coup, je ne vois pas vraiment de solution simple avec deux entrées dans cron qui garantirait la séquence logique de ton traitement. Bon, je ne sais pas si ça intéresse grand monde, mais, en y repensant, pour moi, c'est vraiment ça le coeur du problème de ta solution initiale.
Et, tant qu'on parle de cron, quelques petits ajouts en passant :
attention à l'environnement : cron transmet directement les commandes qu'on lui passe à un sh non interactif. Dans le contexte des commandes lancées par cron, les variables d'environnement définies dans les .profile, ou autres .bash_profile ne sont pas chargées. Quand on ne le sait pas, on peut perdre pas mal de temps avant de comprendre pourquoi une commande ne marche pas.
Relativement au commentaire de srayneau ci-dessous , le répertoire de travail d'une commande lancée par cron est le répertoire home de l'utilisateur en question.
[^] # Re: Légendaires?
Posté par gaaaaaAab . En réponse au journal Jouer sous GNU/Linux : la série des Shadowrun. Évalué à 8.
et des trolls sur linuxfr ;-)
[^] # Re: léger HS: coquille sur C++ (et C++!=C)
Posté par gaaaaaAab . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 2.
je suis allé regarder le man de g++. Effectivement, -permissive permet de compiler du code non conforme. Donc, un point pour toi, et je suis surpris :-) Je ne dirais donc plus que C est un sous-ensemble de C++.
[^] # Re: léger HS: coquille sur C++ (et C++!=C)
Posté par gaaaaaAab . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 2.
Ça peut avoir du sens de regrouper C et C++ dans certains contextes.
Ça m'étonnerait un peu si c'était pas du C++ valide, parce que il me semble que la compatibilité avec le C était un principe très significatif lors de la conception du C++.
Mais comme je pratique pas beaucoup le C++, je ne sais pas trop. En tout cas, avec le drapeau -fpermissive, g++ considère que c'est un warning, et accepte de compiler.
[^] # Re: léger HS: coquille sur C++ (et C++!=C)
Posté par gaaaaaAab . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 2.
bien vu !
Je me suis arrêté à "le compilo donne le même warning pour les deux", mais c'est vrai que ça ne suffit pas.
Cela dit, même entre deux versions d'un seul compilateur sur un seul langage, on pourrait aussi avoir des comportements différents (surtout sur des comportements non définis).
Dans l'absolu, il faudrait en fait préciser le couple (langage, compilo) pour chaque exemple, mais ça devient vite vachement moins facile à appréhender.
# léger HS: coquille sur C++ (et C++!=C)
Posté par gaaaaaAab . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 7.
Sur le fond du journal, c'est un détail, mais si le C est du C++ valide, le contraire n'est pas vrai. Pour avoir un exemple en C/C++, il aurait fallu préférer une version en C avec du bon vieux stdio.h et du printf :-)
Avec la suite gcc/g++ 6.3, le warning est identique en C (ce qui n'est pas du tout surprenant).
sinon, dans cette exemple, tu as écrit un décalage à gauche au lieu d'un décalage à droite (j'imagine que tu t'es laissé embarquer par l'opérateur du cout)
[^] # Re: Hum, ça donne envie
Posté par gaaaaaAab . En réponse au journal Jeu sous GNU/Linux : The Talos Principle. Évalué à 2.
J'avais vu passer SEUM, mais je n'ai pas pris le temps de regarder de près. Pour moi, c'est vraiment la qualité du level design qui fait la richesse de Deadcore. Mais, trop se renseigner avant sur ce que ce genre de jeu propose en la matière, ça peut casser un peu le plaisir de la découverte des niveaux. Cela-dit, tu fais bien de me remettre SEUM en tête, je vais creuser un peu, ça peut effectivement me plaire !
Oui. Je n'ai pas retenu shadowrun. D'une part parce que je ne voulais faire une liste de plusieurs dizaines de titre. Et aussi parce qu'au delà des aspects RPG (progression, quêtes) et du thème (cyberpunk) qui contribuent à rendre ces jeux sympas, je trouve les mécaniques de combat moins riches et moins profondes que les deux que j'ai cité.
Je n'avais pas fini shadowrun returns, mais dragonfall était incontestablement meilleur, et j'ai bien apprécié hong-kong aussi.
Après, les goûts et les couleurs toussa ;-)
[^] # Re: Hum, ça donne envie
Posté par gaaaaaAab . En réponse au journal Jeu sous GNU/Linux : The Talos Principle. Évalué à 3.
j'ai aussi bien aimé the Talos principle.
il y a aussi d'autres bons jeux indés. Je me restreins volontairement à une poignée. Liste évidemment subjective, et contenant des titres vraiment de niche. Si ça vous fait de l'oeil, renseignez vous un peu pour voir si ça peut vous plaire (en dehors du fait qu'un seul de cette liste soit libre). Je met des "genre" pour donner une idée, mais ça correspond objectivement pas à grand chose.
et j'ai envie de citer sunless sea pour l'ambiance lovecraftienne. mais je pense que les mécaniques de jeu ne plairont pas à tout le monde. En tout cas, la première fois, je n'ai pas trop accroché. Et c'est seulement en lui redonnant sa chance un an plus tard que je me suis vraiment plongé dedans.
[^] # Re: port salut, c'est marqué dessus.
Posté par gaaaaaAab . En réponse au message Déployer une application Django avec apache et mod_wsgi. Évalué à 3.
pas forcément. apache attend des données sur la sortie standard du process fils. Si apache n'a pas de réponse, ça peut aussi être parce que le fils s'est vautré, ou ne produit pas une sortie au format attendu par apache (manque de saut de ligne après les en-tête http, lignes de log du process redirigées vers la sortie standard, …). Et bien sûr, ça peut être que le traitement est trop long comme tu le mentionnes.
Le fait qu'il y ait des messages d'erreur différents selon les cas, ça pourrait aussi être que le process fils renvoie du junk, mais que de temps en temps, ça ressemble suffisamment à ce qu'apache attend pour qu'il lise une taille random (et du coup, ça marche pas).
Ça serait intéressant de voir le détail de ce que le process wsgi produit comme sortie.
# Python(s)
Posté par gaaaaaAab . En réponse au journal Cohérence des fonctions d'arrondi. Évalué à 10.
En passant, Python2 renvoie -1, mais Python3 renvoie 0
[^] # Re: sort tout seul
Posté par gaaaaaAab . En réponse au message Ne garder qu'une seule occurrence de chaque ligne d'un fichier. Évalué à 6.
Histoire de pinailler un peu, les deux commandes sont fonctionnellement équivalentes, mais à choisir, je prendrais toujours le "sort -u". Il me parait préférable d'utiliser une seule commande au lieu de deux : un fork en moins, et une gestion d'erreur plus facile si on décide d'en faire. Sur un script utiliser une fois, on s'en fout un peu, mais si ça doit atterrir dans un truc lancé régulièrement, c'est bien d'avoir ces considérations en tête.
# tail -f fichier_de_log ? non ! less +F fichier_de_log
Posté par gaaaaaAab . En réponse au journal Back to basics : avoir un excellent pager avec less. Évalué à 10.
J'étais tombé sur un post d'un blog qui présentait less +F, et c'est de la grosse balle. Ça permet de se mettre en attente sur un fichier (comme tail -f), mais on peut aussi interrompre l'attente pour se balader dans le fichier, puis se remettre en attente sur le fichier. Ça remplace très avantageusement tail -f /var/log/messages par exemple.
[^] # Re: De beaux pillards
Posté par gaaaaaAab . En réponse au message Licences et «contamination». Évalué à 2.
ah ok. c'est ton utilisation du présent qui m'a fait penser que tu avais raté l'info.
[^] # Re: De beaux pillards
Posté par gaaaaaAab . En réponse au message Licences et «contamination». Évalué à 2. Dernière modification le 24 août 2019 à 16:35.
ils ont fait ça longtemps, mais depuis que ça a été racheté, les repreneurs ont immédiatement arrêté ça. En tout cas, ils ont communiqué dessus très vite, et depuis, les quelques fois ou j'ai regardé un truc hébergé chez eux, ça avait l'air ok.
j'ai retrouvé l'annonce
[^] # Re: Oui, enfin quand on regarde les détails...
Posté par gaaaaaAab . En réponse au journal Quand on délègue sa liberté d'expression à twitter. Évalué à 4.
je me réponds tout seul, parce que pourquoi pas. Dans ce que j'ai écrit, j'ai conclus un peu vite que les infos du whois sont publiques. Il faudrait voir si "exiger que des infos soient publiquement disponibles" en fait des informations publiques. Perso, je pense que oui, mais je reconnais que ça pourrait ce discuter.
[^] # Re: Oui, enfin quand on regarde les détails...
Posté par gaaaaaAab . En réponse au journal Quand on délègue sa liberté d'expression à twitter. Évalué à 4. Dernière modification le 24 août 2019 à 18:17.
pas tout à fait, tu en es plus le locataire que le propriétaire ;-)
J'avoue que pour moi, il était acquis que les infos d'enregistrements de noms de domaine étaient publiques. Du coup, je suis allé jeter un œil sur wikipedia, et dans le paragraphe criticism, il y a :
traduction suivant la méthode rache :
Ce qui m'inspire deux commentaires :
- aujourd'hui, le contenu du whois est bien une information publique,
- beaucoup de gens (dont l'ICANN) considèrent que c'est un problème (cf ce paragraphe )
Je comprends l'intérêt (voire la nécessité) de protéger les informations personnelles. D'un autre côté, l'espace des noms de domaine est un espace commun. Quand quelqu'un s'en approprie temporairement un morceau (en enregistrant un nom de domaine), ça ne me paraît pas non plus totalement illégitime d'avoir un moyen de l'identifier.
Bref, pour citer encore wikipedia, mais la page française ce coup-ci :
[^] # Re: Oui, enfin quand on regarde les détails...
Posté par gaaaaaAab . En réponse au journal Quand on délègue sa liberté d'expression à twitter. Évalué à 5.
non, la question du moyen de les récupérer n'est absolument pas la justification avancée. Dans le paragraphe qui commence par "Pour ceux qui ne savent pas ce que c’est, nous allons l’expliquer." , je cite :
Ils n'ont pas écrit que ces infos sont publiques parce que faciles à obtenir, mais et faciles à obtenir.
# en passant
Posté par gaaaaaAab . En réponse au message espace dans une chaine et commande tar. Évalué à 3.
En règle générale, ça serait vraiment bien de poster les sorties correspondant effectivement au script décrit. Là, vu le script, dans la ligne générée, archive.tar.gz devrait plutôt ressembler à archive_2016-09September-18_002627 (curieux format de date). D'autre part,
ne correspond pas non plus à $g tel que g est défini.
Sinon, le calcul de ddate peut être légèrement amélioré.
On peut identifier l'entrée qu'on veut garder avec ls avant de transmettre le résultat à stat (du coup, stat ne traite qu'un seul fichier au lieu d'une liste).
Pour garder la première ligne d'une liste, sed -n '1 p' fonctionne, mais parcourt toute la liste. Il vaut mieux utiliser head (ce qui améliore également la lisibilité).
Sur le plan cosmétique, je préfère évaluer avec $(…) plutôt que \'…\', mais là, c'est plus une question de préférence personnelle.
Bref, j'écrirais plutôt :
Au final, le nombre de commande lancées est le même, mais seul ls travaille sur une liste, les autres commandes ne traitent qu'une seule entrée. Sur des répertoires avec de nombreux fichiers, la différence en temps d'exécution peut être significative.
[^] # Re: head ou tail ou grep
Posté par gaaaaaAab . En réponse au message find : fichiers des N derniers jours avant un fichier . Évalué à 2.
Ce n'est effectivement pas le même fichier de référence.
Pour une fois que je commentais mon code ;-)
[^] # Re: head ou tail ou grep
Posté par gaaaaaAab . En réponse au message find : fichiers des N derniers jours avant un fichier . Évalué à 2.
je vois deux façons de le faire directement dans find.
En excluant le fichier de référence :
ou en prenant l'avant-dernier fichier comme référence :
Personnellement, je préférerais la seconde forme, et je garderais plus qu'une seule sauvegarde complète s'il n'y a pas de problèmes d'espace disque.
# peut-être
Posté par gaaaaaAab . En réponse au message Probleme lie au driver son et wifi. Évalué à 2.
La réponse à ta question est probablement oui. Maintenant, il faudrait poser des "vraies" questions.
Dans un premier temps, je te recommande vivement la lecture de http://www.linux-france.org/article/these/smart-questions/smart-questions-fr.html
[^] # Re: Question ...
Posté par gaaaaaAab . En réponse au journal Un ransomware tout à fait déloyal ... et inquiétant. Évalué à 4.
Dans le journal :
Du coup, j'ai lu ça comme un clin d'oeil au nom du malware en question (fair -> juste/équitable/loyal)
[^] # Re: boucle de boucle
Posté par gaaaaaAab . En réponse au message Problème renommage fichiers avec des espaces.. Évalué à 3.
Bien vu la commande rename, j'avais oublié que ça existait :-)
Pour peaufiner, comme rename peut prendre une liste de fichiers à renommer, on peut combiner find avec xargs, ce qui permet de lancer une seule instance de rename au lieu de le lancer pour chaque résultat de find. Comme les fichiers contiennent éventuellement des espaces il faut alors utiliser l'option -print0 (resp. -0) de find (resp. xargs) pour remplacer l'espace par le caractère nul comme séparateur de champs en sortie (resp. en entrée)
On peut aussi rendre la regex de rename un peu plus précise en évitant de remplacer les pdfout en milieu de noms de fichier avec 's/pdfout$/pdf/'
Il faut aussi protéger l'utilisation du caractère * dans le -iname (en tout cas, chez moi, ça ne marche pas sinon)
au final, ça ferait
[^] # Re: Concetées
Posté par gaaaaaAab . En réponse au message Petits conseils d'installation. Évalué à 2.
Effectivement, la majorité des applications aurait peut-être du mal à remplir 8G de /tmp, mais ces 8Go représente aussi ta RAM. Du coup, si les applis qui tournent sont un peu gourmandes en RAM, tu n'as pas forcément autant d'espace dispo que ça pour ton /tmp. Tu n'es pas non plus à l'abri d'une appli qui déconne et qui blinde /tmp.
Par exemple, sur ma machine, il y a quelques années, en sortant d'une mise en sommeil, il arrivait que mon gestionnaire de fenêtre se mette à pondre des lignes de log en continu dans un fichier dans /tmp, jusqu'à saturation de la partition.
Dans l'absolu, à moins d'auditer dans le moindre détail l'intégralité des trucs qui tournent sur ta bécane, tu ne pourras jamais garantir à 100% que ton /tmp n'épuisera pas ta réserve de RAM. Du coup, il faut regarder ce qui se passe dans le pire des cas. Si tmp est sur le FS, tu blindes ton FS. A priori, c'est pas trop grave. Tu perds des logs, il y a p-e des applis qui se plantent un peu, mais le système d'exploitation continue à fonctionner. Par contre, si tu épuises ta RAM, si tu as du swap, ça va commencer à swapper (un bon coup dans les dents des performances), et à épuisement de RAM+swap, il y a des risques importants que le système crash.
Sur une machine perso, si tu as beaucoup de RAM et que tu veux réduire l'utilisation du SSD, monter /tmp en RAM peut-être une bonne idée. Si ça sature, un reboot et c'est réglé. Sur un serveur, il vaut probablement mieux monter /tmp sur un FS dédié.
[^] # Re: whereis
Posté par gaaaaaAab . En réponse au message pb d'accès fichier sous CRON. Évalué à 2.
La question n'est pas vraiment sur le répertoire dans lequel se trouve les différentes commandes, mais plutôt le répertoire de travail au moment ou elles sont lancées. En l'occurrence, les deux commandes étaient lancées par cron, donc dans le même répertoire de travail (le home de l'utilisateur pour lequel cron exécute ces commandes).
Si au lieu d'une redirection, les commandes python et mail prenait un nom de fichier comme paramètre, alors, oui, la question de savoir ou chaque commande pense que ce fichier se trouve serait très importante.
Ceci dit, si on a besoin d'accéder à un fichier particulier, ça peut être pertinent d'utiliser des chemins absolus dans le contexte de cron. J'attire toutefois ton attention sur le fait qu'en ayant ajouté un "." au début de tes chemins, tu en as fait des chemins relatifs plutôt que des chemins absolus. Du coup, tel que tu l'as écrit, c'est similaire à la solution initiale. Ta proposition souffre aussi du fait que si le répertoire local "tmp" n'existe pas, il n'est pas créé par la redirection ">" et du coup, les deux commandes échouent.
Bref, dans le détail et sur ce cas précis, ta proposition est incorrecte en l'état, mais dans l'absolu, c'est bien de se poser la question des emplacements de fichier (et plus généralement de l'environnement) quand on travaille avec cron.
[^] # Re: un seul script pour les gouverner tous
Posté par gaaaaaAab . En réponse au message pb d'accès fichier sous CRON. Évalué à 2.
Il y en a un de trop :-)
Sinon, pour revenir sur ton problème, je re-précise que je suspecte que ça venait de la différence de temps de traitement entre ton programme Python et la commande mail, mais il faudrait tester pour en être vraiment sûr. Ce n'est pas spécialement nécessaire de le faire, mais c'est important de garder en tête que ça reste une hypothèse non confirmée.
En prenant un peu de hauteur, même si ta solution initiale avait fonctionné, il restait un défaut fondamental: ton traitement est basé sur une séquence logique (la sortie d'une commande est l'entrée de la suivante), mais cron applique une séquence chronologique. Du coup, je ne vois pas vraiment de solution simple avec deux entrées dans cron qui garantirait la séquence logique de ton traitement. Bon, je ne sais pas si ça intéresse grand monde, mais, en y repensant, pour moi, c'est vraiment ça le coeur du problème de ta solution initiale.
Et, tant qu'on parle de cron, quelques petits ajouts en passant :
attention à l'environnement : cron transmet directement les commandes qu'on lui passe à un sh non interactif. Dans le contexte des commandes lancées par cron, les variables d'environnement définies dans les .profile, ou autres .bash_profile ne sont pas chargées. Quand on ne le sait pas, on peut perdre pas mal de temps avant de comprendre pourquoi une commande ne marche pas.
Relativement au commentaire de srayneau ci-dessous , le répertoire de travail d'une commande lancée par cron est le répertoire home de l'utilisateur en question.