PRINT_EXIT_VALUE problems

PRINT_EXIT_VALUE problems

[Vincent Lefevre]

Hi,

This is not new, but there are two problems with the PRINT_EXIT_VALUE
option. They can be shown on the following example (under Debian):

$ zsh-beta -f
xvii% echo $ZSH_VERSION
4.3.15-dev-0-cvs1220
xvii% setopt PRINT_EXIT_VALUE
xvii% false || true
zsh: exit 1
xvii%

1. I don't think the value should be printed in the case of a program
before ||, because the goal of || is to ignore or handle the error.
This output is annoying in the case:

  for i in *; do grep -q ... || echo $i

If the exit status can be useful in some cases, maybe this could be
controlled by an option.

2. Here zsh doesn't say which program failed. I suppose that the
problem is due to the fact that "false" is a builtin.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: PRINT_EXIT_VALUE problems

[Bart Schaefer]

[I suggest further discussion go to zsh-workers rather than -users.]

On Dec 24, 12:13pm, Vincent Lefevre wrote:
}
} xvii% setopt PRINT_EXIT_VALUE
} xvii% false || true
} zsh: exit 1
} 
} 1. I don't think the value should be printed in the case of a program
} before ||, because the goal of || is to ignore or handle the error.

Hrm.  This is a bit problematic.  The call stack is something like
this (deepest frame at bottom):

	execode()
	execlist()	<- here we know the state of "&&"/"||"
	execpline()	<- here we print exit of external jobs [*]
	execpline2()
	execcmd()	<- here we print exit of builtins/functions

[*] which really happens via the SIGCHLD handler, but we wait there.

So in order to suppress printing on the left side of "||", execlist()
will need to record that state in a location that can be read both
from printjob() as called by the signal handler, and from execcmd();
or, we need to pull this out of both of those places and put it into
execlist().

} 2. Here zsh doesn't say which program failed. I suppose that the
} problem is due to the fact that "false" is a builtin.

This actually might be easier to fix, execcmd() should be able to get
the name of the function or builtin it was executing.

Re: PRINT_EXIT_VALUE problems

[Bart Schaefer]

[> zsh-workers]

On Dec 26, 11:40pm, Bart Schaefer wrote:
}
} } 1. I don't think the value should be printed in the case of a program
} } before ||, because the goal of || is to ignore or handle the error.
} 
} 	execode()
} 	execlist()	<- here we know the state of "&&"/"||"
} 	execpline()	<- here we print exit of external jobs [*]
} 	execpline2()
} 	execcmd()	<- here we print exit of builtins/functions

While we're on the subject:

torch% setopt printexitvalue
torch% () { false } || true
torch% 

Functions always begin with printexitvalue reset to off, so anonymous
functions have the side-effect of suppressing printing of their exit
value.  This doesn't affect non-anonymous functions:

torch% fail() { /bin/false }
torch% fail || true
zsh: exit 1
torch% 

Re: PRINT_EXIT_VALUE problems

[Nathan Dorfman]

On Sat, Dec 24, 2011 at 6:13 AM, Vincent Lefevre <vincent@vinc17.net> wrote:
> Hi,
>
> This is not new, but there are two problems with the PRINT_EXIT_VALUE
> option. They can be shown on the following example (under Debian):
>
> $ zsh-beta -f
> xvii% echo $ZSH_VERSION
> 4.3.15-dev-0-cvs1220
> xvii% setopt PRINT_EXIT_VALUE
> xvii% false || true
> zsh: exit 1
> xvii%

Unrelated to the apparent bug you've described, I've been using a
different mechanism to achieve the effect that (I think) you want. $?
does the right thing:

% false || true ; echo $?
0
% false && true ; echo $?
1

You can use the %? sequence in your prompt to see the exit value; what
I do is actually use the following:
%(?// %?? )

This expands to " 1? " after false && true, and the empty string ""
after false || true. I find this really handy as the prompt is
different enough to draw my attention after a non-zero exit status.

Hope this helps,
-nd.

Re: PRINT_EXIT_VALUE problems

[Vincent Lefevre]

On 2011-12-28 11:26:01 -0500, Nathan Dorfman wrote:
> Unrelated to the apparent bug you've described, I've been using a
> different mechanism to achieve the effect that (I think) you want. $?
> does the right thing:
> 
> % false || true ; echo $?
> 0
> % false && true ; echo $?
> 1
> 
> You can use the %? sequence in your prompt to see the exit value;

I already do this. But PRINT_EXIT_VALUE provides more information.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: PRINT_EXIT_VALUE problems

[Bart Schaefer]

Sorry for forgetting to redirect my own last reply to zsh-workers even
though I meant to.  I'm keeping this one on -users on purpose, because
it's no longer about code details.

On Dec 24, 12:13pm, Vincent Lefevre wrote:
}
} xvii% setopt PRINT_EXIT_VALUE
} xvii% false || true
} zsh: exit 1
} 
} 1. I don't think the value should be printed in the case of a program
} before ||, because the goal of || is to ignore or handle the error.

I've been thinking about this a bit more.

Consider the case of a pipeline -- here's a silly example:

torch% return 3 | return 2 | return 1 | true
zsh: exit 3     return 3 | 
zsh: exit 2     return 2 | 
zsh: exit 1     return 1
torch% 

Now consider:

torch% return 3 | return 2 | return 1 || true

If we followed your suggestion above, we should suppress printing the
exit values of every stage of the pipeline.  Is that really desirable?

What about

torch% { (return 3); (return 2); return 1 } || true

Which exit values should be printed there?

Re: PRINT_EXIT_VALUE problems

[Vincent Lefevre]

On 2011-12-28 11:28:35 -0800, Bart Schaefer wrote:
> I've been thinking about this a bit more.
> 
> Consider the case of a pipeline -- here's a silly example:
> 
> torch% return 3 | return 2 | return 1 | true
> zsh: exit 3     return 3 | 
> zsh: exit 2     return 2 | 
> zsh: exit 1     return 1
> torch% 
> 
> Now consider:
> 
> torch% return 3 | return 2 | return 1 || true
> 
> If we followed your suggestion above, we should suppress printing the
> exit values of every stage of the pipeline.

I don't think so, since the exit values of "return 3" and "return 2"
don't affect the exit value of the pipeline. The "|| ..." should
mean that one isn't interested in the exit value of the pipeline
and what caused this exit value (i.e. "return 1").

>  Is that really desirable?
> 
> What about
> 
> torch% { (return 3); (return 2); return 1 } || true
> 
> Which exit values should be printed there?

(return 3) and (return 2) do not affect the tested value for ||, thus
there exit values should be printed. The tested value for || is the
exit value of "return 1", thus this one should not be printed.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

autoload syntax

[Ray Andrews]

All,

Sorry for such an elementary question but I'm fishing around looking for 
sample .zshrc files to play with and I keep coming across several 
syntaxes for this sort of thing:

autoload -U compinit
compinit

or:

autoload -U compinit compinit

or:

autoload -U compinit ; compinit


Which of these is the most kosher?

I get the feeling I could root around in zsh for the next decade and 
still only have scratched the surface of what you can do with it!

Re: autoload syntax

[Bart Schaefer]

On Dec 30, 12:11pm, Ray Andrews wrote:
}
} autoload -U compinit
} compinit
} 
} or:
} 
} autoload -U compinit compinit
} 
} or:
} 
} autoload -U compinit ; compinit
} 
} Which of these is the most kosher?

The second one doesn't run compinit, just marks it for autoloading,
so you probably don't want that.  Where did you see this?

The other two are exactly equivalent, entirely up to your preference.

I use

autoload -U compinit &&
    compinit -d ${ZDOTDIR:-$HOME}/.zcompdump-$ZSH_VERSION \
        ${${${ZSH_VERSION%%<4->*}:+-D}:--C}

which maintains a separate compdump file for each version numbered
4 or higher but does not write one at all for any version less, and
skips the check for new functions if a dump file is already there.
This facilitates having an NFS'd home directory on hosts with various
builds of zsh, or testing a dev build on a host with a more stable
version as the default shell.

I suppose nowadays I could throw $ZSH_PATCHLEVEL in there somewhere.

} I get the feeling I could root around in zsh for the next decade and 
} still only have scratched the surface of what you can do with it!

True of a lot of programming languages ...

Re: autoload syntax

[Mark van Dijk]

> I get the feeling I could root around in zsh for the next decade
> and still only have scratched the surface of what you can do with
> it!
> 
> True of a lot of programming languages ...

...and what keeps them fun to learn, if i may add.

Re: autoload syntax

[Ray Andrews]

All,

I'm just working on my first C project in linux, it's a function for 
moving the mouse pointer to various memorized positions via keystrokes. 
Three questions:

Can I  link this program with zsh the same way I do with a zsh function 
so that it becomes part of the shell?

As it is now, the various memorized positions for the mouse pointer are 
stored in a file. Can I store them in a persistent array? As a 
stand-alone utility I can see that this might be difficult, which is why 
I'm hoping that  if the function becomes  part of the shell, an array 
could be persistent.

How would I make it work in the gui as well as in a terminal? I want to 
bind keys that will function regardless of which application is running. 
I suspect that this would be done in metacity (Gnome).

Thanks

Re: autoload syntax

[Peter Stephenson]

On Wed, 04 Jan 2012 09:35:07 -0800
Ray Andrews <rayandrews@eastlink.ca> wrote:
> I'm just working on my first C project in linux, it's a function for 
> moving the mouse pointer to various memorized positions via keystrokes. 
> Three questions:
> 
> Can I  link this program with zsh the same way I do with a zsh function 
> so that it becomes part of the shell?

You can add it as a module but I'm not sure it's going to help.

I suspect, in fact, you could probably write this as shell function.
Various similar but not identical things have been done with terminals
before.

> As it is now, the various memorized positions for the mouse pointer are 
> stored in a file. Can I store them in a persistent array? As a 
> stand-alone utility I can see that this might be difficult, which is why 
> I'm hoping that  if the function becomes  part of the shell, an array 
> could be persistent.

No, you still need to save it to a file.

> How would I make it work in the gui as well as in a terminal? I want to 
> bind keys that will function regardless of which application is running. 
> I suspect that this would be done in metacity (Gnome).

Certainly the shell can't help you here.  You'll need to investigate
what types of bindings are available in Gnome.  KDE has global bindings,
I seem to remember.  I don't use Gnome but I think metacity may be
officially on the way out...

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: autoload syntax

[Ray Andrews]

On 05/01/12 12:13 PM, Peter Stephenson wrote:

Hi Peter:
> On Wed, 04 Jan 2012 09:35:07 -0800
> Ray Andrews<rayandrews@eastlink.ca>  wrote:
>> I'm just working on my first C project in linux, it's a function for
>> moving the mouse pointer to various memorized positions via keystrokes.
>> Three questions:
>>
>> Can I  link this program with zsh the same way I do with a zsh function
>> so that it becomes part of the shell?
> You can add it as a module but I'm not sure it's going to help.
>
So I can link a C module the same as a shell function? Where
can I find out more about this?
> I suspect, in fact, you could probably write this as shell function.
> Various similar but not identical things have been done with terminals
> before.
>
I'm not surprised. I can't be the first guy who is bothered by
having to use the mouse to move between xterms.
>> As it is now, the various memorized positions for the mouse pointer are
>> stored in a file. Can I store them in a persistent array? As a
>> stand-alone utility I can see that this might be difficult, which is why
>> I'm hoping that  if the function becomes  part of the shell, an array
>> could be persistent.
> No, you still need to save it to a file.
>
... or I guess the environment should work.
>> How would I make it work in the gui as well as in a terminal? I want to
>> bind keys that will function regardless of which application is running.
>> I suspect that this would be done in metacity (Gnome).
> Certainly the shell can't help you here.  You'll need to investigate
> what types of bindings are available in Gnome.  KDE has global bindings,
> I seem to remember.  I don't use Gnome but I think metacity may be
> officially on the way out...
>
I've got it working quite well using metacity bindings, I can hotkey
between applications or xterms on either of my monitors, so I'm
happy enough.

Hey Peter, you never answered my email asking for more information
about zsh. I think I want to get involved.

Ray

Re: autoload syntax

[Peter Stephenson]

On Thu, 05 Jan 2012 12:32:15 -0800
Ray Andrews <rayandrews@eastlink.ca> wrote:
> Hi Peter:
> > On Wed, 04 Jan 2012 09:35:07 -0800
> > Ray Andrews<rayandrews@eastlink.ca>  wrote:
> >> I'm just working on my first C project in linux, it's a function for
> >> moving the mouse pointer to various memorized positions via keystrokes.
> >> Three questions:
> >>
> >> Can I  link this program with zsh the same way I do with a zsh function
> >> so that it becomes part of the shell?
> > You can add it as a module but I'm not sure it's going to help.
> >
> So I can link a C module the same as a shell function? Where
> can I find out more about this?

No, you can link a C module completely differently from like a shell
function...   See the section Modules in zsh-development-guide and the
code in Src/Modules.  The module will need to provide a standard shell interface,
i.e. builtin, parameter, math function or test.

> Hey Peter, you never answered my email asking for more information
> about zsh. I think I want to get involved.

I'm not sure what the questions are, but there are certainly things to
look at.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: autoload syntax

[Mikael Magnusson]

On 5 January 2012 21:32, Ray Andrews <rayandrews@eastlink.ca> wrote:
> On 05/01/12 12:13 PM, Peter Stephenson wrote:
>
> Hi Peter:
>
>> On Wed, 04 Jan 2012 09:35:07 -0800
>> Ray Andrews<rayandrews@eastlink.ca>  wrote:
>>>
>>> I'm just working on my first C project in linux, it's a function for
>>> moving the mouse pointer to various memorized positions via keystrokes.
>>> Three questions:
>>>
>>> Can I  link this program with zsh the same way I do with a zsh function
>>> so that it becomes part of the shell?
>>
>> You can add it as a module but I'm not sure it's going to help.
>>
> So I can link a C module the same as a shell function? Where
> can I find out more about this?
>
>> I suspect, in fact, you could probably write this as shell function.
>> Various similar but not identical things have been done with terminals
>> before.
>>
> I'm not surprised. I can't be the first guy who is bothered by
> having to use the mouse to move between xterms.

What do you mean with this? Obviously nobody uses their mouse to
switch between terminals.

-- 
Mikael Magnusson

Re: autoload syntax

[Mikael Magnusson]

On 5 January 2012 22:29, Ray Andrews <rayandrews@eastlink.ca> wrote:
> On 05/01/12 01:06 PM, Mikael Magnusson wrote:
>
> Mikael,
>
>> I'm not surprised. I can't be the first guy who is bothered by
>>>
>>> having to use the mouse to move between xterms.
>>
>> What do you mean with this? Obviously nobody uses their mouse to
>> switch between terminals.
>>
> Before now I had no other choice than the mouse to move between
> my two screens while X is running. Outside the GUI, I only have one screen
> and
> one tty working, so the issue never comes up. When running Gnome, I often
> have four
> open xterms, two on each monitor, and as far as I can tell there is no way
> to move
> focus from one screen to the other without moving the mouse pointer via the
> mouse itself. There is supposed to be a way to use the keypad arrows to move
> the
> pointer, but it crashes here.

Sounds like you should probably fix your windowing environment rather
than invent more or less crazy hacks. :)

-- 
Mikael Magnusson