Anyone familiar with auto-fu.zsh project?

Anyone familiar with auto-fu.zsh project?

[Sebastian Gniazdowski]

Hello,
last commit to the project is from 2013 and I cannot get it up and
running. Is anyone familiar with its method of functioning? A friend
guesses it pretends <tab> key to be pressed after each character, is
that true? It would then mean it constantly shows completions under
prompt. Is using shell this way actually possible?

In general, I'm looking for a method of calling completion functions
manually and presenting the results in different form. Does someone
know anything about this problem?

-- 
Best regards,
Sebastian Gniazdowski

Re: Anyone familiar with auto-fu.zsh project?

[Eric Freese]

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

Check out https://github.com/Valodim/zsh-capture-completion.

I referenced it recently to implement completion suggestions in
zsh-autosuggestions:
https://github.com/zsh-users/zsh-autosuggestions/pull/330

On Wed, Jun 6, 2018 at 11:43 AM Sebastian Gniazdowski <
sgniazdowski@gmail.com> wrote:

> Hello,
> last commit to the project is from 2013 and I cannot get it up and
> running. Is anyone familiar with its method of functioning? A friend
> guesses it pretends <tab> key to be pressed after each character, is
> that true? It would then mean it constantly shows completions under
> prompt. Is using shell this way actually possible?
>
> In general, I'm looking for a method of calling completion functions
> manually and presenting the results in different form. Does someone
> know anything about this problem?
>
> --
> Best regards,
> Sebastian Gniazdowski
>
-- 
Sent from my iPhone

Re: Anyone familiar with auto-fu.zsh project?

[Takeshi Banse]

Hello,

* Sebastian Gniazdowski <sgniazdowski@gmail.com> [2018-06-07 02:42]:
> A friend guesses it pretends <tab> key to be pressed after each
> character, is that true?

Yes, it is almost true. It calls `complete-word' (or `list-choices') if
it could be appropriate.

I've borrowed from http://mimosa-pudica.net/zsh-incremental.html and
adapted to use keymap+widget

> In general, I'm looking for a method of calling completion functions
> manually and presenting the results in different form. Does someone
> know anything about this problem?

So, this project is not suite for your needs, I guess.

Re: Anyone familiar with auto-fu.zsh project?

[Sebastian Gniazdowski]

New autosuggestions is on the way (reddit says), it looks like the
capture-completion zpty-based solution worked?

On 6 June 2018 at 20:35, Eric Freese <ericdfreese@gmail.com> wrote:
> Check out https://github.com/Valodim/zsh-capture-completion.
>
> I referenced it recently to implement completion suggestions in
> zsh-autosuggestions:
> https://github.com/zsh-users/zsh-autosuggestions/pull/330
>
> On Wed, Jun 6, 2018 at 11:43 AM Sebastian Gniazdowski
> <sgniazdowski@gmail.com> wrote:
>>
>> Hello,
>> last commit to the project is from 2013 and I cannot get it up and
>> running. Is anyone familiar with its method of functioning? A friend
>> guesses it pretends <tab> key to be pressed after each character, is
>> that true? It would then mean it constantly shows completions under
>> prompt. Is using shell this way actually possible?
>>
>> In general, I'm looking for a method of calling completion functions
>> manually and presenting the results in different form. Does someone
>> know anything about this problem?
>>
>> --
>> Best regards,
>> Sebastian Gniazdowski
>
> --
> Sent from my iPhone

Re: Anyone familiar with auto-fu.zsh project?

[Eric Freese]

[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]

It seems to have worked so far, yes, though I'm not sure how many people
have actually tested it. I will be releasing it as an opt-in, experimental
feature in case some issues pop up once people really start using it

I did make some modifications to the zsh-capture-completion script to
better suit our needs. Instead of running `zsh -f` in the zpty, I just run
a function so that the user-defined functions and non-exported variables
are still completed. I also modified it not to print completion
descriptions and to only return the first generated completion since that's
all we need.

Some day I would like to look into how difficult it might be to define a
new builtin to fetch completion results for a given string. That would be
much nicer to work with than this pty trickery.

On Sat, Jun 9, 2018 at 9:30 AM Sebastian Gniazdowski <sgniazdowski@gmail.com>
wrote:

> New autosuggestions is on the way (reddit says), it looks like the
> capture-completion zpty-based solution worked?
>
> On 6 June 2018 at 20:35, Eric Freese <ericdfreese@gmail.com> wrote:
> > Check out https://github.com/Valodim/zsh-capture-completion.
> >
> > I referenced it recently to implement completion suggestions in
> > zsh-autosuggestions:
> > https://github.com/zsh-users/zsh-autosuggestions/pull/330
> >
> > On Wed, Jun 6, 2018 at 11:43 AM Sebastian Gniazdowski
> > <sgniazdowski@gmail.com> wrote:
> >>
> >> Hello,
> >> last commit to the project is from 2013 and I cannot get it up and
> >> running. Is anyone familiar with its method of functioning? A friend
> >> guesses it pretends <tab> key to be pressed after each character, is
> >> that true? It would then mean it constantly shows completions under
> >> prompt. Is using shell this way actually possible?
> >>
> >> In general, I'm looking for a method of calling completion functions
> >> manually and presenting the results in different form. Does someone
> >> know anything about this problem?
> >>
> >> --
> >> Best regards,
> >> Sebastian Gniazdowski
> >
> > --
> > Sent from my iPhone
>
-- 
Sent from my iPhone

Re: Anyone familiar with auto-fu.zsh project?

[Sebastian Gniazdowski]

Hello,
I've just implemented async feature without using zpty. From what I
saw zsh-autosuggestions uses zpty to look-up the suggestion. Maybe it
has some drawbacks and you would be interested in using <( ) instead
of zpty (it's probably still required to capture completions, though)?
It's similar to using zpty:

exec {PCFD}< <(-fast-highlight-check-path)
zle -F -w "$PCFD" fast-highlight-check-path-handler

-fast-highlight-check-path-handler() {
    if read -r -u "$PCFD" line; then
    ...
    fi
    zle -F ${PCFD}
    exec {PCFD}<&-
}

<( ) process is automatically disowned, I've used it in 2 projects and
it works without problems, very robust. The effect:

https://asciinema.org/a/V18uHIn2BR0OVfRsmxyqkVi7K

-- 
Best regards,
Sebastian Gniazdowski

Re: Anyone familiar with auto-fu.zsh project?

[Eric Freese]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

Wow this is much nicer. I've implemented on `develop` branch of
zsh-autosuggestions.

Thank you!

Eric Freese
303 875 2359

On Sun, Jun 10, 2018 at 11:24 PM, Sebastian Gniazdowski <
sgniazdowski@gmail.com> wrote:

> Hello,
> I've just implemented async feature without using zpty. From what I
> saw zsh-autosuggestions uses zpty to look-up the suggestion. Maybe it
> has some drawbacks and you would be interested in using <( ) instead
> of zpty (it's probably still required to capture completions, though)?
> It's similar to using zpty:
>
> exec {PCFD}< <(-fast-highlight-check-path)
> zle -F -w "$PCFD" fast-highlight-check-path-handler
>
> -fast-highlight-check-path-handler() {
>     if read -r -u "$PCFD" line; then
>     ...
>     fi
>     zle -F ${PCFD}
>     exec {PCFD}<&-
> }
>
> <( ) process is automatically disowned, I've used it in 2 projects and
> it works without problems, very robust. The effect:
>
> https://asciinema.org/a/V18uHIn2BR0OVfRsmxyqkVi7K
>
> --
> Best regards,
> Sebastian Gniazdowski
>

Re: Anyone familiar with auto-fu.zsh project?

[Sebastian Gniazdowski]

On 11 June 2018 at 10:25, Eric Freese <ericdfreese@gmail.com> wrote:
> Wow this is much nicer. I've implemented on `develop` branch of
> zsh-autosuggestions.

Decided to do the testing, it's just checkout of develop branch and
then normal everyday use. First impression was that suggestions appear
very quickly, faster than with zpty.

> Thank you!

n/p, I use this in unpublished logger. Background process is started
on demand with <( ), which happens when someone logs something with
zflai-log. It stores to SQLite, MySQL, ElasticSearch, plain file. All
works without any problems, and logging into <( ) spawned process has
negligible duration, that's the point – someone wants MySQL logs but
do not want slowdown.

> Eric Freese
> 303 875 2359
>
> On Sun, Jun 10, 2018 at 11:24 PM, Sebastian Gniazdowski
> <sgniazdowski@gmail.com> wrote:
>>
>> Hello,
>> I've just implemented async feature without using zpty. From what I
>> saw zsh-autosuggestions uses zpty to look-up the suggestion. Maybe it
>> has some drawbacks and you would be interested in using <( ) instead
>> of zpty (it's probably still required to capture completions, though)?
>> It's similar to using zpty:
>>
>> exec {PCFD}< <(-fast-highlight-check-path)
>> zle -F -w "$PCFD" fast-highlight-check-path-handler
>>
>> -fast-highlight-check-path-handler() {
>>     if read -r -u "$PCFD" line; then
>>     ...
>>     fi
>>     zle -F ${PCFD}
>>     exec {PCFD}<&-
>> }
>>
>> <( ) process is automatically disowned, I've used it in 2 projects and
>> it works without problems, very robust. The effect:
>>
>> https://asciinema.org/a/V18uHIn2BR0OVfRsmxyqkVi7K
>>
>> --
>> Best regards,
>> Sebastian Gniazdowski
>
>

Re: Anyone familiar with auto-fu.zsh project?

[Eric Freese]

[-- Attachment #1: Type: text/plain, Size: 2249 bytes --]

Do you know if there is any way to get the PID of the process spawned for
process substitution? It looks like `$!` doesn't hold it as it does in bash.

Ideally I could kill these child processes when they're no longer needed so
that long-running ones don't tie up resources unnecessarily.

Eric Freese
303 875 2359

On Mon, Jun 11, 2018 at 3:46 AM, Sebastian Gniazdowski <
sgniazdowski@gmail.com> wrote:

> On 11 June 2018 at 10:25, Eric Freese <ericdfreese@gmail.com> wrote:
> > Wow this is much nicer. I've implemented on `develop` branch of
> > zsh-autosuggestions.
>
> Decided to do the testing, it's just checkout of develop branch and
> then normal everyday use. First impression was that suggestions appear
> very quickly, faster than with zpty.
>
> > Thank you!
>
> n/p, I use this in unpublished logger. Background process is started
> on demand with <( ), which happens when someone logs something with
> zflai-log. It stores to SQLite, MySQL, ElasticSearch, plain file. All
> works without any problems, and logging into <( ) spawned process has
> negligible duration, that's the point – someone wants MySQL logs but
> do not want slowdown.
>
> > Eric Freese
> > 303 875 2359
> >
> > On Sun, Jun 10, 2018 at 11:24 PM, Sebastian Gniazdowski
> > <sgniazdowski@gmail.com> wrote:
> >>
> >> Hello,
> >> I've just implemented async feature without using zpty. From what I
> >> saw zsh-autosuggestions uses zpty to look-up the suggestion. Maybe it
> >> has some drawbacks and you would be interested in using <( ) instead
> >> of zpty (it's probably still required to capture completions, though)?
> >> It's similar to using zpty:
> >>
> >> exec {PCFD}< <(-fast-highlight-check-path)
> >> zle -F -w "$PCFD" fast-highlight-check-path-handler
> >>
> >> -fast-highlight-check-path-handler() {
> >>     if read -r -u "$PCFD" line; then
> >>     ...
> >>     fi
> >>     zle -F ${PCFD}
> >>     exec {PCFD}<&-
> >> }
> >>
> >> <( ) process is automatically disowned, I've used it in 2 projects and
> >> it works without problems, very robust. The effect:
> >>
> >> https://asciinema.org/a/V18uHIn2BR0OVfRsmxyqkVi7K
> >>
> >> --
> >> Best regards,
> >> Sebastian Gniazdowski
> >
> >
>

Re: Anyone familiar with auto-fu.zsh project?

[Sebastian Gniazdowski]

On 12 June 2018 at 03:55, Eric Freese <ericdfreese@gmail.com> wrote:
> Do you know if there is any way to get the PID of the process spawned for
> process substitution? It looks like `$!` doesn't hold it as it does in bash.
>
> Ideally I could kill these child processes when they're no longer needed so
> that long-running ones don't tie up resources unnecessarily.

I recall very weakly that this appeared for a moment when writing the
logger – that <( ) process likes to survive much. I think main method
is that the spawned function exits. But you seem to want both short
running processes that exit by themselves and long running processes,
that do not exit. My logger exits after configurable amount of
seconds, like 20 of not receiving new logs (I have opposite pipe
direction) or when not log but special exit-string is written to the
named pipe. Found the code:

# Cannot write newline (newline alone is ignored, not logged)? Then cleanup
(( $ZFLAI_FD )) && { builtin print -r -u$ZFLAI_FD 2>&$ZFLAI_NULL_FD ||
{ builtin exec {ZFLAI_FD}>&-; ZFLAI_FD=0; }; }

# Running, but dangerously close to idle-exit moment?
if (( ZFLAI_FD != 0 && ZFLAI_LAST_ACTION + ZFLAI_KEEP_ALIVE - 10 <
EPOCHSECONDS )); then
    builtin print -u$ZFLAI_FD '!ZFLAI-SPECIAL-CMD: exit' 2>/dev/null
    builtin exec {ZFLAI_FD}>&-
    ZFLAI_FD=0
fi

I had to do that protected race condition and request exit when close
to idle exit – this way it is certain that the following, actual
message will not be written during the short window between checking
that <( ) process is alive, and the process being in state of exiting
during that check.

Maybe this will suggest something. I'm busy and cannot switch to other
project right now, I probably will have time tomorrow, so I can fiddle
with this and maybe find something for opposite pipe direction. Maybe
someone knows a trick to open bidirectional named pipe(s) for <( )?
Exec can do {FD}<> <(...), can't remember if I checked this, but
rather yes, checked now and it seems to not work.

Maybe this: long-running process outputs message "EXIT?" every 5
seconds. When write to stdout fails, then exit. But named pipes are
quite distinct, not sure if the write will fail after doing exec
{FD}<&- done on the client, interactive side.

> On Mon, Jun 11, 2018 at 3:46 AM, Sebastian Gniazdowski
> <sgniazdowski@gmail.com> wrote:
>>
>> On 11 June 2018 at 10:25, Eric Freese <ericdfreese@gmail.com> wrote:
>> > Wow this is much nicer. I've implemented on `develop` branch of
>> > zsh-autosuggestions.
>>
>> Decided to do the testing, it's just checkout of develop branch and
>> then normal everyday use. First impression was that suggestions appear
>> very quickly, faster than with zpty.
>>
>> > Thank you!
>>
>> n/p, I use this in unpublished logger. Background process is started
>> on demand with <( ), which happens when someone logs something with
>> zflai-log. It stores to SQLite, MySQL, ElasticSearch, plain file. All
>> works without any problems, and logging into <( ) spawned process has
>> negligible duration, that's the point – someone wants MySQL logs but
>> do not want slowdown.
>>
>> > Eric Freese
>> > 303 875 2359
>> >
>> > On Sun, Jun 10, 2018 at 11:24 PM, Sebastian Gniazdowski
>> > <sgniazdowski@gmail.com> wrote:
>> >>
>> >> Hello,
>> >> I've just implemented async feature without using zpty. From what I
>> >> saw zsh-autosuggestions uses zpty to look-up the suggestion. Maybe it
>> >> has some drawbacks and you would be interested in using <( ) instead
>> >> of zpty (it's probably still required to capture completions, though)?
>> >> It's similar to using zpty:
>> >>
>> >> exec {PCFD}< <(-fast-highlight-check-path)
>> >> zle -F -w "$PCFD" fast-highlight-check-path-handler
>> >>
>> >> -fast-highlight-check-path-handler() {
>> >>     if read -r -u "$PCFD" line; then
>> >>     ...
>> >>     fi
>> >>     zle -F ${PCFD}
>> >>     exec {PCFD}<&-
>> >> }
>> >>
>> >> <( ) process is automatically disowned, I've used it in 2 projects and
>> >> it works without problems, very robust. The effect:
>> >>
>> >> https://asciinema.org/a/V18uHIn2BR0OVfRsmxyqkVi7K
>> >>
>> >> --
>> >> Best regards,
>> >> Sebastian Gniazdowski
>> >
>> >
>
>

Re: Anyone familiar with auto-fu.zsh project?

[Peter Stephenson]

On Mon, 11 Jun 2018 19:55:32 -0600
Eric Freese <ericdfreese@gmail.com> wrote:
> Do you know if there is any way to get the PID of the process spawned
> for process substitution? It looks like `$!` doesn't hold it as it
> does in bash.

Hmm, this is obviously useful but I'd be loath simply to make $! do this
as the fact there's an asynchronous process involved is a bit hidden and
the mechanism is rather different from creating a background job, so
that could be confusing.

We could add it to the $sysparams hash provided by the zsh/system
module?  This already contains some PID information.  (It's
not strictly a system parameter but I don't think anyone's
going to hold a gun to my head and tell me this hash can only
return the result of immediate system calls.)

pws

diff --git a/Doc/Zsh/mod_system.yo b/Doc/Zsh/mod_system.yo
index 7f2009b..a27bab4 100644
--- a/Doc/Zsh/mod_system.yo
+++ b/Doc/Zsh/mod_system.yo
@@ -255,6 +255,11 @@ Returns the process ID of the parent of the current process, even in
 subshells.  Compare tt($PPID), which returns the process ID of the parent
 of the main shell process.
 )
+item(tt(procsubstpid))(
+Returns the process ID of the last process started for process
+substitution, i.e. the tt(<LPAR())var(...)tt(RPAR()) and
+tt(>LPAR())var(...)tt(RPAR()) expansions.
+)
 enditem()
 )
 enditem()
diff --git a/Src/Modules/system.c b/Src/Modules/system.c
index 9fd4d25..7a4f4ee 100644
--- a/Src/Modules/system.c
+++ b/Src/Modules/system.c
@@ -772,6 +772,8 @@ fillpmsysparams(Param pm, const char *name)
 	num = (int)getpid();
     } else if (!strcmp(name, "ppid")) {
 	num = (int)getppid();
+    } else if (!strcmp(name, "procsubstpid")) {
+	num = (int)procsubstpid;
     } else {
 	pm->u.str = dupstring("");
 	pm->node.flags |= PM_UNSET;
@@ -805,6 +807,8 @@ scanpmsysparams(UNUSED(HashTable ht), ScanFunc func, int flags)
     func(&spm.node, flags);
     fillpmsysparams(&spm, "ppid");
     func(&spm.node, flags);
+    fillpmsysparams(&spm, "procsubstpid");
+    func(&spm.node, flags);
 }
 
 static struct mathfunc mftab[] = {
diff --git a/Src/exec.c b/Src/exec.c
index 963b0a5..d445278 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -174,6 +174,11 @@ mod_export int zleactive;
 /**/
 pid_t cmdoutpid;
 
+/* pid of last process started by <(...),  >(...) */
+
+/**/
+mod_export pid_t procsubstpid;
+
 /* exit status of process undergoing 'process substitution' */
 
 /**/
@@ -4850,6 +4855,7 @@ getproc(char *cmd, char **eptr)
 	    return NULL;
 	if (!out)
 	    addproc(pid, NULL, 1, &bgtime);
+	procsubstpid = pid;
 	return pnam;
     }
     closem(FDT_UNUSED, 0);
@@ -4887,6 +4893,7 @@ getproc(char *cmd, char **eptr)
 	{
 	    addproc(pid, NULL, 1, &bgtime);
 	}
+	procsubstpid = pid;
 	return pnam;
     }
     entersubsh(ESUB_ASYNC|ESUB_PGRP);
@@ -4937,6 +4944,7 @@ getpipe(char *cmd, int nullexec)
 	}
 	if (!nullexec)
 	    addproc(pid, NULL, 1, &bgtime);
+	procsubstpid = pid;
 	return pipes[!out];
     }
     entersubsh(ESUB_PGRP);
@@ -6172,6 +6180,7 @@ execsave(void)
     es->cmdoutpid = cmdoutpid;
     es->cmdoutval = cmdoutval;
     es->use_cmdoutval = use_cmdoutval;
+    es->procsubstpid = procsubstpid;
     es->trap_return = trap_return;
     es->trap_state = trap_state;
     es->trapisfunc = trapisfunc;
@@ -6207,6 +6216,7 @@ execrestore(void)
     cmdoutpid = en->cmdoutpid;
     cmdoutval = en->cmdoutval;
     use_cmdoutval = en->use_cmdoutval;
+    procsubstpid = en->procsubstpid;
     trap_return = en->trap_return;
     trap_state = en->trap_state;
     trapisfunc = en->trapisfunc;
diff --git a/Src/zsh.h b/Src/zsh.h
index 8535d48..8e7f20b 100644
--- a/Src/zsh.h
+++ b/Src/zsh.h
@@ -1095,6 +1095,7 @@ struct execstack {
     pid_t cmdoutpid;
     int cmdoutval;
     int use_cmdoutval;
+    pid_t procsubstpid;
     int trap_return;
     int trap_state;
     int trapisfunc;

Re: Anyone familiar with auto-fu.zsh project?

[Eric Freese]

[-- Attachment #1: Type: text/plain, Size: 5490 bytes --]

> We could add it to the $sysparams hash provided by the zsh/system
module?

It just occurred to me that, with zsh/system, I can have the child process
send its pid as the first line of output.

Something like:

```
% zmodload zsh/system
% exec {FOO}< <(echo $sysparams[pid]; sleep 100; echo foo bar)
% read childpid <&$FOO # Get the pid, stored in $childpid
% cat <&$FOO # Handle the rest of the output
```

So it may not actually be necessary to add procsubstpid.

In fact, the approach above may be preferred if you need to get pids for
multiple process substitutions in one command (which I think is possible?).

Next question:

Is it possible to get the current subshell's pid without having to load the
zsh/system module ($sysparams param)? Bash seems to have the $BASHPID
variable. Is there anything like that in zsh core?

Or, alternatively, is it reasonable to assume that everyone will be able to
load the zsh/system module? Background here is that I had a user send a
pull request to zsh-autosuggestions requesting we don't depend on zsh/zpty
module since some people may not have it installed, so I'm trying to
minimize dependencies on non-core modules.

Eric Freese
303 875 2359

On Tue, Jun 12, 2018 at 5:32 AM, Peter Stephenson <p.stephenson@samsung.com>
wrote:

> On Mon, 11 Jun 2018 19:55:32 -0600
> Eric Freese <ericdfreese@gmail.com> wrote:
> > Do you know if there is any way to get the PID of the process spawned
> > for process substitution? It looks like `$!` doesn't hold it as it
> > does in bash.
>
> Hmm, this is obviously useful but I'd be loath simply to make $! do this
> as the fact there's an asynchronous process involved is a bit hidden and
> the mechanism is rather different from creating a background job, so
> that could be confusing.
>
> We could add it to the $sysparams hash provided by the zsh/system
> module?  This already contains some PID information.  (It's
> not strictly a system parameter but I don't think anyone's
> going to hold a gun to my head and tell me this hash can only
> return the result of immediate system calls.)
>
> pws
>
> diff --git a/Doc/Zsh/mod_system.yo b/Doc/Zsh/mod_system.yo
> index 7f2009b..a27bab4 100644
> --- a/Doc/Zsh/mod_system.yo
> +++ b/Doc/Zsh/mod_system.yo
> @@ -255,6 +255,11 @@ Returns the process ID of the parent of the current
> process, even in
>  subshells.  Compare tt($PPID), which returns the process ID of the parent
>  of the main shell process.
>  )
> +item(tt(procsubstpid))(
> +Returns the process ID of the last process started for process
> +substitution, i.e. the tt(<LPAR())var(...)tt(RPAR()) and
> +tt(>LPAR())var(...)tt(RPAR()) expansions.
> +)
>  enditem()
>  )
>  enditem()
> diff --git a/Src/Modules/system.c b/Src/Modules/system.c
> index 9fd4d25..7a4f4ee 100644
> --- a/Src/Modules/system.c
> +++ b/Src/Modules/system.c
> @@ -772,6 +772,8 @@ fillpmsysparams(Param pm, const char *name)
>         num = (int)getpid();
>      } else if (!strcmp(name, "ppid")) {
>         num = (int)getppid();
> +    } else if (!strcmp(name, "procsubstpid")) {
> +       num = (int)procsubstpid;
>      } else {
>         pm->u.str = dupstring("");
>         pm->node.flags |= PM_UNSET;
> @@ -805,6 +807,8 @@ scanpmsysparams(UNUSED(HashTable ht), ScanFunc func,
> int flags)
>      func(&spm.node, flags);
>      fillpmsysparams(&spm, "ppid");
>      func(&spm.node, flags);
> +    fillpmsysparams(&spm, "procsubstpid");
> +    func(&spm.node, flags);
>  }
>
>  static struct mathfunc mftab[] = {
> diff --git a/Src/exec.c b/Src/exec.c
> index 963b0a5..d445278 100644
> --- a/Src/exec.c
> +++ b/Src/exec.c
> @@ -174,6 +174,11 @@ mod_export int zleactive;
>  /**/
>  pid_t cmdoutpid;
>
> +/* pid of last process started by <(...),  >(...) */
> +
> +/**/
> +mod_export pid_t procsubstpid;
> +
>  /* exit status of process undergoing 'process substitution' */
>
>  /**/
> @@ -4850,6 +4855,7 @@ getproc(char *cmd, char **eptr)
>             return NULL;
>         if (!out)
>             addproc(pid, NULL, 1, &bgtime);
> +       procsubstpid = pid;
>         return pnam;
>      }
>      closem(FDT_UNUSED, 0);
> @@ -4887,6 +4893,7 @@ getproc(char *cmd, char **eptr)
>         {
>             addproc(pid, NULL, 1, &bgtime);
>         }
> +       procsubstpid = pid;
>         return pnam;
>      }
>      entersubsh(ESUB_ASYNC|ESUB_PGRP);
> @@ -4937,6 +4944,7 @@ getpipe(char *cmd, int nullexec)
>         }
>         if (!nullexec)
>             addproc(pid, NULL, 1, &bgtime);
> +       procsubstpid = pid;
>         return pipes[!out];
>      }
>      entersubsh(ESUB_PGRP);
> @@ -6172,6 +6180,7 @@ execsave(void)
>      es->cmdoutpid = cmdoutpid;
>      es->cmdoutval = cmdoutval;
>      es->use_cmdoutval = use_cmdoutval;
> +    es->procsubstpid = procsubstpid;
>      es->trap_return = trap_return;
>      es->trap_state = trap_state;
>      es->trapisfunc = trapisfunc;
> @@ -6207,6 +6216,7 @@ execrestore(void)
>      cmdoutpid = en->cmdoutpid;
>      cmdoutval = en->cmdoutval;
>      use_cmdoutval = en->use_cmdoutval;
> +    procsubstpid = en->procsubstpid;
>      trap_return = en->trap_return;
>      trap_state = en->trap_state;
>      trapisfunc = en->trapisfunc;
> diff --git a/Src/zsh.h b/Src/zsh.h
> index 8535d48..8e7f20b 100644
> --- a/Src/zsh.h
> +++ b/Src/zsh.h
> @@ -1095,6 +1095,7 @@ struct execstack {
>      pid_t cmdoutpid;
>      int cmdoutval;
>      int use_cmdoutval;
> +    pid_t procsubstpid;
>      int trap_return;
>      int trap_state;
>      int trapisfunc;
>
>

Re: Anyone familiar with auto-fu.zsh project?

[dana]

On 12 Jun 2018, at 23:09, Eric Freese <ericdfreese@gmail.com> wrote:
>Is it possible to get the current subshell's pid without having to load the
>zsh/system module ($sysparams param)? Bash seems to have the $BASHPID
>variable. Is there anything like that in zsh core?

I asked about that as well once and sysparams was the only suggestion i got.

On 12 Jun 2018, at 23:09, Eric Freese <ericdfreese@gmail.com> wrote:
>Or, alternatively, is it reasonable to assume that everyone will be able to
>load the zsh/system module? Background here is that I had a user send a
>pull request to zsh-autosuggestions requesting we don't depend on zsh/zpty
>module since some people may not have it installed, so I'm trying to
>minimize dependencies on non-core modules.

I'm pretty sure that was me. And no, you can't assume that users will have
zsh/system. Which modules are available to zsh is up to the packager, but these
are the ones that are linked by default with --disable-dynamic:

zsh/compctl
zsh/complete
zsh/complist
zsh/computil
zsh/datetime
zsh/main
zsh/parameter
zsh/rlimits
zsh/sched
zsh/termcap
zsh/zle
zsh/zleparameter
zsh/zutil

So i think those are essentially the 'core' modules. You can probably include
zsh/langinfo and zsh/terminfo in most cases too. Those are the ones i had on the
system that inspired that PR, anyway.

dana

Re: Anyone familiar with auto-fu.zsh project?

[Sebastian Gniazdowski]

On 13 June 2018 at 06:09, Eric Freese <ericdfreese@gmail.com> wrote:
> It just occurred to me that, with zsh/system, I can have the child process
> send its pid as the first line of output.
>
> Something like:
>
> ```
> % zmodload zsh/system
> % exec {FOO}< <(echo $sysparams[pid]; sleep 100; echo foo bar)
> % read childpid <&$FOO # Get the pid, stored in $childpid
> % cat <&$FOO # Handle the rest of the output
> ```

Cool. <() processes are fun, such tricks make a day. I wonder if
someone has some <( ) tricks up in sleeve, broadening of horizons
might result in better code or even architecture.

-- 
Best regards,
Sebastian Gniazdowski

Re: Anyone familiar with auto-fu.zsh project?

[Sebastian Gniazdowski]

On 13 June 2018 at 09:26, dana <dana@dana.is> wrote:
> zsh/compctl
> zsh/complete
> zsh/complist
> zsh/computil
> zsh/datetime
> zsh/main
> zsh/parameter
> zsh/rlimits
> zsh/sched
> zsh/termcap
> zsh/zle
> zsh/zleparameter
> zsh/zutil
>
> So i think those are essentially the 'core' modules. You can probably include
> zsh/langinfo and zsh/terminfo in most cases too. Those are the ones i had on the
> system that inspired that PR, anyway.

Good that zsh/parameters are in that list. I wonder, could one
construct 2-lines or so binary, that when invoked returns ppid e.g.
through stdout. So the <( ) background process wouldn't even need to
do some output capturing, output would go to <( ) pipe as expected. I
compile help binaries from years, e.g. in zdharma/zconvey process,
there's little stripped util-linux/flock, that compiles even on OS X
and FreeBSD.

-- 
Best regards,
Sebastian Gniazdowski

Re: Anyone familiar with auto-fu.zsh project?

[Sebastian Gniazdowski]

dana did some tests on this:

#include <stdio.h>
#include <unistd.h>
int main() {
  pid_t ppid = getppid();
  printf("%d\n", ppid);
  return 0;
}

Effects:
~ exec {FD2}< <( ./gettpid; : ); cat <&$FD2; echo $$
37343
43163

~ exec {FD2}< <( ./gettpid ); cat <&$FD2; echo $$
43163
43163

Wonder why ":" is needed, to gettpid be not the last command.

-- 
Best regards,
Sebastian Gniazdowski

Re: Anyone familiar with auto-fu.zsh project?

[dana]

On 13 Jun 2018, at 03:28, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
>Wonder why ":" is needed, to gettpid be not the last command.

Presumably because zsh optimises out the fork() for the last command.

Anyway i don't actually think you should use that, lol. If you really don't have
zsh/system you should be able to use ${${:-/proc/self}:A:t} on Linux (and NetBSD
and Solaris). I bet that covers 99% of users — i doubt many people are using
static zsh on Macs for example.

dana

Re: Anyone familiar with auto-fu.zsh project?

[Sebastian Gniazdowski]

On 13 June 2018 at 11:17, dana <dana@dana.is> wrote:
> On 13 Jun 2018, at 03:28, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
>>Wonder why ":" is needed, to gettpid be not the last command.
>
> Presumably because zsh optimises out the fork() for the last command.

But how to run a binary without forking first? I would have to be
`exec getppid`.

> Anyway i don't actually think you should use that, lol. If you really don't have
> zsh/system you should be able to use ${${:-/proc/self}:A:t} on Linux (and NetBSD
> and Solaris). I bet that covers 99% of users — i doubt many people are using
> static zsh on Macs for example.

Procfs is nice but lives in a word of cats, echos, ls -l – I mean,
it's a world of text, files and symlinks. IMO it is good to allow
users cat etc. it from interactive command line, but for short
programs, it's like taking away coherency from them, they have to open
a channel for this file tree, I feel this is unstable.

-- 
Best regards,
Sebastian Gniazdowski

Re: Anyone familiar with auto-fu.zsh project?

[dana]

On 13 Jun 2018, at 05:48, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
>But how to run a binary without forking first? I would have to be
>`exec getppid`.

As far as i understand it:

  % echo $$; ( ./getppid 1; ./getppid 2 )
  29746 30173 29746

echo $$     -> main shell
(           -> fork() to sub-shell; new PID, so the PPID is the main shell
./getppid 1 -> fork() and exec(); new PID, so the PPID is the sub-shell
./getppid 2 -> sub-shell is about to finish, so fork()ing again is unnecessary;
               exec() directly instead. getppid assumes the PID of the
               sub-shell, so the PPID remains the main shell

On 13 Jun 2018, at 05:48, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
>Procfs is nice but lives in a word of cats, echos, ls -l – I mean,
>it's a world of text, files and symlinks. IMO it is good to allow
>users cat etc. it from interactive command line, but for short
>programs, it's like taking away coherency from them, they have to open
>a channel for this file tree, I feel this is unstable.

They wouldn't have to do anything, the script would do it for them. In any case,
if procfs is good enough to implement ps, pgrep, top, &c., on Linux and Solaris,
i bet it's probably good enough for this

dana

Re: Anyone familiar with auto-fu.zsh project?

[Peter Stephenson]

On Wed, 13 Jun 2018 04:17:07 -0500
dana <dana@dana.is> wrote:
> On 13 Jun 2018, at 03:28, Sebastian Gniazdowski
> <sgniazdowski@gmail.com> wrote:
> >Wonder why ":" is needed, to gettpid be not the last command.  
> 
> Presumably because zsh optimises out the fork() for the last command.
> 
> Anyway i don't actually think you should use that, lol. If you really
> don't have zsh/system you should be able to use
> ${${:-/proc/self}:A:t} on Linux (and NetBSD and Solaris). I bet that
> covers 99% of users — i doubt many people are using static zsh on
> Macs for example.

If you can really find a zsh distribution on a desktop system that
has /proc/self but doesn't bother packaging zsh/system, the drinks
are on me.

pws

Re: Anyone familiar with auto-fu.zsh project?

[dana]

On 14 Jun 2018, at 03:55, Peter Stephenson <p.stephenson@samsung.com> wrote:
>If you can really find a zsh distribution on a desktop system that
>has /proc/self but doesn't bother packaging zsh/system, the drinks
>are on me.

The one i was using was the Entware package (which tracks OpenWRT) for ARM-based
Linux routers and NAS devices. And even that one was changed recently — when
they updated to 5.4.x a few months ago they finally switched to dynamic linking
with all of the usual modules.

But the zsh-static package for Debian and Ubuntu doesn't seem to have zsh/system
either. I think that technically meets your criteria, even though pretty much
nobody ever uses it (https://qa.debian.org/popcon.php?package=zsh)...

dana

Re: Anyone familiar with auto-fu.zsh project?

[Peter Stephenson]

On Thu, 14 Jun 2018 04:48:51 -0500
dana <dana@dana.is> wrote:
> On 14 Jun 2018, at 03:55, Peter Stephenson <p.stephenson@samsung.com>
> wrote:
> But the zsh-static package for Debian and Ubuntu doesn't seem to have
> zsh/system either. I think that technically meets your criteria, even
> though pretty much nobody ever uses it
> (https://qa.debian.org/popcon.php?package=zsh)...

I hadn't realised static linking was still around on systems where
it's not obviously needed, but it kind of makes sense for certain cases
like early system boot or some other stripped down system, I suppose.

There's an argument for adding zsh/system to the default list of
statically linked modules.  It's not big.

pws