Anda dapat menyimpan dan menetapkan ke IFS sesuai kebutuhan. Tidak ada yang salah dengan melakukannya. Tidak jarang menyimpan nilainya untuk restorasi setelah modifikasi sementara yang cepat, seperti contoh penetapan array Anda.
Seperti @llua menyebutkan dalam komentarnya untuk pertanyaan Anda, hanya dengan tidak mengaktifkan IFS akan mengembalikan perilaku default, setara dengan menetapkan spasi-tab-baris baru.
Ada baiknya mempertimbangkan bagaimana hal itu bisa lebih bermasalah untuk tidak secara eksplisit mengatur / menghapus IFS daripada melakukannya.
Dari edisi POSIX 2013, 2.5.3 Variabel Shell :
Implementasi dapat mengabaikan nilai IFS di lingkungan, atau tidak adanya IFS dari lingkungan, pada saat shell dipanggil, dalam hal ini shell akan mengatur IFS ke <spasi> <tab> <newline> ketika dipanggil .
Shell yang mematuhi POSIX, dipanggil mungkin atau mungkin tidak mewarisi IFS dari lingkungannya. Dari berikut ini:
- Skrip portabel tidak dapat secara inheren mewarisi IFS melalui lingkungan.
- Sebuah skrip yang bermaksud untuk hanya menggunakan perilaku pemisahan standar (atau bergabung, dalam kasus
"$*"
), tetapi yang dapat berjalan di bawah shell yang menginisialisasi IFS dari lingkungan, harus secara eksplisit mengatur / membatalkan pengaturan IFS untuk mempertahankan diri terhadap intrusi lingkungan.
NB Penting untuk dipahami bahwa untuk diskusi ini kata "dipanggil" memiliki arti tertentu. Sebuah shell dipanggil hanya ketika secara eksplisit dipanggil menggunakan namanya (termasuk #!/path/to/shell
shebang). Subshell - seperti yang mungkin dibuat oleh $(...)
atau cmd1 || cmd2 &
- bukan shell yang dipanggil, dan IFS-nya (bersama dengan sebagian besar lingkungan eksekusinya) identik dengan induknya. Shell yang dipanggil menetapkan nilai $
untuk pidnya, sementara subkulit mewarisinya.
Ini bukan semata-mata pembebasan dendam; ada perbedaan nyata dalam bidang ini. Berikut ini adalah skrip singkat yang menguji skenario menggunakan beberapa shell yang berbeda. Ini mengekspor IFS yang dimodifikasi (diatur ke :
) ke shell yang dipanggil yang kemudian mencetak IFS default.
$ cat export-IFS.sh
export IFS=:
for sh in bash ksh93 mksh dash busybox:sh; do
printf '\n%s\n' "$sh"
$sh -c 'printf %s "$IFS"' | hexdump -C
done
IFS umumnya tidak ditandai untuk ekspor, tetapi, jika ya, perhatikan bagaimana bash, ksh93, dan mksh mengabaikan lingkungan mereka IFS=:
, sementara dash dan busybox menghormatinya.
$ sh export-IFS.sh
bash
00000000 20 09 0a | ..|
00000003
ksh93
00000000 20 09 0a | ..|
00000003
mksh
00000000 20 09 0a | ..|
00000003
dash
00000000 3a |:|
00000001
busybox:sh
00000000 3a |:|
00000001
Beberapa info versi:
bash: GNU bash, version 4.3.11(1)-release
ksh93: sh (AT&T Research) 93u+ 2012-08-01
mksh: KSH_VERSION='@(#)MIRBSD KSH R46 2013/05/02'
dash: 0.5.7
busybox: BusyBox v1.21.1
Meskipun bash, ksh93, dan mksh tidak menginisialisasi IFS dari lingkungan, mereka mengekspor kembali IFS yang dimodifikasi.
Jika karena alasan apa pun Anda perlu melewati IFS dengan mudah melalui lingkungan, Anda tidak dapat melakukannya dengan menggunakan IFS itu sendiri; Anda perlu menetapkan nilai ke variabel yang berbeda dan menandai variabel itu untuk ekspor. Anak-anak kemudian perlu secara eksplisit menetapkan nilai itu ke IFS mereka.