Suppress print_exit_value for single function

Suppress print_exit_value for single function

[Sebastian Gniazdowski]

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

Hello,
in a 1-second sched function, I do:

__ret=$?
...
return $__ret

This solves $? malforming by background task. However, for `setopt
print_exit_value', this leads to constant "zsh: Exit 1" message, every
second.

Can I block `setopt print_exit_value' effects for this sched function or to
all sched functions in general? I think a feature could be added for this,
it looks very reasonable and useful.

-- 
Best regards,
Sebastian Gniazdowski

Re: Suppress print_exit_value for single function

[Bart Schaefer]

On Apr 29,  8:42pm, Sebastian Gniazdowski wrote:
}
} Can I block `setopt print_exit_value' effects for this sched function or to
} all sched functions in general?

You can always

  setopt localoptions no_print_exit_value

Re: Suppress print_exit_value for single function

[Sebastian Gniazdowski]

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

On 29 April 2018 at 21:02, Bart Schaefer <schaefer@brasslantern.com> wrote:

> On Apr 29,  8:42pm, Sebastian Gniazdowski wrote:
> }
> } Can I block `setopt print_exit_value' effects for this sched function or
> to
> } all sched functions in general?
>
> You can always
>
>   setopt localoptions no_print_exit_value
>

I still see the messages with this line added before return

-- 
Best regards,
Sebastian Gniazdowski

Re: Suppress print_exit_value for single function

[Sebastian Gniazdowski]

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

PS. A test code:

fun() { sched +1 "fun"; setopt localoptions no_print_exit_value; return 1; }
setopt printexitvalue; fun


On 30 April 2018 at 04:21, Sebastian Gniazdowski <sgniazdowski@gmail.com>
wrote:

> On 29 April 2018 at 21:02, Bart Schaefer <schaefer@brasslantern.com>
> wrote:
>
>> On Apr 29,  8:42pm, Sebastian Gniazdowski wrote:
>> }
>> } Can I block `setopt print_exit_value' effects for this sched function
>> or to
>> } all sched functions in general?
>>
>> You can always
>>
>>   setopt localoptions no_print_exit_value
>>
>
> I still see the messages with this line added before return
>
> --
> Best regards,
> Sebastian Gniazdowski
>

Re: Suppress print_exit_value for single function

[Sebastian Gniazdowski]

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

On 29 April 2018 at 21:02, Bart Schaefer <schaefer@brasslantern.com> wrote:

> On Apr 29,  8:42pm, Sebastian Gniazdowski wrote:
> }
> } Can I block `setopt print_exit_value' effects for this sched function or
> to
> } all sched functions in general?
>
> You can always
>
>   setopt localoptions no_print_exit_value
>

Can it be true that the C array of structures, `funcstack':

typedef struct funcstack *Funcstack;

will have something distinct for function ran from sched? The
print_exit_value code would be then able to easily check for this distinct
trait. I think all this is worth doing, not for aesthetics aspect, but to
allow background functions to maintain $? unchanged (and e.g. repeat
erroneous exit code). It is a poor situation currently, e.g. syntax
highlighting runs after key press and $? is lost, it cannot be directly
used at command line. Lets do something to address this, at least for sched.

-- 
Best regards,
Sebastian Gniazdowski

Re: Suppress print_exit_value for single function

[Daniel Shahaf]

Sebastian Gniazdowski wrote on Sun, Apr 29, 2018 at 20:42:43 +0200:
> Hello,
> in a 1-second sched function, I do:
> 

Thanks for including the example code downthread.

> __ret=$?
> ...
> return $__ret
> 
> This solves $? malforming by background task. However, for `setopt
> print_exit_value', this leads to constant "zsh: Exit 1" message, every
> second.
> 

I'm not sure that this is a problem.  The user opted in to being notified of
errors; there was an error; it was notified of.  If anything, isn't the bug
here that the diagnostic, "zsh: exit 1", neglects to specify the name of the
function that returned that value?

> Can I block `setopt print_exit_value' effects for this sched function or to
> all sched functions in general? I think a feature could be added for this,
> it looks very reasonable and useful.

The answer ought to be "If you don't want sched functions to result in stderr
spam, have your sched functions return zero.", except it sounds like doing that
will override the $? variable of the main shell, creating a race condition:

% echo start && make && echo end
[at 12:00] start
[go have some coffee]
[at 12:03] a 'sched' function returns non-zero
[at 12:05] 'make' finishes successfully, but "end" doesn't get printed

(Right?  I haven't tested this, I'm just going by your description)

So, isn't the answer to that to teach the C code not to write the return value
of a sched function to the global value of $? — but to keep printing
printexitvalue warnings for sched functions?

Cheers,

Daniel

Re: Suppress print_exit_value for single function

[Sebastian Gniazdowski]

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

On 5 May 2018 at 17:10, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:

> (Right?  I haven't tested this, I'm just going by your description)
>

It has a basic practical meaning: feature of various prompts to show a
skull or some red or other indicator of last command ending with error
stops working when sched function always returns 0.

So, isn't the answer to that to teach the C code not to write the return
> value
> of a sched function to the global value of $? — but to keep printing
> printexitvalue warnings for sched functions?
>

I wrote 2 plugins that resulted in user reporting this problem
(printexitvalue spam). The aim at "user might want reports from background
tasks" is problematic when it's noticed that background tasks malform
foreground $? value. It is possible to suppress this malforming (local
ret=$? at sched function start, return $ret at the end), but then it's not
sched's function own return code, it's repeated foreground $? code, so it
shouldn't be reported. I think proper resolution of this is treating $?
value as sacred. We already are steps back from this status of $? as
various plugins run background code and just return 0. Teaching functions
to not write to $? at C level seems to be very rebellious.

Best regards,
Sebastian Gniazdowski