Bash
Polecenie cięcia

Polecenie cut to szybki sposób na wyodrębnienie części wierszy plików tekstowych. Należy do najstarszych poleceń Uniksa. Najbardziej popularnymi implementacjami są wersja GNU znaleziona w systemie Linux i FreeBSD w systemie MacOS, ale każdy smak Uniksa ma swój własny. Patrz różnice poniżej. Wiersze wejściowe są odczytywane ze stdin lub z plików wymienionych jako argumenty w wierszu poleceń.

1. Różnice w składni

Długie opcje w powyższej tabeli są obsługiwane tylko przez wersję GNU.

2. Żadna postać nie jest traktowana specjalnie

cut FreeBSD (na przykład w systemie MacOS) nie ma przełącznika --complement , aw przypadku zakresów znaków można zamiast tego colrm polecenia colrm :

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

  $ colrm 3 5 <<<"123456789"
  126789

Jest jednak duża różnica, ponieważ colrm traktuje znaki TAB (ASCII 9) jako rzeczywiste tabulacje do następnej wielokrotności ośmiu, a odstępy (ASCII 8) jako -1; przeciwnie, cut traktuje wszystkie znaki jako szerokość jednej kolumny.

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

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

3. (Nadal nie) internacjonalizacja

Kiedy zaprojektowano cut , wszystkie znaki miały długość jednego bajta, a internacjonalizacja nie stanowiła problemu. Kiedy pisanie systemów z szerszymi znakami stało się popularne, rozwiązaniem przyjętym przez POSIX było rozróżnienie między starym przełącznikiem -c , który powinien zachować znaczenie wybierania znaków, bez względu na liczbę bajtów, oraz wprowadzenie nowego przełącznika -b który powinien wybierz bajty, niezależnie od bieżącego kodowania znaków. W najbardziej popularnych implementacjach -b został wprowadzony i działa, ale -c nadal działa dokładnie tak jak -b a nie tak, jak powinien. Na przykład z cut GNU:

^{Wygląda na to, że filtr antyspamowy SE umieszcza na angielskich tekstach pojedyncze znaki kanji. Nie mogłem przezwyciężyć tego ograniczenia, więc poniższe przykłady są mniej wyraziste niż mogłyby być.}

  # 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...

Jeśli twoje postacie są poza zakresem ASCII i chcesz użyć cut , zawsze powinieneś być świadomy szerokości znaków w swoim kodowaniu i stosuj odpowiednio -b . Jeśli i kiedy -c zacznie działać zgodnie z dokumentacją, nie będziesz musiał zmieniać swoich skryptów.

4. Porównania prędkości

Ograniczenia cut powodują, że ludzie wątpią w ich przydatność. W rzeczywistości tę samą funkcjonalność można uzyskać dzięki bardziej wydajnym i popularnym narzędziom. Zaletą cut jest jednak jego wydajność . Zobacz poniżej porównania prędkości. test.txt ma trzy miliony linii, z których każda zawiera pięć pól oddzielonych spacjami. Do testu awk użyto mawk , ponieważ jest on szybszy niż GNU awk . Sama powłoka (ostatnia linia) jest zdecydowanie najgorzej wydajna. Podane czasy (w sekundach) są tym, co polecenie time podaje jako czas rzeczywisty .

^{(Aby uniknąć nieporozumień: wszystkie testowane polecenia dały taki sam wynik przy podanym wejściu, ale oczywiście nie są one równoważne i dawałyby różne wyniki w różnych sytuacjach, w szczególności jeśli pola byłyby rozdzielone zmienną liczbą spacji)}

5. Referencyjne strony podręcznika man

• Opengroup
• GNU ANTYLOPA
• FreeBSD