On Sat, Aug 01, 2020 at 05:57:01PM +0200, Klemens Nanni wrote:
> Otherwise it is not clear whether $! will be set or not.  This way,
> `/Co-proc<enter>' brings me to *all* relevant spots in the manual.
> Snippet to demonstrate how $! is set for an asynchronous process:
>       $ ksh -c ': |& echo $!' 
>       67163
> FWIW, sh(1) doesn't document Co-processes (whis is fine/correct) and
> bash(1) says this about $!:
>       !      Expands to the process ID of the job most recently placed into
>              the background, whether executed as an asynchronous command or
>              using the bg builtin (see JOB CONTROL below).
> Feedback? OK?
> Index: ksh.1
> ===================================================================
> RCS file: /cvs/src/bin/ksh/ksh.1,v
> retrieving revision 1.209
> diff -u -p -r1.209 ksh.1
> --- ksh.1     7 Jul 2020 10:33:58 -0000       1.209
> +++ ksh.1     1 Aug 2020 15:50:04 -0000
> @@ -1247,8 +1247,9 @@ The following special parameters are imp
>  set directly using assignments:
>  .Bl -tag -width "1 ... 9"
>  .It Ev \&!
> -Process ID of the last background process started.
> -If no background processes have been started, the parameter is not set.
> +Process ID of the last background process or asynchronous process 
> (Co-process)
> +started.
> +If no processes have been started, the parameter is not set.
>  .It Ev \&#
>  The number of positional parameters ($1, $2, etc.).
>  .It Ev \&$


i'm worried that you're blurring the distinction between asynchronous
and co-process for the reader. i think that's relevant because, as you
say, a page like sh(1) does not document co-processes, whereas ksh(1)

as i understand it, ksh explains co-processes as a type of asynchronous
process. and the setting of "!" is applicable to both. is that right?

so could your text be better written as:

        Process ID of the last background or asynchronous process started.
        If no processes have been started, the parameter is not set.

this would catch the setting of "!" for both async and co-process,
without making the text read like the two are identical.

if your concern is that you need to be able to /co-process, then i'd
rewrite the text to not blur the two:

        Process ID of the last background, co-process, or asynchronous
        process started.

but i dislike that, because it means the text suffers because of an
arbitrary request to make a specific search work.

i guess we could add a note to the "Some notes concerning co-processes"
section if it needs more clarity.

what do you think?


Reply via email to