Связывание и копирование
Вы передаете скрипт в awk как одну строку -в кавычках из оболочки, но, похоже, внутри скрипта тоже есть одинарные кавычки . Они фактически заканчивают строку в кавычках:
awk 'BEGIN {F='[)#/(:]'; FS = "\n"; RS = ""; OFS = "|";fw="";dev=""}
^^^^^^^ not quoted
Оболочка видит )без кавычек, что вызывает синтаксическую ошибку. Не то чтобы вы все равно хотели использовать одинарные кавычки в скрипте awk, это было бы синтаксической ошибкой в awk . Так что вместо этого используйте двойные -кавычки, как вы делали это для других назначений, они прекрасно вписываются в одинарные -кавычки в оболочке и фактически работают в коде awk:
awk 'BEGIN { foo="bar";...}'
Затем обратите внимание, что опция -Fдля awk устанавливает разделитель полей, который является переменной FS, а не F. Итак, вы хотите иметь BEGIN { FS="[)#/(:]";..., и вы, вероятно, не хотите также менять разделитель записей по умолчанию RS— по крайней мере, вы не меняли его в одной строке -выше.
Кроме того, вместо того, чтобы помещать сценарий awk в сценарий оболочки, вы можете просто пропустить оболочку и сделать awk непосредственно интерпретатором этого сценария (, предполагая, что ваш awk находится на/usr/bin/awk):
#!/usr/bin/awk -f
BEGIN { FS="[)#/(:]"; OFS="|"; fw=""; dev=""}
{
if ( $0 ~ /sh failover/ ) fw=$1 ;
if (($0 ~ /This host/) || ($0 ~ /Other host/)) dev=$2;
if ( $0 ~ /\)\:/ ) {
print $2, $1, fw, dev
}
}
Если это называется ./script.awkи сделано исполняемым, вы можете запустить его как ./script.awk filename, то есть с файлом для обработки в качестве аргумента скрипта.
Суть в том, что копирование создает копию файла, а связывание (soft или hard )— нет.
В качестве модели абстракции представьте, что ваш каталог — это таблица с:
filename where the file is content of the file
---------------------------------------------------------
a.txt sector 13456 abcd
b.txt sector 67679 bcde
При копировании файла cp a.txt c.txtя получаю следующее:
filename where the file is content of the file
---------------------------------------------------------
a.txt sector 13456 abcd
b.txt sector 67679 bcde
c.txt sector 79774 abcd
Когда я жестко -связываю файл ln b.txt d.txt, я получаю следующее:
filename where the file is content of the file
---------------------------------------------------------
a.txt sector 13456 abcd
b.txt sector 67679 bcde
c.txt sector 79774 abcd
d.txt sector 67679 bcde
Итак, теперь b.txtи d.txt— это один и тот же файл. Если я добавлю символ fв d.txt, он также появится вb.txt
Проблема с жесткими ссылками заключается в том, что вы можете делать это только в одной и той же файловой системе. Поэтому большинство людей используют программные ссылки,ln -s a.txt e.txt:
filename where the file is content of the file
---------------------------------------------------------
a.txt sector 13456 abcd
b.txt sector 67679 bcde
c.txt sector 79774 abcd
d.txt sector 67679 bcde
e.txt sector 81233 "Look at where a.txt is located"
В первом приближении программные ссылки немного похожи на ярлыки в Windows. Однако программные ссылки являются частью файловой системы и поэтому будут работать с любой программой. Ярлыки Windows — это просто файл, который интерпретируетсяexplore.exe(и некоторыми другими программами ). Но программам Windows необходимо что-то делать для интерпретации ярлыка, тогда как в Linux программные ссылки обрабатываются автоматически.
В большинстве случаев ссылки используют программные ссылки, поскольку они более гибкие, могут указывать на другие файловые системы,может использоваться с NFS и так далее.
Единственный вариант использования -, который я видел для жестких ссылок, заключается в том, чтобы убедиться, что файл не удален пользователем. Системный администратор создал жесткие -ссылки в каталоге-указателе, и когда пользователь непреднамеренноrm-редактировал файл (, что, по-видимому, случалось там часто ), он мог в мгновение ока -восстановить файл без использование ленты, без двойного дискового пространства и т. д.
Это работает следующим образом:
filename where the file is content of the file
---------------------------------------------------------
a.txt sector 13456 abcd
b.txt sector 67679 bcde
Когда пользователь вводит rm a.txt, таблица будет:
filename where the file is content of the file
---------------------------------------------------------
b.txt sector 67679 bcde
Все ссылки на a.txtутеряны. Место на диске может быть освобождено для других файлов.
Однако, если у системного администратора есть копии ссылок на важные файлы, таблица будет:
filename where the file is content of the file
---------------------------------------------------------
a.txt sector 13456 abcd
b.txt sector 67679 bcde
link.a.txt sector 13456 abcd
link.b.txt sector 67679 bcde
Теперь, когда пользователь вводит rm a.txt, таблица становится:
filename where the file is content of the file
---------------------------------------------------------
b.txt sector 67679 bcde
link.a.txt sector 13456 abcd
link.b.txt sector 67679 bcde
Поскольку ссылка на файл начинается с 13456, место на диске файла не будет помечено как свободное. Так что файл все еще там. Когда теперь пользователь спрашивает, можно ли как-то восстановить a.txt, системный администратор просто нажимает ln link.a.txt a.txtи появляется файл a.txtre -! И с его последними правками тоже. (Конечно, link.a.txtнаходится в другом каталоге в той же файловой системе, и это не значит, что о резервных копиях можно забыть, но в то время и в том месте это была полезная опция ).
Нет, ярлыки являются независимыми файлами и должны быть сначала открыты проводником/оболочкой Windows, которая затем открывает приложение, обрабатывающее их, или запускает приложение. С другой стороны, приложения Unix могут напрямую открывать символические ссылки и работать с ними как с реальными файлами.
При копировании создается копия файла, а жесткое -связывание просто создает новый индексный дескриптор, связанный с теми же данными на диске. Жесткая ссылка в основном занимает почти нулевое место на диске.
Я никогда не использовал жесткие ссылки в какой-либо степени, поэтому не могу привести вам ни одного примера. Вот хорошее сравнение между символическими и жесткими ссылками в Unix:https://blog.usejournal.com/what-is-the-difference-between-a-hard-link-and-a-symbolic-link-8c0493041b62https://www.geeksforgeeks.org/soft-hard-links-unixlinux/