`пер -s` в скрипте действует как` cp`

Question

Проблема

У меня есть этот Баш скрипт:

ACTIVE_DB=$(grep -P "^[ \t]*db.active" config.properties | cut -d= -f2 | tr -s " ") 
echo $ACTIVE_DB 
if [ "$ACTIVE_DB" = "A" ] 
then 
    ln -sf config-b.properties config.properties 
else 
    ln -sf config-a.properties config.properties 
fi 

config-a.properties

db.active = A 

конфиг-б. свойства

db.active = B 

Когда я запускаю сценарий, py (= cp), и config.properties часто не является символической ссылкой (и физической ссылкой, если на то пошло), а целый новый файл с тем же содержимым, что и config-a.properties или config-b.properties.

$ ls -li 
53 -rw-r--r-- 1 ogregoir ogregoir  582 Sep 30 15:41 config-a.properties 
54 -rw-r--r-- 1 ogregoir ogregoir  582 Sep 30 15:41 config-b.properties 
56 -rw-r--r-- 1 ogregoir ogregoir  582 Oct 2 11:28 config.properties 

Когда я запускаю это в строке вручную построчно, у меня нет никаких проблем и символическая ссылка действительно всегда создается и config.properties точек в направлении config-a.properties или config-b.properties.

$ ls -li 
53 -rw-r--r-- 1 ogregoir ogregoir  582 Sep 30 15:41 config-a.properties 
54 -rw-r--r-- 1 ogregoir ogregoir  582 Sep 30 15:41 config-b.properties 
55 lrwxrwxrwx 1 ogregoir ogregoir  20 Oct 2 11:41 config.properties -> config-b.properties 

Примечания

• Файл не открыт в другом месте (я единственный активный пользователь и приложение с помощью конфигурации не работает).
• Иногда ln -sf действует нормально, но обычным правилом является то, что он делает бумажную копию.
• Сценарий запускается из другого каталога, но cd s в каталог, где находятся файлы config*.properties, прежде чем выполнять действия здесь.
• Скрипт намного длиннее, но это самый короткий пример, который воспроизводит ошибку.
• bash версия 4.1.2 (это локально, поэтому меня не интересует shellshock).
• ln версия 8.4.
• Операционная система: Red Hat Enterprise Linux Server release 6.5 (Сантьяго).
• Файловая система, используемая для этой папки: ext4.

Вопрос

• Почему не мой сценарий последовательно создать символическую ссылку, но делает бумажную копию?
• Как заставить символическую ссылку здесь?

Answer 1

Я подозреваю, что у вас есть другой скрипт или код, который переписывает символические ссылки. Например, sed -i удалит символические ссылки. Существует множество команд и утилит, которые изменяют файл, создавая копию, изменяя копию, а затем перемещая копию поверх оригинала, которая уничтожает исходную символическую ссылку.

Answer 2

Единственный ответ можно вопрос (как просили): почему ln ведут себя, как cp является: Это не может.

Единственный возможный ответ: то, что вы представляете нам, не совсем то, что выполняется, или есть другие скрипты, которые меняют ответ.

Возможные альтернативы:
1.- Команда ln на самом деле выполняет жесткую ссылку.Список i-узлов (ls -li) подтверждает, что номера i-узлов различны. Итак, нет, это не причина.

2.- Есть ли алиас или функция для ln?
Это легко проверить. Просто выпустите type -a ln внутри Bash. В результате будет показано, что интерпретирует bash ln. Если это ТОЛЬКО файл /bin/ln, то это правильно.
Вы подтвердили, что нет псевдонима или функции.

3.- Как «сценарий запускается из другого каталога». Дело в том, что в файловой системе есть другой файл, имеющий тот же номер i-узла (если ln фактически создает жесткую ссылку). Существование какого-то другой файл с тем же индексным дескриптором может быть проверено с (используйте номера инодов 53,54,56 из вашего списка):

find/-follow -inum <your inum> 

4.- Я надеюсь, что вы по-настоящему знает, что config-b.properties фактически не существует (как файл). Редактирование такого файла может привести к удалению ссылки.

Является ли фактический скрипт выполненным и изменением/обновлением содержимого файла?

Note01: Обратите внимание, что K трюк действительно решить экстракцию всего за один внешний вызов: http://www.charlestonsw.com/perl-regular-expression-k-trick/

ACTIVE_DB=$(grep -Po "^[ \t]*db.active[ ]+=[ ]+\K." config.properties) 

Было подтверждено, что sed -i к config-b.properties позже в режиме реального исполняемого скрипта был источником проблема.