* PRINT_EXIT_VALUE problems
@ 2011-12-24 11:13 Vincent Lefevre
2011-12-27 7:40 ` Bart Schaefer
2011-12-28 16:26 ` PRINT_EXIT_VALUE problems Nathan Dorfman
0 siblings, 2 replies; 16+ messages in thread
From: Vincent Lefevre @ 2011-12-24 11:13 UTC (permalink / raw)
To: zsh-users
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)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PRINT_EXIT_VALUE problems
2011-12-24 11:13 PRINT_EXIT_VALUE problems Vincent Lefevre
@ 2011-12-27 7:40 ` Bart Schaefer
2011-12-27 17:30 ` Bart Schaefer
2011-12-28 19:28 ` Bart Schaefer
2011-12-28 16:26 ` PRINT_EXIT_VALUE problems Nathan Dorfman
1 sibling, 2 replies; 16+ messages in thread
From: Bart Schaefer @ 2011-12-27 7:40 UTC (permalink / raw)
To: zsh-users
[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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PRINT_EXIT_VALUE problems
2011-12-27 7:40 ` Bart Schaefer
@ 2011-12-27 17:30 ` Bart Schaefer
2011-12-28 19:28 ` Bart Schaefer
1 sibling, 0 replies; 16+ messages in thread
From: Bart Schaefer @ 2011-12-27 17:30 UTC (permalink / raw)
To: zsh-users
[> 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%
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PRINT_EXIT_VALUE problems
2011-12-27 7:40 ` Bart Schaefer
2011-12-27 17:30 ` Bart Schaefer
@ 2011-12-28 19:28 ` Bart Schaefer
2011-12-29 2:36 ` Vincent Lefevre
2011-12-30 20:11 ` autoload syntax Ray Andrews
1 sibling, 2 replies; 16+ messages in thread
From: Bart Schaefer @ 2011-12-28 19:28 UTC (permalink / raw)
To: zsh-users
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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PRINT_EXIT_VALUE problems
2011-12-28 19:28 ` Bart Schaefer
@ 2011-12-29 2:36 ` Vincent Lefevre
2011-12-30 20:11 ` autoload syntax Ray Andrews
1 sibling, 0 replies; 16+ messages in thread
From: Vincent Lefevre @ 2011-12-29 2:36 UTC (permalink / raw)
To: zsh-users
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)
^ permalink raw reply [flat|nested] 16+ messages in thread
* autoload syntax
2011-12-28 19:28 ` Bart Schaefer
2011-12-29 2:36 ` Vincent Lefevre
@ 2011-12-30 20:11 ` Ray Andrews
2011-12-30 21:07 ` Bart Schaefer
1 sibling, 1 reply; 16+ messages in thread
From: Ray Andrews @ 2011-12-30 20:11 UTC (permalink / raw)
To: zsh-users
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!
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: autoload syntax
2011-12-30 20:11 ` autoload syntax Ray Andrews
@ 2011-12-30 21:07 ` Bart Schaefer
2011-12-31 3:32 ` Mark van Dijk
2012-01-04 17:35 ` Ray Andrews
0 siblings, 2 replies; 16+ messages in thread
From: Bart Schaefer @ 2011-12-30 21:07 UTC (permalink / raw)
To: zsh-users
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 ...
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: autoload syntax
2011-12-30 21:07 ` Bart Schaefer
@ 2011-12-31 3:32 ` Mark van Dijk
2012-01-04 17:35 ` Ray Andrews
1 sibling, 0 replies; 16+ messages in thread
From: Mark van Dijk @ 2011-12-31 3:32 UTC (permalink / raw)
To: zsh-users
> 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: autoload syntax
2011-12-30 21:07 ` Bart Schaefer
2011-12-31 3:32 ` Mark van Dijk
@ 2012-01-04 17:35 ` Ray Andrews
2012-01-05 20:13 ` Peter Stephenson
1 sibling, 1 reply; 16+ messages in thread
From: Ray Andrews @ 2012-01-04 17:35 UTC (permalink / raw)
To: zsh-users
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: autoload syntax
2012-01-04 17:35 ` Ray Andrews
@ 2012-01-05 20:13 ` Peter Stephenson
2012-01-05 20:32 ` Ray Andrews
0 siblings, 1 reply; 16+ messages in thread
From: Peter Stephenson @ 2012-01-05 20:13 UTC (permalink / raw)
To: zsh-users
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/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: autoload syntax
2012-01-05 20:13 ` Peter Stephenson
@ 2012-01-05 20:32 ` Ray Andrews
2012-01-05 21:01 ` Peter Stephenson
2012-01-05 21:06 ` Mikael Magnusson
0 siblings, 2 replies; 16+ messages in thread
From: Ray Andrews @ 2012-01-05 20:32 UTC (permalink / raw)
To: zsh-users
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: autoload syntax
2012-01-05 20:32 ` Ray Andrews
@ 2012-01-05 21:01 ` Peter Stephenson
2012-01-05 21:06 ` Mikael Magnusson
1 sibling, 0 replies; 16+ messages in thread
From: Peter Stephenson @ 2012-01-05 21:01 UTC (permalink / raw)
To: zsh-users
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/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: autoload syntax
2012-01-05 20:32 ` Ray Andrews
2012-01-05 21:01 ` Peter Stephenson
@ 2012-01-05 21:06 ` Mikael Magnusson
[not found] ` <4F06163D.9040800@eastlink.ca>
1 sibling, 1 reply; 16+ messages in thread
From: Mikael Magnusson @ 2012-01-05 21:06 UTC (permalink / raw)
To: Ray Andrews; +Cc: zsh-users
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PRINT_EXIT_VALUE problems
2011-12-24 11:13 PRINT_EXIT_VALUE problems Vincent Lefevre
2011-12-27 7:40 ` Bart Schaefer
@ 2011-12-28 16:26 ` Nathan Dorfman
2011-12-28 18:42 ` Vincent Lefevre
1 sibling, 1 reply; 16+ messages in thread
From: Nathan Dorfman @ 2011-12-28 16:26 UTC (permalink / raw)
To: zsh-users
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PRINT_EXIT_VALUE problems
2011-12-28 16:26 ` PRINT_EXIT_VALUE problems Nathan Dorfman
@ 2011-12-28 18:42 ` Vincent Lefevre
0 siblings, 0 replies; 16+ messages in thread
From: Vincent Lefevre @ 2011-12-28 18:42 UTC (permalink / raw)
To: zsh-users
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)
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2012-01-05 21:40 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-24 11:13 PRINT_EXIT_VALUE problems Vincent Lefevre
2011-12-27 7:40 ` Bart Schaefer
2011-12-27 17:30 ` Bart Schaefer
2011-12-28 19:28 ` Bart Schaefer
2011-12-29 2:36 ` Vincent Lefevre
2011-12-30 20:11 ` autoload syntax Ray Andrews
2011-12-30 21:07 ` Bart Schaefer
2011-12-31 3:32 ` Mark van Dijk
2012-01-04 17:35 ` Ray Andrews
2012-01-05 20:13 ` Peter Stephenson
2012-01-05 20:32 ` Ray Andrews
2012-01-05 21:01 ` Peter Stephenson
2012-01-05 21:06 ` Mikael Magnusson
[not found] ` <4F06163D.9040800@eastlink.ca>
2012-01-05 21:33 ` Mikael Magnusson
2011-12-28 16:26 ` PRINT_EXIT_VALUE problems Nathan Dorfman
2011-12-28 18:42 ` Vincent Lefevre
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).