A couple of queries

A couple of queries

[Zefram]

-----BEGIN PGP SIGNED MESSAGE-----

In glob.c, in the function file_type() (which contains the delightful
comment "screw POSIX"), there is commented-out code that would return a
character '&' instead of '@' for a symbolic link that doesn't point
anywhere accessible.  Considering that compatibility with "ls -F" isn't
really an issue here (and '%' and '#' are returned for devices which ls
doesn't do), why is this code not used?

Secondly, I had an idea for a new option for a couple of builtins.
compctl has an option -L that makes zsh output the actual compctl
commands that one would have to input in order to get to the current
set of completion options.  A similar option would be very useful for
alias, bindkey (especially), limit, sched and typeset.  (typeset -L is
already taken, so it would have to be something else, but the others
can be -L.)  These options would not only be useful in normal use of
the shell, but would also simplify the reporter script greatly (which
btw won't run here -- awk syntax errors).  This option could be added
to each of the builtins quite easily, and without (much) risk of
breaking anything else.  What are people's opinions on this idea?
Richard, would you be willing to add this to the baseline before the
2.7 release?

 -zefram

-----BEGIN PGP SIGNATURE-----
Version: 2.6.i

iQBVAgUBL/9a32WJ8JfKi+e9AQGF7AH9HAhCS6kfVrKN66tXP6mjG255v4GkEmAS
2Ffm2ABz/NS3YpuGkDBeAV7ZwagpCdVSJFFSlwQCZiW/zLioO4yt8A==
=M++8
-----END PGP SIGNATURE-----

Re: A couple of queries

[Richard Coleman]

> In glob.c, in the function file_type() (which contains the delightful
> comment "screw POSIX"), there is commented-out code that would return a
> character '&' instead of '@' for a symbolic link that doesn't point
> anywhere accessible.  Considering that compatibility with "ls -F" isn't
> really an issue here (and '%' and '#' are returned for devices which ls
> doesn't do), why is this code not used?

I haven't seen that code.  I was going to remove that comment, but forgot.
The code has been posix-ified considerably since the start of the 2.6
cycle.

> Secondly, I had an idea for a new option for a couple of builtins.
> compctl has an option -L that makes zsh output the actual compctl
> commands that one would have to input in order to get to the current
> set of completion options.  A similar option would be very useful for
> alias, bindkey (especially), limit, sched and typeset.  (typeset -L is
> already taken, so it would have to be something else, but the others
> can be -L.)  These options would not only be useful in normal use of
> the shell, but would also simplify the reporter script greatly (which
> btw won't run here -- awk syntax errors).  This option could be added
> to each of the builtins quite easily, and without (much) risk of
> breaking anything else.  What are people's opinions on this idea?
> Richard, would you be willing to add this to the baseline before the
> 2.7 release?

I'm not against adding them if they don't add too much code.  I think these
would be useful.  But I would prefer to use the same option for all of them.
So we need an option letter that is free on all of these builtins, and would
have to change compctl -L to match this.  Since compctl -L is new, this
shouldn't cause too much problem.  Also, in order to make things easier,
I would prefer that the changes to each builtin be put in a separate patch
if possible.

But I would prefer that we wait until the next beta release before this is
implemented.  My box is overflowing with patches.  I'm in the process
of making more changes to the code dealing with internal hash tables.  So
any patch adding these features would be broken by the time I receive it.
Also, with the big patches from Peter (for the history code) and some of the
other big patches, the code will change a lot in the next couple of releases.

Also, just to let everyone know, I'll probably also add the compctl -Q option
either in this release or the next one.

But, my current priority is still to continue the process of cleaning up the
code.  I want to fix the structural problems first, so things like Peter's
patch for history.c will go in first.  I'm also doing some work on param.c.

So the next beta release might take a while.  So what I'll probably do is
make code snapshots (test releases) available starting in about a week,
so people can help me work out all the bugs I'll probably be adding.

rc

Re: A couple of queries

[Zefram]

-----BEGIN PGP SIGNED MESSAGE-----

>I haven't seen that code.  I was going to remove that comment, but forgot.
>The code has been posix-ified considerably since the start of the 2.6
>cycle.

The code in that function seems to indicate that S_IF* isn't POSIX.
Not having a copy of POSIX.1 (and the library here won't open for a
while :-(), can someone confirm that this is the case?  Should the code
be rewritten to use the (ugly, less efficient) S_IS* macros?

>I'm not against adding them if they don't add too much code.  I think these
>would be useful.  But I would prefer to use the same option for all of them.
>So we need an option letter that is free on all of these builtins, and would
>have to change compctl -L to match this.  Since compctl -L is new, this
>shouldn't cause too much problem.

I'd like them all to use the same letter, and was rather disappointed
to see that typeset -L is taken.  -L is a very obvious, quite intuitive
choice, so personally I'd be prepared to have an exception.  I would
probably have chosen -Q.

If we want them *all* to be the same letter, the possibilities are -J,
- -M, -U, -V, -W, -Y, -w and -y, assuming -Q is taken by compctl.  (Hmm,
I hope we don't start needing to use digits for compctl, it's terribly
ugly (why did we do that with zsh's command line options?))  None of
these is anywhere near as good as -L; can someone come up with a
rational reason to pick one of them?  Perhaps -M for coMMands?

>But I would prefer that we wait until the next beta release before this is
>implemented.  My box is overflowing with patches.  I'm in the process
>of making more changes to the code dealing with internal hash tables.  So
>any patch adding these features would be broken by the time I receive it.

I don't think so.  Most of the listing code is there already -- I'll
just need to add a little code to output in a different format.  It's a
fundamentally simple addition.  Anyway, I'll wait for the next beta
before writing this stuff.

 -zefram

-----BEGIN PGP SIGNATURE-----
Version: 2.6.i

iQBVAgUBL/9tWWWJ8JfKi+e9AQGG9gH8D6R7CNNYlLOtDorySrrmFR8lS3YrFjUb
UNhpCrtbXeqMBOUAhoVJs6VGX6vim12nV0BkWuctCeemzL5DCKkFWw==
=s7Jb
-----END PGP SIGNATURE-----