Советы по запоминанию порядка параметров для ln?

64

Я использовал lnдля написания символических ссылок в течение многих лет, но я все еще неправильно понимаю порядок параметров.

Это обычно заставляет меня писать:

ln -s a b

а затем глядя на выходной, чтобы напомнить себе.

Я всегда представляю, a -> bкак я это читаю, когда на самом деле все наоборот b -> a. Это кажется нелогичным, поэтому я нахожу, что я всегда переоцениваю себя.

У кого-нибудь есть советы, которые помогут мне вспомнить правильный порядок?

Zhro
источник
11
иногда это помогает сказать это вслух, когда вы набираете это в «символической ссылке aи называете это b»
jsotola
2
Вы создаете второй параметр, как с помощью cp, и создаете ссылку. Но если вы поймете это неправильно, не беспокойтесь, потому что вы не можете перезаписать существующий файл или символическую ссылку новой ссылкой.
Судод
1
Связанный: Направление символической ссылки
G-Man Говорит 'Восстановите Монику'
1
Думайте об этом как «псевдоним плохого парня». Сначала его всегда называют его настоящим именем, а затем псевдонимами. Пример: Тони Балони ака Оскар Мейер. Или в случае вашей ссылки ln -sab означает «Файл-a также известен как Файл-b».
Скотти Х
1
ln source target, То же самое cp source target, mv source target; ...
user207421

Ответы:

40

Я использую следующее: lnимеет форму с одним аргументом (2-ую форму, указанную на странице руководства ), в которой требуется только цель (потому что lnвообще может работать, не зная цели), и lnсоздает ссылку в текущем каталоге. Форма с двумя аргументами является дополнением к форме с одним аргументом, поэтому цель всегда является первым аргументом.

Гэри
источник
3
Обратите внимание, что форма без пути назначения / назначения является расширением спецификации POSIX ln.
Кусалананда
1
@kusa: вы видели руководство 1971 года в моем ответе с формой с одним аргументом? Как это может быть расширение для posix, если это было там в 1971 году? --- «Если указано
@SP Я не уверен, что понимаю, что ты имеешь в виду. Вы говорите, что историческая реализация каким-то образом превосходит текущий стандарт POSIX?
Кусалананда
1
Я тоже вижу. Разные имена, одни и те же аргументы, по крайней мере. Я понятия не имел, gnu - единственный с этими именами arg.
2
Здесь было много хороших ответов (особенно стихотворение @loa_in_), но я собираюсь пойти с этим. Заявление о том, что порядок параметров согласован (игнорируется -t), выглядит почти как доказательство. lnmsgstr " создает ссылку в текущем каталоге. Форма с двумя аргументами является дополнением к форме с одним аргументом, и поэтому цель всегда является первым аргументом". Поскольку имеет смысл, что это будет иметь место при рассмотрении второй формы, я думаю, что это поможет мне вспомнить.
Жро
85

Я иду по принципу « lnэто как cp. Источник должен быть на первом месте».

Герман
источник
20
... и нравится mv. mv, cpИ lnвсе взять существующий файл в качестве первого аргумента, и предполагаемый конечный файл или имя каталога в качестве второго аргумента.
Ганс-Мартин Моснер
7
Обидно, что memcpyи strcpyт. Д. Работают наоборот.
Аркадиуш Драбчик
6
@ Hans-MartinMosner, за исключением того, что при создании символической ссылки это не обязательно должен быть существующий файл ...
ilkkachu
1
@ilkkachu Ты прав. Нет правил без исключения :-)
Ханс-Мартин Моснер
1
@ArkadiuszDrabczyk С другой стороны, что-то вроде memcpy(dest,src,n);карт очень хорошо dest = src;. Другими словами, установите (первые nбайты) dest равными (первые nбайты) src.
CVN
10

Большинство Unices документируют lnкоманду как

ln source target

(Я опускаю варианты и т.д. здесь)

Примеры:

  • Стандарт POSIX

    ln [-fs] [-L|-P] source_file target_file
    
  • OpenBSD :

    ln [-fhLnPs] source [target]
    
  • NetBSD и FreeBSD

    ln [-L | -P | -s [-F]] [-f | -iw] [-hnv] source_file [target_file]
    
  • Macos

    ln [-Ffhinsv] source_file [target_file]
    
  • Solaris

    /usr/bin/ln [-fns] source_file [target]
    
  • AIX

    ln [ -f | -n ] [ -s ] SourceFile [ TargetFile ]
    

Руководство GNU lnвызывает source цель и target имя ссылки .

Игнорируя выбор слов в 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
Кусалананда
источник
5
Я полностью обвиняю документацию GNU в том, что люди вообще ошибаются. Их формулировка понятна задним числом, но объективно запутывает.
Конрад Рудольф
6
@KonradRudolph, наоборот, формулировка GNU кажется мне точной. Утилита создает ссылку с некоторым именем, указывающую куда-то. «Имя Link» является своего рода очевидным, и «цель» является вполне хорошее описание чего - то , что указал на . Как анекдот, мне все еще приходится иногда думать, какой способ ln -s a bработает, и это не имеет ничего общего с формулировкой GNU, поскольку я не думаю, что когда-либо смотрел на фразы на странице руководства. : D (легче просто бежать, ln -si a bкогда не уверен, он будет жаловаться, если bуже существует.)
ilkkachu
1
@KonradRudolph, хотя технически, называть его «целью» в случае жесткой ссылки неверно , поскольку фактическое назначение - не существующее имя, а inode. Интересно, думали ли люди из GNU, что обычный пользователь не должен думать об этом так подробно?
Илккачу
Интересно отметить, как упоминалось в комментариях к ответу @ gary, что цель не является необязательной в стандарте POSIX.
Жро
@kusa: с помощью «ln -s AB --- скопировать только имя файла в B» я принял вашу интерпретацию в слегка измененном контексте. Я даже могу согласиться с вашим радикальным примером "Привет, мир". «Только имя файла» является строкой. Просто хочу сообщить вам, что я немного отредактировал и добавил много.
7

В случае , если это помогает любому: я привык думать о нем , как «ЛУ , что где », который помогает мне вспомнить , что первый аргумент ( «что») является существующий файл, то второй ( «где») место поставить (ссылку на) это. В отличие от рассуждений в большинстве других ответов, это не более чем содержательная фраза, которую я могу мысленно процитировать себе, когда набираю команду, которая служит памятью. Это, вероятно, не будет полезным для всех, но я подозреваю, что это поможет некоторым людям.

Помогает, что другие стандартные команды управления файлами используют то же соглашение, поэтому я могу сделать то же самое для cpи mv.

Дэвид З
источник
4
Мне любопытно узнать, почему за это проголосовали. Здесь не так много, что может быть не так - я перепутал заказ или что-то еще?
Дэвид Z
Я лично думаю, что «в каком месте» все еще не однозначно без объяснения: что может быть «на что указывает ссылка, указывающая на ссылку»? (правильно) или "что ссылается на что-то?" (неправильно). То же самое с где: "где ссылка указывает на?" (неверно) или «где должна быть создана ссылка» (правильно). Так что это не обязательно поможет так много, если вы сами догадаетесь. Запоминание cp и mv должно помочь.
125_m_125
Мы все ожидаем, что команда UNIX будет включать свои файловые аргументы после других типов аргументов (как, например, grep для exmaple). ln создает файл определенного типа с заданным содержимым. То, что файловая система делает что-то особенное, и мы обычно указываем путь к некоторому исходному файлу, является случайным для ln Например, я мог бы написать текстовый редактор, который бы сохранял содержимое своей первой строки в символической ссылке с именем 1 и т. Д. Это было бы глупо, но он подчеркивает, что ln создает какой-то файл с некоторым текстовым содержимым, ничего более или менее, и делает порядок аргументов казаться логичным.
Дэнни
@ 125_m_125 Альтернативная интерпретация, которую вы представили, не имеет большого смысла для меня, но это нормально; эта помощь памяти не для всех.
Дэвид Z
6

Недавно я услышал отличный способ запомнить эту конкретную вещь: рифма

Что-то старое, что-то новое,

что-то позаимствовано, что-то голубое,

и шесть пенсов в ее туфле.

Первый стих - это аргументы ln: что-то старое, за которым следует имя новой записи каталога.

loa_in_
источник
3
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 First Edition .

Существует вторая простая синтаксическая форма.


Изменить: Я ставлю 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 grom и удалить 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 года отмечает: «ОШИБКИ: ссылки дублируются дважды и восстанавливаются как отдельные файлы с отдельными inode».

Жесткие ссылки на каталоги (редко / недопустимо) могут легко привести к засорению.

Мягкие ссылки на каталоги (очень распространенные) могут привести к вечным циклам - должны распознаваться утилитами / ядром.

Практический пример в bash

Начиная с обычного файла "F" ...

ln F Fhard

... делает Fhard того же размера, что и F, но они ОБА теперь появляются в темно-красных БЕЗ стрелок ls -l --color. Из-за statотображения «Ссылки: 2» в связи с «Inode: XYZ». Жесткая ссылка F превращает F в жесткую ссылку. Оба являются / stay filetype "обычный файл". Но у обоих есть индекс с числом ссылок выше 1.

   ln -s F Fsoft

... делает крошечный "нерегулярный" файл "Fsoft" с типом файла "символическая ссылка" - еще больше экономит место, чем пустой каталог. А не 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

источник
2

Очень полезно помнить, что название ссылки не является обязательным. Если оно не задано, используется базовое имя цели ссылки.

ln -s /path/to/file1 file1

идентично удалению имени ссылки полностью:

ln -s /path/to/file1

Это не имеет никакого смысла, если цель ссылки была упомянута последней.

rexkogitans
источник
1

Просто подумайте, 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
Kaz
источник
«cp foo bar» означает «запретить». «ln abc def» означает «abc». Если вы сохранили символы: «чтобы foo». Это именно проблема.
@ user370539 Это просто неправда; после того, как ln abc def, abcи defв тот же объект; они неразличимы. Более того, операция не оказывает никакого влияния abc, кроме увеличения количества ссылок. Назначения def. Указатель на объект вновь установлен в defлокации.
Каз
@ user370539 Если ссылка является символической, то ln -s abc defозначает, что содержимое abcзаписывается в местоположение def. abcдаже не нужно ничего решать; это может быть свисающая связь.
Каз
Ваш комментарий точно ... неправильный. Это должно быть наоборот.
rexkogitans
@rexkogitans Я хочу сказать, что это соответствует. Если заказ «неправильно» , и должно быть отменено, то это должно быть для всех этих команд: mv dest src, ln [ -s ] dest src, cp dest src, ...
Kaz
0

Лично я предпочитаю избегать запоминания X, чтобы знать, где искать X, когда мне это нужно. Я также являюсь поклонником отношения «лучше безопасно, чем сожалеть», поэтому мне всегда нравится тщательно проверять, что я пишу, особенно как root.

В этом случае ответ буквально в первых строках справочной страницы:

   ln [OPTION]... [-T] TARGET LINK_NAME
   (...)
   In the 1st form, create a link to TARGET with the name LINK_NAME.

Я бы не предложил этого, если бы потребовалось углубиться в man-страницу, но, поскольку это в самом начале, ИМХО, это стоит 3 секунд, которые требуются для ввода man lnи выхода.

dr01
источник
-1

Подобно cp, который я мысленно читаю как «скопировать это в то», я читаю ln команды как «связать это с этим».

jl6
источник
2
Это очень похоже на самый лучший ответ .
Майкл
Таким образом, «ln -s AB» связывает A с B? Теперь это A -> B или B -> A? Я думаю, что большинство даже не прошли первый этап путаницы. Они говорят, что это просто, но это просто неправильно.
-2

Вот как я это помню: Забудь цель. Другими словами, если я нахожусь в dir1 и хочу создать здесь символическую ссылку на file1, которая существует в / some / other / dir /, я бы просто сделал:

ln -s /some/other/dir/file1

Вы получите символическую ссылку с именем file1 в dir1, которая указывает на / some / other / dir / file1. Со страницы руководства для ln:

ln [OPTION] ... TARGET (2-я форма) ... Во 2-й форме создайте ссылку на TARGET в текущем каталоге.

Просто имейте в виду, что это работает, только если вы хотите, чтобы символическая ссылка имела то же имя, что и цель (что, скорее всего, имеет место).

Прыгающий кролик
источник
Может кто-нибудь объяснить, почему это было отклонено? Я просто скопировал со страницы руководства (и, соответственно, приписал). Это поможет другим понять, как разместить на SE. Благодарю.
Прыгающий кролик
Я могу объяснить: это культурное столкновение. Не беспокойся Проверьте другие ответы, комментарии ...
-3

Я хотел бы расширить ответ @ Гэри.

В дополнение к его ответу: lnкоманда может принимать произвольное количество аргументов, так что вы можете создать несколько символических ссылок за один вызов (что удобно, когда вам это нужно).

  1. С этим знанием, когда вы сталкиваетесь ln -s foo bar baz, каково самое логичное объяснение, какие аргументы означают что?
  2. С ответом на вопрос № 1, когда вы сталкиваетесь ln -s foo bar, каково наиболее логичное объяснение того, что аргументы означают что?
yegle
источник
1
Если у вас есть дополнение к ответу Гэри, предложите его как редактирование. На самом деле, два ваших последних (гипотетических?) Вопроса делают этот «ответ» более похожим на второй вопрос.
Джефф Шаллер
-3

Представьте себе версию, 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]...

jrw32982 поддерживает Монику
источник
-6

" lsпоказывает a -> bтак ln a b"

Просто помните, что это неправильно.

О, Боже мой
источник
6
Я всегда помню «что-то, что-то всегда не так». Но какой путь не так? Это проблема. Проблема становится моей второй догадкой, даже когда я понимаю это правильно. Потому что я не могу вспомнить правильный порядок!
Жро
Я думаю, я понимаю, что вы имеете в виду: вывод ls -l: link -> targetможет запутать ваше представление о том, как настроить lnкомандную строку. Но я боюсь, что это не сильно поможет.
Судод