私は基本的なBashでUbuntu 16.04を使用しています。
実行するかどうかはわかりません。
#!/bin/bash
myFunc() {
export myVar="myVal"
}
myFunc
すべての意味で実行と同じですexport myVar="myVal"。
もちろん、グローバル変数は通常関数の外部で宣言する必要があります（技術的に可能であっても慣例の問題だと思います）。しかし、人々が非常に一般的な関数を作成し、変数を使用したいというよりエキゾチックなケースがあると思います。その中にはまだどこでも何でも使えます。
export関数内の変数は、CLIからグローバルに直接エクスポートして、シェル内のすべてのエントリ（その中のすべてのサブシェルと関数）で使用できるようにするのと同じですか？
答え1
myVarスクリプトは、スクリプト環境に環境変数を生成します。現在提供されているスクリプトは機能的には次のとおりです。
#!/bin/bash
export myVar="myVal"
関数本体で発生するという事実は、export環境変数の範囲（この場合）とは何の関係もありません。関数が呼び出されると、存在し始めます。
変数は、スクリプト環境および関数呼び出し後にスクリプトから開始された他のプロセスの環境で使用できます。
この変数は、スクリプトが起動しない限り（または.を使用してsource）親プロセス（スクリプトを実行する対話型シェル）環境には存在しません。この場合、スクリプト全体は対話型シェル環境（たとえば「source」）に存在します。シェルファイル）。
関数呼び出し自体はありません。
myFunc() {
export myVar="myVal"
}
購入これmyFuncファイルは呼び出しシェルの環境に配置されます。その後、この関数を呼び出すと環境変数が生成されます。
質問も参照してくださいシェル変数はどのような範囲を持つことができますか？
答え2
変数をエクスポートする関数を使用する場合は、サブシェルから呼び出さないように注意してください。
( export_var_func ) # Variable will NOT be exported outside
パイプはサブシェルを使用するため、関数がパイプされていてもこれが発生します。
たとえば、T字型に入るパイプは次のとおりです。
export_var_func | tee my.log # Variable will NOT be exported outside
サブシェルのパイピングを防ぐには、代わりにリダイレクトを使用してください。
export_var_func > >(tee func.log) # Variable WILL be exported outside