команда tail не получает только новые строки

  • Бинарная схема принятия решений (моя очень любимая структура данных, хорошая для представления булевых уравнений и решения их. Эффективный для большой партии вещей)
  • "куча" (дерево, где родитель узла всегда поддерживает некоторое отношение к детям узла, например, родитель узла всегда больше, чем каждый из, его - дети (макс. "куча"))
  • Приоритетные Очереди (действительно просто минимальная "куча" и макс. "куча", хорошая для того, чтобы поддержать порядок большого количества элементов там, например, объект с самым высоким значением, как предполагается, удален сначала)
  • Хеш-таблицы, (со всеми видами стратегий поиска, и переполнение блока, обрабатывающее)
  • Сбалансированные деревья двоичного поиска (Каждый из них, имеют их собственные преимущества)
    • RB-деревья (в целом хороший, при вставке, поиск, удалении и итерации заказанным способом)
    • Avl-деревья (быстрее для поиска, чем RB, но в других отношениях очень похожий на RB)
    • Косые деревья (быстрее для поиска, когда недавно используемые узлы, вероятно, будут снова использованы)
    • дерево Fusion (Использование быстрого умножения для получения еще лучших времен поиска)
    • B+Trees (Используемый для индексации в базах данных и файловых системах, очень эффективных, когда задержка к чтению-записи из/в индекс будет значительной).
  • Пространственные индексы (Превосходный для запросов для того, являются ли точки/круги/прямоугольники/строки/кубы в непосредственной близости от или содержавший друг в друге)
    • дерево BSP
    • Дерево квадрантов
    • Дерево октантов
    • дерево Диапазона
    • Партии подобных но немного отличающихся деревьев и различные размеры
  • деревья Интервала (хорошее открытие перекрывающиеся интервалы, линейные)
  • Графики
    • список смежности (в основном список краев)
    • матрица смежности (таблица, представляющая ориентированные ребра графика с единственным битом на край. Очень быстро для обхода графика)
  • Они - те, я могу задуматься о. Существуют еще больше на Википедию приблизительно структуры данных

4
задан 19.05.2020, 04:29

2 ответа

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

, Например, сравните свой рабочий процесс с выполнением этого:

for((i=0;i<20;i++)); do echo $i >> file.txt; sleep 1; done

, Который будет писать число в file.txt каждую секунду в течение двадцати секунд. Если Вы будете открывать другой терминал и работать tail -fn 0 file.txt, Вы будете видеть вывод, который Вы ожидаете.

Так, для получения желаемого поведения добавляют текст к файлу с помощью >> от терминала вместо того, чтобы вручную редактировать его.

<час> [еще 1117] детали

nano, кажется, нечетный здесь. Большинство редакторов при открытии файла, тогда сохраняющего его, на самом деле удалит исходный файл и сохранит новый с тем же именем. Можно протестировать это путем проверки inode номер файла:

$ ls -il file.txt
16647801 -rw-r--r-- 1 terdon terdon 9 Apr  6 18:19 file.txt

Файлы просто hardlinks к определенному inodes, в этом случае, file.txt точки к inode 16647801. Теперь, откройте файл в gedit, добавьте строку и проверьте inode снова:

$ gedit file.txt
$ ls -il file.txt
16647854 -rw-r--r-- 1 terdon terdon 13 Apr  6 18:23 file.txt

, Как Вы видите, inode число изменилось, другими словами, исходный файл был удален, и был создан новый. nano не делает, это, пробуя то же самое [1 111] не изменяет inode. Это действительно, однако, удаляет исходное содержание, перезаписывающее их с новым содержанием. Вот почему tail на самом деле шоу вывод, если Вы пробуете его и редактируете файл с [1 113] (или emacs или много других редакторов), дополнительные строки, которые Вы добавляете, не покажут в выводе [1 115] вообще.

13
ответ дан 19.05.2020, 04:30
  • 1
    Нано был проблемой.Спасибо. Используя echo text >> file.txt вместо нано решает проблему. – Kaktus 19.05.2020, 04:31
  • 2
    Удаление файла (remove(...); и воссоздание его с нуля) и усечение его содержания (open(..., O_TRUNC | O_WRONLY); или fopen(..., "wb"); или ftruncate(...)) не являются тем же, следовательно мой вопрос. Оба могут привести к другому виду условий состязания. – thecodejack 19.05.2020, 04:31
  • 3
    @rr-ах, хорошо, я вижу то, что Вы имеете в виду. Ну, я работал strace на нано и этом , взгляды как он сначала открывают O_RDONLY, затем закрываются и открываются снова O_WRONLY|O_CREAT|O_APPEND в этой точке, которую это, кажется, делает write() вызов, но я can' t говорят что it' s запись. Наконец, это закрывается снова и открывается O_WRONLY|O_CREAT|O_TRUNC и затем пишет текст, который я сказал ему писать. Так, Вы, кажется, совершенно правы, и работа происходит с усеченным вызовом. Я отредактировал соответственно, спасибо. – superluminary 19.05.2020, 04:31
  • 4
    @rr-да, that' s, почему Вы получаете файл усеченная ошибка. Исходное содержание было удалено (файл был удален), и затем новое содержание добавляется. – Enijar 19.05.2020, 04:32
  • 5
    nano does however, delete the original and overwrite it with a new file, just pointing to the same inode. Вы уверены в этом? Это звучит ужасно непортативным. Doesn' t это просто усекают файл и добавляют новое содержание? – bodi0 19.05.2020, 04:32

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

В этой конкретной ситуации я использовал бы следующее в качестве обходного решения:

watch -n 1 cat file.txt

команда часов периодически выполняет команду. Интервал обновления, в секундах, определяется с -n и может быть скорректирован к Вашей симпатии.

7
ответ дан 19.05.2020, 04:30

Теги

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