Я предполагаю, что большинство людей на этом сайте знакомы с tail, в противном случае - он предоставляет режим «следования», который при добавлении текста к файлу tail будет выгружать эти символы в терминал.
То, что я ищу (и, возможно, могу написать сам, если необходимо), - это версия tail, которая работает с двоичными файлами. В основном у меня есть беспроводное соединение, по которому я хотел бы передать файл, когда он идет по другому сетевому каналу. Просматривая исходный код хвоста, его будет несложно переписать, но я бы не стал изобретать велосипед! Это не будет строго "хвостом", поскольку я хотел бы, чтобы весь файл был скопирован, но он будет наблюдать, как добавляются новые байты, и передавать их.
Идеи?





Подключите его к hexdump:
tail -f somefile | hexdump -C
Разве tail -f не будет выводить новые данные только тогда, когда он видит новую строку в двоичном файле? Я сомневаюсь, что он разблокирует свой стандартный вывод.
Хорошее замечание, Крис, я об этом не подумал. Итак, я только что протестировал его сейчас на Debian, и да, он по-прежнему работает, если в потоке нет новых строк, хотя это поведение может отличаться на разных платформах.
Использование hexdump - отвлекающий маневр, не так ли? Или, возможно, просто иллюстрация того, куда нужно отправлять двоичные данные. Я не вижу ничего в вопросе с просьбой о шестнадцатеричном дампе, вот и все ...
Обратите внимание, что hexdump выводится на экран только с шагом 16 байтов.
less somefile
Затем нажмите shift F
Я не перестаю видеть, как можно было бы использовать меньше для перенаправления на вывод файла и нажать Shift + F ...
Это не хвост - это постепенное копирование файла. Посмотрите на rsync.
Интересно, что это принятый ответ, где есть два ответа, которые больше соответствуют вопросу: stackoverflow.com/a/6173419/1353930stackoverflow.com/a/6171491/1353930. rsync здесь бесполезен, потому что он не может передавать данные. он ограничен (относительно статичными) файлами на диске
@ Дэниел Алдер. rsync можно запустить повторно, отправив только новые данные.
потоковая передача означает, что вы выполняете запуск сценария cgi или подключаетесь к netcat и т. д. Но это был больше вопрос в @Goyuix
Строго говоря, для этого вам нужно написать программу, поскольку tail не предназначен для работы с бинарными файлами. Есть также проблемы с буферизацией, которых вы, вероятно, захотите избежать, если хотите как можно скорее получить новые «просачивающиеся» данные.
Посмотрев еще раз, я увидел, что вы отметили свой вопрос gnu-coreutils. Так что, если вы знаете, что будете использовать реализацию tail в GNU, она, вероятно, безопасна для двоичного кода и, вероятно, не имеет проблемной буферизации (проверьте и посмотрите).
Этот наспех написанный скрипт Python для Windows может оказаться полезным:
# bintail.py -- reads a binary file, writes initial contents to stdout,
# and writes new data to stdout as it is appended to the file.
import time
import sys
import os
import msvcrt
msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY)
# Time to sleep between file polling (seconds)
sleep_int = 1
def main():
# File is the first argument given to the script (bintail.py file)
binfile = sys.argv[1]
# Get the initial size of file
fsize = os.stat(binfile).st_size
# Read entire binary file
h_file = open(binfile, 'rb')
h_bytes = h_file.read(128)
while h_bytes:
sys.stdout.write(h_bytes)
h_bytes = h_file.read(128)
h_file.close()
# Loop forever, checking for new content and writing new content to stdout
while 1:
current_fsize = os.stat(binfile).st_size
if current_fsize > fsize:
h_file = open(binfile, 'rb')
h_file.seek(fsize)
h_bytes = h_file.read(128)
while h_bytes:
sys.stdout.write(h_bytes)
h_bytes = h_file.read(128)
h_file.close()
fsize = current_fsize
time.sleep(sleep_int)
if __name__ == '__main__':
if len(sys.argv) == 2:
main()
else:
sys.stdout.write("No file specified.")
Также существует приложение бинтейл, которое кажется более надежным, чем вышеупомянутый сценарий.
The bintail package contains a single application, bintail. The program reads a normal file from disk, and pipes the output to stdout, byte-by-byte, with no translation, similar to what tail(1) does to text files. This is useful for "tailing" binary files, such as WAV files, while they are being written in realtime. This app is a work in progress, but it already does what it was designed to do for me.
Спасибо, это именно то, что мне нужно, для перенаправления вывода из "tcpflow" в поток nodejs :) Это не сработало с "tail -f".
В linux binutils tail -c +1 -f somefile работает точно так же.
Linux coreutils tail (1) отлично работает с двоичными файлами. Для большинства приложений вам просто нужно избегать его линейной ориентации, чтобы вывод не начинался в каком-то случайном месте в середине структуры данных. Вы можете сделать это, просто начав с начала файла, что также является именно тем, о чем вы просили:
tail -c +1 -f somefile
работает нормально.
Я использую это, так как он работает и в прямых трансляциях:
cat ./some_file_or_dev | hexdump -C
образец сброса моих нажатий клавиш (и релизов):
[user@localhost input]$ sudo cat /dev/input/event2 | hexdump -C
00000000 81 32 b1 5a 00 00 00 00 e2 13 02 00 00 00 00 00 |.2.Z............|
00000010 04 00 04 00 36 00 00 00 81 32 b1 5a 00 00 00 00 |....6....2.Z....|
00000020 e2 13 02 00 00 00 00 00 01 00 36 00 01 00 00 00 |..........6.....|
00000030 81 32 b1 5a 00 00 00 00 e2 13 02 00 00 00 00 00 |.2.Z............|
00000040 00 00 00 00 00 00 00 00 81 32 b1 5a 00 00 00 00 |.........2.Z....|
00000050 a3 af 02 00 00 00 00 00 04 00 04 00 36 00 00 00 |............6...|
00000060 81 32 b1 5a 00 00 00 00 a3 af 02 00 00 00 00 00 |.2.Z............|
^C
Проблема с hexdump заключается в том, что он ожидает, пока каждая строка будет напечатана кратными 16 байтам, но пока вы знаете об этой проблеме, все в порядке.
Вероятно, это из-за переключателя -C (столбец ascii)
Я сам не был уверен на 100%, но я попробовал, и он отлично работает.