zsh ignores the arguments on its first command.

zsh ignores the arguments on its first command.

[Martin Buchholz]

Hi zsh maintainers,

This is a bug report.

It seems that when the shell is invoked using
zsh -i -c 'COMMAND1; COMMAND2'
then COMMAND1 is executed without its arguments!

$ ssh LUCID /bin/zsh -i -c '/bin/echo 1 2 3; /bin/echo 4 5 6; echo
ZSH_VERSION=${ZSH_VERSION}'
/etc/zsh/zshrc:10: unknown parameter: terminfo

4 5 6
ZSH_VERSION=4.3.10

but it definitely is executed, as you can see here:

$ ssh LUCID /bin/zsh -i -c 'pwd; echo ZSH_VERSION=${ZSH_VERSION}'
/etc/zsh/zshrc:10: unknown parameter: terminfo
/home/martinrb
ZSH_VERSION=4.3.10

That's a pretty serious bug, but should be easy for y'all to fix.

Thanks,

Martin

Re: zsh ignores the arguments on its first command.

[Peter Stephenson]

Martin Buchholz wrote:
> Hi zsh maintainers,
> 
> This is a bug report.
> 
> It seems that when the shell is invoked using
> zsh -i -c 'COMMAND1; COMMAND2'
> then COMMAND1 is executed without its arguments!

I think your terminal is being screwed up somehow.  That explains both
why you can't see the echo output and can't see the ${+terminfo}.

It usually helps if you can boil bugs down to what happens with the "-f"
option, so we're not relying on unseen side effects of initialisation
scripts.

Also, I'm afraid we don't have the spare time to go poking around in
distribution's zshrc files, but if you think there's some effect we
(rather than the distribution) should know about, please do report it.

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

Re: zsh ignores the arguments on its first command.

[Martin Buchholz]

Thanks, Peter.

You are right that this one is not a bug in zsh (or at least not just zsh).
Sigh... I guess I fell into a shell-quoting trap,
even though I consider myself an expert on that...

Here's one right way to do it:

$ ssh localhost "zsh -fc 'echo 1 2 3; echo 4 5 6'"
1 2 3
4 5 6

The openssh documentation doesn't seem to specify
exactly how a remote command is executed.

Martin

On Tue, Jun 1, 2010 at 14:45, Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
> Martin Buchholz wrote:
>> Hi zsh maintainers,
>>
>> This is a bug report.
>>
>> It seems that when the shell is invoked using
>> zsh -i -c 'COMMAND1; COMMAND2'
>> then COMMAND1 is executed without its arguments!
>
> I think your terminal is being screwed up somehow.  That explains both
> why you can't see the echo output and can't see the ${+terminfo}.
>
> It usually helps if you can boil bugs down to what happens with the "-f"
> option, so we're not relying on unseen side effects of initialisation
> scripts.
>
> Also, I'm afraid we don't have the spare time to go poking around in
> distribution's zshrc files, but if you think there's some effect we
> (rather than the distribution) should know about, please do report it.
>
> --
> Peter Stephenson <p.w.stephenson@ntlworld.com>
> Web page now at http://homepage.ntlworld.com/p.w.stephenson/
>

Re: zsh ignores the arguments on its first command.

[Martin Buchholz]

On Tue, Jun 1, 2010 at 14:45, Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
> Martin Buchholz wrote:

> I think your terminal is being screwed up somehow.  That explains both
> why you can't see the echo output and can't see the ${+terminfo}.

I expect ${+terminfo} to be 0, not to give an error.

> It usually helps if you can boil bugs down to what happens with the "-f"
> option, so we're not relying on unseen side effects of initialisation
> scripts.

Alright, let's try again to report the bug with the terminfo special
parameter and the zsh/terminfo module:

$ (unset TERM; zsh -fic 'echo $ZSH_VERSION; echo ${+terminfo}')
4.3.10
zsh:1: unknown parameter: terminfo


 $ (unset TERM; zsh -fic 'echo $ZSH_VERSION; echo ${+terminfo}')
4.3.4
0

The behavior in 4.3.4 is the expected one,
and the behavior in 4.3.10 is a regression
introduced since then.

My guess is that the zsh core is not prepared to deal
with the NULL return from getterminfo.

Martin

Re: zsh ignores the arguments on its first command.

[Peter Stephenson]

On Wed, 2 Jun 2010 00:05:20 -0700
Martin Buchholz <martinrb@google.com> wrote:
> Alright, let's try again to report the bug with the terminfo special
> parameter and the zsh/terminfo module:
> 
> $ (unset TERM; zsh -fic 'echo $ZSH_VERSION; echo ${+terminfo}')
> 4.3.10
> zsh:1: unknown parameter: terminfo

Ah, thanks, unsetting TERM was the key.

I think we're being over eager in reporting that the terminfo module didn't
load because the terminal wasn't set up.  Setting up the terminal should be
handled dynamically when the TERM variable changes (which is a completely
sepearate issue).

Index: Src/Modules/terminfo.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/terminfo.c,v
retrieving revision 1.34
diff -p -u -r1.34 terminfo.c
--- Src/Modules/terminfo.c	13 Mar 2008 11:11:05 -0000	1.34
+++ Src/Modules/terminfo.c	2 Jun 2010 11:17:51 -0000
@@ -341,8 +341,12 @@ boot_(Module m)
 # ifdef HAVE_SETUPTERM
     int errret;
 
-    if (setupterm((char *)0, 1, &errret) == ERR)
-	return 1;
+    /*
+     * Just because we can't set up the terminal doesn't
+     * mean the modules hasn't booted---TERM may change,
+     * and it should be handled dynamically---so ignore errors here.
+     */
+    (void)setupterm((char *)0, 1, &errret);
 # endif
 #endif
 
-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: zsh ignores the arguments on its first command.

[Martin Buchholz]

Peter,

Thanks for the fix.

I was thinking that, in addition,
the construct ${+NAME}
should never cause "unknown parameter",
not even due to failure to load a module
that provides the parameter as a feature,
so an additional fix in the zsh core might be good.
If a module fails to load, NAME should become an
ordinary unset variable, and ${+NAME} should be 0.

Martin

On Wed, Jun 2, 2010 at 04:19, Peter Stephenson <Peter.Stephenson@csr.com> wrote:
> On Wed, 2 Jun 2010 00:05:20 -0700
> Martin Buchholz <martinrb@google.com> wrote:
>> Alright, let's try again to report the bug with the terminfo special
>> parameter and the zsh/terminfo module:
>>
>> $ (unset TERM; zsh -fic 'echo $ZSH_VERSION; echo ${+terminfo}')
>> 4.3.10
>> zsh:1: unknown parameter: terminfo
>
> Ah, thanks, unsetting TERM was the key.
>
> I think we're being over eager in reporting that the terminfo module didn't
> load because the terminal wasn't set up.  Setting up the terminal should be
> handled dynamically when the TERM variable changes (which is a completely
> sepearate issue).
>
> Index: Src/Modules/terminfo.c
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Src/Modules/terminfo.c,v
> retrieving revision 1.34
> diff -p -u -r1.34 terminfo.c
> --- Src/Modules/terminfo.c      13 Mar 2008 11:11:05 -0000      1.34
> +++ Src/Modules/terminfo.c      2 Jun 2010 11:17:51 -0000
> @@ -341,8 +341,12 @@ boot_(Module m)
>  # ifdef HAVE_SETUPTERM
>     int errret;
>
> -    if (setupterm((char *)0, 1, &errret) == ERR)
> -       return 1;
> +    /*
> +     * Just because we can't set up the terminal doesn't
> +     * mean the modules hasn't booted---TERM may change,
> +     * and it should be handled dynamically---so ignore errors here.
> +     */
> +    (void)setupterm((char *)0, 1, &errret);
>  # endif
>  #endif
>
> --
> Peter Stephenson <pws@csr.com>            Software Engineer
> Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
> Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK
>
>
> Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
>

Re: zsh ignores the arguments on its first command.

[Peter Stephenson]

On Wed, 2 Jun 2010 09:44:13 -0700
Martin Buchholz <martinrb@google.com> wrote:
> I was thinking that, in addition,
> the construct ${+NAME}
> should never cause "unknown parameter",
> not even due to failure to load a module
> that provides the parameter as a feature,
> so an additional fix in the zsh core might be good.
> If a module fails to load, NAME should become an
> ordinary unset variable, and ${+NAME} should be 0.

I don't think that can be right.  You're basically asking for all (or a
substantial subset of) autoload failures to be silent.

To me, the module autoload is a contract that when you reference the
variable the module *will* be loaded.  If it isn't that's an error.  Take
the present example: the module failed to load because of an error that (so
far as I know) we're not interested in.  If this instead failed silently
the user would simply know that $terminfo wasn't working despite the fact
they've (maybe implicitly) asked for it and not have a clue why or even
that something had failed and hence wouldn't know what to do about it.

The autoload interface is a convenience to avoid you having to load modules
explicitly, which deliberately doesn't expose the module layer directly, so
necessarily interacts with it simply (load the module on demand, and that's
it).  If you're paranoid about not having module loads fail you need to do
more at the zmodload level.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: zsh ignores the arguments on its first command.

[Martin Buchholz]

On Thu, Jun 3, 2010 at 02:01, Peter Stephenson <Peter.Stephenson@csr.com> wrote:
> On Wed, 2 Jun 2010 09:44:13 -0700
> Martin Buchholz <martinrb@google.com> wrote:
>> I was thinking that, in addition,
>> the construct ${+NAME}
>> should never cause "unknown parameter",
>> not even due to failure to load a module
>> that provides the parameter as a feature,
>> so an additional fix in the zsh core might be good.
>> If a module fails to load, NAME should become an
>> ordinary unset variable, and ${+NAME} should be 0.
>
> I don't think that can be right.  You're basically asking for all (or a
> substantial subset of) autoload failures to be silent.

I think you're right that users should be notified
of all module load failures, including those
caused by autoloaded features.

However, "unknown parameter" is a very
misleading and frustrating error message,
especially when the construct ${+NAME}
asks to simply return 0 for unknown parameters.

Emacs has a similar feature, and a more
informative error message, of the form

    error ("Autoloading failed to define function %s",

So please change the zsh error to something like

"Autoloading of module %s failed to define parameter %s"

Martin

> To me, the module autoload is a contract that when you reference the
> variable the module *will* be loaded.  If it isn't that's an error.  Take
> the present example: the module failed to load because of an error that (so
> far as I know) we're not interested in.  If this instead failed silently
> the user would simply know that $terminfo wasn't working despite the fact
> they've (maybe implicitly) asked for it and not have a clue why or even
> that something had failed and hence wouldn't know what to do about it.
>
> The autoload interface is a convenience to avoid you having to load modules
> explicitly, which deliberately doesn't expose the module layer directly, so
> necessarily interacts with it simply (load the module on demand, and that's
> it).  If you're paranoid about not having module loads fail you need to do
> more at the zmodload level.
>
> --
> Peter Stephenson <pws@csr.com>            Software Engineer
> Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
> Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK
>
>
> Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
>

Re: zsh ignores the arguments on its first command.

[Peter Stephenson]

On Thu, 3 Jun 2010 06:22:57 -0700
Martin Buchholz <martinrb@google.com> wrote:
> So please change the zsh error to something like
> 
> "Autoloading of module %s failed to define parameter %s"

You're right, it's a specific error for this case, it could be a lot
clearer.

Index: Src/params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/params.c,v
retrieving revision 1.160
diff -p -u -r1.160 params.c
--- Src/params.c	12 May 2010 10:07:01 -0000	1.160
+++ Src/params.c	3 Jun 2010 13:31:33 -0000
@@ -461,7 +461,8 @@ getparamnode(HashTable ht, const char *n
 	     * stuff to go ahead with the autoload stub with
 	     * no error status we're in for all sorts of mayhem?
 	     */
-	    zerr("unknown parameter: %s", nam);
+	    zerr("autoloading module %s failed to define parameter: %s", mn,
+		 nam);
 	}
     }
     return hn;


-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: zsh ignores the arguments on its first command.

[Martin Buchholz]

Peter,

Thank you very much!

Martin

On Thu, Jun 3, 2010 at 06:32, Peter Stephenson <Peter.Stephenson@csr.com> wrote:
> On Thu, 3 Jun 2010 06:22:57 -0700
> Martin Buchholz <martinrb@google.com> wrote:
>> So please change the zsh error to something like
>>
>> "Autoloading of module %s failed to define parameter %s"
>
> You're right, it's a specific error for this case, it could be a lot
> clearer.
>
> Index: Src/params.c
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Src/params.c,v
> retrieving revision 1.160
> diff -p -u -r1.160 params.c
> --- Src/params.c        12 May 2010 10:07:01 -0000      1.160
> +++ Src/params.c        3 Jun 2010 13:31:33 -0000
> @@ -461,7 +461,8 @@ getparamnode(HashTable ht, const char *n
>             * stuff to go ahead with the autoload stub with
>             * no error status we're in for all sorts of mayhem?
>             */
> -           zerr("unknown parameter: %s", nam);
> +           zerr("autoloading module %s failed to define parameter: %s", mn,
> +                nam);
>        }
>     }
>     return hn;
>
>
> --
> Peter Stephenson <pws@csr.com>            Software Engineer
> Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
> Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK
>
>
> Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
>

Re: zsh ignores the arguments on its first command.

[Bart Schaefer]

On Thu, Jun 3, 2010 at 6:32 AM, Peter Stephenson
<Peter.Stephenson@csr.com> wrote:
>
> You're right, it's a specific error for this case, it could be a lot
> clearer.

Martin has something of a point in that when getparamnode() calls
zerr() for this, the shell behaves somewhat as if ${terminfo?} had
been used rather than ${+terminfo}.

Perhaps the correct thing here is to change this to a zwarn() and
allow the setting of the UNSET option to control whether autoload
failure aborts the script.  I'm not convinced that's right, either,
though.

Re: zsh ignores the arguments on its first command.

[Peter Stephenson]

On Thu, 3 Jun 2010 07:15:59 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Martin has something of a point in that when getparamnode() calls
> zerr() for this, the shell behaves somewhat as if ${terminfo?} had
> been used rather than ${+terminfo}.
> 
> Perhaps the correct thing here is to change this to a zwarn() and
> allow the setting of the UNSET option to control whether autoload
> failure aborts the script.  I'm not convinced that's right, either,
> though.

Yes, as you'll see from the comment just above the code I changed, I had
upgraded it from a warning to an error, since it doesn't mean "the shell
programmer didn't get around to setting this variable" it means "something
nasty happened such that this variable that you were expecting to implement
special behaviour is never going to do what you expect".  I think that's a
hard(er) error.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom