Verschachtelter Bash-Befehl funktioniert nicht in TeamCity ssh exec

Question

Ich versuche ein Skript zu schreiben, um meinen Server in TeamCity mit dem Build-Schritt "SSH EXEC" neu zu starten.

Eines der Dinge, die das Skript zu tun hat, entpackt eine Zip-Datei, die ich in einem vorherigen Schritt hochgeladen habe, aber die Version im Dateinamen wird immer ändern, also versuche ich den Namen der Zip mit einem verschachtelten zu suchen Befehl.

unzip `ls | grep zip` 

Dies funktioniert für mich, wenn ich auf meinen Server ssh und es im Terminal zu tun, aber es funktioniert nicht, wenn es Teamcity zu tun versucht. Ich erhalte die folgende Meldung in der Build

[19:36:55][Step 3/3] UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP. 
[19:36:55][Step 3/3] 
[19:36:55][Step 3/3] Usage: unzip [-Z] [-opts[modifiers]] file[.zip] [list] [-x xlist] [-d exdir] 
[19:36:55][Step 3/3] Default action is to extract files in list, except those in xlist, to exdir; 
[19:36:55][Step 3/3] file[.zip] may be a wildcard. -Z => ZipInfo mode ("unzip -Z" for usage). 
[19:36:55][Step 3/3] 
[19:36:55][Step 3/3] -p extract files to pipe, no messages  -l list files (short format) 
[19:36:55][Step 3/3] -f freshen existing files, create none -t test compressed archive data 
[19:36:55][Step 3/3] -u update files, create if necessary  -z display archive comment only 
[19:36:55][Step 3/3] -v list verbosely/show version info  -T timestamp archive to latest 
[19:36:55][Step 3/3] -x exclude files that follow (in xlist) -d extract files into exdir 
[19:36:55][Step 3/3] modifiers: 
[19:36:55][Step 3/3] -n never overwrite existing files   -q quiet mode (-qq => quieter) 
[19:36:55][Step 3/3] -o overwrite files WITHOUT prompting  -a auto-convert any text files 
[19:36:55][Step 3/3] -j junk paths (do not make directories) -aa treat ALL files as text 
[19:36:55][Step 3/3] -U use escapes for all non-ASCII Unicode -UU ignore any Unicode fields 
[19:36:55][Step 3/3] -C match filenames case-insensitively  -L make (some) names lowercase 
[19:36:55][Step 3/3] -X restore UID/GID info     -V retain VMS version numbers 
[19:36:55][Step 3/3] -K keep setuid/setgid/tacky permissions -M pipe through "more" pager 
[19:36:55][Step 3/3] -O CHARSET specify a character encoding for DOS, Windows and OS/2 archives 
[19:36:55][Step 3/3] -I CHARSET specify a character encoding for UNIX and other archives 
[19:36:55][Step 3/3] 
[19:36:55][Step 3/3] See "unzip -hh" or unzip.txt for more help. Examples: 
[19:36:55][Step 3/3] unzip data1 -x joe => extract all files except joe from zipfile data1.zip 
[19:36:55][Step 3/3] unzip -p foo | more => send contents of foo.zip via pipe into program more 
[19:36:55][Step 3/3] unzip -fo foo ReadMe => quietly replace existing ReadMe if archive file newer 
[19:36:56][Step 3/3] SSH exit-code [0] 

Answer 1

Protokoll, das, was Ausgänge entpacken ist, wenn es keine Argumente. Meine Vermutung ist, dass ls | grep zip eine leere Zeichenfolge zurückgibt, weil ls nichts gefunden hat.

Ich denke, das ist ein Artefakt davon, wie die lokale Shell die Eingabe der Zeichenfolge in ssh verarbeitet. Wenn Sie

tun

ssh $host "unzip `ls | grep zip`" 

von einem lokalen Bash-Shell, sieht bash, dass es ein eingebettetes Subshell ist und führt erste ls | grep zip lokal und bettet das Ergebnis in den String und gibt den resultierenden String zu ssh. Da (vermutlich) gibt es keine Zip-Datei im aktuellen Verzeichnis, in dem diese ssh-Befehl ausgeführt wird, wird der eigentliche Befehl an den Remote-Shell übergeben

ssh $host "unzip " 

Die Art und Weise, dies zu beheben ist es, die einfachen Anführungszeichen zu entkommen, so dass sie nicht sind interpretiert von bash, aber eingebettet und an die Remote-Shell weitergeleitet:

ssh $host "unzip \`ls | grep zip\`"