it-swarm-id.com

Mengapa kita menggunakan "./" (dot slash) untuk mengeksekusi file di Linux / UNIX?

Mengapa kami menggunakan ./filename untuk mengeksekusi file di linux?

Mengapa tidak memasukkan saja seperti perintah lain gcc, ls dll ...

89
Renjith G

Di Linux, UNIX dan sistem operasi terkait, . Menunjukkan direktori saat ini. Karena Anda ingin menjalankan file di direktori Anda saat ini dan direktori itu tidak ada di $PATH Anda, Anda memerlukan bit ./ Untuk memberi tahu Shell di mana executable berada. Jadi, ./foo Berarti menjalankan executable yang disebut foo yang ada di direktori ini.

Anda dapat menggunakan type atau which untuk mendapatkan path lengkap dari perintah yang ditemukan di $PATH Anda.

80
badp

Jawaban literalnya adalah seperti yang diberikan orang lain: karena direktori saat ini tidak ada dalam $PATH Anda.

Tapi kenapa? Singkatnya, ini untuk keamanan. Jika Anda mencari di direktori home orang lain (atau/tmp), dan ketikkan saja gcc atau ls, Anda ingin tahu bahwa Anda menjalankan yang asli, bukan versi jahat Anda teman iseng telah menulis yang menghapus semua file Anda. Contoh lain adalah test atau [, Yang mungkin mengesampingkan perintah-perintah dalam skrip Shell, jika Shell Anda tidak memiliki mereka sebagai built-in.

Memiliki . Sebagai entri terakhir di jalur Anda sedikit lebih aman, tetapi ada serangan lain yang memanfaatkannya. Yang mudah adalah dengan mengeksploitasi kesalahan ketik umum, seperti sl atau ls-l. Atau, temukan perintah umum yang tidak diinstal pada sistem ini - vim, misalnya, karena sysadmin berkemungkinan di atas rata-rata untuk mengetikkannya.

103
mattdm

Jika maksud Anda, mengapa Anda perlu ./ pada awalnya - itu karena (tidak seperti di Windows), direktori saat ini bukan bagian dari jalur Anda secara default. Jika Anda menjalankan:

$ ls

shell Anda mencari ls di direktori di variabel lingkungan PATH Anda (echo $PATH untuk melihatnya), dan menjalankan executable pertama bernama ls yang ditemukan. Jika Anda mengetik:

$ a.out

shell akan melakukan hal yang sama - tetapi mungkin tidak akan menemukan executable yang disebut a.out. Anda perlu memberi tahu Shell di mana a.out berada - itu ada di direktori saat ini (.) Maka pathnya adalah ./a.out.

Jika Anda bertanya mengapa ini disebut "a.out", itu hanya nama file output default untuk gcc. Anda dapat mengubahnya dengan arg baris perintah -o. Sebagai contoh:

$ gcc test.c -o test
$ ./test
45
Simon Whitaker

Anda dapat mencoba menambahkan :. ke variabel $ PATH Anda.

Coba ALT + F2 dan ketik: gksudo gedit /etc/environment jika menjalankan Linux/GTK (ini adalah yang Anda miliki jika menggunakan Ubuntu).

NAMUN, saya sangat menyarankan Anda TIDAK melakukan itu. Ini buruk, buruk, buruk.

Anda tahu, hal-hal seperti itu berfungsi seperti ini sejak tahun 1970. Ada alasan mengapa direktori saat ini tidak termasuk dalam $ PATH.

. adalah direktori saat ini

.something akan menjadi file tersembunyi (Ketik "ALT +" untuk membuatnya muncul di Nautilus, atau coba "ls -la ".

./someProgram.sh adalah apa yang Anda ketik untuk MENJALANKAN someProgram.sh yang dapat dieksekusi di direktori saat ini.

.somethingElse berarti Anda memiliki executable tersembunyi di direktori saat ini, yang merupakan ide yang buruk.

4
tiktak

Aturan yang lebih lengkap sebenarnya adalah: jika ada garis miring / Ada di jalurnya, jangan cari PATH

Sebelum kita masuk ke pemikiran, Anda harus terlebih dahulu mengetahui fakta ini: menjalankan salah satu dari:

bin/someprog

atau:

/bin/someprog

atau:

cd bin
./myexec

jalankan bin/someprog tanpa mencari variabel PATH untuk alasan yang sama persis: semua bin/someprog, /bin/someprog dan ./someprog memiliki garis miring / Di dalamnya.

someprog sendiri tidak memiliki garis miring /, dan karenanya mencari hanya dalam PATH.

POSIX 7 menetapkan aturan ini di: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01

Dasar Pemikiran untuk aturan / POSIX PATH

Misalkan berlari:

someprog

akan mencari:

  • relatif terhadap CWD pertama
  • relatif terhadap PATH setelah

Lalu, jika Anda ingin menjalankan /bin/someprog Dari distro Anda, dan Anda melakukannya:

someprog

kadang-kadang akan berfungsi, tetapi yang lain gagal, karena Anda mungkin berada di direktori yang berisi program someprog lain yang tidak terkait.

Oleh karena itu, Anda akan segera mengetahui bahwa ini tidak dapat diandalkan, dan Anda akan selalu selalu menggunakan jalur absolut ketika Anda ingin menggunakan PATH, karena itu mengalahkan tujuan PATH.

Ini juga mengapa memiliki jalur relatif di PATH Anda adalah ide yang sangat buruk. Saya melihat Anda, node_modules/bin .

Sebaliknya, misalkan menjalankan:

./someprog

Akan mencari:

  • relatif terhadap PATH terlebih dahulu
  • relatif terhadap CWD setelah

Kemudian, jika Anda baru saja mengunduh skrip someprog dari repositori git dan ingin menjalankannya dari CWD, Anda tidak akan pernah yakin bahwa ini adalah program aktual yang akan dijalankan, karena mungkin distro Anda memiliki:

/bin/someprog

yang ada di Anda PATH dari beberapa paket yang Anda instal setelah minum terlalu banyak setelah Natal tahun lalu.

Karena itu, sekali lagi, Anda akan dipaksa untuk selalu menjalankan skrip lokal relatif terhadap CWD dengan path lengkap untuk mengetahui apa yang Anda jalankan:

"$(pwd)/someprog"

yang akan sangat mengganggu juga.

Aturan lain yang mungkin membuat Anda tergoda untuk melakukannya adalah:

jalur relatif hanya menggunakan PATH, jalur absolut hanya CWD

tetapi sekali lagi ini memaksa pengguna untuk selalu menggunakan jalur absolut untuk skrip non-PATH dengan "$(pwd)/someprog".

Aturan pencarian path / Menawarkan solusi yang mudah diingat untuk masalah tentang:

  • slash: jangan gunakan PATH
  • tanpa garis miring: hanya gunakan PATH

yang membuatnya sangat mudah untuk selalu tahu apa yang Anda jalankan, dengan mengandalkan fakta bahwa file dalam direktori saat ini dapat diekspresikan baik sebagai ./somefile atau somefile, dan karenanya memberikan makna khusus untuk salah satu diantara mereka.

Kadang-kadang, sedikit menjengkelkan bahwa Anda tidak dapat mencari some/prog Relatif terhadap PATH, tapi saya tidak melihat solusi yang lebih waras untuk ini.