Dlaczego podstawianie poleceń powłoki pożera znak nowej linii?

Zgodnie z poniższym przykładem i moim ostatnim pytaniem In bash, gdzie zniknął znak końca nowej linii? Chcę wiedzieć, dlaczego tak się dzieje

  x="$(echo -ne "a\nb\n")" ; echo -n "$x" | xxd -p 
# Output is: 610a62 
# The trailing newline from the 'echo' command
#   has been "deleted" by Command Substitution

Zakładam, że musi istnieć jakiś bardzo ważny powód akcji powłoki, mianowicie Zastąpienie polecenia, aby faktycznie usunąć niektóre dane z wyjściowego polecenia, które zastępuje ...
ale nie mogę się tym zająć, ponieważ wydaje się, że tak jest antyteza tego, co ma robić ... tj. przekazać wyjście polecenia z powrotem do procesu skryptu ... Wstrzymywanie jednego znaku wydaje mi się dziwne, ale przypuszczam, że jest rozsądny powód ... Chcę dowiedzieć się, co to za powód ... .

Ponieważ powłoka nie była pierwotnie zamierzana jako pełny język programowania.

Trudno jest usunąć znak końcowy \nz niektórych danych wyjściowych polecenia. Jednak do celów wyświetlania prawie wszystkie polecenia kończą swój wynik \n, więc… musi istnieć prosty sposób na usunięcie go, gdy chcesz go użyć w innym poleceniu. $()Wybrano automatyczne usuwanie z konstrukcją.

Może więc zaakceptujesz to pytanie jako odpowiedź:

Czy możesz znaleźć prosty sposób na usunięcie końcowego, \njeśli nie zostało to zrobione automatycznie w poniższym poleceniu?

> echo The current date is "$(date)", have a good day!

Należy pamiętać, że cytowanie jest wymagane, aby zapobiec rozbiciu podwójnych spacji, które mogą pojawić się w sformatowanych datach.

Jest to część standardu :

Powłoka powinna rozszerzyć podstawianie poleceń, wykonując polecenie w środowisku podpowłoki (patrz Środowisko wykonywania powłoki ) i zastępując podstawienie polecenia (tekst polecenia wraz z „$ ()” lub cudzysłowami) standardowym wyjściem polecenia, usuwając sekwencje jednego lub więcej <nowej linii> na końcu podstawienia.

Oczywiście norma jest prawdopodobnie napisana w ten sposób, ponieważ tak to kshzrobiło czy coś, ale jest to standard i jest to udokumentowane zachowanie. Jeśli ci się nie podoba, użyj Perla lub czegoś innego, co pozwoli ci zachować końcowe znaki nowej linii.

To ma dla mnie sens. Nowa linia jest tylko na pierwszym miejscu, w normalnym wyjściu polecenia, tak że monit pojawia się po zakończeniu polecenia w nowym wierszu. Nowa linia w większości przypadków nie jest częścią oryginalnego wyjścia, służy do uporządkowania ekranu. Podczas analizowania danych wyjściowych polecenia nowy wiersz na końcu jest zwykle kłopotliwy. Dlaczego wcpolecenie wyświetla 2 wiersze tekstu? Och, nie, wyprowadza jeden, po którym następuje nowa linia. Kiedy parsujesz wc, nie chcesz się martwić, że istnieją 2 linie wyjściowe - tak naprawdę nie ma, jest tylko jedna.

Napotkałem ten sam problem i znalazłem poniższy przykład. Wydaje się, że zacytowanie pomogło tej sytuacji, a przynajmniej zrobiło to dla mnie:

http://tldp.org/LDP/abs/html/commandsub.html .

dir_listing=`ls -l`
echo $dir_listing     # unquoted

# Expecting a nicely ordered directory listing.

# However, what you get is:
# total 3 -rw-rw-r-- 1 bozo bozo 30 May 13 17:15 1.txt -rw-rw-r-- 1 bozo
# bozo 51 May 15 20:57 t2.sh -rwxr-xr-x 1 bozo bozo 217 Mar 5 21:13 wi.sh

# The newlines disappeared.


echo "$dir_listing"   # quoted
# -rw-rw-r--    1 bozo       30 May 13 17:15 1.txt
# -rw-rw-r--    1 bozo       51 May 15 20:57 t2.sh
# -rwxr-xr-x    1 bozo      217 Mar  5 21:13 wi.sh

dlaczego echo "hello "(bez cudzysłowów) pożera przestrzeń? wartość znaków IFS jest postrzegana przez powłokę jako ograniczniki, dlatego końcowe znaki (które niczego nie ograniczają) są usuwane. podstawienie polecenia jest po prostu wykonaniem polecenia w podpowłoce, więc jest zgodne z tą samą logiką.