基本的なシェルスクリプトfoo.shがあるとします。
#!/bin/sh
while [ 1 ]
do
echo "looping"
sleep 1
done
そして、これをコマンドとして提供したい:/snap/bin/myapp.foo
Snapcraft.yamlがあります:
apps:
foo:
command: opt/foo/bin/foo.sh
parts:
foo:
source: .
plugin: dump
organize:
foo.sh: opt/foo/bin/foo.sh
これはファイル/snap/bin/myapp.foo
になりますが、/ usr/bin/snapへのリンクです。コマンドを実行すると、セグメンテーションエラーが発生します。
このためにsnapcraft.yamlをセットアップする正しい方法は何ですか? sh
をスナップにパッケージ化する必要があるかどうか疑問に思っていますか?または、シェルスクリプトがスナップで使用されることを意図していない場合
わかりましたので、2つのことが欠けていました。
1)コマンドセクションで、$ SNAP環境変数を使用する必要があります。作成するすべてのパーツは、実行時にそのenv変数に関連して保存されます。
2)シェルスクリプトを直接呼び出すのではなく、インタープリター(この場合は「sh」)を指定します。それなしで失敗しました。
apps:
foo:
command: sh $SNAP/opt/foo/bin/foo.sh
parts:
foo:
source: .
plugin: dump
organize:
foo.sh: opt/foo/bin/foo.sh
補遺1:Ubuntu 18では、SnapがUbuntu 16にあるlibcのバージョンに結び付けられていることが、私の使用にとって本当に重要な要因であることが判明しました。これにより、Snapはturnは、bashやdash/shなどと競合を起こします。
シェルスクリプトを実行しようとしていて、セグメンテーション違反が発生している場合は、これに関連している可能性があります。プロセスはシェルスクリプトの呼び出しを試み、上部の「Shebang」(「#!/ bin/bash」)を読み取り、/ bin/bashを実行するとlibcの競合が発生します。
補遺2:親プロセスがシェルスクリプトを起動する状況では、上部の「Shebang」ステートメントが無効になる可能性があることに注意してください。たとえば、実際のパスは「$ SNAP/bin/sh」であり、「/ snap/project-name/project-revision/bin/sh」のようなものに解決されるため、「#!/ bin/sh」は正しく解決されません。 「。
これを回避するには、関連するすべてのパスの先頭に$ SNAPを付けて、PATH環境がプログラムに渡されるようにします。次に、「bash child.sh」と「child.sh」など、インタープリターでスクリプトを呼び出すように親プログラムを調整します。