>> Would you care if waiting on such identifications for background processes
>> will occasionally be forgotten?
>>
>> How many efforts would you invest to add potentially missing wait function
>> calls?
>
> It's axiomatic: if you want to make a decision based on the exit status of
> any asynchron
On 12/27/20 1:30 PM, Saint Michael wrote:
We could allow only strings or more complex objects, but using bash-language
only, an internal mechanism, and also we need to define a semaphore.
Is it doable?
Of course it's doable; all that takes is requirements, definition, and
implementation. The
On 27/12/2020 at 19:30, Saint Michael wrote:
Yes, superglobal is great.
Example, from the manual:
" Shared Memory
Shared memory allows one or more processes to communicate via memory that
appears in all of their virtual address spaces. The pages of the virtual
memory is referenced by page table e
Yes, superglobal is great.
Example, from the manual:
" Shared Memory
Shared memory allows one or more processes to communicate via memory that
appears in all of their virtual address spaces. The pages of the virtual
memory is referenced by page table entries in each of the sharing
processes' page t
On 12/27/20 12:38 PM, Saint Michael wrote:
Bash is very powerful for its ability to use all kinds of commands and pipe
information through them. But there is a single thing that is impossible to
achieve except using files on the hard drive or on /tmp. We need a new
declare -g (global) where a var
Bash is very powerful for its ability to use all kinds of commands and pipe
information through them. But there is a single thing that is impossible to
achieve except using files on the hard drive or on /tmp. We need a new
declare -g (global) where a variable would have its contents changed by
subs
I want to suggest a new feature, that may be obvious at this point.
How do I do this?
Philip Orleans
On 12/27/20 5:01 AM, Markus Elfring wrote:
If you have the pid of an asynchronous command -- and the easiest way to get
that pid
is by referencing $! after it was started -- you can call `wait' with that pid
to retrieve the status, even if it's already terminated.
Would you care if waiting on
On 12/27/20 5:01 AM, Markus Elfring wrote:
If you have the pid of an asynchronous command -- and the easiest way to get
that pid
is by referencing $! after it was started -- you can call `wait' with that pid
to retrieve the status, even if it's already terminated.
Would you care if waiting on
> If you have the pid of an asynchronous command -- and the easiest way to get
> that pid
> is by referencing $! after it was started -- you can call `wait' with that pid
> to retrieve the status, even if it's already terminated.
Would you care if waiting on such identifications for background pr
10 matches
Mail list logo
