Il 30/07/22, Alessandro Rubini<rub...@linux.it> ha scritto: >>> farebbe comodo avere una shell, compatibile con bash, che >>> tramite qualche carattere particolare, accetta commenti su piu` righe. > > Non sarebbe compatibile con bash. Gia` bash non e` compatibile con sh > e non dovrebbe essere usata per gli script :) > > Non vedo dove stia il problema nel mettere un "#" ad ogni riga di > commento. Gli editor faranno vedere queste righe con il colore dei > commenti (mentre con altri accrocchi non succede). E, sempre gli editor, > sono in grado di riallineare il paragrafo mantentendo i marcatori di > commento al posto giusto. > >> Puoi farlo anche in bash. Per esempio: >> >> https://www.geeksforgeeks.org/multi-line-comment-in-shell-script/ > > Il primo accrocchio ("<<comm") e` pericoloso. Da "man bash": > > all lines of the here-document are subjected to parameter ex- > pansion, command substitution, and arithmetic expansion > > Quindi questo > > #!/bin/bash > > << commento > se facessi $(echo pio > /tmp/file) creerei un file > commento > > Mi crea un file. I commenti non devono avere effetti. Questo non e` un > commento. > > Il secondo accorcchio (": '") e` meno rischioso. "duepunti" e` il > comando interno che non fa niente ("does nothing beyond expanding > arguments and performing any specified redirections"). Quindi > duepunti-spazio-apice apre un argomento che puo` essere di piu` righe, > senza grossi rischi, a meno che non si infilino altri apici dentro il > "commento" stesso. > > Rimane che non e` un commento, e chi guarda il codice (compresa la > colorazione di sintassi degli editor) non lo percepisce come un > commento. > > Mi spiace, ma quella pagina e` sbagliata, sia perche` da` consigli > sbagliati sia (ed e` peggio) perche` non spiega cosa significano quei > caratteri strani -- che non sono commenti. > > Se e` vero che il commento "helps in understanding the code, improves > code-readability, and also helps in enhancing the structure of the > program" quello che *non* bisogna fare e` seguire i consigli che > seguono.
È vero che è un accrocchio, rompe gli editor e nel link non spiegano niente (penso che neanche capiscano loro stessi che cosa servano certe cose, chi sa fa chi non sa insegna), ma l'argomento sicurezza è un'esagerazione. Intanto here-doc e true con argomenti sono equivalenti sull'essere exploitabili tramite $(), ma ormai gli script shell per gli usi di distribuzione non servono più, rimane solo il linguaggio degli accrocchi che uno si fa per sè. Un antico adagio diceva che UNIX non ti ferma dallo spararti nei piedi, se è ciò che vuoi UNIX conficcherà il proiettile nel tuo piede nella maniera più efficiente.
