Contenu | Rechercher | Menus

Annonce

Si vous rencontrez des soucis à rester connecté sur le forum (ou si vous avez perdu votre mot de passe) déconnectez-vous et reconnectez-vous depuis cette page, en cochant la case "Me connecter automatiquement lors de mes prochaines visites".
Test de l'ISO d'Ubuntu francophone : nous avons besoin de testeurs pour la version francophone d'Ubuntu 14.04. Liens et informations ici.
nombre réponses : 25

#0 Re : -1 »  Script pour activer WiFi » Hier à 01:18

Postmortem
Réponses : 7

Salut,

morane a écrit :
sudo ./home/port/Bureau/demarrer-WiFi v2.sh
sudo: ./home/guillaumeport/Bureau/demarrer-WiFi: command not found

Il faudrait plutôt le lancer ainsi :

sudo "/home/port/Bureau/demarrer-WiFi v2.sh"

Pas de point devant /home, sinon le shell va chercher ton script dans un dossier home qui se trouverait dans le répertoire où tu es avant de lancer la commande. Il faut utiliser des guillemets étant donné que le nom de ton script contient une espace.

#1 Re : -1 »  [Résolu] Bash: while imbriquées. C'est où que ça coince? » Hier à 01:04

Postmortem
Réponses : 14

Salut,
Me permet une petite précision concernant une des 1ère ligne du script posté en 1er :

while [ -z $nouveau ] || [ $nouveau != '0' ]

Au 1er passage, le test [ -z $nouveau ] est vrai non pas parce que $nouveau est nul ou non déclaré mais parce que la chaîne "-z" n'est pas de longueur nulle.
En effet, si $nouveau est nulle, le test effectué est [ -z ], ce qui correspond à ce test : [ -n "-z" ].
Entre simple crochets, il faut mettre les variables entre guillemets. Par contre, entre double crochets, les guillemets autour des variables ne sont pas nécessaires (mais rien n'empêche de les mettre ! )
Il faut donc écrire :

[ -z "$nouveau" ]
# ou
[[ -z $nouveau ]]
# ou
[[ -z "$nouveau" ]]

#2 Re : -1 »  Programmation cron-crontab / capture planifiée d'un streaming » Le 20/07/2014, à 09:35

Postmortem
Réponses : 21

Salut,
"kill -TERM" est moins bourrin. Si le programme qui recoit le signal a prévu la capture du signal TERM, il peut faire certaines actions (nettoyer des fichiers temporaires par exemple) avant de quitter. Le programme peut même ignorer ce signal.
"kill -KILL", c'est tuer le programme dès réception de ce signal ; on ne peut capturer ou ignorer ce signal.

#4 Re : -1 »  Programmation cron-crontab / capture planifiée d'un streaming » Le 20/07/2014, à 13:37

Postmortem
Réponses : 21

Ton script commence par "#!/bin/bash" alors que dans cron, tu l'appelles par "/bin/sh /home/Nom_d_utilisateur/.local/share/nautilus/scripts/webradio.sh". C'est donc sh qui exécute ton script et non bash.
Dans cron, il faut l'appeler ainsi :

0 23 * * 1-7 /home/Nom_d_utilisateur/.local/share/nautilus/scripts/webradio.sh >> /home/Nom_d_utilisateur/Documents/cronerr.txt 2>&1

Il faut d'abord le rendre exécutable par la commande :

chmod +x /home/Nom_d_utilisateur/.local/share/nautilus/scripts/webradio.sh

#5 Re : -1 »  Programmation cron-crontab / capture planifiée d'un streaming » Le 21/07/2014, à 10:19

Postmortem
Réponses : 21

Salut,
Petite précision concernant cette remarque :

arcane17 a écrit :

Problème que j'avais déjà rencontré. Les instructions dans Crontab ne s'exécutent pas si elles ne sont pas précédées de DISPLAY=:0

Les instructions s'exécutent même si on ne met pas "DISPLAY=:0".
La variable DISPLAY sert à indiquer où doit s'afficher un objet graphique ; dans ton cas, DISPLAY est utile pour la commande "/usr/bin/xterm -e ..." mais pas pour les autres (à moins que le script webradio.sh doive afficher quelque chose à l'écran)

#6 Re : -1 »  script avec mv : simplification ? » Le 30/07/2014, à 16:30

Postmortem
Réponses : 6

Salut,
Quel est l'intérêt de la boucle for alors que tu n'utilises pas la variable fichier après ?
Et concernant cette boucle, ceci :

for fichier in *

Est bien mieux que :

for fichier in `ls *`

Le "ls" ne va faire que t'apporter des soucis.
Une proposition vite fait en bash, en bouclant sur les chiffres et lettres plutôt que sur les fichiers :

shopt -s nocaseglob
for i in {A..Z} {0..9}
do
   mv "$i"* "$i"/
done

Par contre, ça fera des erreurs s'il n'y a pas de fichiers commençant par tous les chiffres/lettres.

Édit : correction d'une erreur de syntaxe.

#7 Re : -1 »  [Résolu]Supprimer toutes ligne précédant la ligne contenant une chaine » Le 31/07/2014, à 23:40

Postmortem
Réponses : 12

Salut,

awk 'i;/#003#/{i=1}' fichier

Par contre, j'ai pas testé, j'ai pas awk sur mon tel.

#8 Re : -1 »  [Résolu]Supprimer toutes ligne précédant la ligne contenant une chaine » Le 01/08/2014, à 09:03

Postmortem
Réponses : 12
φlip a écrit :
Tomzz a écrit :

Mon fichier est classé par les champs #00n# il ne peut pas y avoir de doublons mais il peut y avoir des trous dans la numérotation.

C'est plutôt le fait qu'il peut y avoir des trous dans la numérotation qui m'a échappé.

Et donc que le champ au début de la ligne numéro n n'est pas forcément #00n# !! tongue

#9 Re : -1 »  [Résolu]Supprimer toutes ligne précédant la ligne contenant une chaine » Le 01/08/2014, à 11:09

Postmortem
Réponses : 12

La commande awk suivante :

awk 'i;/#003#/{i=1}' fichier

Est équivalente à ceci mais qui est plus compréhensible :

awk ' i != 0 {print $0}
      $0 ~ /#003#/ { i=1 }' fichier

On affiche la ligne que si i est différent de 0.
i prend la valeur 1 quand on rencontre #003# dans la ligne.
Le fait de mettre la partie affichage avant la partie qui change la valeur de i fait que la 1ère ligne contenant la valeur recherchée n'est pas affichée.
Si on veut que la ligne contenant la valeur recherchée soit affichée, il suffit d'inverser :

awk '/#003#/{i=1};i' fichier

On aurait très bien pu mettre i=2, i=3 ou n'importe quel nombre différent de 0.

Édit :
Concernant la rapidité, awk est une flèche... Après tout dépend de ce qu'on met dedans... Tout comme dans sed !
Les 2 sont faits pour traiter des fichiers textes donc à toi de voir et de tester.
L'avantage de awk, c'est que tu peux travailler plus facilement sur des champs, ce qui est le cas d'un fichier csv.

#10 Re : -1 »  [Résolu] Filtrer des blocs de texte délimités. » Le 30/07/2014, à 16:44

Postmortem
Réponses : 3

Salut,
Avec awk, on peut choisir la ligne vide comme délimiteur d'enregistrement :

awk 'BEGIN{RS=""; FS="\n"} /rule=1/' fichier

Par contre, j'ai pas testé !

#11 Re : -1 »  Probléme de Sudo » Le 29/07/2014, à 15:25

Postmortem
Réponses : 10

Salut,

Sibe a écrit :

Il faut donc avec le droit admin (sudo) remettre les bons droits a ce fichier ...

Sauf que comme le disent tiramiseb et pingouinux, sudo ne fonctionne plus car sudoers n'a pas les bons droits. Tu ne peux donc remettre les droits grâce à sudo.
Il me semble qu'il faut démarrer en mode recovery ou avec un live cd et ensuite aller modifier les droits du fichier.

#12 Re : -1 »  Suppression de TOUS fichiers dans un dossier » Le 18/07/2014, à 18:27

Postmortem
Réponses : 11

Salut,
Pour TOUT effacer dans /home/iccorail/Impressions sans supprimer Impressions lui-même (en bash) :

shopt -s dotglob
rm -rf /home/iccorail/Impressions/*

Si on ne met pas le shopt -s dotglob, * ne prend pas en compte les fichiers/dossiers cachés (qui commencent par ".")

#13 Re : -1 »  Syntaxe de la commande find [RESOLU] » Le 21/07/2014, à 11:33

Postmortem
Réponses : 19

Salut,
Le souci vient du fait que la date de modification d'un répertoire ne change qui si on créé ou supprime quelque chose dedans. Si on modifie un fichier déjà existant dans ce répertoire, la date ne change pas.
Du moins, ceci est valable pour la date de modification que l'on recherche avec l'option -mtime de find.
Avec -ctime, on fait une recherche sur la date de dernier changement de statut ; perso, je n'utilise jamais ça.
Il faudrait donc que tu recherches les fichiers non modifiés depuis plus de 31 jours pour les supprimer et ensuite, supprimer les répertoires vides.

#14 Re : -1 »  Syntaxe de la commande find [RESOLU] » Le 21/07/2014, à 12:56

Postmortem
Réponses : 19

"find: -exec CMD must end by ';'" veut dire que la commande après "-exec" doit se terminer par un ";".
Le ";" étant un caractère spécial du shell, le shell interprète ce caractère qui veut dire fin d'une commande. Ainsi le shell détecte la fin du find et exécute la commande find sans le ";".
Il faut donc écrire "\;", ainsi le shell n'interprete pas spécialement le ";" et le transmet à find (sans le "\" qui est devant). Et donc, "-exec" voit bien un ";" qui marque la fin de la commande.
Les "{}" sont remplacées par le nom de fichier/dossier trouvé par find, il faut bien les mettre.
Ta commande doit donc ressembler à quelque chose de ce goût :

find /repertoire/de/départ -depth -type d -mtime +31 -exec rm -rf {} \;

Édit :

Mophete a écrit :

il n'y a que des répertoires non vides...

la commande indiquée plus haut ne génère aucune erreur, mais un

find -type d -mtime +31

juste après un retour au prompt me ressort des résultats, qui auraient donc dus être effacés préalablement...

C'est normal, "-mtime +31" veut dire ce qui est modifié il y a plus de 31 fois 24h. La commande lancée à qq minutes d'intervalles sort donc de nouveaux fichiers.

#15 Re : -1 »  Syntaxe de la commande find [RESOLU] » Le 21/07/2014, à 13:04

Postmortem
Réponses : 19

@pingouinux :
Je n'ai pas essayé mais je ne suis pas certain que cela fonctionne avec "-delete". En effet, lorsque tu supprimes un fichier, tu changes la date de modif du répertoire le contenant et donc, le répertoire n'apparaît plus comme modifié il y a plus de 31 jours. Rere-édit : en fait, cette remarque était valable si tu n'avais pas mis le "-type d" et que tu supprimais des fichiers avant le répertoire.

Édit : et du coup, en y repensant, ma solution ne supprimera que les dossiers se trouvant "au fond" d'une arborescence.

Re-édit :
En fait, il semble surtout que -delete ne supprime que des dossiers vides.

#16 Re : -1 »  Syntaxe de la commande find [RESOLU] » Le 21/07/2014, à 14:22

Postmortem
Réponses : 19
pingouinux a écrit :

La commande de Postmortem (#10), et la mienne (#14) devraient faire ce que tu veux. La différence est que la sienne supprime aussi les nouveaux fichiers dans les vieux répertoires.

Ah oui, t'as raison !
Si un fichier est modifié ce jour dans un répertoire où il n'y a pas eu de création/suppression depuis + de 31 jours, il disparaît avec le répertoire si on utilise ma solution.

#17 Re : -1 »  condition dans un shell » Le 18/07/2014, à 20:58

Postmortem
Réponses : 5

Salut,
Il manque des espaces :

if [ $post -gt 0 ]

#18 Re : -1 »  Comprendre les pages "man" svp ? » Le 15/07/2014, à 00:45

Postmortem
Réponses : 10

Les commandes GNU ont aussi une doc plus complète que le man que l'on peut accéder par la commande "info" ; par exemple :

info sed

#19 Re : -1 »  fonctionnement de * et detournement commandes » Le 13/07/2014, à 12:45

Postmortem
Réponses : 23

Beaucoup de commande GNU acceptent l'option -- qui marque la fin des options. Du coup, en faisant comme ça, on évite le souci, -rf sera bien vu comme un fichier :

rm -- *

#20 Re : -1 »  fonctionnement de * et detournement commandes » Le 13/07/2014, à 22:50

Postmortem
Réponses : 23
Brunod a écrit :

Il faudrait une solution qui intègre cette sécurité par défaut, pour ne pas devoir vérifier le contenu d'un répertoire avant d'exécuter une commande.

Je ne vois pas comment cette sécurité pourrait être par défaut. Comment rm, ou n'importe quelle autre commande, pourrait décider quand -rf est un fichier ou quand c'est une option ?
Je pense que -- a justement été créé pour ça.

#21 Re : -1 »  fonctionnement de * et detournement commandes » Le 14/07/2014, à 16:58

Postmortem
Réponses : 23

Je ne comprends pas ton raisonnement Brunod. "--" est justement là pour marquer la fin des options et donc éviter qu'un fichier ou tout autre argument soit pris pour une option. C'est exactement ce qu'il faut utiliser pour éviter les problèmes décrits dans les articles ci-dessus.
Si on ne maîtrise pas les noms de fichiers sur lesquels on intervient, il suffit de prendre l'habitude de l'utiliser. Et d'ailleurs, au vu des exemples donnés, je vais l'utiliser plus souvent !

#22 Re : -1 »  fonctionnement de * et detournement commandes » Le 14/07/2014, à 17:16

Postmortem
Réponses : 23

J'ai pas essayé mais si on fait un tel alias, on ne pourra pas utiliser d'options ou si ?

#23 Re : -1 »  fonctionnement de * et detournement commandes » Le 14/07/2014, à 18:44

Postmortem
Réponses : 23

Moi je ne vois pas pourquoi on empêcherait l'utilisateur de mettre - au début d'un nom de fichier.
Je pense que c'est au programme de bien gérer ça, au même titre qu'un programme ne doit pas être gêner par des noms de fichier contenant espace ou n'importe quoi.

#24 Re : -1 »  [Résolu] Générer une suite de x lettres » Le 13/07/2014, à 12:46

Postmortem
Réponses : 6

C'est pas mal aussi, merci pingouinux.