la barre oblique inversée doit être le dernier caractère sur la ligne pour qu'elle soit interprétée comme une commande de continuation. Aucun commentaire ou même des espaces ne sont autorisés après cela.

vous devriez pouvoir mettre des lignes de commentaire entre vos commandes

# output MYSQLDUMP file
cat ${MYSQLDUMP} | \
# simplify the line
sed '/created_at/d' | \
# create some newlines
tr ",;" "\n" | \
# use some sed magic
sed -e 's/[asbi]:[0-9]*[:]*//g' -e '/^[{}]/d' -e 's/""//g' -e '/^"{/d' | \
# more magic
sed -n -e '/^"/p' -e '/^print_value$/,/^option_id$/p' | \
# even more magic
sed -e '/^option_id/d' -e '/^print_value/d' -e 's/^"\(.*\)"$//' | \
tr "\n" "," | \
# I hate phone numbers in my output
sed -e 's/,\([0-9]*-[0-9]*-[0-9]*\)/\n/g' -e 's/,$//' | \ 
# one more sed call and then send it to the CSV file
sed -e 's/^/"/g' -e 's/$/"/g' -e 's/,/","/g' >> ${CSV}

comme DigitalRoss l'a souligné, la barre oblique inversée n'est pas nécessaire lorsque la ligne se termine par | . Et vous pouvez mettre des commentaires sur une ligne qui suit un | :

 cat ${MYSQLDUMP} |         # Output MYSQLDUMP file
 sed '1d' |                 # skip the top line
 tr ",;" "\n" | 
 sed -e 's/[asbi]:[0-9]*[:]*//g' -e '/^[{}]/d' -e 's/""//g' -e '/^"{/d' |
 sed -n -e '/^"/p' -e '/^print_value$/,/^option_id$/p' |
 sed -e '/^option_id/d' -e '/^print_value/d' -e 's/^"\(.*\)"$//' |
 tr "\n" "," |
 sed -e 's/,\([0-9]*-[0-9]*-[0-9]*\)/\n/g' -e 's/,$//' |   # hate phone numbers
 sed -e 's/^/"/g' -e 's/$/"/g' -e 's/,/","/g' >> ${CSV}

Les antislashes la #, en l'interprétant comme son caractère littéral au lieu d'un caractère de commentaire.

$IFS commentaire hacks

ce hack utilise parameter expansion sur $IFS , qui est utilisé pour séparer les mots dans les commandes:

$ echo foo${IFS}bar
foo bar

de même:

$ echo foo${IFS#comment}bar
foo bar

en utilisant ceci, vous pouvez mettre un commentaire sur une ligne de commande avec contination:

$ echo foo${IFS# Comment here} \
> bar
foo bar

mais le commentaire devra être avant la suite \ .

notez que l'expansion du paramètre est effectuée à l'intérieur du commentaire:

$ ls file
ls: cannot access 'file': No such file or directory
$ echo foo${IFS# This command will create file: $(touch file)}bar
foo bar
$ ls file
file

exception

le seul cas rare où cela échoue est si $IFS a déjà commencé avec le texte exact qui est supprimé par l'expansion (c'est-à-dire après le caractère # ):

$ IFS=x
$ echo foo${IFS#y}bar
foo bar
$ echo foo${IFS#x}bar
foobar

Note Le Dernier foobar n'a pas espace, illustrant la question.

puisque $IFS ne contient que des espaces par défaut, c'est extrêmement peu probable que vous rencontriez ce problème.

crédit à le commentaire de @pjh qui a déclenché cette réponse.

voici un script bash qui combine les idées et les idiomes de plusieurs commentaires précédents pour fournir, avec des exemples, des commentaires inline ayant la forme générale ${__+ <comment text>} .

en particulier

• <comment text> peut être multi-ligne
• <comment text> n'est pas de paramètre étendu", 1519170920"
• pas de sous-processus sont générés (donc les commentaires sont efficaces)

Il y a une restriction sur le <comment text> , à savoir, les Bretelles non équilibrées '}' et les parenthèses ')' doivent être protégées (i.e., '\}' et '\)' ).

il y a une exigence sur l'environnement local bash:

• le nom du paramètre __ doit être désactivé

tout autre paramètre-nom de bash valide sur le plan syntaxique remplacera __ , à condition que le le nom n'a pas de valeur définie.

un exemple de script suit

# provide bash inline comments having the form
#     <code> ${__+ <comment>} <code> 
#     <code> ${__+ <multiline
#                   comment>} <code>

# utility routines that obviate "useless use of cat"
function bashcat { printf '%s\n' "$(</dev/stdin)"; }
function scat { 1>&2 bashcat; exit 1; }

# ensure that '__' is unset && remains unset
[[ -z ${__+x} ]] &&  # if '__' is unset
  declare -r __ ||   # then ensure that '__' remains unset 
  scat <<EOF         # else exit with an error
Error: the parameter __='${__}' is set, hence the
  comment-idiom '${__+ <comment text>}' will fail
EOF

${__+ (example of inline comments)
------------------------------------------------
the following inline comment-idiom is supported
    <code> ${__+ <comment>} <code> 
    <code> ${__+ <multiline
                  comment>} <code> 
(advisory) the parameter '__' must NOT be set;
  even the null declaration __='' will fail
(advisory) protect unbalanced delimiters \} and \) 
(advisory) NO parameter-expansion of <comment> 
(advisory) NO subprocesses are spawned
(advisory) a functionally equivalent idiom is 
    <code> `# <comment>` <code> 
    <code> `# <multiline
               comment>` <code>
however each comment spawns a bash subprocess
that inelegantly requires ~1ms of computation 
------------------------------------------------}