No meu manual, a seguinte linha deve retornar 1e, se retornar >1, a reprodução deverá parar:
shell: ls -l /opt/tomcat/|grep "[ ]\+{{ newTomcatVer }}$"; echo $?
Minha peça realmente falhou com este erro:
"msg": "There is more than one /opt/tomcat/apache-tomcat-8.x.xx instance on server01, ending play"
Depois de executar novamente no modo de depuração, vejo que este comando shell está sendo representado assim na saída de depuração:
"cmd": "ls -l /opt/tomcat/|grep \"[ ]\\+apache-tomcat-8.5.69$\"; echo $?",
Acima, as aspas duplas são escapadas com \caracteres. A questão é: qual comando está realmente sendo usado - aquele que está no manual ou aquele que vemos na saída de depuração?
Porque se eu executar o comando que está no notebook, ou seja, sem caracteres de escape, a saída será 1a esperada:
[tomcat@server01 ~]$ ls -l /opt/tomcat/|grep "[ ]\\+apache-tomcat-8.5.69$"; echo $?
1
Mas se eu emitir o comando que está na saída de depuração, recebo o seguinte:
[tomcat@server01 ~]$ ls -l /opt/tomcat/|grep \"[ ]\\+apache-tomcat-8.5.69$\"; echo $?
grep: Invalid regular expression
2
Alguma idéia de como resolver isso?
Responder1
Usarsolteiroaspas no grepcomando.
grep "[ ]\+{{ newTomcatVer }}$"
Quando você usa aspas duplas, o shell tentará fazer a expansão da variável, o que significa que tentará entender $". Isso acontece $\"porque o shell não reconhece $"como um parâmetro que pode expandir, então ele tenta adivinhar o que você queria e escapa das aspas.
Não há nenhuma razão real para fazer a expansão dos parâmetros do shell aqui, então você pode colocar o regex entre aspas simples para resolver o problema. O shell não tentará expandir os parâmetros e os tratará $literalmente.
grep '[ ]\+{{ newTomcatVer }}$'