where.exe tidak menemukan lib OpenSSL ketika variabel% ProgramFiles% digunakan dalam variabel lingkungan PATH

Saya menginstal versi OpenSSL 32bit dan 64bit pada Vista x64. Versi 32bit diinstal pada c:\Program Files (x86)\OpenSSLdan versi 64bit diinstal pada c:\Program Files\OpenSSL. Kemudian saya menambahkan entri %ProgramFiles%\OpenSSLke PATHvariabel lingkungan. %ProgramFiles%\OpenSSLdiperluas ke c:\Program Files (x86)\OpenSSLuntuk program 32bit dan diperluas ke c:\Program Files\OpenSSLuntuk program 64bit. Idenya adalah untuk memiliki program 32bit menggunakan versi 32bit OpenSSL libs dan program 64bit menggunakan versi 64bit. Saya ingin memeriksa apakah ini berfungsi dengan menjalankan 32bit cmd.exe dan mengeluarkan where ssleay32.dlldan kemudian dengan menjalankan 64bit cmd.exe dan mengeluarkan yang sama. Namun dalam kedua kasus saya mendapatkan kesalahan. INFO: Could not find files for the given pattern(s).
Apa yang salah?

Ini adalah tindak lanjut untuk variabel lingkungan PATH berbeda untuk Windows 32bit dan 64bit - apakah mungkin?

— Piotr Dobrogost
sumber

Apa yang terjadi ketika Anda mencari openssl.exe, daripada dll? Juga, sudahkah Anda mencoba metode lain, seperti mengeksekusi openssl.exe dalam cmd untuk melihat apakah itu yang benar? (Anda dapat menggunakan Monitor Proses untuk melihat yang menjalankan versi openssl.exe). Mungkin "di mana" tidak bekerja dengan baik di lingkungan Anda.

— harrymc

where openssl.exemenemukan satu di folder OpenVPN yang setelah OpenSSL satu di PATH.

— Piotr Dobrogost

Saya pikir Anda telah membuktikan dengan sangat baik bahwa% ProgramFiles% tidak berfungsi seperti yang diharapkan dalam PATH. Mungkin cmd -k akan bekerja dengan parameter "set path =% path%;% ProgramFiles% \ OpenSSL", atau kombinasi lainnya.

— harrymc

Jawaban:

Masukkan 32bit .DLLs ke dalam direktori \ Windows \ SysWOW64 dan DLL 64bit ke dalam direktori \ Windows \ system32.

EDIT:

Mungkin ini membantu:

Ini hanya dugaan yang cerdas, tetapi setelah beberapa penyelidikan saya yakin saya telah menemukan masalahnya:

Jika definisi variabel lingkungan var1 berisi variabel lingkungan lain var2 dan nama var1 secara alfabet kurang dari nama var2 (yaitu strcmp (v1, var2) <0), maka var2 tidak akan diperluas. Ini sepertinya karena ketika Windows pertama mengatur variabel lingkungan, mereka dibuat dalam urutan abjad, sehingga var2 tidak ada sampai setelah var1 telah dibuat (dan ekspansi tidak dapat dilakukan).

Saya percaya ini adalah batasan di Windows. Benar-benar semacam pemeriksaan ketergantungan antara variabel harus dilakukan sehingga mereka dibuat dalam urutan yang benar. Untungnya, ada solusinya.

1) Aktifkan 'ekspansi variabel tertunda' di registri (lihat http://batcheero.blogspot.com/2007/06/how-to-enabledelayedexpansion.html )

2) Ubah tanda '%' di sekitar var2 menjadi '!', Mis. "% Var2%" menjadi "! Var2!"

Saya telah melakukan beberapa pengujian terbatas pada Windows 7 dan ini tampaknya memperbaiki masalah.

Itu dari sini: http://social.answers.microsoft.com/Forums/en-US/vistainstall/thread/48b23109-9fbc-47c5-a5d1-465773f94704

— Darokthar
sumber

Kenapa harus saya? Pengaturan saya saat ini harus bekerja. Saya ingin tahu mengapa tidak.

— Piotr Dobrogost

Itu tidak bekerja, itu sebabnya Anda harus mencobanya. Saya mengerti bahwa itu harus berhasil. Saya hanya berusaha membantu. Dan windows sedang mencari path di atas untuk. DLL. Jika berfungsi seperti itu saya tidak akan peduli mengapa konfigurasi lainnya tidak berfungsi. Mungkin itu bug atau berfungsi sebagaimana mestinya. Kami tidak tahu ... Jelas tidak ada orang lain yang tahu atau mau menjawab. Cobalah atau biarkan apa adanya ...

— Darokthar

Jika berfungsi seperti itu saya tidak akan peduli mengapa konfigurasi lainnya tidak berfungsi. Saya peduli :)

— Piotr Dobrogost

@Piotr Dobrogost Saya tidak peduli dengan hadiahnya. Jika Anda memberikannya kepada saya atau tidak, itu tidak masalah bagi saya. Tetapi saya baru saja menemukan hal-hal yang saya edit ke dalam pos ...

— Darokthar

Mengatur ekspansi variabel yang tertunda dalam registri membuat output echo %path%jalur tampilan dengan% ProgramFiles% diperluas dengan benar. Namun, where.exe masih tidak menangani jalur seperti itu.

— Piotr Dobrogost

Sepertinya harrymc benar mengatakannya

Saya pikir Anda telah membuktikan dengan sangat baik bahwa% ProgramFiles% tidak berfungsi seperti yang diharapkan dalam PATH.

Yang aneh adalah saya tidak dapat menemukan informasi tentang masalah ini menggunakan google ...

Solusi yang saya gunakan terinspirasi oleh ide dalam jawaban Darokthar;
Saya terhubung
c:\windows\system32\OpenSSL-binke c:\Program Files\OpenSSL\bin
dan
c:\windows\SysWOW64\OpenSSL-binke c:\Program Files (x86)\OpenSSL\bin
dan ditambahkan c:\windows\system32\OpenSSL-binke PATH.

— Piotr Dobrogost
sumber

Root dari prob: omong kosong "abjad" di Windows (yaitu envvar1tidak diperluas di dalam yang lain envvar2jika envvar2"datang lebih dulu" menurut abjad).

Solusi saya: lupakan tentang penggunaan %ProgramFiles%sepenuhnya, bahkan dengan ekspansi variabel yang tertunda. Alih-alih membuat envvar lain, disebut _ProgFilesatau serupa: garis bawah utama akan berarti bahwa semua envvars yang mengikutinya menurut abjad akan menggunakannya sebagai diperluas dengan benar ...

Jadi PATH Anda akan membaca ... ;%_ProgFiles%\OpenSSL;...atau semacamnya.

— mike rodent
sumber