Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

On exit<>0 netssh backend deletes all command output

オープン
#59 コメント 4 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
ruby
領域
devops

調査の方向性

lib/sshkit/backends/netssh.rb の _execute() から始め、次に capture() と test() およびその raise_on_non_zero_exit の処理を比較します。stdout、stderr、ロギング、ゼロ以外の終了がどのように相互作用するかを追跡します。意図された失敗時の動作と出力の保持が定義され、関連するテストでカバーされていれば完了です。

索引モデルが issue の本文から書いたものです。

説明

_execute() in the netssh backend assigns '' to stdout and stderr when a non zero exit code which automatically produces the "command stderr: Nothing written" & "command stdout: Nothing written" logs. Is there a reason stdout/stderr are nixed?

This is confusing especially if the command has been dutifully printing things on stdout.

Also throwing an exception on exit<>0 by default totally destroys the usefulness of capture(). capture() should probably add raise_on_non_zero_exit: false in the arguments like test() does.

The point is that in most cases capturing the output is significant when there is an error - the successful case is the boring one. The way SSHKit's API is at the moment it seems it does not provide an easy way to grab the log and determine that a command failed.

The naive approach would be to let capture() return a tuple: [bool,output]

主要言語
Ruby
スター
1.2k
フォーク
257
PR マージ指標
30日以内にマージされた PR はありません

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

capistrano/sshkit のほかの issue

capistrano/sshkit の issue をすべて見る

似ている issue

Ruby の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。