Или это не vi?

нормально всё с редактированием в vi

Через ssh - да, а через paramiko? Боюсь себе представить код, который будет ему команды слать)

это emacs

да

Супер. Ты умеешь пользоваться ими?

С точки зрения операционной системы есть всего два способа изменить файл: полностью заменить его содержимое и дописать что-то в конец. Когда ты открываешь файл в vi и вроде как меняешь всего две буквы, в момент сохранения старый файл целиком стирается, а новый записывается. То, что новый от старого отличается на два байта, операционную систему не волнует.

на самом деле способов чуть больше )

Супер. Ты умеешь пользоваться ими?

да))

да))

Тогда вообще шикарно ? Значит, ты уже знаешь как решать твою задачу.

Не знаю, о чем вы, но что насчет ФС? Наверняка перезаписывается только один блок

Теоретически можно заменить два байта в фйле, но это очень уж низоуровнево.

суть в том, что подключиться нужно к приставке mag250, на борту linux2.6 обрезаный.

а что за файл изменить надо? и что мешает скачать и локально поправить?

Теоретически можно заменить два байта в фйле, но это очень уж низоуровнево.

Не пару байт, а 512, а то и 4096, вот тут я хз. P.S.: плюс метаинфу всякую

на самом деле способов чуть больше )

Например?

Например?

можно в середину файла записать

изменить всего лишь надо два параметра. ты предлагаешь башевскую каманду/скрипт пульнуть ему?))

Встреча сообщества SPb Python 11 сентября в ЦДО "Феникс". Возвращение вторых вторников! Формируем программу все вместе. https://spbpython.guru/news/meetup-20180911-second-tuesday-again #secondtuesday #meetup

можно в середину файла записать

Можно, но это нужно тесно с фалйовой системой работать: искать блоки на диске, писать прямо в них. Довольно редкая задача, имхо.

изменить всего лишь надо два параметра. ты предлагаешь башевскую каманду/скрипт пульнуть ему?))

Именно

Можно, но это нужно тесно с фалйовой системой работать: искать блоки на диске, писать прямо в них. Довольно редкая задача, имхо.

Wut? ОС сама это должна делать

Ну ФС, если быть точнее

Wut? ОС сама это должна делать

Ок, я не знаю таких системных вызовов. Если знаешь - делись)

Ну ФС, если быть точнее

ФС - это уже не ось)

Ок, я не знаю таких системных вызовов. Если знаешь - делись)

Так с помощью обычных. Seek на нужное место и поехали. Дичайше лень гуглить, поэтому просто скажу, что _наверно_ есть. Ну иначе изменение пары байт в начале многогигабайтного файла занимала бы огромное время.

ФС - это уже не ось)

Ой все, я не компьютерщик, не понимаю всех этих ваших штук

Именно

Благодарю, ща буду тестить))

Так с помощью обычных. Seek на нужное место и поехали. Дичайше лень гуглить, поэтому просто скажу, что _наверно_ есть. Ну иначе изменение пары байт в начале многогигабайтного файла занимала бы огромное время.

man fopen говорит, что нельзя. Открыть файл на запись можно или в режиме w, который очищает файл, или в режиме a, который добавляет в конец. При этом можно открыть на чтение и запись сразу, но 1) режим w один фиг затирает файл, и читать можно только то, что записано в текущем "сеансе", 2) в режиме a указатель чтения окажется в начале файла, но писать можно будет только в конец.

Можно, но это нужно тесно с фалйовой системой работать: искать блоки на диске, писать прямо в них. Довольно редкая задача, имхо.

FALLOC_FL_INSERT_RANGE

http://man7.org/linux/man-pages/man2/fallocate.2.html

man fopen говорит, что нельзя. Открыть файл на запись можно или в режиме w, который очищает файл, или в режиме a, который добавляет в конец. При этом можно открыть на чтение и запись сразу, но 1) режим w один фиг затирает файл, и читать можно только то, что записано в текущем "сеансе", 2) в режиме a указатель чтения окажется в начале файла, но писать можно будет только в конец.

r+

Вау

И то, и другое)

Спасибо, теперь буду ещё умнее.

FALLOC_FL_INSERT_RANGE

Если я правильно понимаю, это не физическая вставка места в середину, а явная фрагментация, так?

Так с помощью обычных. Seek на нужное место и поехали. Дичайше лень гуглить, поэтому просто скажу, что _наверно_ есть. Ну иначе изменение пары байт в начале многогигабайтного файла занимала бы огромное время.

Это только с бинарными файлами известного формата можно делать. С текстовыми -- нет.

man fopen говорит, что нельзя. Открыть файл на запись можно или в режиме w, который очищает файл, или в режиме a, который добавляет в конец. При этом можно открыть на чтение и запись сразу, но 1) режим w один фиг затирает файл, и читать можно только то, что записано в текущем "сеансе", 2) в режиме a указатель чтения окажется в начале файла, но писать можно будет только в конец.

Кроме fopen можно использовать ещё и open(), но проблема не в этом, а в том, что разделить файл на строки можно только прочитав его с начала построчно и обработав соотв. образом.

Это только с бинарными файлами известного формата можно делать. С текстовыми -- нет.

С текстовыми, для которых количество байт на символ вариативно? Ну это само собой разумеется

man fopen говорит, что нельзя. Открыть файл на запись можно или в режиме w, который очищает файл, или в режиме a, который добавляет в конец. При этом можно открыть на чтение и запись сразу, но 1) режим w один фиг затирает файл, и читать можно только то, что записано в текущем "сеансе", 2) в режиме a указатель чтения окажется в начале файла, но писать можно будет только в конец.

fopen - это про libc.

Кроме fopen можно использовать ещё и open(), но проблема не в этом, а в том, что разделить файл на строки можно только прочитав его с начала построчно и обработав соотв. образом.

Вообще, я имел ввиду системный выхов Linux, а не функцию пайтона. И делить на строки, в общем, можно и с середины, и с конца. Например, tail так делает: читает с конца, бьёт на строки, если не хватило, дочитывает ещё немного.

Если я правильно понимаю, это не физическая вставка места в середину, а явная фрагментация, так?

что значит "явная фрагментация"?

С текстовыми, для которых количество байт на символ вариативно? Ну это само собой разумеется

Там посрать.

Хотя, нет, я неправ

Вообще, я имел ввиду системный выхов Linux, а не функцию пайтона. И делить на строки, в общем, можно и с середины, и с конца. Например, tail так делает: читает с конца, бьёт на строки, если не хватило, дочитывает ещё немного.

системный вызов -- это open()

что значит "явная фрагментация"?

Блоки выделяются в произвольном свободном участке диска, и в таблице файлов (или как она называется в современных ФС) отмечается, что с такого-то по такой-то байт нужно читать из такого-то блока.

системный вызов -- это open()

man такого вызова не знает

man такого вызова не знает

вообще-то знает

man такого вызова не знает

https://www.opennet.ru/man.shtml?topic=open&category=2

Блоки выделяются в произвольном свободном участке диска, и в таблице файлов (или как она называется в современных ФС) отмечается, что с такого-то по такой-то байт нужно читать из такого-то блока.

а чем это отличается от обычной записи в файл?

а чем это отличается от обычной записи в файл?

Ничем. Это не управляется программно.

https://linux.die.net/man/3/open

Выделение блоков под файл файловой системой не управляется программно.

а чем это отличается от обычной записи в файл?

Да принципиально ничем, просто не думал, что этим можно явно управлять, причём довольно просто.

https://linux.die.net/man/3/open

это не та секция. 3 - это библиотечные вызовы. сисколлы - это 2я

Да принципиально ничем, просто не думал, что этим можно явно управлять, причём довольно просто.

можно через fallocate/posix_fallocate. но это скорее хинт, а не гарантия что выделят физически непрерывный кусок на диске.

это не та секция. 3 - это библиотечные вызовы. сисколлы - это 2я

This manual page is part of the POSIX Programmer's Manual. Не, ничего не говорит? Это не стандарт С/C++, это POSIX.

В какой секции манов при этом это описано -- ну, по барабану. Оно может быть и реализовано в стандартной библиотеке С, как в Шиндовс например

но вот то что я кидал выше про fallocate(не путать с posix вариантом) - это возможность вставить/удалить блоков в любой точке файла без дорогой возни с перемещением всего контента.

ERROR: S client not available

В какой секции манов при этом это описано -- ну, по барабану. Оно может быть и реализовано в стандартной библиотеке С, как в Шиндовс например

вы неправы, т.к. путаете сисколлы и библиотечные вызовы.

ок. я неправ.

>Requests is the only Non-GMO HTTP library for Python, safe for human consumption.

>Requests is the only Non-GMO HTTP library for Python, safe for human consumption.

the only? а пруф?:)

http://docs.python-requests.org/en/master/

сверху прям

сверху прям

я имел в виду, что то что оно единственное без ГМО не доказано

а, ну то что без ГМО можно доказать. А вот то, что единственное - надо постараться.

а, ну то что без ГМО можно доказать. А вот то, что единственное - надо постараться.

вот я именно об этом:)

Встреча сообщества SPb Python 11 сентября в ЦДО "Феникс". Возвращение вторых вторников! Формируем программу все вместе. https://spbpython.guru/news/meetup-20180911-second-tuesday-again #secondtuesday #meetup

Нда.

Нда.

Высказывайтесь конкретнее, пожалуйста

Высказывайтесь конкретнее, пожалуйста

Ну это про дату. Сам знаешь почему ?

Ну это про дату. Сам знаешь почему ?

Так получилось. Раньше с FProg часто совпадали. Бывает.

Оно само, ага-да.

Оно само, ага-да.

Я не смотрел на программу PiterPy Meetup, когда мы в июне восстановили наши традиционные вторые вторники.

Всем привет! В связи с тем, что сообщество важнее, чем его организаторы, решение этого вопроса надо отдать сообществу. Внезапно для меня (я правда не ожидал, что PiterPy Meetup возьмет себе наши исторические вторые вторники) у организаторов @spbpython и @p anonymous poll Мы выше всего этого. У них уже докладчики и всё такое. Давайте выберем новый день и будем его придерживаться. – 37 ??????? 76% В один день, значит в один день. Так веселее и места на митапах будет больше. – 8 ?? 16% Ни шагу назад. SPb Python должен быть во второй вторник! PiterPy Meetup должен уступить. – 4 ? 8% ? 49 people voted so far.

Всем привет! В связи с тем, что сообщество важнее, чем его организаторы, решение этого вопроса надо отдать сообществу. Внезапно для меня (я правда не ожидал, что PiterPy Meetup возьмет себе наши исторические вторые вторники) у организаторов @spbpython и @p anonymous poll Мы выше всего этого. У них уже докладчики и всё такое. Давайте выберем новый день и будем его придерживаться. – 37 ??????? 76% В один день, значит в один день. Так веселее и места на митапах будет больше. – 8 ?? 16% Ни шагу назад. SPb Python должен быть во второй вторник! PiterPy Meetup должен уступить. – 4 ? 8% ? 49 people voted so far.

Всем привет! В связи с тем, что сообщество важнее, чем его организаторы, решение этого вопроса надо отдать сообществу. Внезапно для меня (я правда не ожидал, что PiterPy Meetup возьмет себе наши исторические вторые вторники) у организаторов @spbpython и @piterpy_meetup наметилась конфронтация по поводу дат митапов. Предыстория вопроса вкратце такова. Чуть меньше года назад @nazarov_tech будучи одним из организаторов митапов SPb Python решил отпочковаться и организовать своё сообщество вместе с некоторыми другими участниками. Сделано, на мой взгляд, это было не очень корректно, но мы достигли договоренностей, создали новый сайт spbpython.guru, где размещали все анонсы всех наших активностей и активностей PiterPy Meetup. По договоренности митапы с докладами делал PiterPy Meetup, в том числе в наши традиционные вторые вторники. Не так давно Митя в одностороннем порядке, выразив личную неприязнь ко мне лично, разорвал все договоренности. Мы, естественно, решили вернуться к нашим вторым вторникам. В августе это не получилось по техническим причинам (Рафаэль не мог быть в Питере во второй вторник). Всем оргам PiterPy Meetup было прекрасно известно, что мы вернемся ко вторым вторникам. И я лично сообщал об этом Мите. В связи с этим вопрос: что мы будем делать с датами наших митапов?

А где вариант "поговорить, выяснить причины и решить мирно"?

А где вариант "поговорить, выяснить причины и решить мирно"?

не вариант на данный момент. а митапы надо делать сейчас.

Что могут не поделить два питониста?

Что могут не поделить два питониста?

GIL

- синглтон

GIL

+

А вариант, "хочу посетить оба мероприятия"? Эх, не дело терять контакты/связи

А вариант, "хочу посетить оба мероприятия"? Эх, не дело терять контакты/связи

так в разные дни никто не мешает оба посетить. таких варианта аж два

Я за диалог, а дом варианты про решения с одной стороны, грубо говоря