Итак, у вас есть что-то вроде этого:
$ foo='my dir'
$ ls $foo
my: no file or directory found
dir: no file or directory found
Вместо этого попробуйте следующее:
$ foo='my dir'
$ ls "$foo"
Или даже лучше:
$ ls "${foo}"
Оба этих метода защищают символ [: space:] от интерпретации оболочкой и гарантируют, что он будет прочитан как [: space:] характер, а не предел для команды.
Это очень хорошая привычка при написании сценариев оболочки!
Имена файлов стандартизированы, главным образом, в интересах программного обеспечения для обслуживания архивов и локального кэша.
Раньше, до того, как архитектура m68k
была добавлена в Debian, в именах файлов использовалось «пакет_версия .deb», и проблем не возникало. Имя архитектуры добавлялось к имени файла, когда программному обеспечению архива требовалось хранить пакеты i386
и m68k
одного и того же пакета и версии в одном каталоге. Поскольку список пакетов всегда содержал как длинные имена , так и имена файлов формата 8.3 , это можно было реализовать без нарушения работы клиентов.
Dpkg вообще не заботится об именах файлов пакетов. Во время выполнения установки APT создает каталог со всеми файлами пакета для этого запуска установки, и каждый файл будет иметь номер текущего запуска, предшествующий имени файла (, т. е. если вы устанавливаете пакет foo
версии 1, а пакет bar
версии 2, от которой зависит foo
, apt передаст 0-bar_2_all.deb
и 1-foo_1_amd64.deb
в dpkg ).
APT обычно предполагает, что имена уникальны для целей кэширования. Если вы повторно используете имя, пользователи, которые уже имеют этот файл в своем кэше, попытаются возобновить загрузку, если новый файл больше, что оставит их с недействительным файлом, который впоследствии отбрасывается, поскольку он не проходит проверку контрольной суммы. Однако эта ошибка отображается пользователю, и ему необходимо перезапустить установку.
За годы работы у меня накопилось большое количество .deb
пакетов с нестандартными -именами, и я не помню, чтобы сталкивался с какими-либо проблемами. «Известные» пакеты с нестандартными именами -, с которыми люди могут столкнуться в настоящее время, включают google-chrome-stable_current_amd64.deb
и steam.deb
. (В обоих случаях фиксированное имя без версии гарантирует, что стабильный URL-адрес можно использовать для загрузки, а стабильное имя — для инструкций по установке.)
Однако я не не помню, чтобы встречались с пробелами в именах; это также не должно вызывать проблем с инструментами, но может вызвать путаницу у ваших пользователей (, поскольку им нужно будет заключать имя файла в кавычки или экранировать пробелы, если они используют инструменты на основе оболочки -).
Следует также отметить, что использование нестандартного имени -, которое не совпадает с именем вашего пакета (, хранящимся в файле control
), также может вызвать путаницу, , например. при попытке удалить пакет (, так как имя пакета не будет совпадать с именем, используемым для его установки ).
В результате всего этого, если вы не хотите придерживаться канонического имени, я бы рекомендовал что-то вроде my-program.deb
илиmy-program_amd64.deb
(в зависимости от того, хотите ли вы поддерживать несколько архитектур ).Вы также можете сделать это символической ссылкой на имя файла с версией, если хотите разрешить загрузку более старых версий.