Работа fuser

Добрый день, стоит такая задача.
Открыть файл home/d/Balmont.txt двумя разными редакторами (выбрал vi и nano) и вывести процессы, работающие с Balmont.txt с помощью fuser.
Соответственно в двух окнах терминала открыл файл двумя редакторами, а в третьем прописал:
.
По итогу, ничего не вывелось.
Пробовал всё делать в одном окне, переводя процессы редакторов в фоновый режим, всё равно ничего не выводится. В чём ошибка?

0

В открытой сессии vim посмотри на вывод команды :sw

и данное полученное имя swap-файла подсунь fuser

Добавлено через 11 минут
(
удобнее даже так: сначала выполни команду
:redir @*
а затем
:sw
и искомое имя своп-файла окажется в clipboard
)

0

А ты из той же самой директории fuser вызвал? Попробуй абсолютный путь.

0

Да, все из домашнего каталога делаю.

Добавлено через 6 минут
Спасибо за объяснения, вот задание:

"Откройте на редактирование один и тот же файл двумя редакторами. Определите PID и имя владельца процессов, которые используют данный файл. С помощью сигнала SIGTERM завершите процессы, которые используют данный файл с выдачей запроса на подтверждение от пользователя. "

По всем пунктам видно, что нужно использовать команду
Я бы сделал, как вы описали, но это противоречит заданию, где нужно убить всех зайцев одной командой. Плюс vim и nano блокируют файл (то есть, в любом случае, работают с ним), следовательно эти два процесса для файла myfile должны быть видны в fuser.

0

Сообщение от Bacchus Плюс vim и nano блокируют файл

не блокируют, если верить собственным глазам и выводу от fuser

Добавлено через 22 минуты
fusertest

0

Сообщение от volodin661 не блокируют, если верить собственным глазам и выводу от fuser

Тогда какие стандартные редакторы блокируют доступ к файлу или непосредственно используют его?
Как я читал,

"Vim - мощный текстовый редактор командной строки, который может блокировать файл при его открытии. Emacs - другой мощный текстовый редактор, который также может блокировать файл при его открытии. Nano - легкий текстовый редактор, который может блокировать файл, если он открыт в режиме редактирования."

Да и nano, если открыт vim, говорит, что файл занят другим процессом.

0

Сообщение от Bacchus Плюс vim и nano блокируют файл

Ничего подобного! flock они не используют. А даже если одна использует, другая, судя по всему - нет. Ну, а т.к. блокировка эта лишь "консультативная", то на нее смело можно класть.
В линуксе есть лишь одно средство, позволяющее заблокировать файл так, чтобы уж точно никто больше не имел к нему доступа (кроме ядра, естественно): вызвать unlink и спокойно работать с файлом (правда, в случае падения утилиты файл исчезнет).
А в мане, похоже, имеется в виду условная блокировка - как та же "либра" во время редактирования файла создает в той же директории специальный файлик-метку, говорящий другому запущенному процессу убогого "офиса", что файл уже редактируется (а в файлик пишется PID процесса, который файл редактирует - чтобы если он упадет, не было дедлоков).

1

Сообщение от Eddy_Em если одна

вы совершенно правы
изменим чтонибудь в файле misc.txt
появится и тогда
и тогда
и тогда

1

skouzmine, провел эксперимент. Действительно, vim не держит редактируемый файл (видимо, в целях безопасности - если упадет, чтобы файл не повредить). Видимо, файл лишь перезаписывается при сохранении, а все время редактирования целиком сидит в оперативке!
А вот если этот файл начать просматривать при помощи less или more, то все ОК: fuser покажет, что файл открыт ими.

Одним словом, контрольная работа невыполнима, т.к. противоречит принципам утилит-редакторов. Открыл файл при помощи mc - та же петрушка! Файл полностью переписывается в оперативку и с ним работает пользователь. fuser не показывает ничего. Попытался открыть 16-гиговый файл в редакторе mc: пошла медленная "загрузка" - т.е. он таки пытается этот файл в оперативку скинуть. И если файл будет больше размера доступной ОЗУ, то, подозреваю, ничего не выйдет. Для этих целей нужны спецредакторы, которые именно открывают файл и работают с ним (но это чревато серьезными повреждениями файла при смерти процесса, а смерть может не только от случайного сегфолта наступить или от kill, но и от oom-killer, который следит, чтобы оперативку не засоряли всякие эдакие).

1

1