На UNIX-подобных системах за эти годы (наиболее актуально для меня, Linux) я заметил, что .(текущий каталог) никогда не включается $PATHпо умолчанию. Почему это?
Я помню, как читал много лет назад, что это была проблема безопасности, но статья, которую я прочитал, не объясняла, в чем именно заключалась проблема. Это потому, что кто-то мог оставить вредоносную версию lsили cpв каталоге, и я бы запустил его, даже не подозревая, что он там есть?
Ответы:
Вы правильно ответили на свой вопрос, именно поэтому точка не на пути:
защитить от детских вирусов или честных ошибок.
Конечно, это очень бесполезная и бесполезная антивирусная мера, и ничто не мешает вам самим добавлять точки на путь.
-rfв каталоге (делает rm *интересным) ;-)
-rfв первую очередь? ;)
Да. Если вы поставите «.» в пути вы бы отправили много командных вызовов файлам в вашем текущем каталоге.
Даже если это было последним, все еще есть ошибка пилота. Например, в Solaris 10 отсутствует «верх». Я набираю «top» в моей системе весь день, потому что я думаю, что я нахожусь в системе, которая имеет «top».
Извините, я хотел бы спросить об этом в виде комментария к выбранному ответу, но у меня пока нет ни одного представителя в superuser.
Ответ безопасности имеет смысл, но если вы поставите "." в вашей переменной PATH, как последняя вещь, разве оболочка не должна выглядеть последней в текущем каталоге, когда она ищет исполняемые файлы, и таким образом снижать риск безопасности? Если бы он выполнял поиск в $ PATH по порядку, он бы нашел / bin / ls, прежде чем найдет ./ls.
Итак, насколько небезопасно для меня ставить "." в конце моей переменной среды $ PATH?
Это работает, как я предлагаю. Вот как я тестировал:
Сначала добавьте "." в конец вашей переменной среды PATH.
Затем поместите следующий файл в какой-то каталог, например ~ / dir1 / dir2 / test_which.rb:
#!/your/path/to/ruby
puts "this file is from the current directory"И поместите этот файл в /usr/bin/test_which.rb
#!/your/path/to/ruby
puts "this file is at /usr/bin/test_which.rb"Не забудьте chmod + x файлы, чтобы они были исполняемыми.
Теперь, если вы измените каталог на ~ / dir1 / dir2 и выполните test_which.rb, вы получите вывод
this file is at /usr/bin/test_which.rbДействительно, если вы запускаете «which test_which.rb» из любого места, он должен сообщить
/usr/bin/test_which.rbВы все еще можете выполнить файл в текущем каталоге, набрав:
./test_which.rbdcили slили sduoв оболочке, и был сохранен командой «команда не найдена». Когда-либо.
ls(цветной вывод и многое другое), в lкоторой полностью исключены опечатки.
Больше чем угроза безопасности, имея «.» в PATH сделать практически невозможным, чтобы убедиться, что выполнение любой команды действует как задумано. Подумайте о запуске команды типа «zip» в огромной директории, содержащей тысячи файлов со случайными именами. Возможность того, что один из них на самом деле называется zip, не является ничтожной и может привести к ошибке, которую очень трудно понять (на самом деле файл должен быть исполняемым, что, однако, может произойти).
В частности, это верно при написании скриптов, которые хранят переменную PATH пользователя. Хороший письменный скрипт должен иметь дело со всеми угловыми случаями (например, имена файлов с пробелами в них или начинающиеся с '-'). Но нецелесообразно предотвращать выполнение файла в текущем каталоге вместо системной команды ...
lsэто будет/usr/bin/lsи./lsне будет. Существует также препятствие, если вы знаете, как добавить.к концу своего пути, у вас, вероятно, есть представление о том, что вы делаете. корень не должен никогда иметь.в пути, многие системы не позволяют даже корневой журнал в больше.