que quieren incluir comando parámetros-inline comentarios, por ejemplo .:comentarios entre los parámetros en BASH
sed -i.bak -r \
# comment 1
-e 'sed_commands' \
# comment 2
-e 'sed_commands' \
# comment 3
-e 'sed_commands' \
/path/to/file
El código anterior no funciona. ¿Hay alguna forma diferente de insertar comentarios en la línea de parámetros?
Si realmente quieres comentar argumentos, puede intentar esto:
ls $(
echo '-l' #for the long list
echo '-F' #show file types too
echo '-t' #sort by time
)
Este será equivalente a:
ls -l -F -t
eco es una cáscara integrada, por lo que no ejecutar comandos externos, así que es lo suficientemente rápido. Pero, es loco de todos modos.
o
makeargs() { while read line; do echo ${line//#*/}; done }
ls $(makeargs <<EOF
-l # CDEWDWEls
-F #Dwfwef
EOF
)
me gustaría recomendar el uso de bloques de texto más largos para su secuencia de comandos sed, es decir
sed -i.bak '
# comment 1
sed_commands
# comment 2
sed_commands
# comment 3
sed_commands
' /path/to/file
Por desgracia, los comentarios incluyeron en bloques de secuencia de comandos sed no son universalmente una característica compatible. La versión sun4 le permite poner un comentario en la primera línea, pero en ningún otro lado. AIX sed no permite comentarios, o usa un char diferente además de # para comentarios. Tus resultados pueden variar
Espero que esto ayude.
Usted podría invocar sed varias veces en lugar de pasar todos los argumentos a un solo proceso:
sed sed_commands | # comment 1
sed sed_commands | # comment 2
sed sed_commands | # comment 3
sed sed_commands # final comment
Es obvio que es más derrochador, pero puede decidir que tres procesos de sed extra son una compensación justa para facilitar la lectura y portabilidad (al punto de @ shellter sobre soporte para comentarios dentro de comandos sed). Depende de tu situación
ACTUALIZACIÓN: también deberá ajustar si originalmente pretendía editar los archivos en su lugar, como lo implica su argumento -i. Este enfoque requeriría una tubería.
idea horrible - desperdicia esfuerzo al copiar la fecha a través de 3 pipes. –
Para ser justos, debo agregar: si los archivos son solo kilobytes de tamaño, está bien, si son megabytes , obteniendo dudas, si son gigabytes o más grandes, entonces 6 copias innecesarias (dentro y fuera de cada uno de los tres tubos) es demasiado caro para la comodidad. –
Normalmente trato de presentar el número mínimo de procesos en una respuesta shell, pero menciono esto como una opción porque "horrible" es relativo. En 1983, claro. En 2011 , como dije, podría valer la compensación. Usted dice que la legibilidad no vale lo que podría ser unos pocos milisegundos enteros y docenas de bytes, pero en algunas situaciones vale la pena sacrificar esas migajas si se pueden aclarar expresiones regulares crípticas en el guión. –
No hay una manera de hacer lo que tratan de hacer en la cáscara, más sed. Pongo los comentarios antes de que el guión sed, así:
# This is a remarkably straight-forward SED script
# -- When it encounters an end of here-document followed by
# the start of the next here document, it deletes both lines.
# This cuts down vastly on the number of processes which are run.
# -- It also does a substitution for XXXX, because the script which
# put the XXXX in place was quite hard enough without having to
# worry about whether things were escaped enough times or not.
cat >$tmp.3 <<EOF
/^!\$/N
/^!\\ncat <<'!'\$/d
s%version XXXX%version $SOURCEDIR/%
EOF
# This is another entertaining SED script.
# It takes the output from the shell script generated by running the
# first script through the second script and into the shell, and
# converts it back into an NMD file.
# -- It initialises the hold space with [email protected], which is a marker.
# -- For lines which start with the marker, it adds the pattern space
# to the hold space and exchanges the hold and pattern space. It
# then replaces a version number followed by a newline, the marker
# and a version number by the just the new version number, but
# replaces a version number followed by a newline and just the
# marker by just the version number. This replaces the old version
# number with the new one (when there is a new version number).
# The line is printed and deleted.
# -- Note that this code allows for an optional single word after the
# version number. At the moment, the only valid value is 'binary' which
# indicates that the file should not be version stamped by mknmd.
# -- On any line which does not start with the marker, the line is
# copied into the hold space, and if the original hold space
# started with the marker, the line is deleted. Otherwise, of
# course, it is printed.
cat >$tmp.2 <<'EOF'
1{
x
s/^/[email protected]/
x
}
/^[email protected] /{
H
x
s/\([ ]\)[0-9.][0-9.]*\[email protected] \([0-9.]\)/\1\2/
s/\([ ]\)[0-9.][0-9.]*\([ ][ ]*[^ ]*\)\[email protected] \([0-9.][0-9.]*\)/\1\3\2/
s/\([ ][0-9.][0-9.]*\)\[email protected] $/\1/
s/\([ ][0-9.][0-9.]*[ ][ ]*[^ ]*\)\[email protected] $/\1/
p
d
}
/^[email protected]/!{
x
/^[email protected]/d
}
EOF
Hay otro sed script en el archivo que se encuentra alrededor de 40 líneas de largo (marcado como 'entretenida'), aunque aproximadamente la mitad de esas líneas simplemente se incorporan shell script agregado a la salida. No he cambiado el script de shell que contiene este material en 13 años porque (a) funciona y (b) los guiones sed me asustan. (El formato NMD contiene un nombre de archivo y un número de versión separados por espacios y ocasionalmente una palabra de etiqueta 'binaria' en lugar de un número de versión, más líneas de comentarios y líneas en blanco.)
No tiene que entender qué el script lo hace, pero comentar antes del script es la mejor forma que he encontrado para documentar scripts sed.
No.
Si coloca el \ antes del #, escapará del carácter de comentario y ya no tendrá más comentarios.
Si coloca el \ después del # será parte del comentario y ya no escapará de la nueva línea.
La falta de comentarios en línea es una limitación de bash a la que harías mejor para adaptarte que tratar algunas de las sugerencias barrocas ya presentadas.
Aunque el hilo es bastante viejo, lo encontré para la misma pregunta y también lo harán otros. Aquí está mi solución para este problema:
Necesita comentarios, de modo que si observa su código mucho más tarde, es probable que tenga una idea de lo que realmente hizo cuando escribió el código. Solo estoy teniendo el mismo problema al escribir mi primer script rsync, que tiene muchos parámetros que también tienen efectos secundarios.
Agrupe los parámetros que pertenecen juntos por tema y colóquelos en una variable, que recibe el nombre correspondiente. Esto hace que sea fácil identificar lo que el parámetro dirigir. Este es tu pequeño comentario. Además, puede poner un comentario encima de la declaración de variables para ver cómo puede cambiar el comportamiento. Este es el comentario de la versión larga.
Llamar a la aplicación con las variables de parámetros correspondientes.
## Options
# Remove --whole-file for delta transfer
sync_filesystem=" --one-file-system \
--recursive \
--relative \
--whole-file \ " ;
rsync \
${sync_filesystem} \
${way_more_to_come} \
"${SOURCE}" \
"${DESTIN}" \
Buena descripción, fácil de editar, y comentarios similares en los parámetros. Requiere más esfuerzo, pero tiene una calidad superior.
voy a sugerir otra forma en que funciona, al menos en algunos casos:
Digamos que tengo el comando:
foo --option1 --option2=blah --option3 option3val /tmp/bar`
me puede escribir de esta manera:
options=(
--option1
--option2=blah
--option3 option3val
)
foo ${options[@]} /tmp/bar
Ahora digamos que quiero eliminar temporalmente la segunda opción. Yo sólo puedo comentar hacia fuera:
options=(
--option1
# --option2=blah
--option3 option3val
)
Tenga en cuenta que esta técnica puede no funcionar cuando se necesita extensa evadan o citar. He tenido algunos problemas con eso en el pasado, pero lamentablemente no recuerdo los detalles en este momento :(
En la mayoría de los casos, esta técnica funciona bien. Si necesita espacios en blanco incrustados en un parámetro, simplemente encierre la cadena entre comillas, como de costumbre.
Idea interesante ... –
Bueno, pero tenga en cuenta que 'do echo $ {línea // # * /};' funcionará, siempre que su comando no use el argumento '-e'; si lo hace (como 'tshark'), de lo contrario, se interpretará como un argumento para' echo', y terminará desapareciendo de la salida. Luego puede usar 'printf"% s "$ {línea // # * /};' en su lugar, pero eso no le permite usar cosas como '-r" $ 1 "' para pasar un nombre de archivo en los argumentos, ya que las comillas dobles llegarán escapadas al comando (y no serán interpretadas por el intérprete de comandos), lo que arruinará el nombre del archivo. – sdaau