¿Por qué falla `grep fil *`?

Encontré echo file|grep fil*fallas, pero echo abcd|grep abc*tiene éxito.

No lo entiendo, ¿alguien puede explicar?

— tmpbin
fuente

¿Puedes agregar el sistema y la versión de grep? Esto se debe a que con gnugrep 2.16 (en Ubuntu 14.04 LTS), no genera ningún error (código de salida 0) y coincide con las tres primeras letras. Por ejemplo, echo file|grep fil*respuestas con file.

— Hastur

@Hastur El problema es causado por la expansión del nombre de archivo antes de la expresión regular. Mi directorio de trabajo contiene un archivo prefijado por fil, pero no un archivo prefijado por abc, por lo que fil * se reemplaza por el nombre del archivo, pero abc * no cambia.

— tmpbin

Gracias, no lo pensé. Cuando hago mis intentos, los pruebo en un nuevo directorio ...

— Hastur

Hay dos problemas con tu ejemplo.

La principal es que está asumiendo que las expresiones regulares funcionan de la misma manera que los patrones globales, ya que *es un comodín que significa "cualquier secuencia de caracteres". En las expresiones regulares, *significa "cualquier número del átomo anterior", por lo que fil*significa fseguido de iseguido de cero o más lcaracteres. Debe decir grep fil.*para obtener el significado deseado: .significa "cualquier carácter individual, por lo que .*significa" cualquier secuencia de caracteres ".

El problema menor es que estás usando caracteres especiales sin comillas que significan algo bajo las reglas globales, lo que significa que el shell podría interpretarlos. Si tuviera algún archivo en el directorio local que coincida con los patrones globales fil*o abc*, el shell los expandiría , por greplo que obtendría los nombres de los archivos expandidos como un patrón, no el RE previsto. Siempre que usted esté usando este tipo de caracteres en la línea de comandos, debe citarlos: echo file | grep 'fil.*'.

— Warren Young
fuente