1

私はこのようなコードスニペットを見ましたgit-stash

            rm -f "$TMP-index" &&
            GIT_INDEX_FILE="$TMP-index" git read-tree HEAD &&


            # find out what the user wants
            GIT_INDEX_FILE="$TMP-index" \
                    git add--interactive --patch=stash -- &&

            # state of the working tree
            w_tree=$(GIT_INDEX_FILE="$TMP-index" git write-tree) ||
            die "$(gettext "Cannot save the current worktree state")"

            git diff-tree -p HEAD $w_tree -- >"$TMP-patch" &&
            test -s "$TMP-patch" ||
            die "$(gettext "No changes selected")"

            rm -f "$TMP-index" ||
            die "$(gettext "Cannot remove temporary index (can't happen)")"

私が理解していないのは、次のような表現です。

GIT_INDEX_FILE="$TMP-index" git read-tree HEAD

に値を割り当ててからコマンドを実行するということTMP-indexですGIT_INDEX_FILEかgit read-tree HEAD？

それについてはよくわかりません。そこで、このようなコマンドを書いてみました。

A="1" ls
echo $A

の値Aはまだnullです。

私もこれを試しました：

echo $a
=> 1
k=$(a=100 echo $a)
=> 
echo $k
=> 1

の値aはまったく変更されていないようです。だからa=100役に立たないようです。

誰かがこのような構文についてのアイデアを持っていますか？

4

3 に答える 3

1

に値を割り当ててからコマンドを実行するということTMP-indexですGIT_INDEX_FILEかgit read-tree HEAD？

完全ではありません。構文：

VAR1=val1 VAR2=val2 somecommand arg1 arg2

somecommand引数arg1とを使用してコマンドを実行するようにシェルに指示しますarg2が、somecommandの環境はにVAR1設定されval1、にVAR2設定されval2ます。シェル自体はこれらの割り当ての影響を受けず、の環境のみが影響を受けますsomecommand。効果は次と同等です。

env VAR1=val1 VAR2=val2 somecommand arg1 arg2

唯一の違いは、前者の方法ではユーティリティを見つけて実行する必要がないため（シェルビルトインユーティリティではないと/usr/bin/env想定しています）、非常に高速です。env

また、次と同等です。

(export VAR1=val1 VAR2=val2; somecommand arg1 arg2)

括弧に注意してください。これにより、シェルは別のサブシェルでコマンドを実行します。サブシェルへの変更（変数の割り当てなど）は、サブシェルが終了しても保持されません。

例

#!/bin/sh
FOO=value1
printf %s\\n "In the shell, FOO is ${FOO} (before running python)"
FOO=value2 python -c 'import os; print "In python, FOO is", os.environ["FOO"]'
printf %s\\n "In the shell, FOO is ${FOO} (after running python)"

上記のスクリプトは、次の出力を出力します。

In the shell FOO is value1 (before running python)
In python, FOO is value2
In the shell, FOO is value1 (after running python)

Gitが行っていること

提供したGitシェルコードのスニペットでは、インデックスを台無しにすることなくインデックス変更操作を実行できるように、のいくつかの呼び出しをgit stash一時的に変更しています。GIT_INDEX_FILEgitstash

  • まず、git stashを使用git read-treeして一時インデックスファイルを作成し、その内容をにあるものに初期化しますHEAD。
  • 次に、どの部分を隠しておくかをユーザーに尋ね、選択した変更を一時インデックスファイルに保存するためにgit stash使用します。git add --interactive
  • 3番目に、一時インデックスの内容をツリーオブジェクトとしてGitリポジトリに保存するためにgit stash使用します。git write-tree
  • 第4にgit stash、ツリーオブジェクトをと比較して、HEAD実際に隠しておくものを選択したことを確認します。
  • 最後に、git stash作成した一時インデックスファイルを削除します。
于 2012-12-31T17:32:59.707 に答える
1

BASHでは、変数の定義とその後の新しいプロセスの実行にいくつかの問題があります。

変数を定義するだけの場合、それは新しいプロセスによって「継承」されません

変数を定義しましょう

$ VAR='value'
$ echo $VAR
value

そして、新しいプロセスに入ります

$ bash

変数は未定義です

$ echo $VAR

$

しかし、戻ったら

$ exit

varが再度定義されます

$ echo $VAR
value
$

これを回避する通常の方法は、エクスポートを使用することです

$ export VAR2='yep'
$ bash
$ echo $VAR2
yep
$

あなたが見ているもの（そう思われる）は、子プロセスで変数を割り当てますが、元のプロセスでは割り当てない、そのための代替構文です

$ var3='wow' bash  #this line opens a new bash, and assigns the variable for this new bash
$ echo $var3
wow
$ exit
$ echo $var3

$
于 2012-12-31T05:51:56.460 に答える
1

「ということですか...」という質問に対する答えは「はい」です。

ただし、変数の展開はコマンドの解析時に発生するため、環境変数を設定してシェルにインポートした結果を確認するには時期尚早であり、期待する結果が得られないのはそのためです。

1 行の環境変数式の結果を確認するには、さまざまな方法があります。あなたは観察することができます...

$ B=100 env | grep B
B=100

...また...

$ z=abc sh -c 'echo $z'
abc
于 2012-12-31T05:45:18.460 に答える