Советы по запоминанию порядка параметров для ln?
У меня также была эта проблема в Fedora 26. Сегодня они выпустили обновление, которое должно решить эту проблему.
Обновите пакеты и повторите процедуру, которую вы сделали до:
sudo fwupdmgr refresh
sudo fwupdmgr update
NAME ln -- make a link
SYNOPSIS ln name1[ name2 ]
DESCRIPTION ln creates a link to an existing file name1.
If name2 is given, the link has that name;
Из 1971 г. Первое издание руководств Unix .
Существует вторая , простая, синтаксическая форма.
Я поставил FILE или FILENAME вместо TARGET ---см. комментарии и т. д. См. также очень длинное добавление внизу, касающееся айсберга, твердого и мягкого из ln, а не только его верхушки.
Итак, GNU lnимеет это:
ln [opt] FILENAME
In the 2nd form, create a link to FILENAME in the current directory.
где вам не нужно имя ссылки. После ln -s /usr/lib/modulesвы получите
modules -> /usr/lib/modules
с тем же именем, что и FILENAME («цель» или «источник» ), прямо там, где вы находитесь. Нет выбора, нет путаницы.
Теперь, если вы более требовательны и хотите, чтобы ссылка была создана под другим именем и/или где-то еще , вы добавляете желаемое имя или путь. Настоящая цель идет первой, а новое необычное название ссылки — второй.
Или вы говорите :«Я знаю эту нотацию стрелки в ls -lдля ссылок. У меня нет стрелки в оболочке, чтобы показать направление моей ссылки. Так что я должен перевернуть ее».
Вы создаете его в одном направлении, поэтому вы можете использовать его в другом.
(КОНЕЦ ОТВЕТА --ЧАСТЬ ВОПРОСА)
На другом уровне само слово «связь» несет в себе глубокий скрытый двойной смысл. Символические ссылки появились позже, поэтому в первые дни ссылка была просто ссылкой. Не было ни мягкого, ни жесткого, ни варианта -s. А теперь я даже использую исходную -целевую символику:
mv A B --- move the whole file to B (dir or new name)
cp A B --- copy whole file (mv and cp are "the same" here)
ln A B --- copy whole file MINUS data blocks (=copy only inode and name), and increase "link count" for track keeping
На данном этапе ссылки есть, но нет жестких и мягких, и ls -lне показывает стрелок, потому что в (жесткой )ссылке нет направления.«Ссылка» на этом этапе эволюции Unix означала, что имя файла «B» (запись каталога «B» )в файловой системе указывает на тот же индексный дескриптор, на который указывает имя файла «A».
Файлы A и B "связаны" друг с другом, потому что они используют одни и те же блоки. Итак, теперь с каждым rmядро должно проверять :, удаляю ли я/освобождаю блоки этого файла на диске, или есть другой файл, связанный с теми же блоками? Для этого используется счетчик ссылок.
Допустим, вы хотите предотвратить удаление большого файла в /tmp, и выполните ln /tmp/bigfile. Теперь у вас есть большой большой файл в вашем рабочем каталоге. После очистки /tmp и удаления «оригинала» вы с радостью продолжаете использовать те же блоки данных. Вы не получаете мертвую или оборванную ссылку, у вас есть нормальный файл. Указание не на файл, а только на блоки файловой системы, как это делает любая запись в каталоге. Только теперь "очистка" /tmp не так эффективна, как раньше. Он выглядит пустым, и это так, но блоки в разделе не освобождаются.
Несмотря на то, что жесткая ссылка сама по себе не занимает места, как cp, она может косвенно.
Добавление ln -sк приведенной выше последовательности:
ln -s A B --- copy only the file's name to "B"
Теперь "B", программная ссылка, содержит только строку с путем. Это "мягкая" информация. Технически «А» и «Б» не связаны. Но все же B является «ссылкой» в новом смысле, что вы можете использовать это сохраненное имя пути как ярлык для «A». Теперь это "ссылка на A"(точка ), а не "связанная с inode файла A"
Оба вида ссылок могут сбить с толку не только людей, но и ядро/фс. На справочной странице 1971 года отмечается :«ОШИБКИ :ссылки записываются дважды и восстанавливаются как отдельные файлы с отдельными индексными дескрипторами».
Жесткие ссылки на каталоги (редко/не разрешены )могут легко привести к засорению.
Мягкие ссылки на каталоги (очень распространены )могут привести к вечным петлям -они должны распознаваться утилитами/ядром.
Практический пример в bash
Начиная с обычного файла "F"...
ln F Fhard
...делает Fhard того же размера, что и F, но они ОБА отображаются теперь темно-красным БЕЗ стрелок в ls -l --color. Из-за того, что statпоказывает «Ссылки :2» в связи с «Inode :xyz». Жесткая ссылка F превращает F в жесткую ссылку. Оба являются/остаются типом файла «обычный файл». Но у обоих есть inode со счетчиком ссылок выше 1.
ln -s F Fsoft
...делает крошечный "необычный" файл "Fsoft" с типом файла "символическая ссылка" ---еще более экономящим место, чем пустой каталог. A ls -lне показывает ничего особенного для "F". Для Fsoft отображаемый размер составляет 1 байт, поскольку строка имеет значение «F», а Fsoft -> Fотображается как имя. Не нужно раскрашивать мягкую ссылку, чтобы распознать ее, потому что в краткой форме ls -Fвы получаете спиральную цепочку @, добавленную :Fsoft@
С ls -lэто выглядит так:
-rw-r--r-- 2 root root 6070340 Sep 16 16:28 F
-rw-r--r-- 2 root root 6070340 Sep 16 16:28 Fhard
lrwxrwxrwx 1 root root 1 Sep 16 16:31 Fsoft -> F
У Фарда размер и тип Фхарда.
Fsoft использует имя F и длину имени F в качестве размера и другой тип файла.
Короткийls -sF:
5932 F 5932 Fhard 0 Fsoft@
добавление --block-size=1также не дает одинаковых размеров. Fsoft имеет размер "один байт, ноль блоков". F и Fhard отклоняются параллельно:
6074368 F 6074368 Fhard 0 Fsoft@
Чтобы увидеть, зависает Fsoft или нет, lsпозволяет использовать цвета.
ORPHAN 40;31;01 # symlink to nonexistent file, or non-stat'able file
На случай, если это кому-то поможет :Я привык думать об этом как "в что чтогде ", что помогает мне вспомнить, что первый аргумент ("что" )— это существующий файл, второе («где» )— это место, где (можно разместить ссылку на )его. В отличие от рассуждений в большинстве других ответов, это не более чем содержательная фраза, которую я могу мысленно повторять про себя, когда набираю команду, которая служит средством памяти. Это, вероятно, не будет полезно для всех, но я подозреваю, что это поможет некоторым людям.
Помогает то, что другие стандартные команды работы с файлами используют то же соглашение, поэтому я могу сделать то же самое для cpи mv.
Большинство Unices документируют команду lnкак
ln source target
(Здесь я опускаю опции и т. д.)
Примеры:
ln [-fs] [-L|-P] source_file target_fileln [-fhLnPs] source [target]ln [-L | -P | -s [-F]] [-f | -iw] [-hnv] source_file [target_file]macOS
ln [-Ffhinsv] source_file [target_file]/usr/bin/ln [-fns] source_file [target]ln [ -f | -n ] [ -s ] SourceFile [ TargetFile ]
Руководство GNU lnявляется лишним и называет цельsourceи имя ссылкиtarget.
ln [option]… [-T] target linkname
Игнорируя выбор слов GNU, утилита lnследует той же семантике, что и, например. mvи cpв том, что цель — это то, что создано из источника .
Следовательно,
ln -s a b
создаст символическую ссылку b, указывающую на a.
Также обратите внимание, что при создании символических ссылок источником является просто строка, представляющая, на что должна указывать символическая ссылка. Обычно не делается никаких проверок, чтобы убедиться, что он указывает на что-то полезное :
.$ ln -s "hello world" README.txt
$ ls -l
total 0
lrwxr-xr-x 1 kk wheel 11 Sep 15 11:39 README.txt -> hello world
Личное мнение о выборе GNU использовать «цель» и «имя ссылки», а не «источник», за которым следует «цель»:
Может показаться очевидным, что вторым аргументом, то, что создается, должно быть «имя ссылки», а первым аргументом, целью ссылки, является «цель». Однако это верно только в том случае, если вы используете ссылку.
Когда вы создаете ссылку, что вы и делаете с ln, второй аргумент, то, что создается, является «целью» операции lnи он создается с использованием первого аргумента, «источника».
Это,вместе с аналогичным "исходным" ->"целевым" порядком аргументов для других основных инструментов документация не -GNU для lnкажется более естественной.
Очень полезно помнить, что имя ссылки необязательно. Если он не указан, используется базовое имя цели ссылки.
ln -s /path/to/file1 file1
идентично полному удалению имени ссылки:
ln -s /path/to/file1
Это не имело бы никакого смысла, если бы цель ссылки упоминалась последней.
Лично я предпочитаю избегать запоминания X в пользу знания , где искать X, когда мне это нужно. Я также являюсь поклонником позиции «лучше перестраховаться, чем сожалеть», поэтому мне всегда нравится тщательно проверять то, что я пишу, особенно под root.
В этом случае ответ находится буквально в первых строках справочной страницы:
ln [OPTION]... [-T] TARGET LINK_NAME
(...)
In the 1st form, create a link to TARGET with the name LINK_NAME.
Я бы не предложил это, если бы для этого требовалось углубиться в справочную страницу, но, поскольку она находится в самом начале, ИМХО стоит трех секунд, необходимых для ввода man lnи выхода.
Просто подумайте о Unix -> AT&T -> пункт назначения справа:
mov %eax, %ebx ;; AT&T style assembler syntax: %ebx register gets value of %ecx
mv foo bar ;; foo renamed to bar
cp foo bar ;; contents of foo go to bar
foo | bar ;; data moves left to right in pipeline
ln abc def ;; link to abc installed as def
Вот как я это помню. :Забудь цель. Другими словами, если я нахожусь в каталоге dir1 и хочу создать здесь символическую ссылку на файл file1, который существует в каталоге /some/other/dir/, я бы просто сделал:
ln -s /some/other/dir/file1
Вы получите символическую ссылку с именем file1 в dir1, которая указывает на /some/other/dir/file1. Со страницы руководства для ln:
ln [OPTION]... TARGET (2nd form) ... In the 2nd form, create a link to TARGET in the current directory.
Просто имейте в виду, что это работает только в том случае, если вы хотите, чтобы символическая ссылка имела то же имя, что и цель (, что наиболее вероятно ).
Представьте себе версию ln, позволяющую создавать несколько (символических )ссылок в одной команде.
Synopsis: ln -s TARGET NEW_LINK...
Example: ln -s target_file new_link_1 new_link_2 new_link_3
Было бы бесполезно изменить это, так как символическая ссылка может указывать только на один TARGETза раз, а обычное соглашение командной строки заключается в том, чтобы помещать повторяющуюся часть в конец командной строки, например.grep PAT [FILE]...
Я хотел бы расширить ответ @gary.
В дополнение к своему ответу :команда lnможет принимать произвольное количество аргументов, так что вы можете создавать несколько символических ссылок за один вызов (, что удобно, когда вам это нужно ).
- С этим знанием, когда вы сталкиваетесь с
ln -s foo bar baz, какое самое логичное объяснение, какие аргументы что означают? - При ответе на #1, когда вы сталкиваетесь с
ln -s foo bar, какое самое логичное объяснение, какие аргументы что означают?
Подобно команде cp, которую я мысленно читаю как «скопировать это в то», я читаю команды ln как «связать это с этим».