zsh-5.2-test-2

zsh-5.2-test-2

[Peter Stephenson]

You can now find a second test version prior to zsh 5.3 in

http://www.zsh.org/pub/development/

Fixes since the first test version include those for the
following issues:

- the problem with "~-"

- a regression since 5.2 in use of ERR_EXIT / ERR_RETURN with shell
structures

- test failures owing to an environmental issue in an interactive test

It looks like I ought to be able to make a release at the weekend ---
note that at this stage it will not be held up by problems that were
already in 5.2.

pws

Re: zsh-5.2-test-2

[Peter Stephenson]

On Tue, 6 Dec 2016 19:49:16 +0000
Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> You can now find a second test version prior to zsh 5.3

Timetable:  I'll probably produce a final test version 3 this evening
(GMT), which as far as I know should fix any problems new since 5.2
that have been brought up at the last minute, then 5.3 on Sunday,
unless anyone notices anything else significant.

pws

zsh-5.2-test-3

[Peter Stephenson]

On Fri, 09 Dec 2016 09:57:29 +0000
Peter Stephenson <p.stephenson@samsung.com> wrote:
> Timetable:  I'll probably produce a final test version 3 this evening
> (GMT), which as far as I know should fix any problems new since 5.2
> that have been brought up at the last minute, then 5.3 on Sunday,
> unless anyone notices anything else significant.

5.2-test-3 is in
 
http://www.zsh.org/pub/development/

This should fix some test failures with Solaris, some _arguments
oddities with option handling (will be fixed more betterer in 5.3), and
though there's no fix here it moves a regex multibyte handling test to
the last in the set (D07) so if it fails you can be pretty sure the
problem is limited to interaction with the external regex library.

(Now it only takes seconds instead of an hour to send multi-megabyte email
to Australia I don't even have time for my G&T first.  Grumble.)

pws

Re: zsh-5.2-test-3

[Ray Andrews]

On 12/09/2016 11:54 AM, Peter Stephenson wrote:
>
> 5.2-test-3 is in
>   
> http://www.zsh.org/pub/development/
>
>
     Seems to have fired up ok, however:

    $ make -s

    builtin.c:5041:11: warning: ‘cursplit’ may be used uninitialized in
    this function [-Wmaybe-uninitialized]

    compmatch.c:774:15: warning: ‘savl’ may be used uninitialized in
    this function [-Wmaybe-uninitialized]

    $ make check

    ./V10private.ztst: starting.
    Pattern match failed:


    **************************************
    46 successful test scripts, 1 failure, 1 skipped
    **************************************
    Makefile:187: recipe for target 'check' failed
    make[1]: *** [check] Error 1
    make[1]: Leaving directory '/aMisc/Zsh-new/zsh-5.2-test-3/Test'
    Makefile:263: recipe for target 'check' failed
    make: *** [check] Error 2
    make check  10.40s user 7.06s system 32% cpu 53.316 total

... I  remember there were a few inconsequential errors last time I did 
this however.

BTW, if there a 'make check' that only shows errors or warnings?  No 
need to see all the stuff that's fine.

Re: zsh-5.2-test-3

[Ray Andrews]

On 12/10/2016 06:07 PM, Ray Andrews wrote:

I unzipped the 'doc' file, but there's no install for it. Do I copy it 
to the zsh tree somewhere? Previous installs show no 'Doc' directory.  I 
ran 'make install', not sure what changed.  But 'Doc' has lots of .html 
files and those seem not to have been copied anywhere.

Re: zsh-5.2-test-3

[Peter Stephenson]

On Sat, 10 Dec 2016 19:46:28 -0800
Ray Andrews <rayandrews@eastlink.ca> wrote:
> On 12/10/2016 06:07 PM, Ray Andrews wrote:
> I unzipped the 'doc' file, but there's no install for it. Do I copy it 
> to the zsh tree somewhere? Previous installs show no 'Doc' directory.  I 
> ran 'make install', not sure what changed.  But 'Doc' has lots of .html 
> files and those seem not to have been copied anywhere.

It goes on top of the non-doc untar and you can then install everything
including documentation without having to build the latter.  If you have
YODL you can build from scratch and the doc bundle isn't necessary.
Most zsh developers won't need the doc file (but obviously having
somebody look at its contents is a very good idea).

pws

Re: zsh-5.2-test-3

[Ray Andrews]

On 12/11/2016 09:15 AM, Peter Stephenson wrote:
> somebody look at its contents is a very good idea). pws 

Thanks Peter.  BTW, the contents of the /help directory, I never been 
able to figure out how one accesses that information, it seems that it 
is meant to be pulled up by some command.  'run-help' doesn't do it, 
'man' neither.  For example 'test' contains:

test [ arg ... ]
[ [ arg ... ] ]
        Like the system version of test.  Added for  compatibility; use
        conditional  expressions  instead  (see the section `Conditional
        Expressions').  The main  differences  between  the conditional
        expression  syntax  and the test and [ builtins are:  these com-
        mands are not handled syntactically, so  for  example  an empty
        variable  expansion  may cause an argument to be omitted; syntax
        errors cause status 2 to be returned instead of a  shell error;
        and  arithmetic  operators  expect integer arguments rather than
        arithmetic expressions.

        The command attempts to implement POSIX and its extensions where
        these are specified.  Unfortunately there are intrinsic ambigui-
        ties in the  syntax;  in  particular  there  is  no distinction
        between  test  operators  and  strings  that resemble them. The
        standard attempts to resolve these for small  numbers  of argu-
        ments  (up  to  four);  for five or more arguments compatibility
        cannot be relied on.  Users are urged wherever possible  to use
        the `[[' test syntax which does not have these ambiguities.

... and that's possibly useful help, but how do I get to it?

Re: zsh-5.2-test-3

[Bart Schaefer]

On Dec 11, 10:16am, Ray Andrews wrote:
}
} Thanks Peter.  BTW, the contents of the /help directory, I never been 
} able to figure out how one accesses that information, it seems that it 
} is meant to be pulled up by some command.  'run-help' doesn't do it,

run-help would do it if you had "autoload run-help".  See the doc for
the run-help function in zshcontrib, or Functions/Misc/run-help.

The help files are generated directly from the documentation so there's
nothing in there that "man zshbuiltins" wouldn't also show you.

Re: zsh-5.2-test-3

[Ray Andrews]

On 12/11/2016 11:23 AM, Bart Schaefer wrote:
> On Dec 11, 10:16am, Ray Andrews wrote:
> }
> } Thanks Peter.  BTW, the contents of the /help directory, I never been
> } able to figure out how one accesses that information, it seems that it
> } is meant to be pulled up by some command.  'run-help' doesn't do it,
>
> run-help would do it if you had "autoload run-help".  See the doc for
> the run-help function in zshcontrib, or Functions/Misc/run-help.
>
> The help files are generated directly from the documentation so there's
> nothing in there that "man zshbuiltins" wouldn't also show you.

'autoload run-help' still gives me the 'normal' man page, it seems, but 
as you say the information in 'man zshbuiltins' is the same as that in 
'/help'.  I changed the name of '/help' to see what would happen but 
'man zshbuiltins' works just the same, so it seems that '/help' is 
redundant.  Or is it?  I see the same text in '/share/man/man1'.

I'm always frustrated  looking in the right place for the right help -- 
'man test' is not the zsh version and when one is looking in the 'man 
zsh...' it can be less than obvious which subsection is appropriate.  I 
wonder if it would be possible to tweek things so that 'man XXX' always 
gave me the appropriate information for whatever version of the command 
was actually in play regardless of it's provenance.  I remember last 
year crashing into  the fact that there are several versions of some 
commands, so one wants to be sure.
>

Re: zsh-5.2-test-3

[Bart Schaefer]

On Dec 11, 12:19pm, Ray Andrews wrote:
}
} 'autoload run-help' still gives me the 'normal' man page, it seems

You really do need to look at the documentation that I mentioned.

----
run-help CMD
     This function is designed to be invoked by the run-help ZLE widget,
     in place of the default alias.  See `Accessing On-Line Help'
     for setup instructions.
----

Then look at the cross-referenced "Accessing ..." page:

----
... By default, run-help is an alias for the man command, so
this often fails when the command word is a shell builtin or a
user-defined function.  By redefining the run-help alias, one can
improve the on-line help provided by the shell.

[Some useful stuff about the help directory skipped here, you can
read it in the actual manual.]

To use the run-help function, you need to add lines something like the
following to your .zshrc or equivalent startup file:

     unalias run-help
     autoload run-help
----

I'd guess that you autoloaded the function without removing the alias.

Re: zsh-5.2-test-3

[Ray Andrews]

On 12/11/2016 03:45 PM, Bart Schaefer wrote:
> On Dec 11, 12:19pm, Ray Andrews wrote:
> }
> } 'autoload run-help' still gives me the 'normal' man page, it seems
>
> You really do need to look at the documentation that I mentioned.
>
> I'd guess that you autoloaded the function without removing the alias.
>
To be honest sir,  I shouldn't have said anything before I did my 
homework, that was a bit lazy.  Several irons in the fire right now, 
pardon.  Yeah, did that now and it takes me to the right man page, but 
doesn't search within it for the command -- if that's even to be 
expected.  I've often wondered if 'man' has some search that is specific 
to the command headings within one of those large files like 
zshcontrib.  When the command is a common word, like 'test' one sees it 
dozens of times in plain text before one gets to the command itself.

Re: zsh-5.2-test-3

[Bart Schaefer]

On Dec 11,  5:04pm, Ray Andrews wrote:
}
} Yeah, did that now and it takes me to the right man page, but 
} doesn't search within it for the command

Oh, one bit I overlooked -- if you're running zsh with $fpath pointing
into the build tree, it will not find the help files without some more
configuration -- the location is substituted into the run-help function
definition by "make install".

To run out of the build tree, you have to explicitly assign the HELPDIR
parameter to point to the appropriate Doc/help subdirectory.

Re: zsh-5.2-test-3

[Ray Andrews]

On 12/12/2016 08:37 AM, Bart Schaefer wrote:
> On Dec 11,  5:04pm, Ray Andrews wrote:
> }
> } Yeah, did that now and it takes me to the right man page, but
> } doesn't search within it for the command
>
> Oh, one bit I overlooked -- if you're running zsh with $fpath pointing
> into the build tree, it will not find the help files without some more
> configuration -- the location is substituted into the run-help function
> definition by "make install".
>
> To run out of the build tree, you have to explicitly assign the HELPDIR
> parameter to point to the appropriate Doc/help subdirectory.
>
Sorry Bart I don't have any idea what you mean.

3 /aWorking 2$ echo $fpath
/usr/local/share/zsh/site-functions 
/aWorking/zsh-5.2-test-3/share/zsh/site-functions 
/aWorking/zsh-5.2-test-3/share/zsh/5.2-test-3/functions

... the first directory doesn't exist, the others are correct (based on 
" --prefix=  "), and why would I want $fpath pointing anywhere else? 
Anyway, as yesterday, " $ run-help test " takes me to "zshbuiltins" and 
that's what I want, no? Throw in Daniel's insights into better 
searching, and it's pretty functional.

However " $ run-help zmv " finds nothing, tho it is there in 'zshall' 
but just a single line.

Re: zsh-5.2-test-3

[Bart Schaefer]

On Dec 12,  9:02am, Ray Andrews wrote:
}
} Sorry Bart I don't have any idea what you mean.

If you look at Functions/Misc/run-help in the git checkout or tarball,
you'll see

local HELPDIR="${HELPDIR:-@runhelpdir@}"

Obviously there's no directory named "@runhelpdir@".  Instead that
string is replaced by "make install" with the directory into which
the help files have been installed.

So if you've never run "make install" you have to do

HELPDIR=/where/zsh/is/built/Doc/help

for appropriate value of /where/zsh/is/built/.

If you *have* run "make install" then

    grep -m 1 HELPDIR $^fpath/run-help(N)

will show you where it thinks the help files should be, and if they're
not at that location, then they didn't get installed or something else
has caused them to be in the "wrong" place, and you need to set HELPDIR
to the right place.
 
} However " $ run-help zmv " finds nothing, tho it is there in 'zshall' 
} but just a single line.

The run-help function only "knows about" the same things that "which"
knows about.  If "which zmv" doesn't find anything, run-help won't
either.

The HELPDIR files are only automatically constructed for zsh builtins,
so those are not going to assist with zmv.

Re: zsh-5.2-test-3

[Ray Andrews]

On 12/12/2016 09:39 AM, Bart Schaefer wrote:
> The run-help function only "knows about" the same things that "which"
> knows about.  If "which zmv" doesn't find anything, run-help won't
> either.
>
> The HELPDIR files are only automatically constructed for zsh builtins,
> so those are not going to assist with zmv.
>
Ok, thanks Bart and Daniel.  I'm a bit exhausted by these intricacies 
for now.  What seems to work for everything all the time even on 
Tuesdays is just 'man  zshall' and then Daniel's search style. And the 
HTML 'book' for more involved study.  Not to push my luck, but if I 
could export zshall to plain text I could implement my ' ~test ' 
conversion and just use text editor capabilities to navigate the thing 
and it would be that simple and maybe fun.

Re: zsh-5.2-test-3

[Bart Schaefer]

On Dec 12,  1:11pm, Ray Andrews wrote:
}
} [...]   Not to push my luck, but if I 
} could export zshall to plain text I could implement my ' ~test ' 
} conversion and just use text editor capabilities to navigate the thing 
} and it would be that simple and maybe fun.

The Perl script Util/helpfiles is what constructs the Doc/help tree by
parsing "man zshbuiltins".  It could probably expand to do a similar
thing for "man zshcontrib" but that has a less regular structure.

Anyway that script sets up "man" and then feeds it through "col" or
"colcrt" to produce output that is as close to plain text as possisble.
Could certainly be cannibalized to do that part for "man zshall".

Re: zsh-5.2-test-3

[Daniel Shahaf]

Ray Andrews wrote on Mon, Dec 12, 2016 at 13:11:05 -0800:
> On 12/12/2016 09:39 AM, Bart Schaefer wrote:
> >The run-help function only "knows about" the same things that "which"
> >knows about.  If "which zmv" doesn't find anything, run-help won't
> >either.
> >
> >The HELPDIR files are only automatically constructed for zsh builtins,
> >so those are not going to assist with zmv.
> >
> Ok, thanks Bart and Daniel.  I'm a bit exhausted by these intricacies for
> now.  What seems to work for everything all the time even on Tuesdays is
> just 'man  zshall' and then Daniel's search style. And the HTML 'book' for
> more involved study.  Not to push my luck, but if I could export zshall to
> plain text I could implement my ' ~test ' conversion and just use text
> editor capabilities to navigate the thing and it would be that simple and
> maybe fun.

You could just read the yodl source (Doc/Zsh/*.yo).  The markup is
pretty simple.  E.g., to find the documentation of the `test' builtin,
search for `item(tt(test)'.

Re: zsh-5.2-test-3

[Ray Andrews]

On 12/12/2016 03:35 PM, Daniel Shahaf wrote:
>
> You could just read the yodl source (Doc/Zsh/*.yo).  The markup is
> pretty simple.  E.g., to find the documentation of the `test' builtin,
> search for `item(tt(test)'.
>
Ha!

     $ man zshall > zshall-75.txt

Done ;-)

The only thing is that the width of the doc  is fixed at whatever would 
have fit on the terminal were it not redirected so I have it at 75 chars 
which is just right for my editor taking up half the screen as I 
normally run it.

Re: zsh-5.2-test-3

[Daniel Shahaf]

Ray Andrews wrote on Sun, Dec 11, 2016 at 17:04:33 -0800:
> Yeah, did that now and it takes me to the right man page, but doesn't
> search within it for the command -- if that's even to be expected.
> I've often wondered if 'man' has some search that is specific to the
> command headings within one of those large files like zshcontrib.
> When the command is a common word, like 'test' one sees it dozens of
> times in plain text before one gets to the command itself.

Two optiosn:

1) Use regular expressions.  Assuming your $PAGER is 'less':

    man zshall
    /^ *test <Enter>
    [that's slash, caret, space, asterisk, etc — type it exactly so]

will find instance of 'test' on beginning of line, only.  Then `n'
to go to the next match.

Sidebar: I use MANOPT='--nh --nj' to inhibit hyphenation in manpages,
which is useful when grepping for words that would otherwise have
straddled a end-of-line hyphen.  (I also use MANWIDTH=80, but that's
a matter of preference.)

2) Use the HTML or PDF manual, which have indices at the end.  Looking
up `test' in the index will jump you to the right place.

Re: zsh-5.2-test-3

[Ray Andrews]

On 12/12/2016 12:37 AM, Daniel Shahaf wrote:
> Two optiosn:
>
> 1) Use regular expressions.  Assuming your $PAGER is 'less':
>
>      man zshall
>      /^ *test <Enter>
>      [that's slash, caret, space, asterisk, etc — type it exactly so]
>
> will find instance of 'test' on beginning of line, only.  Then `n'
> to go to the next match.

Bloody marvelous, I had no idea we were allowed to use those tricks 
inside man. But as above still has a few bad hits, whereas:

/^ (seven spaces) test <Enter>

... has only one bad hit, but what an improvement.  So I take it that 
'run-help' can't magically whisk us down to the command itself?  I had 
supposed that there could be some functionality built into man that 
might make that possible (hidden tags or something), but if it's just 
text as seen then of course that won't be happening.  I wonder if some 
wiz could find a way?  I know that the rules for man are now written in 
stone, but if in, say, zshbuiltins all the command headings looked like:

        ~test  [ arg ...

... or something, then you could always search for "  ~test  " thus 
eliminating any plain text uses of the word.

I'll experiment with your other ideas a bit later.  Thanks Daniel. You 
know, the above is one of those little things that no adept would bother 
to mention because it so obvious once you know it, but when you don't 
know it, life is that much nastier.

BTW, why would run-help  alias to man by default?  We already have man, 
so who need another way of running it?  Wouldn't the changes Bart 
mentioned be the natural default for a zsh specific command? I'd sure 
have appreciated it.

Re: zsh-5.2-test-3

[Bart Schaefer]

On Dec 12,  8:28am, Ray Andrews wrote:
}
} BTW, why would run-help alias to man by default?

It used to be the case that zsh was frequently installed as just the
binary, without the function suite present in any usuable location,
so a lot of the defaults are arranged to make sure the shell works
under those circumstances.

} We already have man, so who need another way of running it?

Are you not using the run-help ZLE key-binding?

If you're on a command line and type ESC-h, ZLE will find the first
word on the line and invoke run-help on it.

Way, way back, that key binding just ran "man" directly; the alternate
name was introduced so "man" could be swapped for something smarter.
This happened so long ago that shell functions didn't exist yet, so
it was done by creating an alias, and it has been that way ever since.

Re: zsh-5.2-test-3

[Ray Andrews]

On 12/12/2016 09:14 AM, Bart Schaefer wrote:
> If you're on a command line and type ESC-h, ZLE will find the first
> word on the line and invoke run-help on it.
Yup, works fine.
>
> Way, way back, that key binding just ran "man" directly; the alternate
> name was introduced so "man" could be swapped for something smarter.
> This happened so long ago that shell functions didn't exist yet, so
> it was done by creating an alias, and it has been that way ever since.
>
There is no substitute for historical perspective!

Re: zsh-5.2-test-3

[Daniel Shahaf]

Ray Andrews wrote on Sun, Dec 11, 2016 at 12:19:06 -0800:
> I wonder if it would be possible to tweek things so that 'man XXX'
> always gave me the appropriate information for whatever version of the
> command was actually in play regardless of it's provenance.
> I remember last year crashing into  the fact that there are several
> versions of some commands, so one wants to be sure.

You need to set $MANPATH like you set $PATH.

Man pages generally document their version (in zsh it's in the left
footer), so you can always check that the foo(1) man page matches `foo
--version`.

Re: zsh-5.2-test-3

[Daniel Shahaf]

Ray Andrews wrote on Sat, Dec 10, 2016 at 18:07:43 -0800:
>    $ make -s
> 
>    compmatch.c:774:15: warning: ‘savl’ may be used uninitialized in
>    this function [-Wmaybe-uninitialized]

False positive.  (The other one — not quoted — is in bin_print().)

> BTW, if there a 'make check' that only shows errors or warnings?  No need to
> see all the stuff that's fine.

You could eliminate a few lines of output at the top by passing -s to
'make check', as you already do for 'make all'.  The per-file harness
messages are unconditional, however.  (And we might want not to add
complexity there...)

Cheers,

Daniel