Perché shell Command Substitution assorbe un carattere newline finale?

Come nel seguente esempio, e come nella mia recente domanda In bash, dove è finito il carattere newline finale? , Voglio sapere "perché" succede

  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

Presumo che ci debba essere una ragione molto significativa per un'azione shell, vale a dire la sostituzione dei comandi, per eliminare effettivamente alcuni dati dall'output del comando che sta sostituendo ...
ma non riesco a capire come funziona, come sembra l'antitesi di ciò che dovrebbe fare .. cioè. restituire l'output di un comando al processo di script ... Trattenere un personaggio mi sembra strano, ma suppongo che ci sia una ragione ragionevole per farlo ... Sono curioso di scoprire qual è quella ragione ... .

Perché la shell non era originariamente concepita per essere un linguaggio di programmazione completo.

È abbastanza difficile rimuovere un finale \ndall'output di un comando. Tuttavia, a scopi di visualizzazione, quasi tutti i comandi terminano il loro output con \n, quindi ... ci deve essere un modo semplice per rimuoverlo quando si desidera utilizzarlo in un altro comando. La rimozione scelta con la $()costruzione è stata la soluzione scelta.

Quindi, forse accetterai questa domanda come risposta:

Riesci a trovare un modo semplice per rimuovere il trailing \nse questo non è stato fatto automaticamente nel seguente comando?

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

Si noti che è necessario un preventivo per evitare la distruzione di doppi spazi che possono apparire in date formattate.

Fa parte dello standard :

La shell espande la sostituzione del comando eseguendo il comando in un ambiente subshell (consultare Shell Execution Environment ) e sostituendo la sostituzione del comando (il testo del comando più il "$ ()" o backquotes racchiuso) con l'output standard del comando, rimuovendo sequenze di una o più <newline> s alla fine della sostituzione.

Ovviamente, lo standard è probabilmente scritto in questo modo perché è così ksho qualcosa del genere, ma è lo standard ed è un comportamento documentato. Se non ti piace, usa Perl o qualcos'altro che ti consentirà di mantenere le nuove righe finali.

Beh, ha senso per me. La nuova riga è presente solo in primo luogo, nell'output del comando normale, in modo che il prompt appaia dopo il completamento del comando su una nuova riga. La nuova riga non fa parte dell'output originale nella maggior parte dei casi, è lì per riordinare lo schermo. Quando analizzi l'output di un comando, la nuova riga alla fine è di solito problematica. Perché il wccomando genera 2 righe di testo? Oh, non lo fa, ne esce uno seguito da una nuova riga. Quando analizzi wcnon vuoi preoccuparti del fatto che ci sono 2 linee di output - non ce ne sono davvero, ce n'è solo una.

Stavo riscontrando lo stesso problema e ho trovato l'esempio seguente. Sembra che la citazione abbia aiutato la situazione, almeno per me:

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

perché echo "hello "(senza virgolette) inghiotte lo spazio? il valore dei caratteri IFS è visto dalla shell come delimitatore, per cui quelli finali (che non delimitano nulla) vengono rimossi. la sostituzione di encomi è semplicemente eseguendo gli encomi in una sotto-shell, quindi segue la stessa logica.