Saya bertemu masalah yang sama juga.

FYI Saya menggunakan OSX Yosemite jika itu penting, menggunakan iTerm2!

Sudahkah Anda meningkatkan XCode Anda?

Saya memperbaiki masalah ini dengan:

brew doctor
xcode-select --install
brew update
brew upgrade

@meisheep Ya, versi Xcode saya adalah 7, dan setelah pembaruan brew masih ada masalah

Itu terjadi sama pada saya ketika sudo -E -s . Periksa apakah sudo adalah alias dengan alias sudo .

Ini sebenarnya adalah dua masalah yang menurut saya:

• command not found: compdef sudah dilaporkan di #4378
• sudo -s memberikan peringatan karena izin yang salah

Oleh karena itu saya telah membuat masalah baru tentang masalah ke-2 di #4388 dan menyarankan untuk menutup tiket ini karena itu.

Saya punya masalah ini juga.

@mccornella Saya memeriksa alias saya dan sudo adalah alias untuk nocorrect sudo

Juga, saya menggunakan rilis XCode saat ini serta versi terbaru dari Brew.

Mendapatkan compdef kesalahan di Mavericks, 10.9.5 juga.

#3889 yang baru saja digabungkan memengaruhi urutan startup penyelesaian.

Secara khusus, itu menghapus opsi -i ke compinit , yang memberi tahu compinit untuk mengabaikan direktori yang tidak aman secara diam-diam. Sekarang setelah itu hilang, jika compinit menemukan direktori yang tidak aman, itu akan meminta Anda atau menolak seperti ini. "Direktori tidak aman" yang disebutkan mungkin ada sebelumnya, dan ini hanya perubahan dalam konfigurasi zsh, dan bukan hal-hal yang diinstal pada sistem Anda.

Lihat #3889 untuk diskusi.

Saya pikir ini adalah masalah dengan compinit tanpa -i tidak kompatibel dengan sudo -s , atau sudo yang meluncurkan shell interaktif. Saya mendapatkan masalah yang sama meskipun izin saya "benar", seperti halnya @ShaoXinSen .

[~/.oh-my-zsh on ⇄ master]
$ sudo -s
Password:
[oh-my-zsh] Insecure completion-dependent directories detected:
lrwxr-xr-x    1 janke  staff    23 Sep 15 01:24 /Users/janke/.oh-my-zsh -> local/opp/omz/oh-my-zsh
drwxr-xr-x  208 janke  staff  7072 Sep 23 15:08 /Users/janke/.oh-my-zsh/plugins
drwxr-xr-x    4 janke  staff   136 Sep 19 15:11 /Users/janke/.oh-my-zsh/plugins/brew
-rw-r--r--    1 janke  staff  3790 Sep 19 15:11 /Users/janke/.oh-my-zsh/plugins/brew/_brew
drwxr-xr-x    7 janke  staff   238 Sep 19 15:11 /Users/janke/.oh-my-zsh/plugins/emoji
[...]
[oh-my-zsh] For safety, completions will be disabled until you manually fix all
[oh-my-zsh] insecure directory permissions and ownership and restart oh-my-zsh.
[oh-my-zsh] See the above list for directories with group or other writability.

[oh-my-zsh] Insecure completion caches also detected:
-rw-r--r--  1 janke  staff  35292 Sep 15 01:22 /Users/janke/.zcompdump
-rw-r--r--  1 janke  staff  35453 Sep 15 01:24 /Users/janke/.zcompdump-new-spiffy-5.0.2
-rw-r--r--  1 janke  staff  35453 Sep 21 15:10 /Users/janke/.zcompdump-spiffy-5.0.2
[oh-my-zsh] Moving to "/Users/janke/.oh-my-zsh/cache//zcompdump-bad/"...

[# root<strong i="11">@spiffy</strong> ~/local/opp/omz/oh-my-zsh on ⇄ master]

Saya pikir masalahnya adalah ketika Anda sudo , keamanan dievaluasi dari perspektif id pengguna efektif Anda ( root ), tetapi Anda masih memiliki penyelesaian dari pengguna biasa Anda di jalur ( janke dalam kasus saya). Saya tidak berpikir ada cara untuk menyelesaikannya dengan konfigurasi file. compinit -i tampak seperti Hal yang Tepat untuk menangani kasus di mana identitas pengguna Anda mungkin berubah selama sesi tanpa mengulang semua jalur Anda untuk mencocokkannya.

Memulihkan -i ke panggilan compinit pada .oh-my-zsh mungkin adalah cara yang tepat untuk menangani ini, dari apa yang saya lihat. Anda dapat melakukannya dengan pemeriksaan bersyarat untuk melihat apakah Anda melakukan root, tetapi masalah ini sepertinya juga akan mempengaruhi sudo -ing ke pengguna non-root juga (pada sistem yang mendukungnya).

Hanya chmod 755 /Users/charlespantoga/.oh-my-zsh dan seterusnya ~
Ini bekerja dengan baik untuk saya ~

Bahkan ketika Anda melakukan sudo -s ? ~/.oh-my-zsh sudah mode 755 , dan begitu juga poster aslinya.

Mendapatkan masalah serupa sejak pemutakhiran terakhir, setiap kali jendela terminal baru dibuka di Ubuntu:

[oh-my-zsh] Insecure completion-dependent directories detected:
dan
[oh-my-zsh] Insecure completion caches also detected:

melakukan chmod 755 int dia folder zsh memperbaikinya, tetapi masalahnya kembali setelah beberapa saat. Juga beberapa penyelesaian tidak berfungsi setelah pemutakhiran bahkan setelah menyetel izin ke 755, misalnya penyelesaian git untuk cabang yang memiliki garis miring, misalnya feature/123 tidak akan dilengkapi secara otomatis, tetapi feature123 akan.

@nihilnovi : sepertinya kode perbaikan izin mungkin tidak memperbaiki semua direktori "tidak aman" untuk Anda. Apa yang Anda dapatkan untuk output compaudit ? (Jalankan dari akun yang mengalami masalah penyelesaian, dalam sesi di mana pesan kesalahan itu muncul.)

@apjanke

There are insecure directories:
/home/mike/.zsh/completion
/home/mike/.zsh

Hmm. Itu bukan direktori standar yang dikontrol OMZ. Apakah Anda menciptakannya sendiri? Apakah ada perangkat lunak sinkronisasi yang mengendalikannya, mungkin? Apa yang ls -lda tunjukkan untuk izin mereka sekarang? Saya tidak tahu mengapa itu akan berulang jika Anda sudah chmod 755 mengedit direktori tersebut.

Ketika ini terjadi, apakah Anda melakukan semacam sudo ? Atau apakah ini sesi terminal normal? Dan apa umask ?

Tidak, saya tidak melakukan apa pun kecuali menjalankan upgrade_oh_my_zsh , kesalahan yang saya dapatkan bukan dari folder itu, melainkan dari .oh-my-zsh/ .
.zsh izin adalah drwxrwxr-x , saya tidak melakukan apa pun pada direktori itu.

umask adalah 002

Setelah melakukan git reset --hard origin/master di .oh-my-zsh/ dan menghapus plugin git-extra di .zshrc kesalahan tampaknya telah hilang, akan dilaporkan jika kembali.

Umask Anda mungkin 022 . Jika 002 , direktori apa pun yang Anda buat akan "tidak aman" dari sudut pandang zsh.

Perubahan terbaru di OMZ bukan untuk membuat direktori itu; itu untuk mengubah bagaimana inisialisasi OMZ dari sistem penyelesaian Zsh (dengan compinit ) memperlakukan direktori yang tidak aman. (Dulu diam-diam mengabaikannya; sekarang ia mencoba memperbaikinya secara otomatis, dan akan membiarkan Zsh mengeluh tentang yang belum diperbaiki sehingga Anda dapat membersihkannya.) Jadi, bahkan jika Anda belum melakukan apa pun pada direktori itu akhir-akhir ini, keadaannya mungkin yang menyebabkan Zsh error.

Direktori ~.zsh itu tidak aman. drwxrwxr-x adalah mode 775 . (Yang akan Anda buat jika umask adalah 002 .) Ubah ke 755 dengan chmod -R 755 ~/.zsh dan kesalahan ini akan hilang.

Kesalahan mungkin disebabkan oleh skrip yang dijalankan dari ~/.oh-my-zsh , tetapi mungkin disebabkan oleh status file di luar direktori itu. Secara khusus, sistem penyelesaian akan memeriksa izin semua direktori. Output dari compaudit memberi tahu Anda direktori mana yang tidak disukai.

Terima kasih banyak atas bantuan dan informasi Anda, saya telah belajar sedikit dari ini :)

Tampaknya umask adalah 002 karena ini:

Enables setting of the umask group bits to be the same as owner bits (examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is the same as gid, and username is the same as the primary group name.

dari http://askubuntu.com/questions/44542/what-is-umask-and-how-does-it-work di bawah A note on the default umask , jadi saya tidak yakin apakah saya harus mengutak-atik default Pengaturan umask Ubuntu karena OMZ.

Menarik. Saya tidak tahu tentang USERGROUP umask itu; akan melihat ke dalamnya. Terimakasih atas peringatannya. (BTW, adakah yang tahu _why_ Ubuntu/PAM melakukan 002 bukannya 022 ?)

Bukan hanya OMZ yang membutuhkan direktori ini menjadi 755 , tetapi Zsh itu sendiri: compaudit adalah perintah dasar Zsh.

Kita harus berhati-hati dengan pengguna Ubuntu lainnya.

Masalah yang sama di sini:
[oh-my-zsh] Direktori yang bergantung pada penyelesaian tidak aman terdeteksi:
dr-xr-xr-x 3 admin admin 102 11 Sep 17:20 /usr/local/share/zsh
dr-xr-xr-x 3 admin admin 102 11 Sep 17:20 /usr/local/share/zsh/site-functions
lrwxr-xr-x 1 admin admin 74 11 Sep 17:20 /usr/local/share/zsh/site-functions/_youtube-dl -> ../../../Cellar/youtube-dl/2015.09.09 /share/zsh/site-functions/_youtube-dl
[oh-my-zsh] Demi keamanan, penyelesaian akan dinonaktifkan sampai Anda memperbaiki semuanya secara manual
[oh-my-zsh] izin dan kepemilikan direktori tidak aman dan mulai ulang oh-my-zsh.
[oh-my-zsh] Lihat daftar di atas untuk direktori dengan grup atau kemampuan menulis lainnya.

/Users/macgeneral/.oh-my-zsh/plugins/git/git.plugin. zsh:81 : perintah tidak ditemukan: compdef
[..]

Saya baru saja menggunakan
sudo mv /usr/local/share/zsh /usr/local/share/zsh.bak dan sekarang berfungsi lagi - tidak tahu apakah saya merusak apa pun selain penyelesaian youtube_dl;)

setelah itu saya mencopot youtube-dl yang tidak saya gunakan tetapi segera setelah saya menginstalnya kembali ada kesalahan yang sama - mana yang akan menjadi izin direktori "aman"?

@macgeneral : Itu akan merusak barang zsh diinstal Homebrew, termasuk dukungan penyelesaian zsh yang diinstal sebagai bagian dari paket yang disediakan oleh Homebrew. Tetapi penyelesaian tersebut sudah rusak, karena zsh melihat direktori tersebut sebagai tidak aman dan menolak untuk memuatnya; itu hanya diam-diam mengabaikan mereka sebelumnya, karena opsi -i .

Izin ini sepertinya aman; hanya saja zsh tidak mengenalinya karena dimiliki oleh admin dan tidak secara khusus oleh root . zsh hanya akan mengenali mereka sebagai aman jika mereka dimiliki oleh root atau Anda sendiri ( macgeneral dalam kasus ini, saya pikir). Jadi, chown -R macgeneral /usr/local akan membuat zsh menganggapnya aman. Tapi itu mungkin bukan cara Anda ingin mengelola instalasi Homebrew Anda. IMHO, memiliki Homebrew atau instalasi lain yang dikelola oleh pengguna peran non- root adalah pengaturan yang sah.

Dalam kasus Anda, sepertinya compinit -i adalah Hal yang Benar; mungkin OMZ harus memberikan opsi untuk itu, dan untuk menekan pengumuman tentang direktori yang tidak aman. Sejauh mendapatkan zsh untuk bekerja sepenuhnya dengan instalasi Homebrew non- root , bukan milik sendiri, saya tidak tahu... Saya pikir Anda mungkin terjebak karena harus menginstal Homebrew lakukan sendiri jika Anda ingin penyelesaian zsh berfungsi, karena itulah skenario yang didukung oleh Homebrew sendiri.

Jadi apa solusi terbaik?

Ini mungkin tidak membantu tetapi, ketika menjalankan compaudit sebagai pengguna normal saya, saya tidak menghasilkan apa-apa. Ketika saya menjalankan sudo -s saya mendapatkan:

/Users/charlespantoga/.oh-my-zsh/plugins/brew
/Users/charlespantoga/.oh-my-zsh/plugins/git
/Users/charlespantoga/.oh-my-zsh/plugins
/Users/charlespantoga/.oh-my-zsh/plugins
/Users/charlespantoga/.oh-my-zsh
/Users/charlespantoga/.oh-my-zsh
/Users/charlespantoga/.oh-my-zsh/plugins/brew/_brew

Dan ketika saya menjalankan sudo -i saya mendapatkan daftar LONGGGGG direktori yang 'tidak aman'. Faktanya, ia memandang setiap fungsi zsh sebagai tidak aman.

There are insecure directories and files:
/Users/charlespantoga/.oh-my-zsh/plugins/brew
/Users/charlespantoga/.oh-my-zsh/plugins/git
/usr/local/share/zsh/site-functions
/usr/local/Cellar/zsh/5.1.1/share/zsh/functions
/Users/charlespantoga/.oh-my-zsh/plugins
/Users/charlespantoga/.oh-my-zsh/plugins
/Users/charlespantoga/.oh-my-zsh
/Users/charlespantoga/.oh-my-zsh
/usr/local/share/zsh
/usr/local/Cellar/zsh/5.1.1/share/zsh
/Users/charlespantoga/.oh-my-zsh/plugins/brew/_brew
/usr/local/Cellar/zsh/5.1.1/share/zsh/functions/_SUSEconfig
/usr/local/Cellar/zsh/5.1.1/share/zsh/functions/_a2ps
...
/usr/local/Cellar/zsh/5.1.1/share/zsh/functions/_zypper

Saya tidak menggunakan sistem zsh, saya menggunakan minuman yang diinstal ZSH.

Saya percaya compaudit memandang file-file ini sebagai tidak aman karena root (pengguna yang masuk melalui sudo -s ) tidak memiliki akses tulis ke sana. Saya pikir ini lebih merupakan fitur dan bukan bug ...

@ShaoXinSen @apjanke apa pendapat Anda?

Mungkin "bug" dalam hal ini adalah bahwa OMZSH harus menangani compaudit/compinit secara berbeda saat melakukan sudo ke pengguna lain. Misalnya, ast @apjanke yang dinyatakan sebelumnya, seharusnya menggunakan flag -i saat root.

@varcharlez : Tidak, compaudit melihatnya sebagai tidak aman ketika Anda root karena dimiliki oleh, dan dengan demikian dapat ditulis oleh, pengguna non-root. Direktori yang tidak aman adalah direktori yang dapat ditulis oleh pengguna yang a) bukan root dan b) bukan Anda. Dan ya, saya setuju bahwa itu adalah fitur dan bukan bug.

Secara umum, saya akan merekomendasikan _not_ menjalankan OMZ sebagai root, dan karenanya tidak melakukan sudo -s .

Saya tidak tahu apa hal terbaik untuk dilakukan di sini. Saya mulai berpikir kita harus memasukkan kembali -i untuk semua kasus, karena ada pengaturan pengguna yang sah yang akan memiliki direktori tidak aman yang tidak dapat "diperbaiki" oleh perubahan konfigurasi apa pun, dan kami tidak ingin untuk selalu mengomel dalam kasus-kasus itu. Keamanan tidak perlu menonaktifkan penyelesaian sepenuhnya. Kami mungkin juga harus menambahkan opsi untuk menonaktifkan fitur penonaktifan penyelesaian, sehingga pengguna dapat menghindari pesan tersebut saat memulai.

Memperbaiki untuk saya dengan chmod 755 /home/myuser/.oh-my-zsh/plugins/git dan chmod 755 /home/myuser/.oh-my-zsh/plugins/ Itu terjadi setelah pembaruan dan saya pikir alasannya adalah izin yang salah di versi baru.
Lihat di mana kesalahan dalam kasus Anda dan ubah izin dan itu akan berfungsi.

Pertanyaan utama di sini adalah apakah sudo -s harus dikecilkan atau tidak. Saya mengerti bahwa salah menulis file cache sebagai pengguna 1 yang kemudian terlihat oleh pengguna 2.

Namun, saya rasa banyak pengguna yang menggunakan sudo -s untuk menjalankan perintah tertentu dalam direktori home mereka menggunakan hak akses root. Tidak ada yang salah dengan ini, jadi saya lebih suka berpikir bahwa oh-my-zsh harus menemukan solusi yang dapat mengatasi situasi tersebut.

Saran saya adalah memindahkan direktori cache dari direktori $HOME. Saya melihat bahwa Midnight Commander menggunakan direktori /tmp/mc-root untuk menyimpan data sementara yang memiliki izin drwx------ (700) dan saya pikir kita harus melakukan hal yang sama untuk oh-my-zsh.

Oh My Zsh tidak banyak diaudit untuk keamanan atau kebenaran, dan ini rumit. Bahkan jika kami memperbaiki masalah ini, saya tetap tidak akan merekomendasikan menjalankannya sebagai root atau dengan sudo -s .

Tapi itu tidak berarti kita tidak bisa atau tidak boleh memperbaikinya.

Memindahkan lokasi cache terdengar seperti ide yang bagus. Mungkin tidak tanpa syarat: bahwa data cache dimaksudkan untuk bertahan di banyak sesi, dan /tmp bersifat volatil, jadi untuk kasus biasa Anda mungkin masih menginginkannya di $ZSH_CACHE_DIR . Tapi kita bisa memindahkannya untuk kasus sudo (dengan memeriksa $SUDO_USER != $USER atau yang serupa). Tempelkan di bawah subdirektori per pengguna di bawah $TMPDIR dengan izin yang tepat.

File cache .zcompdump tidak disimpan di bawah $ZSH_CACHE_DIR ; mereka ditempatkan langsung di bawah $HOME . Keduanya dan $ZSH_CACHE_DIR mungkin harus dipindahkan dalam kasus sudo jika kita melakukan ini. Atau Anda tidak bisa menggunakan cache .zcompdump saat berjalan di bawah sudo .

Dan kemudian kita tidak perlu menghapus file .zcompdump . Itu ketidaknyamanan karena Anda perlu menghabiskan waktu eksekusi untuk membuat ulang, dan mekanisme saat ini meninggalkan file di bawah direktori home Anda yang mungkin tidak dapat Anda tulis.

[~/.oh-my-zsh/cache on ⇄ master]
$ ls -l
total 0
drwxr-xr-x  6 root  staff 204 Sep 28 05:50 zcompdump-bad
[~/.oh-my-zsh/cache on ⇄ master]
$ rm zcompdump-bad/.zcompdump
rm: zcompdump-bad/.zcompdump: Permission denied

@nihilnovi : Sepertinya compaudit sudah memiliki kode untuk mendeteksi hal-hal per-pengguna-grup itu , meskipun itu tidak efektif untuk kasus ketika Anda melakukan sudo .

Akar masalah ini adalah penggabungan #3889 (https://github.com/robbyrussell/oh-my-zsh/commit/56cdec75348cc7c33f54c5441884238c25a6597b) yang diperkenalkan oleh @leycec. Jika saya mengerti dengan benar, tujuannya adalah untuk menekan peringatan compdef dan bukan untuk meningkatkan keamanan.

Namun, saya pikir masalah ini telah diperbaiki dengan memindahkan perintah autoload atas (lihat diff) dan tidak perlu menghapus -i dari panggilan compinit . Karenanya saya menyarankan tiga perubahan ini:

• lewati pemeriksaan izin compaudit saat dijalankan sebagai root
• jalankan compinit meskipun compaudit gagal
• jalankan compinit menggunakan flag -i (abaikan direktori yang tidak aman)

Lihat https://github.com/stucki/oh-my-zsh/commits/fix-4383. Saya belum membuat permintaan tarik, menunggu umpan balik tentang pendekatan ini terlebih dahulu.

Selain itu, jika Anda benar-benar ingin memperbaiki masalah keamanan saat menggunakan sudo -s , saya sarankan untuk memeriksa apakah $ZSH_CACHE_DIR dimiliki oleh $USER , dan hentikan dengan peringatan jika ini tidak disarankan .

Jika tidak, seperti yang sudah disebutkan sebelumnya, masalah yang diketahui dengan sudo -s harus (dan bisa!) diselesaikan, lihat #3891.

Satu hal lagi: Saya juga mencoba memecahkan masalah ini dengan menyetel ZSH_COMPDUMP ke sesuatu yang berbeda (mis. tambahkan $USER ke nama file). Ternyata ini tidak semudah kelihatannya:

• compaudit masih akan memberikan peringatan untuk file lain milik OMZ (lihat #4388)
• $ZSH_COMPDUMP diabaikan di Ubuntu (setidaknya) ketika compinit dipanggil awalnya oleh /etc/zsh/zshrc . Ini terjadi sebelum .zshrc lokal saya dibaca, sehingga tidak dapat diubah oleh OMZ:

$  tail /etc/zsh/zshrc 

# If you don't want compinit called here, place the line
# skip_global_compinit=1
# in your $ZDOTDIR/.zshenv or $ZDOTDIR/.zprofile
if [[ -z "$skip_global_compinit" ]]; then
  autoload -U compinit
  compinit
fi

Saran di komentar memecahkan masalah, tetapi membutuhkan tindakan manual ...

Mulai melihat ini hari ini juga, tepat setelah menjalankan pembaruan di oh-my-zsh. Saat masuk ke mesin yang terpengaruh (Pengujian Debian) dengan ssh atau membuka terminal, saya akan melihatnya
"[oh-my-zsh] Direktori yang bergantung pada penyelesaian tidak aman terdeteksi:
(berbagai /home/user/dirs)"

menjalankan compaudit yang pada dasarnya mengeluarkan semua file di /home/user/oh-my-zsh.
*lari chmod -R 755 /home/user/.oh-my-zsh
untuk menyelesaikan.
* Ini bukan saran - ini hanya apa yang saya lakukan untuk menghilangkan kesalahan.

@fiver22 : chmod itu adalah perbaikan yang tepat dalam kasus Anda: itulah yang compaudit ingin Anda lakukan, dan mengapa pesan kesalahan ini diekspos sejak awal. Anda bisa melanjutkan dan memanggil saran itu. :)

@stucki : Saya mendukung pendekatan umum perbaikan Anda. Saya pikir kita perlu memperbaikinya sedikit, jadi ini bukan hanya cara memutar untuk mengembalikan #3889.

Secara khusus, hal utama yang #3889 coba lakukan adalah menghindari pembuatan file .zcompdump merosot jika compinit -i akhirnya mengabaikan banyak direktori yang tidak aman. Mungkin itu berarti kita harus menggunakan -D untuk menghindari pembuatan file cache jika compaudit melihat masalah.

$ZSH_COMPDUMP diabaikan di Ubuntu (setidaknya) ketika compinit dipanggil awalnya oleh /etc/zsh/zshrc. Ini terjadi sebelum .zshrc lokal saya dibaca, jadi tidak dapat diubah oleh OMZ ...

Saya _think_ kita benar-benar dapat menangani ini di .zshrc . Pertama kali /etc/zsh/zshrc berjalan dalam sesi shell login, itu masih memiliki default $FPATH , dan direktori di dalamnya akan aman, sehingga tidak akan memunculkan pesan kesalahan atau meminta. Dan itu akan menghasilkan cache .zcompdump di lokasi default. Kemudian OMZ, berjalan dari pengguna ~/.zshrc , menambahkan direktori yang mungkin bermasalah ke $FPATH , dan membuatnya sendiri .zcompdump . Satu-satunya saat global /etc/zsh/zshrc akan melihat dir $FPATH adalah ketika Anda memanggilnya dari subkulit (misalnya menjalankan zsh -i dari dalam zsh ) dan ia melihat perubahan yang telah dilakukan OMZ pada $FPATH diekspor dan variabel lain – dalam hal ini ia dapat mengatur dan mengekspor $skip_global_compinit dari ~/.zshrc , dan /etc/zsh/zshrc akan melihatnya sebagian besar waktu itu penting.

Ini semakin kacau.

Dan, satu lagi faktor rumit: mungkin ada bug di compinit -i itu sendiri terkait dengan pengecualian direktori dengan orang tua yang tidak aman, di mana seharusnya, tetapi sebenarnya tidak, mengabaikannya.

Ini semakin kacau.

Benar sekali. Saya masih mendukung pengembalian sebagian besar hal yang #3889 ubah. Masalah asli yang coba dipecahkannya adalah masalah yang berbeda (ini tentang memindahkan perintah autoload ), dan tampaknya perubahan tersebut memiliki terlalu banyak efek samping yang tidak diinginkan.

Lihat juga diskusi di https://github.com/stucki/oh-my-zsh/commit/bcb45cae1295b2dc918125892d404f52ae6ad42f. Saran saya saat ini adalah menghapus cek compaudit dan fungsi handle_completion_insecurities .

Masalah asli yang coba dipecahkan adalah masalah yang berbeda (ini tentang memindahkan perintah autoload)

Ini bukan tentang memindahkan autoload . Itu masalah pemformatan kode yang tidak signifikan, dan sejauh yang saya tahu tidak berpengaruh kecuali membuat compaudit tersedia. Motivasi utamanya adalah untuk:

• Cegah pembuatan file .zcompdump rusak/rusak jika compinit -i berakhir dengan mengecualikan banyak direktori. .zcompdumps Rusak adalah masalah yang sering terjadi pada OMZ, dan ini dapat membantu beberapa.
• Beri tahu pengguna bahwa beberapa definisi penyelesaian mereka diabaikan, sehingga mereka tidak hanya bertanya-tanya "mengapa beberapa penyelesaian saya tidak berfungsi?"
• Sesuatu tentang keamanan, saya pikir.

Salah satu tujuan awalnya juga untuk secara otomatis memperbaiki direktori yang tidak aman, sehingga penyelesaiannya akan mulai bekerja. Tapi itu ditinggalkan karena terlalu rumit atau tidak bisa dijalankan, saya pikir.

3889 adalah utas raksasa, dan hal-hal di sana banyak berubah selama diskusi. Mungkin @leycec atau orang lain dapat meringkas maksud #3889 dan mekanisme yang masuk ke perubahan kode aktual dalam beberapa paragraf, jadi kami memiliki dasar yang lebih baik untuk diskusi.

Mengingat efek samping dan kerusakan, saya juga mendukung sebagian besar mengembalikan semua barang #3889 baru sampai dapat diuji lebih lanjut. Sebaiknya dengan membiarkannya dalam basis kode dan meletakkannya di belakang centang $ZSH_DISABLE_COMPFIX yang defaultnya adalah true untuk saat ini, jadi mudah untuk menguji dan melihat bagaimana ia berinteraksi dengan kode lain.

Sesuai dengan judulnya, #3889 hanya tentang Cygwin. Namun, seperti yang kita lihat, ini memengaruhi lebih banyak platform.
Oleh karena itu: Ya tolong, kembalikan cek compaudit untuk saat ini dan lihat apakah ada yang memberikan solusi umum...

Inilah PR yang mematikannya secara default: #4426

Ini akan mengembalikan perilaku compinit secara default untuk pengguna, membuat pesan kesalahan sudo -s hilang, dan membiarkan semua kode #3889 tetap utuh sehingga Anda dapat mengujinya dengan memutar pengaturan ZSH_DISABLE_COMPFIX=false di ~/.zshrc sebelum memuat OMZ.

(Yah, itu akan memperbaiki banyak pesan kesalahan sudo . File cache yang merosot masih akan merusak banyak hal.)

Jika ini digabungkan, semua orang yang masih mengalami masalah setelah memperbarui harus rm -f ~/.zcompdump* untuk menghapus cache penyelesaian yang basi.

Terima kasih!

terima kasih atas perbaikannya. sepertinya menonaktifkan pembaruan otomatis adalah cara yang harus saya lakukan di masa depan. Saya telah dibakar beberapa kali oleh pembaruan yang membuat saya kurang produktif;)

DISABLE_UPDATE_PROMPT=true
DISABLE_AUTO_UPDATE=true

chmod -R 755 <Insecure completion-dependent directories path>

chmod -R 755

Melakukan chmod tidak cukup untuk memperbaikinya sudo , karena setelah Anda sudo , zsh melakukan pemeriksaan yang menganggap Anda sebagai root, dan beberapa direktori tersebut mungkin dimiliki oleh pengguna normal, jadi zsh akan menganggap mereka tidak aman saat Anda berada di sudo .

Ya, hanya memutakhirkan ke versi oh-my-zsh saat ini sudah cukup. Maaf bila membingungkan!

Saya mendapatkan masalah serupa, tetapi ketika saya mencoba memanggil zsh dari bash. Adakah yang punya ide bagaimana cara memperbaikinya?

‣ bash
bash-3.2$ /bin/zsh -l -c "which fastlane"
complete:13: command not found: compdef
/usr/local/opt/rbenv/shims/fastlane

@ohwutup mengomentari #4771 yang merupakan masalah sebenarnya Anda.

@ohwutup juga jika Anda menjalankan AWS atau menggunakan aws-cli, kami menemukan solusinya. Coba lihat.

Mengatur pemilik direktori .oh-my-zsh (rekursif) ke root dan mengubah izin ke drwxr-xr-x memperbaikinya untuk saya