RE: "here" document broken? (New findings)

RE: "here" document broken? (New findings)

[Com MN PG P E B Consultant 3]

> > The following script, call it zsh_here, works well:
> > 
> > #!/bin/zsh -f
> > cat << EOD
> >   xxx
> > EOD 
> > 
> > If I change it like this, it does not work anymore:
> > 
> > #!/bin/zsh
> > cat << EOD
> >   xxx
> > EOD
>     First let's take a look at the /etc/zsh* files. If you source
> them explictly in your first example, does it still work?

Things got even more bizarre. When I returned to work after a long
weekend, those scripts which worked last week (i.e. those where I
used the -f flag), now show the same error too!

>     Can you install a new version of zsh locally (in your home) and
> run it to reproduce the error?

This is a good idea. And I will also persuade one of my colleagues to
execute the script in his environment.

Ronald

Re: "here" document broken? (New findings)

[Bart Schaefer]

On Oct 28, 11:34am, Com MN PG P E B Consultant 3 wrote:
}
} As the only difference is the -f flag in the invocation of zsh,
} the culprit might be my startup scripts. But they are innocent:

}    zsh -x -c zsh_here

How about changing zsh_here to put the -x on the #! line, so that you
can see what's happening *inside* the script?

#!/bin/zsh -x
cat << EOD
  xxx
EOD

Re: "here" document broken? (New findings)

[DervishD]

    Hi Ronald :)

 * Com MN PG P E B Consultant 3 <mn-pg-p-e-b-consultant-3.com@siemens.com> dixit:
> The following script, call it zsh_here, works well:
> 
> #!/bin/zsh -f
> cat << EOD
>   xxx
> EOD 
> 
> If I change it like this, it does not work anymore:
> 
> #!/bin/zsh
> cat << EOD
>   xxx
> EOD
> 
> If I execute it, I get the error message 
> 
>    zsh_here:2: no such file or directory

    Try this:

    #!/bin/zsh
    cat << EOD
    EOD

    If you still get the error, then the problem is in the "cat" line
(which I assume from the error output and line number) and in some
interaction with RC files.
 
> (1) If in the "good" version (version 1), I explicitly source .zshenv
> and .zshrc, it still works.

    Then the problem is probably not on those files but on /etc/zsh*
ones.
 
> I start to suspect that this zsh version (4.0.7) is broken. Unless
> someone has another idea where to look, I try to persuade our
> sysadmin to install a newer version (I know this won't be easy...).

    First let's take a look at the /etc/zsh* files. If you source
them explictly in your first example, does it still work?

    Can you install a new version of zsh locally (in your home) and
run it to reproduce the error?

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

RE: "here" document broken? (New findings)

[Com MN PG P E B Consultant 3]

Things are still mysterious, but I am now able to narrow down
the problem. So here is what I have so far:

The following script, call it zsh_here, works well:

#!/bin/zsh -f
cat << EOD
  xxx
EOD 

If I change it like this, it does not work anymore:

#!/bin/zsh
cat << EOD
  xxx
EOD

If I execute it, I get the error message 

   zsh_here:2: no such file or directory

As the only difference is the -f flag in the invocation of zsh,
the culprit might be my startup scripts. But they are innocent:

(1) If in the "good" version (version 1), I explicitly source .zshenv
and .zshrc, it still works.

(2) If I remove .zshenv and .zshrc (and also a .profile which was
still hanging around), and then call the "bad" version, I still get 
the error message.

To be really sure that in case of (2), no other files are secretly
sourced, I also called my script like this:

   zsh -x -c zsh_here

and get the output:

+zsh:1> zsh_here
zsh_here:2: no such file or directory

Aside from this flaw, the zsh seems to work fine: I have several scripts
which
work like a charm, as long I don't use here documents.

I start to suspect that this zsh version (4.0.7) is broken. Unless
someone
has another idea where to look, I try to persuade our sysadmin to
install
a newer version (I know this won't be easy...).

Ronald