実行可能ファイルをインストールする方法


13

実行可能ファイルで提供されていない.deb.rpm、実行可能ファイルとしてのみ提供されているソフトウェアに遭遇することがあります。
たとえば、Visual Studio CodeWebStormKerbal Space Programmなど

この質問では、Visual Studio Codeを参照ポイントとします。

ソフトウェアは、zip形式のパッケージとして提供されます。
解凍すると、VSCode-linux-x64という名前の実行可能ファイルを含むフォルダーが残りますCode。私の端末で実行したいので、
ダブルクリックするCodeか、ポイントすることができます/home/user/Downloads/VSCode-linux-x64/Code
ただし、このアプリケーションをインストールする適切な方法があるかどうかを知りたいです。

私が達成したいことは:

  • この方法で提供されるすべてのアプリケーション/ソフトウェア(実行可能ファイル)を配置できる1つの場所
  • ターミナルサポート(つまり、たとえばvscode、ターミナルの任意のフォルダーから書き込むことができ、Visual Studio Codeが自動的に実行されます。

追加情報:

  • デスクトップ環境:Gnome3
  • OS:Debian

編集:
私は@kbaに答えを出すことにしました。彼のアプローチは私のバックアップソリューションとそれ以外にうまく機能するからです。スクリプトでバイナリを実行すると、引数を追加できます。
しかし、公平を期すために、@ John WH Smithのアプローチは@kbaのアプローチと同じくらい優れています。

回答:


12

名前でプログラムを呼び出すために、シェルは$PATH環境変数内のディレクトリを検索します。Debianでは、$PATHユーザーのデフォルトに/home/YOUR-USER-NAME/bin(ie ~/bin)を含める必要があります。

最初にディレクトリ~/binが存在することを確認するか、存在しない場合は作成します。

mkdir -p ~/bin

バイナリをそのディレクトリにシンボリックリンクして、シェルで使用できるようにすることができます。

mkdir -p ~/bin
ln -s /home/user/Downloads/VSCode-linux-x64/Code ~/bin/vscode

これによりvscode、コマンドラインまたはコマンドランチャーから実行できます。

注:バイナリを$PATHディレクトリにコピーすることもできますが、相対パスに依存している場合は問題が発生する可能性があります。

ただし、一般的には、OSが提供する手段(apt-get、debパッケージ)またはソフトウェアプロジェクトのビルドツールを使用して、ソフトウェアを適切にインストールすることが常に推奨されます。これにより、依存パス(起動スクリプト、マニュアルページ、構成など)が正しく設定されます。

更新:Thomas DickeyのコメントFaheem Mithaの答えも反映しています。トップレベルのバイナリを備えたtarballとして提供され、そこから実行されることが予想されるソフトウェアに対して私が通常行うことです。

適切な場所(標準準拠順/opt/usr/localまたはホームディレクトリ内のフォルダなど)に配置し、その場所に変更してバイナリを実行する場所(または)で~/build実行可能なスクリプトラッパーを作成します。$PATH/usr/local/bin~/bin

#/bin/sh
cd "$HOME/build/directory"
exec ./top-level-binary "$@"

これにより、そのディレクトリへの変更とバイナリの手動実行がエミュレートされるため、存在しない相対パスなどの問題のデバッグが容易になります。


1
私はこのアプローチが好きです。個人的には、bashプロファイルにエイリアスをスローしますが、これを使って多くのプログラムを実行していると、面倒になります。
WorBlux

1
その後、シェルからのみ使用できます。ある時点で.desktop、メニューから開始するエントリをインストールしたり、構成を追加したり、コマンドラインフラグを検出したりできます。エイリアスは非常に柔軟性がありません。
kbaはモニカと一緒に

8

TLDPによると/opt、この種のソフトウェアには適しているかもしれません。私は自分でそれを使ってプリンター関連のツールをいくつか保存し、Skypeの「動的」バージョン(kbaが言ったように、PATHそれに応じて変数を設定することで「ターミナルサポート」を実現できます)。

より一般的には/opt、実行可能ファイルとしてパッケージ化されたプロプライエタリなソフトウェアを「インストール」するために使用する傾向がありますが、それはおそらく私だけです。加えて、私は通常、この種のソフトウェアを避ける傾向があります。なぜなら、私は通常、それを実行するとどうなるかについては確実性がないからです。

私が選んだもう1つの理由/optは、通常は/opt/'package'ディレクトリ(およびなどの他のoptディレクトリ/etc/opt)以外のファイルに依存しないサードパーティの独立したコードを対象としているためです。

正常に機能するためにファイルシステムツリー内の特定の場所に存在する必要があるパッケージファイルを除き、/ opt、/ var / opt、および/ etc / opt階層の外部に他のパッケージファイルが存在することはありません。[...]通常、システム上のパッケージをサポートするために必要なすべてのデータは、/ etc / opt / 'package'および/ var / opt / 'にコピーされるファイルを含む、/ opt /' package '内に存在する必要があります。 / optの予約ディレクトリと同様に

ソースコードをリリースする利点の1つは、コンパイルプロセスを構成し、システムの仕様に基づいてカスタムライブラリ/ヘッダーパスを提供できることです。開発者がコードを実行可能ファイルとしてリリースすることを決定すると、その利点は失われます。私見では、この時点で、開発者はもはや自分のプログラムの依存関係が利用可能であると仮定することを許可されていません(そのため、すべてを実行可能ファイルと一緒にパッケージ化する必要があります)。

ここにインストールするパッケージは、別の/ opt / 'package'または/ opt / 'provider'ディレクトリツリーに静的ファイル(つまり、追加のフォント、クリップアート、データベースファイル)を配置する必要があります(Windowsのインストール方法と同様)新しいソフトウェアを独自のディレクトリツリーC:\ Windows \ Progam Files \ "Program Name")に追加します。「package」はソフトウェアパッケージを説明する名前で、「provider」はプロバイダーのLANANA登録名です。

詳細については、私も読んでお勧めします。この他のU&L問題 betwen違いを扱う、/optとし/usr/local。私は個人的に避けるだろう/usr/local、私は1じゃない場合は特に、この場合には組み込まれて、私はインストールしていたプログラムを。


6

Visual Studio Codeの例のように、バイナリzipアーカイブまたはtarballから配布バイナリパッケージを作成することは完全に可能であり、実際非常に簡単です。

はい、debsやrpmsのようなLinuxディストリビューションバイナリパッケージは通常ソースから生成されますが、そうである必要はありません。また、結果の配布バイナリパッケージが配布ポリシーに準拠するために「正しい」場所にインストールするように、多くの場合(常にではありませんが)配置することができます。

ランダムなプロプライエタリtarballの場合、ソフトウェアを適切にインストールする方法があれば、たとえば、makefileのインストールターゲットは、配布パッケージングマシンで使用できます。それ以外の場合、これには「手動で」ファイルを「正しい」場所にマッピングする必要があり、多くの作業が必要になる場合があります。そのようなパッケージを作成するのは奇妙なことのように思えるかもしれませんが、それでもパッケージ管理の大きな利点の1つであるクリーンインストールとアンインストールがあります。そしてもちろん、そのようなパッケージは名前に値するLinuxディストリビューションには決して受け入れられませんが、それはあなたの質問ではありません。


それは真実です。パッケージ化されていない、非標準のソフトウェアをローカルシステムで確実に実行したいだけの場合、Debianパッケージを作成すると、深刻なヤクのシェービングIMHOにつながる可能性があります。
kbaはモニカと一緒に

宣言:この質問の執筆中にヤクは剃られませんでした。
ファヒムミサ

@FaheemMitha-でヤクを痛みなく剃ることができますfpm
ディアハンター

@DeerHunterそのことを聞いたことがあります。使ったことがありますか?
ファヒムミタ

1
@DeerHunter良い点は確かに、私が使ってきたFPMを数年前にプロジェクトのためのクロスプラットフォームのバイナリパッケージをビルドするために、それは本当に風でした。
kbaは、モニカと一緒に

3

私は、バイナリ実行可能ファイルとしてのみ配信されるソフトウェアを見たことはほとんどなく、率直に言って少し疑っています。他に何もない場合は、少なくともREADME(インストール手順が記載されている)およびLICENSEそれに付随するものを期待します。それは言われています...

ディストリビューションのパッケージマネージャーによって管理されていないローカルにインストールされたバイナリが保持される通常の場所は/usr/local/binです。そこに置くことができます。そのディレクトリはすでに(またはそうあるべきです)$PATHなので、コマンドラインで名前を入力してソフトウェアを実行できます。

通常、ソフトウェアはまた、中に入るのmanページを(文書化されていないソフトウェアは右、悪いのですか?)が必要/usr/local/manとなに行くかもしれない他の言語やプラグインへの翻訳など、いくつかのサポートファイルを持っているかもしれません/usr/local/share/usr/local/lib、というように。このため、パッケージとして提供されないソフトウェア.deb.rpm、通常はすべてを適切な場所に配置するインストーラーが付属しています。ソースからインストールする場合、通常はになりmake installます。


Visual Studio Codeの場合、ディレクトリツリー全体に77個のLICENSEファイルが散在しています。トップレベルCodeは出発点にすぎません。実行中にライセンスが表示される場合があります(64ビットの実行可能ファイルは手元のマシンでは実行されませんが、OPの実際の質問に対応する適切な回答を提供するために誰かがその種類を確認する必要があります。
Thomas Dickey

説明をありがとう@ThomasDickey。OPの正確な状況を誤解したと思います。私はと思っただけで、彼らが受け取ったものは(tarballに包まれた)一つのELF実行可能だった
Celada

いいえ-簡単に確認しました(To Doリストではありません...)、ファイル数は約1500です。OSXを見てみると、それは実行され、Webブラウザーのチュートリアルで始まります。@kbaの答えは部分的に便利ですが、原則として/usr/local、ホームディレクトリではなく下で解凍してみます。(すべてのプログラムが機能するわけではありません- Eclipse例えば、)。
トーマスディッキー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.