Forum Astuces.divers [Terminal] vider un fichier / créer un fichier vide

• # vider un fichier / créer un fichier vide

  Posté par Pierre Habouzit le 23 février 2002 à 22:58. Évalué à 1.

  

  touch c'est pas mal non plus ...

  • [^] # Re: vider un fichier / créer un fichier vide

    Posté par togno le 06 mars 2002 à 18:37. Évalué à 1.

    

    pour le créer oui, pour le vider non. Et puis c'est encore plus rapide que touch. Enfin je trouve

    • [^] # Re: vider un fichier / créer un fichier vide

      Posté par samds le 05 octobre 2003 à 16:04. Évalué à 1.

      

      [2003-10-05 @ 16:03:47][sam@skikda][~] time `> touch`
      
      real 0m0.001s
      user 0m0.000s
      sys 0m0.000s
      [2003-10-05 @ 16:03:52][sam@skikda][~] rm touch
      rm: détruire fichier régulier vide `touch'? y
      détruit `touch'
      [2003-10-05 @ 16:03:55][sam@skikda][~] time `touch touch`
      
      real 0m0.025s
      user 0m0.000s
      sys 0m0.000s
      [2003-10-05 @ 16:03:58][sam@skikda][~]
      
      
      :-)
      sam

      • [^] # Re: vider un fichier / créer un fichier vide

        Posté par Anonyme le 23 février 2004 à 09:16. Évalué à 1.

        

        Normal que 'touch' mette plus de temps que '>'
        car lors que l'on lance touch, il y a création d'un processus,
        pas pour > ou c'est le shell (déjà lancé) qui fait le boulot.

      • [^] # Re: vider un fichier / créer un fichier vide

        Posté par gnujsa le 14 mai 2004 à 05:16. Évalué à 1.

        

        $ time perl -e '`touch toto`;'
        
        real 0m0.009s
        user 0m0.000s
        sys 0m0.000s
        
        $ time perl -e '`> toto`;'
        
        real 0m0.025s
        user 0m0.020s
        sys 0m0.010s
        
        héhé ;-)

• # Pas mal!

  Posté par ced le 10 juillet 2002 à 10:43. Évalué à 2.

  

  Ouep pas mal je connaissais pas :)
  
  A utiliser avec modération qd meme ca pourrait etre dangereux (style qd on veut créer un fichier et qu'il existe déja..).
  
  Je pense que je vais rester à touch pour créer des fichiers vides :) Mais je note qd meme
  >pwet
  c vrai que c plus rapide que
  rm pwet | touch pwet

  • [^] # Re: Pas mal!

    Posté par calo le 28 octobre 2002 à 12:56. Évalué à 1.

    

    Pour un équivalent exact de touch (sans risquer de détruire le fichier), on peut faire >> fichier

    • [^] # Re: Pas mal!

      Posté par Anonyme le 04 novembre 2002 à 15:38. Évalué à 1.

      

      Oui mais là on ne vide plus le fichier...
      
      
      Le problème vient de Cédric qui dit qu'il faut utiliser l'astuce « avec modération qd meme ca pourrait etre dangereux (style qd on veut créer un fichier et qu'il existe déja..). » : si le fichier existe déjà, on le vide, c'est l'objet de l'astuce.

    • [^] # Re: Pas mal!

      Posté par matiasf le 24 février 2003 à 02:19. Évalué à 1.

      

      Non, touch change la date de dernière modification du fichier alors qu'il ne modifie pas le fichier (s'il existe).
      Si tu fait >> fichier, ça ne change pas le fichier, donc ni la date de dernière modification.

  • [^] # Re: Pas mal!

    Posté par Cédric Foll le 06 janvier 2003 à 16:46. Évalué à 1.

    

    >rm pwet | touch pwet
    
    Pourquoi utiliser un pipe ????
    
    plutot faire
    
    rm pwet;touch pwet

    • [^] # Re: Pas mal!

      Posté par Gyro Gearllose le 10 mars 2003 à 16:40. Évalué à 1.

      

      ou encore, à la LFS :
      rm pwet && touch pwet
      Au moins, si le rm échoue, la 2nde commande n'est pas exécutée.

      • [^] # Re: Pas mal!

        Posté par Nap le 23 mai 2003 à 09:49. Évalué à 1.

        

        pkoi "à la LFS" ?

        • [^] # Re: Pas mal!

          Posté par Gyro Gearllose le 27 mai 2003 à 12:33. Évalué à 1.

          

          Parce que....
          
          Plus sérieusement, c'est en installant pour la première fois un LFS que j'ai découvert cette façon d'enchaîner les commandes, et que c'est utilisé à outrance dans le LFS. C'est un peu plus long (ben oui, deux "&" contre un ";" ;-)) que d'enchainer les commandes en les séparant par un ";", mais au moins, ça évite de lancer un make suite à un ./configure qui a foiré !

  • [^] # Re: Pas mal!

    Posté par dido le 09 juillet 2003 à 13:43. Évalué à 1.

    

    
    >pwet
    c vrai que c plus rapide que
    rm pwet | touch pwet
    
    Cela ne donne cependant pas toujours le même résultat.
    Imagines que ton fichier pwet fasse 1go et qu'il soit toujours ouvert par un processus.
    

    • : > pwet te libère l'éspace utlisé contrairement au rm+touch
    • les droits/propriètaires du fichier ne sont pas modifiés par le >

• # pas portable sur tous les shells

  Posté par quad le 24 juillet 2002 à 10:08. Évalué à 2.

  

  
  > fichier
  
  Avec un csh, tcsh (d'autres ?) te renvoie un "Invalid null comand."
  
  Y'a pas que bash dans la vie :-)
  
  Allez, je vais pas rester sur une phrase à fort potentiel trollesque,
  donc je fournis une solution :
  
  :> fichier
  
  Y'a un caractère de plus, c'est le seul inconvénient.

  • [^] # Re: pas portable sur tous les shells

    Posté par togno le 24 octobre 2002 à 22:09. Évalué à 1.

    

    OK merci. Sinon pour le ksh d'AIX ça marche.

  • [^] # Re: pas portable sur tous les shells

    Posté par Gruik Man le 28 novembre 2002 à 18:15. Évalué à 1.

    

    De toutes façons, les shells C sux0rent, c'est bien connu :)

    • [^] # Re: pas portable sur tous les shells

      Posté par Ptah le 10 décembre 2002 à 09:48. Évalué à 1.

      

      http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/(...)

      • [^] # Re: pas portable sur tous les shells

        Posté par Mathieu Pillard (site web personnel) le 20 décembre 2002 à 14:33. Évalué à 1.

        

        c'est bien de resortir le lien, encore faut il le comprendre... sur la partie shell interactif, qui est quand meme un gros morceau, tcsh a rien a envier a bash...

        • [^] # Soit dit sans troller...

          Posté par Salagnac le 24 avril 2003 à 15:15. Évalué à 1.

          

          Oui mais meme dans un shell interactif on a bien souvent envie de taper un petit script de rien du tout (genre un for nom in `ls` etc) et c'est penible si le shell ne permet pas de faire ca. (c'est pour ca que je suis passé de tcsh a bash, malgré certaines pertes (correction des fotes d'orthographe, etc) (pas de troll svp, je sais bien que je pourrais le faire meme avec bash si je prenais la peine de lire les pages man)

          • [^] # Re: Soit dit sans troller...

            Posté par Mathieu Pillard (site web personnel) le 31 mai 2003 à 22:59. Évalué à 1.

            

            bah tcsh permet de faire des choses sympa avec foreach... donc bon ... j'attends toujours un vrai argument anti tcsh pour la partie interactive. il est certain que pour le cote scripting only, sh est plus portable tout ca. mais pour le cote interactif, bof.

          • [^] # Re: Soit dit sans troller...

            Posté par Simon Huet le 08 juin 2003 à 07:47. Évalué à 1.

            

            zsh te permet tout ce que bash permet avec en plus une meilleure autocomplétion et aussi la correction de fautes d'orthographe...

            • [^] # Re: Soit dit sans troller...

              Posté par Benjamin (site web personnel) le 26 juin 2003 à 09:22. Évalué à 1.

              

              et zsh consomme un volume de RAM absolument inacceptable pour chaque instance :) /me -> []

              • [^] # Re: Soit dit sans troller...

                Posté par Bapt (site web personnel) le 07 juillet 2003 à 14:15. Évalué à 1.

                

                Ce n'est pas forcément si flagrant que ça, et étant donné le nombre de fonctionnalité de ZSH (par rapport à bash entre autre) ça ne m'étonne pas :
                il gère tout bash ou presque (y compris un compatibilité bash-completion dans les version 4.1.X ou supérieur), les fonctions ksh et [t]csh.
                il apporte une telle souplesse, et une telle maniabilité, qu'il permet de ce passer dans beaucoup de cas d'interface graphique, et donc de gagner de la mémoire :)
                
                si je fait u petit calcul rapide :
                la mémoire prise par zsh légèrement supérieur à bash
                la mémoire économisée par l'utilisation de zsh = très important
                =>mem(zsh)<mem(bash)+mem(application)
                je parle pour faire les mêmes choses :)

          • [^] # Re: Soit dit sans troller...

            Posté par wismerhill le 05 août 2003 à 18:30. Évalué à 1.

            

            (genre un for nom in `ls` etc)
            Fais plutôt un for nom in *, ça t'évitera de lancer un ls inutilement et ça fait trois caractères de moins à écrire.

• # Re: vider un fichier / créer un fichier vide

  Posté par Pooly (site web personnel) le 06 décembre 2002 à 13:39. Évalué à 1.

  

  ouais...
  echo -n "" > fichier
  (ok inutile si on a bash )

  • [^] # Re: vider un fichier / créer un fichier vide

    Posté par Pierre Tramo le 15 décembre 2002 à 00:49. Évalué à 1.

    

    Pourquoi s'embêter ?
    echo > fichier

    • [^] # Re: vider un fichier / créer un fichier vide

      Posté par matiasf le 24 février 2003 à 02:21. Évalué à 1.

      

      marche pas, ça crée un fichier avec un caractère ('\n').
      il faut :
      echo -n > fichier

• # Re: vider un fichier / créer un fichier vide

  Posté par Whoo (site web personnel) le 07 décembre 2002 à 09:50. Évalué à 1.

  

  Bonjour,
  
  Moi je préfere un :
  cat /dev/null > mon fichier
  Qui permet de vider un fichier en cours d'utilisation.
  
  @+ Whoo

  linux / linux / linux

  • [^] # Re: vider un fichier / créer un fichier vide

    Posté par togno le 07 décembre 2002 à 11:41. Évalué à 1.

    

    Salut,
    
    toujours sous bash, j'ai essayé un simple :
    > monfichier
    alors que je remplissait "monfichier" avec un autre programme. Ca a bien vidé le fichier, alors qu'il était en cours d'utilisation.

  • [^] # Re: vider un fichier / créer un fichier vide

    Posté par matiasf le 24 février 2003 à 02:49. Évalué à 2.

    

    Si le fichier est en cours d'utilisation (utiliser /usr/sbin/lsof pour confirmer), ça ne marche car il y a deux descripteurs de fichier ouverts sur le même fichier. C'est le dernier qui ferme le fichier qui défini la taille.
    Exemple :
    $ free -s 1 > toto &
    [1] 17839
    [ attendons un peu]
    $ > toto
    $ cat /dev/null > toto ; ll toto ; sleep 2 ; ll toto
    -rw-r--r-- 1 f.matias users 0 fév 24 02:38 toto
    -rw-r--r-- 1 f.matias users 72996 fév 24 02:38 toto
    
    La première taille à 0 de toto c'est car le jobs %1 n'a pas encore écrit depuis la fermeture du fichier par "> toto".
    C'est même une caratéristique appréciée d'unix. Imaginons le "drame" si le process qui écrit en continu fait un seek ! Ça nous priverait aussi de la possibilité d'écriture pas plusieurs process dans un fichier.
    
    Cette caractéristique, n'est pas lié au shell mais au noyau.

    • [^] # Re: vider un fichier / créer un fichier vide

      Posté par Linux_GTI le 06 mars 2003 à 21:04. Évalué à 6.

      

      C'est aussi pour ça que lors d'un logrotate, apache reçoit un SIGHUP pour fermer et ouvrir les fichiers de log.

    • [^] # Re: vider un fichier / créer un fichier vide

      Posté par zarkod le 27 août 2003 à 16:33. Évalué à 1.

      

      y a t'il moyen de forcer l'utilisation du même descripteur de fichier pour vider le contenu du fichier en cours de remplissage par une autre application?

• # Re: vider un fichier / créer un fichier vide

  Posté par shelton2 (site web personnel) le 09 septembre 2003 à 23:54. Évalué à 1.

  

  Sous zsh la syntax est:
  >! fichier
  sinon ca marche pas :(

  • [^] # Re: vider un fichier / créer un fichier vide

    Posté par marvin le 25 septembre 2003 à 21:14. Évalué à 1.

    

    Yep, mais du coup, ça devient assez difficile d'écraser un fichier par erreur, donc --> :)
    
    On peut néamoins désactiver cette fonction en rajoutant dans son "~/.zhrc" :
    setopt clobber

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.