Bash
Het snijcommando

De opdracht cut is een snelle manier om delen van regels tekstbestanden te extraheren. Het hoort bij de oudste Unix-opdrachten. De meest populaire implementaties zijn de GNU-versie gevonden op Linux en de FreeBSD-versie gevonden op MacOS, maar elke smaak van Unix heeft zijn eigen. Zie hieronder voor verschillen. De invoerregels worden gelezen uit stdin of uit bestanden die als argumenten op de opdrachtregel worden vermeld.

1. Syntaxisverschillen

Lange opties in de bovenstaande tabel worden alleen ondersteund door de GNU-versie.

2. Geen enkel personage krijgt een speciale behandeling

FreeBSD cut (die bijvoorbeeld wordt meegeleverd met MacOS) heeft niet de --complement schakelaar, en in het geval van colrm plaats daarvan de opdracht colrm gebruikt:

  $ cut --complement -c3-5 <<<"123456789"
  126789

  $ colrm 3 5 <<<"123456789"
  126789

Er is echter een groot verschil, omdat colrm TAB-tekens (ASCII 9) behandelt als echte tabellen tot het volgende veelvoud van acht, en backspaces (ASCII 8) als -1 breed; integendeel, cut behandelt alle tekens als één kolom breed.

  $ colrm  3 8 <<<$'12\tABCDEF' # Input string has an embedded TAB
  12ABCDEF

  $ cut --complement -c3-8 <<<$'12\tABCDEF'
  12F

3. (Nog steeds geen) Internationalisering

Toen cut werd ontworpen, waren alle personages één byte lang en was internationalisering geen probleem. Toen schrijfsystemen met bredere karakters populair werden, was de oplossing die POSIX gebruikte om tussen de oude -c switch te dumpen, die zijn betekenis zou moeten behouden om karakters te selecteren , ongeacht het aantal bytes breed, en om een nieuwe switch -b te introduceren die selecteer bytes, ongeacht de huidige tekencodering. In de meeste populaire implementaties werd -b geïntroduceerd en werkt, maar -c werkt nog steeds precies zoals -b en niet zoals zou moeten. Bijvoorbeeld met GNU cut :

^{Het lijkt erop dat het spamfilter van SE Engelse teksten met geïsoleerde kanji-tekens op een zwarte lijst plaatst. Ik kon deze beperking niet overwinnen, dus de volgende voorbeelden zijn minder expressief dan ze zouden kunnen zijn.}

  # In an encoding where each character in the input string is three bytes wide,
  # Selecting bytes 1-6 yields the first two characters (correct)
  $ LC_ALL=ja_JP.UTF-8 cut -b1-6 kanji.utf-8.txt
  ...first two characters of each line...
  

  # Selecting all three characters with the -c switch doesn’t work.
  # It behaves like -b, contrary to documentation.
  $ LC_ALL=ja_JP.UTF-8 cut -c1-3 kanji.utf-8.txt
  ...first character of each line...

  # In this case, an illegal UTF-8 string is produced.
  # The -n switch would prevent this, if implemented.
  $ LC_ALL=ja_JP.UTF-8 cut -n -c2 kanji.utf-8.txt
  ...second byte, which is an illegal UTF-8 sequence...

Als je personages buiten het ASCII-bereik vallen en je wilt cut , moet je altijd rekening houden met de tekenbreedte in je codering en dienovereenkomstig -b gebruiken. Als en wanneer -c begint te werken zoals gedocumenteerd, hoeft u uw scripts niet te wijzigen.

4. Snelheidsvergelijkingen

cut 's beperkingen hebben mensen twijfelen aan het nut ervan. In feite kan dezelfde functionaliteit worden bereikt door krachtigere, meer populaire hulpprogramma's. Het voordeel van cut is echter de prestaties . Zie hieronder voor enkele snelheidsvergelijkingen. test.txt heeft drie miljoen regels, elk met vijf door spaties gescheiden velden. Voor de awk test werd mawk gebruikt, omdat het sneller is dan GNU awk . De shell zelf (laatste regel) is verreweg de slechtste speler. De opgegeven (in seconden) tijden zijn wat de time commando geeft als real time.

^{(Om misverstanden te voorkomen: alle geteste commando's gaven dezelfde output met de gegeven input, maar ze zijn natuurlijk niet equivalent en zouden verschillende outputs in verschillende situaties geven, met name als de velden werden gescheiden door een variabel aantal spaties)}

5. Referentiële man-pagina's

• Opengroup
• GNU
• FreeBSD