Как изменить способ интерпретации файла файловой системой Linux? Мой файл исходного кода читается как "битая ссылка", несмотря на то, что это все еще текстовый файл

Использование grep предполагает, что имя файла java состоит только из букв, цифр и _

awk '/Caused/{getline; print}' testError.log | grep -oE '\w+\.java'

Использование sed для общего имени файла

awk '/Caused/{getline; print}' testError.log | sed -r 's/.*\((.*):.*/\1/'
-1
27.08.2016, 02:36
3 ответа

Очень интересно!

Ваш продюсер_потребитель.Файл cc представляет собой символическую ссылку. Но это не старая символическая ссылка. Это символическая ссылка с совершенно чокнутой целью. Это потому, что целью ссылки является чрезвычайно длинное имя файла, которое (также) является всем исходным кодом программы на C ++. Конечно, эта символическая ссылка является висящей символической ссылкой; и поведение head и nautilus, которое вы видите, вполне ожидаемо для такой символической ссылки.

Вы не представили никаких доказательств, подтверждающих вывод о том, что имеет место какая-либо «коррупция». Это вполне допустимая символическая ссылка, хотя и ненормальная. Существует множество способов создать такую ​​символическую ссылку с помощью различных обычных инструментов. Например, это упражнение для новичков в использовании замен оболочки.

Как вы попали в эту причудливую неразбериху, знаете только вы, и вы не раскрыли нам. Как из этого выбраться - полная пустяк. Это две команды, одну из которых вы в основном уже выполнили:

readlink producer_consumer.cc > producer_consumer.cc.new
mv producer_consumer.cc{.new,}

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

Так что, возможно, вы снова выполняете эти две команды.

4
29.04.2021, 00:10

Решение заключается в том, что после создания версии файла сначала удалите его и подтвердите удаление. Во-вторых, создайте новый файл и скопируйте его правильное содержимое из системы версий, не клонируя его. Например, в веб-браузере, если это позволяет GitHub, они фиксируют их.

Это удалит их из системы управления версиями. Это связано с тем, что команда git status не может отличить символическую ссылку от файла исходного кода. Если вы их просто исправите, команда git status не сможет показать их между ними. Итак, вам сначала нужно зафиксировать удаление, а затем исправить добавление их в другой фиксации.

0
29.04.2021, 00:10

Ваш файл отображается как неработающая ссылка, потому что это неработающая ссылка. Это ссылка, целью которой является что-то похожее на код C ++. Обычно цель ссылки выглядит как путь к файлу, но для системы это всего лишь текст.

Нет, я понятия не имею, как вы к этому пришли. Может быть, где-то плохой копипаст. Вы выполнили команду ln -s '// EPOS Synchronizer…}'pumer_consumer.cc или сделали что-то подобное. Может быть, команда makefile, выполняющая ln -s '$ (shell cat $ <)' $ < или что-то подобное.

Если вы хотите сохранить текущий контент, извлеките его с помощью readlink и сохраните в файл:

mv producer_consumer.cc bad-link
readlink bad-link >producer_consumer.cc
rm bad-link

Похоже, вы сохранили символическую ссылку в своем репозитории git. Git может хранить символические ссылки, но если вы проверите их в системе без символических ссылок, вы получите обычный файл. Если у вас есть обычный файл в вашей рабочей копии Linux, зафиксируйте его в git.

git -m 'Changed symlink back to regular file' producer_consumer.cc

У вас все еще будет символическая ссылка, если вы посмотрите исторические версии. git log Manufacturer_consumer.cc должен сообщить вам, когда была отмечена символическая ссылка, но это может не помочь с объяснением причины.

3
29.04.2021, 00:10

Теги

Похожие вопросы