Блокировка файла в shell () (Блокировка файла в shell (аналог flock_t си))

[lastpriot]

Возможно ли средствами shell реализовать блокировку файла?
(в гугле по даному вопросу ничего вразумительного не нашел)

[Uncle_Theodore]

Возможно ли средствами shell реализовать блокировку файла?
(в гугле по даному вопросу ничего вразумительного не нашел)

Типа как man 1 flock ?
Вот тут еще посмотри
http://project.net.ru/security/article7/gl6.html

[lastpriot]

спасибо за наводку)

[lastpriot]

поправьте меня, если ошибаюсь:
в скрипте создается блокировка на файл спомощью flock, пример

Код: Выделить всё

#!/bin/sh

(flock -x /home/lastpriot/local.txt -c test
ls /
sleep 30
)
200>/tmp/mylock

но доступ на чтение и запись к фалу local.txt с других скриптов все равно есть(
или в других скриптах надо делать проверку на блокировку с помощью flock ?
разьясните, пожалуйста

[Rootlexx]

Это рекомендательная блокировка. Поэтому да, "в других скриптах надо делать проверку на блокировку с помощью flock". Или включить строгие блокировки для ФС опцией монтирования "mand", а затем для файла - убиранием бита исполнения для группы и установкой бита SGID.

[lastpriot]

спасибо)
ещё вопрос по bash'у: как с дочернего процесса передать переменные в родительский?

[drBatty]

ещё вопрос по bash'у: как с дочернего процесса передать переменные в родительский?

ответ: никак.

можно сделать временный файл. числа от 0 до 255 можно передавать как код возврата. (это не так уж и мало - они могут быть например индексами к БД).

[Rootlexx]

как с дочернего процесса передать переменные в родительский?

Как вариант:

Код: Выделить всё

var=$(
# Дочерний процесс; нужная переменная просто выводится на stdout.
...
echo $result;
)

Конечно, это если сам дочерний процесс ничего другого на stdout не выводит.

[drBatty]

Конечно, это если сам дочерний процесс ничего другого на stdout не выводит.

по идее, если что-то выводит, можно создать свой поток: man mkfifo

[Rootlexx]

по идее, если что-то выводит, можно создать свой поток: man mkfifo

Вот только с выводом большого объёма данных будут проблемы, если их вовремя не читать. Придётся либо запускать параллельно читающий процесс либо ковыряться с ulimit.

[lastpriot]

ещё вопрос по bash'у: как с дочернего процесса передать переменные в родительский?

ответ: никак.

можно сделать временный файл. числа от 0 до 255 можно передавать как код возврата. (это не так уж и мало - они могут быть например индексами к БД).

надо возвращать текстовую инф
думал через глобальные переменные, но почему то не сложилось ни с export ни с declare
как временное решение использую tmp-файл, но больше склоняюсь к fifo

кстати, как аналог

Код: Выделить всё

var=$(
# Дочерний процесс; нужная переменная просто выводится на stdout.
...
echo $result;
)

использую такой формат (более лаконичный)

Код: Выделить всё

result=`<script>`

[watashiwa_daredeska]

надо возвращать текстовую инф

Стандартное решение в этом случае — выводить на stdout shell-script вида:

Код: Выделить всё

var1=value1
var2=value2
...
varN=valueN

и запускать так:

Код: Выделить всё

eval "$(program arg1 arg2 ... argN)"

Главное, с квотированием при выводе переменных не накосячить.

[lastpriot]

с помощью eval решил вопрос по возврату переменных (организовал в виде массива, избежал написания парсера)
всем спасибо)

[drBatty]

но почему то не сложилось ни с export ни с declare

это связанно с безопасностью - злоумышленник ведь может подменить в своём ~/.bashrc переменные, и они поменяются в родительском, (или для родительской программы). Например враг может $PATH, и когда программа запустившая ~/.bashrc запустит ещё что-то, то запустится вовсе не это что-то, а ПО злоумышленника. Причём с правами суперпользователя. Потому дочерний процесс не может менять переменные родителя.

использую такой формат (более лаконичный)

тоже самое. Только в вашем формате не допускает вложенность.

Главное, с квотированием при выводе переменных не накосячить.

довольно опасно, если переменные и значения неизвестно откуда...
а так да, стандартное решение.

[t.t]

кстати, как аналог

Код: Выделить всё

var=$(
# Дочерний процесс; нужная переменная просто выводится на stdout.
...
echo $result;
)

использую такой формат (более лаконичный)

Код: Выделить всё

result=`<script>`

В bash такой синтаксис deprecated, поэтому лучше его не использовать: можно напороться на странные неизлечимые глюки. Я в своё время напоролся:
http://forum.posix.ru/viewtopic.php?id=943
Кроме того, как уже отметил drBatty, он не допускает вложенности.

[watashiwa_daredeska]

В bash такой синтаксис deprecated

С чего бы? Он просто old style, а в bash его задепрекейтят не раньше, чем в POSIX.

[/dev/random]

В bash такой синтаксис deprecated, поэтому лучше его не использовать: можно напороться на странные неизлечимые глюки. Я в своё время напоролся:
http://forum.posix.ru/viewtopic.php?id=943
Кроме того, как уже отметил drBatty, он не допускает вложенности.

1) он допускает вложенность. Для этого внутренние бактики нужно экранировать:
$ echo `echo a \`echo b\` c`
a b c

2) "неизлечимые глюки", приведённые по ссылке, явно связаны с бакслэшем: бактики являются своего рода кавычками, и бакслэши в них интерпретируются особым образом.

[t.t]

В bash такой синтаксис deprecated

С чего бы? Он просто old style, а в bash его задепрекейтят не раньше, чем в POSIX.

Первоисточника навскидку не нашёл, но обсуждений достаточно:
http://mywiki.wooledge.org/BashFAQ/082
http://wiki.bash-hackers.org/scripting/obsolete
http://unix.derkeiler.com/Newsgroups/comp....4/msg00785.html
http://linuxgazette.net/52/okopnik2.html

[t.t]

1) он допускает вложенность. Для этого внутренние бактики нужно экранировать:
$ echo `echo a \`echo b\` c`
a b c

2) "неизлечимые глюки", приведённые по ссылке, явно связаны с бакслэшем: бактики являются своего рода кавычками, и бакслэши в них интерпретируются особым образом.

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