Dlaczego $ „\ 0” jest tym samym co „”?

Typowym sposobem robienia rzeczy z kilkoma plikami jest - i nie uderzaj mnie za to:

for f in $(ls); do …

Teraz, aby zabezpieczyć się przed plikami ze spacjami lub innymi dziwnymi postaciami, naiwnym sposobem byłoby zrobienie:

find . -type f -print0 | while IFS= read -r -d '' file; …

Tutaj -d ''skrótem jest ustawienie ASCII NUL jak w -d $'\0'.

Ale dlaczego tak jest? Dlaczego są ''i $'\0'takie same? Czy to z powodu korzeni C Bash z pustym łańcuchem zawsze kończącym się na zero?

man page of bashBrzmi:

          -d delim
                 The first character of delim is  used  to  terminate  the
                 input line, rather than newline.

Ponieważ ciągi zwykle kończą się znakiem NULL, pierwszym znakiem pustego ciągu jest bajt NULL. - Dla mnie to ma sens. :)

Źródło brzmi:

static unsigned char delim;
[...]
    case 'd':
      delim = *list_optarg;
      break;

Bo pusty ciąg delimjest po prostu bajtem zerowym.

Istnieją dwa braki w bash, które wzajemnie się kompensują.

Kiedy piszesz $'\0', jest to traktowane wewnętrznie identycznie jak pusty ciąg. Na przykład:

$ a=$'\0'; echo ${#a}
0

To dlatego, że wewnętrznie bash sklepach wszystkie ciągi jako C ciągów, które są zakończony zerem - A znaki NUL koniec łańcucha. Bash po cichu obcina łańcuch do pierwszego bajtu zerowego (który nie jest częścią łańcucha!).

# a=$'foo\0bar'; echo "$a"; echo ${#a}
foo
3

Kiedy przekazujesz ciąg jako argument do -dopcji readwbudowanej, bash patrzy tylko na pierwszy bajt ciągu. Ale tak naprawdę nie sprawdza, czy ciąg nie jest pusty. Wewnętrznie pusty ciąg jest reprezentowany jako 1-elementowa tablica bajtów, która zawiera tylko bajt zerowy. Zamiast czytać pierwszy bajt łańcucha, bash czyta ten bajt zerowy.

Następnie wewnętrznie mechanizm readwbudowany działa dobrze z bajtami zerowymi; ciągle odczytuje bajt po bajcie, dopóki nie znajdzie separatora.

Inne pociski zachowują się inaczej. Na przykład ash i ksh ignorują bajty zerowe podczas odczytu danych wejściowych. Z ksh ksh -d ""czyta do nowej linii. Muszle są zaprojektowane tak, aby dobrze radziły sobie z tekstem, a nie z danymi binarnymi. Zsh jest wyjątkiem: używa reprezentacji łańcuchowej, która radzi sobie z dowolnymi bajtami, w tym bajtami zerowymi; w zsh $'\0'jest łańcuchem o długości 1 (ale read -d ''dziwnie zachowuje się jak read -d $'\0').