coproc lock -g surictrl -m 0660 -w $SURI_LOCK lock-keeper
read x <&${COPROC[0]}
----

The corpoc command executes a shell command in a forked shell without
waiting for it. Stdin and stdout of the coprocess are connected to pipes
whose file descriptors are available as member 0 and 1 of an array, by
default named COPROC.

The command used here acquires an exclusive lock on the file passed as
argument to -w and then execs another command (which inherits the
lock). In this case, this other command writes a \n terminated string to
its stdout and then reads from its stdin until an EOF is encountered
which causes it to terminate, implicitly releasing the lock.

The parent shell will remained blocked in the read until it has read the
line written by the lock-keeper command. This means execution of the
main script will be paused until the lock could be acquired. The two
lines above are part of a shell function defined as ()-delimited
block. The function will thus run in a forked subshell. Upon return of
the function, the subhshell will exit which causes the stdin descriptor
of the locking coprocess to be closed, ultimatively leading to release
of the lock.

Comments, opinions or alternate suggestions, especially something which
would work with a stock /bin/sh very much appreciated.

On 2021-10-10, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> coproc lock -g surictrl -m 0660 -w $SURI_LOCK lock-keeper
> read x <&${COPROC[0]}
> ----
>
> The corpoc command executes a shell command in a forked shell without
> waiting for it. Stdin and stdout of the coprocess are connected to pipes
> whose file descriptors are available as member 0 and 1 of an array, by
> default named COPROC.
>
> The command used here acquires an exclusive lock on the file passed as
> argument to -w and then execs another command (which inherits the
> lock). In this case, this other command writes a \n terminated string to
> its stdout and then reads from its stdin until an EOF is encountered
> which causes it to terminate, implicitly releasing the lock.
>
> The parent shell will remained blocked in the read until it has read the
> line written by the lock-keeper command. This means execution of the
> main script will be paused until the lock could be acquired. The two
> lines above are part of a shell function defined as ()-delimited
> block. The function will thus run in a forked subshell. Upon return of
> the function, the subhshell will exit which causes the stdin descriptor
> of the locking coprocess to be closed, ultimatively leading to release
> of the lock.
>
> Comments, opinions or alternate suggestions, especially something which
> would work with a stock /bin/sh very much appreciated.

u don;t wanna wait but you use *lock* :P

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> On 2021-10-10, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> coproc lock -g surictrl -m 0660 -w $SURI_LOCK lock-keeper
>> read x <&${COPROC[0]}
>> ----
>>
>> The corpoc command executes a shell command in a forked shell without
>> waiting for it. Stdin and stdout of the coprocess are connected to pipes
>> whose file descriptors are available as member 0 and 1 of an array, by
>> default named COPROC.
>>
>> The command used here acquires an exclusive lock on the file passed as
>> argument to -w and then execs another command (which inherits the
>> lock). In this case, this other command writes a \n terminated string to
>> its stdout and then reads from its stdin until an EOF is encountered
>> which causes it to terminate, implicitly releasing the lock.
>>
>> The parent shell will remained blocked in the read until it has read the
>> line written by the lock-keeper command. This means execution of the
>> main script will be paused until the lock could be acquired. The two
>> lines above are part of a shell function defined as ()-delimited
>> block. The function will thus run in a forked subshell. Upon return of
>> the function, the subhshell will exit which causes the stdin descriptor
>> of the locking coprocess to be closed, ultimatively leading to release
>> of the lock.
>>
>> Comments, opinions or alternate suggestions, especially something which
>> would work with a stock /bin/sh very much appreciated.
>
> u don;t wanna wait but you use *lock* :P

u assumption wrong :-) --- the point of this exercise is obviously to ensure
that the shell waits until the lock is free (ie, not used by the
possibly concurrently running other process also manipulating the same,
shared resources).

On 2021-10-11, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>> On 2021-10-10, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>> coproc lock -g surictrl -m 0660 -w $SURI_LOCK lock-keeper
>>> read x <&${COPROC[0]}
>>> ----
>>>
>>> The corpoc command executes a shell command in a forked shell without
>>> waiting for it. Stdin and stdout of the coprocess are connected to pipes
>>> whose file descriptors are available as member 0 and 1 of an array, by
>>> default named COPROC.
>>>
>>> The command used here acquires an exclusive lock on the file passed as
>>> argument to -w and then execs another command (which inherits the
>>> lock). In this case, this other command writes a \n terminated string to
>>> its stdout and then reads from its stdin until an EOF is encountered
>>> which causes it to terminate, implicitly releasing the lock.
>>>
>>> The parent shell will remained blocked in the read until it has read the
>>> line written by the lock-keeper command. This means execution of the
>>> main script will be paused until the lock could be acquired. The two
>>> lines above are part of a shell function defined as ()-delimited
>>> block. The function will thus run in a forked subshell. Upon return of
>>> the function, the subhshell will exit which causes the stdin descriptor
>>> of the locking coprocess to be closed, ultimatively leading to release
>>> of the lock.
>>>
>>> Comments, opinions or alternate suggestions, especially something which
>>> would work with a stock /bin/sh very much appreciated.
>>
>> u don;t wanna wait but you use *lock* :P
>
> u assumption wrong :-) --- the point of this exercise is obviously to ensure
> that the shell waits until the lock is free (ie, not used by the
> possibly concurrently running other process also manipulating the same,
> shared resources).
Why do you need a lock? It is only need when other processes are not
under you control?

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> On 2021-10-11, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>> On 2021-10-10, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>> coproc lock -g surictrl -m 0660 -w $SURI_LOCK lock-keeper
>>>> read x <&${COPROC[0]}
>>>> ----

[...]

>>> u don;t wanna wait but you use *lock* :P
>>
>> u assumption wrong :-) --- the point of this exercise is obviously to ensure
>> that the shell waits until the lock is free (ie, not used by the
>> possibly concurrently running other process also manipulating the same,
>> shared resources).
> Why do you need a lock? It is only need when other processes are not
> under you control?

Non-atomic modification of some set of files by two possibly
concurrently running processes.

On 2021-10-12, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>> On 2021-10-11, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>>> On 2021-10-10, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>>> coproc lock -g surictrl -m 0660 -w $SURI_LOCK lock-keeper
>>>>> read x <&${COPROC[0]}
>>>>> ----
>
> [...]
>
>>>> u don;t wanna wait but you use *lock* :P
>>>
>>> u assumption wrong :-) --- the point of this exercise is obviously to ensure
>>> that the shell waits until the lock is free (ie, not used by the
>>> possibly concurrently running other process also manipulating the same,
>>> shared resources).
>> Why do you need a lock? It is only need when other processes are not
>> under you control?
>
> Non-atomic modification of some set of files by two possibly
> concurrently running processes.
What's problem to run them sequentually? AS if you don't have two
disks?

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> On 2021-10-12, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>> On 2021-10-11, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>>>> On 2021-10-10, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>>>> coproc lock -g surictrl -m 0660 -w $SURI_LOCK lock-keeper
>>>>>> read x <&${COPROC[0]}
>>>>>> ----
>>
>> [...]
>>
>>>>> u don;t wanna wait but you use *lock* :P
>>>>
>>>> u assumption wrong :-) --- the point of this exercise is obviously to ensure
>>>> that the shell waits until the lock is free (ie, not used by the
>>>> possibly concurrently running other process also manipulating the same,
>>>> shared resources).
>>> Why do you need a lock? It is only need when other processes are not
>>> under you control?
>>
>> Non-atomic modification of some set of files by two possibly
>> concurrently running processes.
> What's problem to run them sequentually? AS if you don't have two
> disks?

They are being forced to run sequentially if both of them attempt to
modify the same set of files at the same time.

On 2021-10-12, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>>>
>>>>> u assumption wrong :-) --- the point of this exercise is obviously to ensure
>>>>> that the shell waits until the lock is free (ie, not used by the
>>>>> possibly concurrently running other process also manipulating the same,
>>>>> shared resources).
>>>> Why do you need a lock? It is only need when other processes are not
>>>> under you control?
>>>
>>> Non-atomic modification of some set of files by two possibly
>>> concurrently running processes.
>> What's problem to run them sequentually? AS if you don't have two
>> disks?
>
> They are being forced to run sequentially if both of them attempt to
> modify the same set of files at the same time.

I admire your patience in bothering to explain what should be obvious!
I'd expect such non-understanding if this was a MSDOS group :-)

Needless to say I found your solution interesting.
Jim