Bash (i inne powłoki uniksowe), 32 (33) bajty
Pierwsza i druga próba:
case `echo|od` in *5*)echo B;;*)echo L;;esac # portable
[[ `echo|od` =~ 5 ]]&&echo B||echo L # non-portable
Dzięki Dennisowi, krótsza wersja:
od<<<a|grep -q 5&&echo L||echo B # non-portable
echo|od|grep -q 5&&echo B||echo L # portable
echoNarzędzie wysyła do nowej linii, o wartości sześciokątnym 0A, a nie innym wyjściu. Bo <<<atak jest 61 0A.
odNarzędzie domyślnie interpretuje jako wejście dwubajtowych słów, zero-wyściełane, jeśli liczba jest nieparzysta liczba bajtów i konwertuje do ósemkowym. Powoduje to, że wyjście echa jest interpretowane jako 0A 00, które jest konwertowane na 005000postać big-endian lub 000012little-endian. 61 0Astaje się 005141w little-endian i 060412big-endian. Pełne wyjście OD także adres i rozmiar danych co oznacza, że nie można używać 0, 1lub 2do testu.
Polecenie jest dobrze zdefiniowane, aby ujawnić endianizm systemu. Od standardu :
Kolejność bajtów używana podczas interpretacji wartości liczbowych jest zdefiniowana w implementacji, ale powinna odpowiadać kolejności, w jakiej stała odpowiedniego typu jest przechowywana w pamięci w systemie.
Uwagi dotyczące zgodności
Nie jestem pewien, czy wstawianie echo|odcudzysłowów bez podwójnych cudzysłowów wokół nich [co skutkuje trzema słowami do case] jest obsługiwane we wszystkich systemach. Nie jestem pewien, czy wszystkie systemy obsługują skrypty powłoki bez kończącego znaku nowej linii. Jestem w większości pewien, ale nie 100% zachowania OD po dodaniu bajtu wypełniającego w systemach big-endian. W razie potrzeby echo amożna go użyć w wersjach przenośnych. Wszystkie skrypty działają w bash, ksh i zsh, a te przenośne działają w desce rozdzielczej.