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

    Posté par . Évalué à 1.

    touch c'est pas mal non plus ...
    • [^] # Re: vider un fichier / créer un fichier vide

      Posté par . É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 . É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
  • # Pas mal!

    Posté par . É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 . Évalué à 1.

      Pour un équivalent exact de touch (sans risquer de détruire le fichier), on peut faire >> fichier
      • [^] # Re: Pas mal!

        Posté par (page perso) . É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 . É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 . Évalué à 1.

      >rm pwet | touch pwet

      Pourquoi utiliser un pipe ????

      plutot faire

      rm pwet;touch pwet
      • [^] # Re: Pas mal!

        Posté par . É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 . Évalué à 1.

          pkoi "à la LFS" ?
          • [^] # Re: Pas mal!

            Posté par . É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 . É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 . É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 . Évalué à 1.

      OK merci. Sinon pour le ksh d'AIX ça marche.
    • [^] # Re: pas portable sur tous les shells

      Posté par . Évalué à 1.

      De toutes façons, les shells C sux0rent, c'est bien connu :)
      • [^] # Re: pas portable sur tous les shells

        Posté par . Évalué à 1.

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

          Posté par (page perso) . É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 . É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 (page perso) . É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 . É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 (page perso) . Évalué à 1.

                et zsh consomme un volume de RAM absolument inacceptable pour chaque instance :) /me -> []
                • [^] # Re: Soit dit sans troller...

                  Posté par (page perso) . É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 . É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 (page perso) . Évalué à 1.

    ouais...
    echo -n "" > fichier
    (ok inutile si on a bash )
  • # Re: vider un fichier / créer un fichier vide

    Posté par (page perso) . É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 . É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 . É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 (page perso) . Évalué à 1.

    Sous zsh la syntax est:
    >! fichier
    sinon ca marche pas :(
    • [^] # Re: vider un fichier / créer un fichier vide

      Posté par . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.