ある変数を使用して別の変数を作成しようとすると、予期しない結果が発生します。私はそれを少し絞り込みましたが、ここで何が起こっているかについて少し助けを使うことができます. 私のローカルスクリプトはこれを行います：
CUR_TIME=$(date "+%Y%m%d_%HH%MM%SS")
CUR_TIME="build_"$CUR_TIME
それは私に望ましい結果を与えます。ただし、これを使用して別の変数を作成したり、この変数を含む何かをエコーしたりするときはいつでも:
echo "/home/path/blah/$CUR_TIME"
$CUR_TIME私の結果は、変数をエコーバックするだけです。ここで何が起きてるの？
変数はローカル シェル セッションで設定されます。$CUR_TIMEこのように ssh 経由でリモート サーバーから追加の変数を取得しています。additional_vars=$(ssh user@server "cat variables.properties")
私はそうしますeval $addtional_vars。に$additional_varsはかなりの数の変数が含まれており、それらを個別にエコーしても問題なく動作します。
そのため、次の形式を使用して新しい変数を作成またはエコーアウトします。
echo "/home/path/blah/$additional_var1/"
これは適切にエコーしますが、これを行うと（逆）：
echo "/$additional_var1/home/path/blah"
私の結果はちょうど/home/path/blahです。
編集
さらにトラブルシューティングを行った後、変数のいずれか$additional_varsをパス名に含めて、指定したものの前に配置すると、パスのその部分が null になるように見えます。したがって、$CUR_TIME変数だけではありません。奇妙なのは、 をエコーアウトするだけ$additional_varで問題ないことです。
私の .properties ファイルは次のようになります。
var1="something"
var2="something2"
var3="something3"
var3="ftp://something/another/$something_else"
var4="something.something"
eval $additional_varsを使用してテストするprintf ${additional_vars} | hexdump -Cと、出力は 16 進値になり、次に|var1="something".|