問題タブ [go-cobra]

cobra addコマンドを使用して、cobra フレームワークを使用して Go CLI アプリを作成しました。ビルドした後go build、Windows cmd のリポジトリにいる場合は完全に正常に動作します。をクリックすると.exe、端末に次のメッセージが表示されます。

これは私の場合には適していません。C や C++ のように、直接開いてそこにコマンドを入力できるコンソール アプリケーションの場所が欲しいです。コブラを使用しているときにこれを実現する方法について何か提案はありますか?

よろしくお願いします。

コブラを使用して CLI コマンド ツールを作成します。エラー処理以外はすべて問題ないようです

コマンドが誤って送信された場合（間違った引数または間違った入力）、std.outの代わりにstd.errを返すようにしたい

シナリオを簡素化するために、これを作成しました。これは私のユースケースを示しています

バイナリをコンパイルしてバイナリexec.Commandに対して実行すると、すべてが期待どおりに機能します。しかし、エラーシナリオをテストしたい場合は、 at ではなくmycli provide apps apps1 in に返されることを確認したいstd.errstd.out

私が実行すると、mycli provide apps myappすべてがOKになるはずです

しかし、実行するmycli provide apps myapp2と std.out ではなく std.err を取得したいのですが、ここではそうではありません...ここで何が欠けていますか?

https://play.golang.org/p/B00z4eZ7Sj-

コブラを使用して GRPC クライアントを実装しています。サブコマンドの背後には、さまざまなサービス コールがあります。

viperコードの重複を避けるために、シングルトンには単一の接続と単一のクライアントを保持します。しかし、それが適切な方法であるかどうかはわかりません。

今、 でcmd/root.go::initConfig()、接続とクライアントを作成して保存します。

接続は で閉じられ、同じファイルrootCmd.PersistentPostRun()で定義されています。root.go

viperクライアントは、サブコマンドのファイルから取得され、使用されRunます。たとえば、

この実装は機能しますが、それが良い習慣であるかどうかはわかりません。具体的には

1. ある関数で接続を作成し、別の関数で閉じるのは悪いことですか?
2. クライアントを保存するのは理にかなっていますか、viperそれとも各サブコマンドのRun関数で新しいクライアントを作成する方が良いですか?

すべてのソースコードはこのリポジトリにあります