Function code breaking out of if then ...fi

Function code breaking out of if then ...fi

[Michal Maruska]

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

Hello,
I wonder if the following behaviour is a bug, or
simply my wrong expectation:

This script, assuming the globbing fails, and I'm not using NULL_GLOB,
does not bother finishing the commands in the "then ....fi" block,
instead continues after "fi".


#! /usr/bin/zsh -feu

fn () {
    foreach sum (non-existing*) {echo $sum}
}

if true;
then
    fn
    exit 0
fi

echo tragedy
exit -1


---------------------------

I was advised (on IRC) to use

{ fn } always { TRY_BLOCK_ERROR=0 }


But I'd like to see the behaviour documented in
the chapters not about " {} always {} ".
Thank you

Re: Function code breaking out of if then ...fi

[Bart Schaefer]

On Nov 2, 10:09am, Michal Maruska wrote:
}
} I wonder if the following behaviour is a bug, or
} simply my wrong expectation:
} 
} This script, assuming the globbing fails, and I'm not using NULL_GLOB,
} does not bother finishing the commands in the "then ....fi" block,
} instead continues after "fi".

This doesn't really have anything to do with the function.  The same
thing happens with

if true;
then
    echo non-existing*
    exit 0
fi

What slightly surprises me is that a glob failure isn't considered an
error for purposes of ERR_EXIT (the -e option in your #! line).  I
would have expected the whole script to quit at that point, but I guess
glob errors are not treated as command failures because the command
never executes in the first place.

However, what *is* happening is that a glob failure in a complex command
acts in the manner of a "break" statement.  This is to prevent runaway
loops spewing the same globbing error ad infitinum; I remember that this
change was made a long while ago, but I don't recall exactly when, and
it appears it would take a major excavation to find it in the ChangeLog.

The trouble of course is that a "break" statement isn't supposed to have
any effect in the body of an "if", but although actually using "break"
in that context is not allowed, the same logic isn't applied when the
internal error-flag gets set by a glob failure, and zsh bails out of
the if-body the same way it would from a loop-body.

Whether this is a bug could be argued either way.  NOMATCH occupies a
sort of grey area between parser-detectable syntax error and run-time
command failure.

} I was advised (on IRC) to use
} 
} { fn } always { TRY_BLOCK_ERROR=0 }

This is a workaround, because it introduces a new complex command (the
braced expression to the left of "always") and gives you a hook for
clearing the error before it affects any surrounding complex command.  
But that would be the wrong place to document this behavior of NOMATCH.

Re: Function code breaking out of if then ...fi

[Han Pingtian]

On Fri, Nov 02, 2012 at 02:39:11PM -0700, Bart Schaefer wrote:
> On Nov 2, 10:09am, Michal Maruska wrote:
> }
> } I wonder if the following behaviour is a bug, or
> } simply my wrong expectation:
> } 
> } This script, assuming the globbing fails, and I'm not using NULL_GLOB,
> } does not bother finishing the commands in the "then ....fi" block,
> } instead continues after "fi".
> 
> This doesn't really have anything to do with the function.  The same
> thing happens with
> 
> if true;
> then
>     echo non-existing*
>     exit 0
> fi
> 
> What slightly surprises me is that a glob failure isn't considered an
> error for purposes of ERR_EXIT (the -e option in your #! line).  I
> would have expected the whole script to quit at that point, but I guess
> glob errors are not treated as command failures because the command
> never executes in the first place.
> 
On my latop, if use 'echo non-existing*' in the if command, the 
script will exit immediately, looks like the glob failure is 
considered an error of ERR_EXIT. And changing to

    { echo non-existing* } always { TRY_BLOCK_ERROR=0 }

doesn't help, it still exits immediately. In the contrast, using 'fn'
won't trigger ERR_EXIT.

Re: Function code breaking out of if then ...fi

[Han Pingtian]

On Mon, Nov 05, 2012 at 04:22:50PM +0800, Han Pingtian wrote:
> On my latop, if use 'echo non-existing*' in the if command, the 
> script will exit immediately, looks like the glob failure is 
> considered an error of ERR_EXIT. And changing to
> 
>     { echo non-existing* } always { TRY_BLOCK_ERROR=0 }
> 
> doesn't help, it still exits immediately. In the contrast, using 'fn'
> won't trigger ERR_EXIT.
But the failure of 'echo non-existing*' won't trigger a 'trap "..." ZERR' command
at the sametime, this isn't like a normal failing command will do ...

Re: Function code breaking out of if then ...fi

[Peter Stephenson]

n Fri, 02 Nov 2012 14:39:11 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:

> On Nov 2, 10:09am, Michal Maruska wrote:
> }
> } I wonder if the following behaviour is a bug, or
> } simply my wrong expectation:
> } 
> } This script, assuming the globbing fails, and I'm not using
> NULL_GLOB, } does not bother finishing the commands in the
> "then ....fi" block, } instead continues after "fi".
> 
> What slightly surprises me is that a glob failure isn't considered an
> error for purposes of ERR_EXIT (the -e option in your #! line).  I
> would have expected the whole script to quit at that point, but I
> guess glob errors are not treated as command failures because the
> command never executes in the first place.
> 
> However, what *is* happening is that a glob failure in a complex
> command acts in the manner of a "break" statement.

It's not really like a break, it's like (well, is) a global error flag
--- but the error status gets reset at the top level command loop, which
we reach in a script after the end of a set of complex commands --- but
only right at the end, when we're reading a new (possibly complex,
arbitrarily nested) command from the script.

I think actually what's going on could be considered a bug which is an
oversight for the case of scripts.  If the code was running a function,
the failure would cause it to skip right to the end of the function,
indeed any arbitrarily nested hierarchy of functions.  If we took the
rough equivalence between functions and scripts seriously, any hard
error (zerr() or zerrnam()) would cause a script to exit in the same
way.  Interactively, the error flag would still get reset but
non-interactively it wouldn't.

I don't see anything in the documentation to suggest that the top-level
command loop should be special non-interactively in the way it currently
is.  Indeed, when documenting try- and always-blocks, I wrote:

  An `error' in this context is a condition such as a syntax error
  which causes the shell to abort execution of the  current  func‐
  tion,  script,  or  list.
         ^^^^^^

which is clearly not true.  If there's a more fundamental description
of what happens on an error, I don't know where it is.

Indeed, it looks to me that without this the shell is violating the
"shall exit" terms of POSIX, section 2.8.1 of the shell command
language.  To use the example they give, this script

echo "${x!y}"
echo Got here

shouldn't print anything apart from the error message, but does.

pws

Re: Function code breaking out of if then ...fi

[Peter Stephenson]

On Mon, 05 Nov 2012 14:29:42 +0000
Peter Stephenson <p.stephenson@samsung.com> wrote:
> It's not really like a break, it's like (well, is) a global error flag
> --- but the error status gets reset at the top level command loop,
> which we reach in a script after the end of a set of complex commands
> --- but only right at the end, when we're reading a new (possibly
> complex, arbitrarily nested) command from the script.
> 
> I think actually what's going on could be considered a bug which is an
> oversight for the case of scripts.

Hmmm... there are multiple loops here and they have different error
handling.

In loop(),

	if (((!interact || sourcelevel) && errflag) || retflag)
	    break;

This actually does what I want: if it's not interactive, and there's an
error, break out of the loop.  This is the "top level" loop I was
thinking of.

However, there are two even topper level loops in zsh_main().  They
appear to be limited to handling the case of hitting EOF and a parse
error --- no other sort of error --- however, and aren't restricted to
interactive behaviour.  I don't really like the look of the combination
of these three loops --- it smells to me like the effect hasn't been
thought through properly.  I can see you need to exit if you've got a
parse error, because you don't know what to execute yet, but I don't see
that you need to ignore all other errors in the outer loops.  retflag
and sourcelevel are irrelevant out here but I can definitely see a
case for "if (!interact && errflag) /* exit */".

pws

Re: Function code breaking out of if then ...fi

[Peter Stephenson]

Another inconsistency with error handling...

% fn() { setopt mumbly; print Got here; }
% fn
fn:setopt: no such option: mumbly
Got here
% fn() { set -o mumbly; print Got here; }
% fn
fn:set: no such option: mumbly

This is because set is a POSIX special builtin but setopt isn't.  It
should be documented, however.

Index: Doc/Zsh/builtins.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/builtins.yo,v
retrieving revision 1.145
diff -p -u -r1.145 builtins.yo
--- Doc/Zsh/builtins.yo	11 Oct 2012 20:14:03 -0000	1.145
+++ Doc/Zsh/builtins.yo	5 Nov 2012 16:06:10 -0000
@@ -1361,6 +1361,11 @@ or without the tt(no) prefix remains the
 If the tt(-m) flag is given the arguments are taken as patterns
 (which should be quoted to protect them from filename expansion), and all
 options with names matching these patterns are set.
+
+Note that a bad option name does not cause execution of shell code
+to be aborted; this is different from `tt(set -o)'.  This is because
+tt(set) is regarded as a special builtin by the POSIX standard,
+but tt(setopt) is not.
 )
 findex(shift)
 cindex(parameters, positional)

pws

Re: Function code breaking out of if then ...fi

[Han Pingtian]

This looks like also a inconsistency (or I'm missing something again):

Though both 'print nosuchfile*' and 'ls nosuchfile*' return non-zero vaules,
but the internal command one won't trigger ZERR trap, but the external
one does:

    #!/usr/local/bin/zsh -feu
    
    trap 'echo caught a error' ZERR
    
    ls nosuchfile*

will fail with 

    ./t3.sh:5: no matches found: nosuchfile*
    caught a error

but this one

    #!/usr/local/bin/zsh -feu
    
    trap 'echo caught a error' ZERR
    
    print nosuchfile*

will fail only with 
    
    ./t3.sh:5: no matches found: nosuchfile*

Re: Function code breaking out of if then ...fi

[Peter Stephenson]

On the behaviour that when the shell encounters a "fatal" error in a
script it resumes at the next "top level" command:  here's a proposal.
This makes that behaviour optional, for compatibility, but turns it off
by default.  I don't think the old, undocumented, behaviour is intuitive
enough for us to go on leaving it as the default.  The shell essentially
skips a chunk of code and resumes later on at a point where there's not
the slightest reason to suppose it's appropriate to do so; you might be
relying on the structure that was previously executing to set things up
for the next chunk of code.

I'm not really even sure we need the option, but it seems possible that
people who happened on the behaviour have become reliant on it.

I've taken the opportunity to document the behaviour on fatal errors.
The list is exhausting rather than exhaustive.  I haven't bothered
listing errors associated with interactive shells where you'd be
returned to the command prompt.

That test at the end was a bit weird:  I don't think it was testing
POSIX_BUILTINS at all since errors with read-only variables are always
hard errors as a grep for the error message will immediately show.
It does provide a useful test for CONTINUE_ON_ERROR.

Index: Doc/Zsh/grammar.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/grammar.yo,v
retrieving revision 1.23
diff -p -u -r1.23 grammar.yo
--- Doc/Zsh/grammar.yo	1 Feb 2012 12:53:49 -0000	1.23
+++ Doc/Zsh/grammar.yo	9 Nov 2012 22:43:30 -0000
@@ -438,7 +438,7 @@ where var(term) is at least one newline 
 A short form of tt(select).
 )
 enditem()
-texinode(Reserved Words)(Comments)(Alternate Forms For Complex Commands)(Shell Grammar)
+texinode(Reserved Words)(Errors)(Alternate Forms For Complex Commands)(Shell Grammar)
 sect(Reserved Words)
 cindex(reserved words)
 findex(disable, use of)
@@ -451,7 +451,56 @@ select coproc nocorrect foreach end ! [[
 
 Additionally, `tt(})' is recognized in any position if neither the
 tt(IGNORE_BRACES) option nor the tt(IGNORE_CLOSE_BRACES) option is set.
-texinode(Comments)(Aliasing)(Reserved Words)(Shell Grammar)
+texinode(Errors)(Comments)(Reserved Words)(Shell Grammar)
+sect(Errors)
+cindex(errors, handling of)
+Certain errors are treated as fatal by the shell: in an interactive
+shell, they cause control to return to the command line, and in a
+non-interactive shell they cause the shell to be aborted.  In older
+versions of zsh, a non-interactive shell running a script would not
+abort completely, but would resume execution at the next command to be
+read from the script, skipping the remainder of any functions or
+shell constructs such as loops or conditions; this somewhat illogical
+behaviour can be recovered by setting the option tt(CONTINUE_ON_ERROR).
+
+Fatal errors found in non-interactive shells include:
+startlist()
+list(Failure to parse shell options passed when invoking the shell)
+list(Failure to change options with the tt(set) builtin)
+list(Parse errors of all sorts, including failures to parse
+mathematical expressions)
+list(Failures to set or modify variable behaviour with tt(typeset),
+tt(local), tt(declare), tt(export), tt(integer), tt(float))
+list(Execution of incorrectly positioned loop control structures
+(tt(continue), tt(break)))
+list(Attempts to use regular expression with no regular expression
+module available)
+list(Disallowed operations when the tt(RESTRICTED) options is set)
+list(Failure to create a pipe needed for a pipeline)
+list(Failure to create a multio)
+list(Failure to autoload a module needed for a declared shell feature)
+list(Errors creating command or process substitutions)
+list(Syntax errors in glob qualifiers)
+list(File generation errors where not caught by the option tt(BAD_PATTERN))
+list(All bad patterns used for matching within case statements)
+list(File generation failures where not caused by tt(NO_MATCH) or
+list(All file generation errors where the pattern was used to create a
+multio)
+list(Memory errors where detected by the shell)
+list(Invalid subscripts to shell variables)
+list(Attempts to assign read-only variables)
+list(Logical errors with variables such as assignment to the wrong type)
+list(Use of invalid variable names)
+list(Errors in variable substitution syntax)
+list(Failure to convert characters in tt($')...tt(') expressions)
+similar options)
+endlist()
+
+If the tt(POSIX_BUILTINS) option is set, more errors associated with
+shell builtin commands are treated as fatal, as specified by the POSIX
+standard.
+
+texinode(Comments)(Aliasing)(Errors)(Shell Grammar)
 sect(Comments)
 cindex(comments)
 pindex(INTERACTIVE_COMMENTS, use of)
Index: Doc/Zsh/options.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/options.yo,v
retrieving revision 1.107
diff -p -u -r1.107 options.yo
--- Doc/Zsh/options.yo	1 Mar 2012 03:34:15 -0000	1.107
+++ Doc/Zsh/options.yo	9 Nov 2012 22:43:31 -0000
@@ -1733,6 +1733,22 @@ Make the tt(echo) builtin compatible wit
 This disables backslashed escape sequences in echo strings unless the
 tt(-e) option is specified.
 )
+pindex(CONTINUE_ON_ERROR)
+pindex(NO_CONTINUE_ON_ERROR)
+pindex(CONTINUEONERROR)
+pindex(NOCONTINUEONERROR)
+cindex(error, option to continue script on)
+item(tt(CONTINUE_ON_ERROR))(
+If a fatal error is encountered (see 
+ifnzman(noderef(Errors))\
+ifzman(the section ERRORS in zmanref(zshmisc))), and the code is running
+in a script, the shell will resume execution at the next statement
+in the script at the top level, in other words outside all functions
+or shell constructs such as loops and conditions.  This mimics the
+behaviour of interactive shells, where the shell returns to the
+line editor to read a new command; it was the normal behaviour in versions
+of zsh before 5.0.1.
+)
 pindex(CSH_JUNKIE_HISTORY)
 pindex(NO_CSH_JUNKIE_HISTORY)
 pindex(CSHJUNKIEHISTORY)
Index: Src/hist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/hist.c,v
retrieving revision 1.118
diff -p -u -r1.118 hist.c
--- Src/hist.c	21 Apr 2012 18:42:56 -0000	1.118
+++ Src/hist.c	9 Nov 2012 22:43:31 -0000
@@ -573,7 +573,7 @@ histsubchar(int c)
 		} else {
 		    herrflush();
 		    unqueue_signals();
-		    zerr("Ambiguous history reference");
+		    zerr("ambiguous history reference");
 		    return -1;
 		}
 
Index: Src/init.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/init.c,v
retrieving revision 1.127
diff -p -u -r1.127 init.c
--- Src/init.c	11 Oct 2012 20:14:03 -0000	1.127
+++ Src/init.c	9 Nov 2012 22:43:31 -0000
@@ -1608,15 +1608,20 @@ zsh_main(UNUSED(int argc), char **argv)
 	 * We only do this at top level, because if we are
 	 * executing stuff we may refer to them by job pointer.
 	 */
+	int errexit = 0;
 	maybeshrinkjobtab();
 
 	do {
 	    /* Reset return from top level which gets us back here */
 	    retflag = 0;
 	    loop(1,0);
+	    if (errflag && !interact && !isset(CONTINUEONERROR)) {
+		errexit = 1;
+		break;
+	    }
 	} while (tok != ENDINPUT && (tok != LEXERR || isset(SHINSTDIN)));
-	if (tok == LEXERR) {
-	    /* Make sure a parse error exits with non-zero status */
+	if (tok == LEXERR || errexit) {
+	    /* Make sure a fatal error exits with non-zero status */
 	    if (!lastval)
 		lastval = 1;
 	    stopmsg = 1;
Index: Src/options.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/options.c,v
retrieving revision 1.65
diff -p -u -r1.65 options.c
--- Src/options.c	11 Oct 2012 20:14:03 -0000	1.65
+++ Src/options.c	9 Nov 2012 22:43:31 -0000
@@ -113,6 +113,7 @@ static struct optname optns[] = {
 {{NULL, "combiningchars",     0},			 COMBININGCHARS},
 {{NULL, "completealiases",    0},			 COMPLETEALIASES},
 {{NULL, "completeinword",     0},			 COMPLETEINWORD},
+{{NULL, "continueonerror",    0},                        CONTINUEONERROR},
 {{NULL, "correct",	      0},			 CORRECT},
 {{NULL, "correctall",	      0},			 CORRECTALL},
 {{NULL, "cshjunkiehistory",   OPT_EMULATE|OPT_CSH},	 CSHJUNKIEHISTORY},
Index: Src/zsh.h
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/zsh.h,v
retrieving revision 1.186
diff -p -u -r1.186 zsh.h
--- Src/zsh.h	11 Oct 2012 20:14:03 -0000	1.186
+++ Src/zsh.h	9 Nov 2012 22:43:31 -0000
@@ -1971,6 +1971,7 @@ enum {
     COMPLETEINWORD,
     CORRECT,
     CORRECTALL,
+    CONTINUEONERROR,
     CPRECEDENCES,
     CSHJUNKIEHISTORY,
     CSHJUNKIELOOPS,
Index: Test/A04redirect.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/A04redirect.ztst,v
retrieving revision 1.24
diff -p -u -r1.24 A04redirect.ztst
--- Test/A04redirect.ztst	3 Oct 2012 18:11:15 -0000	1.24
+++ Test/A04redirect.ztst	9 Nov 2012 22:43:31 -0000
@@ -419,26 +419,26 @@
 >output
 ?zsh:.:2: no such file or directory: /nonexistent/nonexistent
 
-  $ZTST_testdir/../Src/zsh -f <<<'
+  $ZTST_testdir/../Src/zsh -f -o CONTINUE_ON_ERROR <<<'
   readonly foo
   foo=bar set output
   echo output'
-0:failed assignment on posix special, NO_POSIX_BUILTINS
+0:failed assignment on posix special, CONTINUE_ON_ERROR
 >output
 ?zsh: read-only variable: foo
 
-  $ZTST_testdir/../Src/zsh -f -o POSIX_BUILTINS <<<'
+  $ZTST_testdir/../Src/zsh -f <<<'
   readonly foo
   foo=bar set output
   echo output'
-1:failed assignment on posix special, POSIX_BUILTINS
+1:failed assignment on posix special, NO_CONTINUE_ON_ERROR
 ?zsh: read-only variable: foo
 
-  $ZTST_testdir/../Src/zsh -f -o POSIX_BUILTINS <<<'
+  $ZTST_testdir/../Src/zsh -f -o CONTINUE_ON_ERROR <<<'
   readonly foo
   foo=bar echo output
   echo output'
-0:failed assignment on non-posix-special, POSIX_BUILTINS
+0:failed assignment on non-posix-special, CONTINUE_ON_ERROR
 >output
 ?zsh: read-only variable: foo
 

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

Re: Function code breaking out of if then ...fi

[Bart Schaefer]

On Nov 9, 10:52pm, Peter Stephenson wrote:
}
} On the behaviour that when the shell encounters a "fatal" error in a
} script it resumes at the next "top level" command:  here's a proposal.
} This makes that behaviour optional, for compatibility, but turns it off
} by default.  I don't think the old, undocumented, behaviour is intuitive
} enough for us to go on leaving it as the default.  The shell essentially
} skips a chunk of code and resumes later on at a point where there's not
} the slightest reason to suppose it's appropriate to do so; you might be
} relying on the structure that was previously executing to set things up
} for the next chunk of code.

I believe I know the reason for this behavior, and perhaps it points to a
bug:

When reading a startup file such as .zshrc, there is an intent to avoid
skipping the entire configuration just because of one erroneous command
somewhere in the middle.

My possibly flawed recollection was that this was only supposed to happen
in startup scripts, not in scripts run as standalone programs or loaded
by "source" or ".".

If this patch modifies the behavior of startup files, perhaps one further
step would be to turn on CONTINUE_ON_ERROR before startup files are read,
then turn it off before entering the main loop iff the starup files
themselves have not frobbed it.  I believe something similar is done
with MONITOR and also HASHDIRS.

Re: Function code breaking out of if then ...fi

[Peter Stephenson]

On Fri, 09 Nov 2012 17:13:19 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> I believe I know the reason for this behavior, and perhaps it points to a
> bug:
> 
> When reading a startup file such as .zshrc, there is an intent to avoid
> skipping the entire configuration just because of one erroneous command
> somewhere in the middle.

I've a vague memory of this too, but evidence suggests it's not showing
CONTINUE_ON_ERROR behaviour (this is before my patch):


% cat ~/tmp/zdotdir/.zshrc
print First line
echo *fumblewumble*
print Second line
% ZDOTDIR=~/tmp/zdotdir zsh
First line
/home/pws/tmp/zdotdir/.zshrc:2: no matches found: *fumblewumble*
% exit     # <- this is the prompt inside the new shell
% zsh ~/tmp/zdotdir/.zshrc 
First line
/home/pws/tmp/zdotdir/.zshrc:2: no matches found: *fumblewumble*
Second line


So if that was the intention, we've already messed it up.  A bit of
historical research might be interesting.

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

Re: Function code breaking out of if then ...fi

[Peter Stephenson]

On Sat, 10 Nov 2012 21:23:30 +0000
Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> On Fri, 09 Nov 2012 17:13:19 -0800
> Bart Schaefer <schaefer@brasslantern.com> wrote:
> > When reading a startup file such as .zshrc, there is an intent to
> > avoid skipping the entire configuration just because of one
> > erroneous command somewhere in the middle.
> 
> I've a vague memory of this too, but evidence suggests it's not
> showing CONTINUE_ON_ERROR behaviour (this is before my patch):

In fact, the code I've altered can't have an effect on this:  as it says
in the essay I wrote before, I'm modifying code above the "top-level"
loop in loop(), that's called mainly to handle "do you really want to
exit" for interactive shells.  The initialisation code is not handled
from here; run_init_scripts() has finised from this point.  I think we'd
need code within loop() itself, which handles the lines read from
startup files.  In this code the test

	if (((!interact || sourcelevel) && errflag) || retflag)
	    break;

ensures we *do* break out of the loop if we're sourcing a file (whether
or not at initialisation).

Hmm... we're not getting confused between keeping going in a particular
startup file and allowing the shell to execute another file, are we?

pws