zsh-workers
 help / color / mirror / Atom feed
* One possible answer to typeset vs. unset
@ 2020-11-28 19:49 Bart Schaefer
  2020-11-28 20:00 ` Bart Schaefer
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Bart Schaefer @ 2020-11-28 19:49 UTC (permalink / raw)
  To: Zsh hackers list

Those of you who get zsh repository commit messages will have seen
this already.  Rather than send a patch here (yet), I've taken
Daniel's suggestion and created a new branch.  The changes address the
issue that "typeset foo" creates $foo set to an empty string, by
concealing the internal value rather than altering the way internal
values are defaulted.

You can see these changes by checking out the "declarednull" branch.

I did not (yet) introduce an option or emulation control of this,
though I did test a build where it was predicated on emulation, and
the current default behavior is unchanged in that case.

This imposes the following changes, most of which can be amended if desired:

A typeset variable with no assignment triggers NO_UNSET warnings when
the name is used in parameter expansion or math.  Incidentally, there
is no existing test that covers this; that is, NO_UNSET is tested only
with names that have never been declared or names that have been
explicitly unset.

The typeset -AEFHLRTZailux options are applied upon the first
assignment to the variable. Explicit unset before the first assignment
discards all of those properties. If any option is applied to an
existing name, historic behavior is unchanged.

Consequent to the foregoing, the (t) parameter expansion flag prints
nothing until after the first assignment, and the (i) and (I)
subscript flags also print nothing.  I think the latter is one of the
more problematic consequences, especially for some completion
functions.

One that I forgot in the commit log:  The behavior of "typeset foo;
typeset foo" is changed.  Previously the second typeset would output
the current setting of foo:
  foo=''
With these changes, that outputs nothing.  However, once a value has
been assigned the historic behavior is restored, so "typeset foo=bar;
typeset foo" outputs
  foo=bar
Furthermore, "typeset foo; typeset -p foo" outputs only
  typeset foo

The bash behavior of "unset foo; typeset -p foo" is NOT used.  This is
called out as an emulation distinction, not a change.

The test cases have not been updated, so several now fail.  The test
harness has been updated to declare default values, because otherwise
the harness itself is the first thing that breaks.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: One possible answer to typeset vs. unset
  2020-11-28 19:49 One possible answer to typeset vs. unset Bart Schaefer
@ 2020-11-28 20:00 ` Bart Schaefer
  2020-11-28 20:21 ` Bart Schaefer
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 15+ messages in thread
From: Bart Schaefer @ 2020-11-28 20:00 UTC (permalink / raw)
  To: Zsh hackers list

On Sat, Nov 28, 2020 at 11:49 AM Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> A typeset variable with no assignment triggers NO_UNSET warnings when
> the name is used in parameter expansion or math.

There are a couple of possible ways to amend this.

The most radical would be for "typeset foo" to fail when NO_UNSET,
thus forcing all declarations to assign explicit defaults.

The other way would be to test the PM_DECLARED flag and treat the
variable as if set.  This could cause problems for (at least) numeric
types, because $num returns empty string rather than zero, which is
exactly the sort of thing you want NO_UNSET to alert you about.

So the right thing is most likely no amendment at all.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: One possible answer to typeset vs. unset
  2020-11-28 19:49 One possible answer to typeset vs. unset Bart Schaefer
  2020-11-28 20:00 ` Bart Schaefer
@ 2020-11-28 20:21 ` Bart Schaefer
  2020-12-01  8:54 ` Felipe Contreras
  2020-12-02 17:18 ` Vincent Lefevre
  3 siblings, 0 replies; 15+ messages in thread
From: Bart Schaefer @ 2020-11-28 20:21 UTC (permalink / raw)
  To: Zsh hackers list

On Sat, Nov 28, 2020 at 11:49 AM Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> concealing the internal value rather than altering the way internal
> values are defaulted.

I should note that it's possible that this introduces memory leaks for
global-scope parameters, because it introduces a case where a struct
param with the PM_UNSET flag remains in the global parameter table.
Ordinarily that only happens to function scope parameters.  I think
such leaks, if they exist at all, would be detectable only when the
shell is about to exit anyway.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: One possible answer to typeset vs. unset
  2020-11-28 19:49 One possible answer to typeset vs. unset Bart Schaefer
  2020-11-28 20:00 ` Bart Schaefer
  2020-11-28 20:21 ` Bart Schaefer
@ 2020-12-01  8:54 ` Felipe Contreras
  2020-12-03 21:19   ` Bart Schaefer
  2020-12-02 17:18 ` Vincent Lefevre
  3 siblings, 1 reply; 15+ messages in thread
From: Felipe Contreras @ 2020-12-01  8:54 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

On Sat, Nov 28, 2020 at 1:49 PM Bart Schaefer <schaefer@brasslantern.com> wrote:

> You can see these changes by checking out the "declarednull" branch.

I tried this branch, and I tried to make it pass all the tests. And it
did mostly work, except with tied variables.

I don't know what would be the proper solution for tied variables, but
I used this hack to make the tests pass:

--- a/Src/builtin.c
+++ b/Src/builtin.c
@@ -2513,6 +2513,7 @@ typeset_single(char *cname, char *pname, Param
pm, UNUSED(int func),
        }
        tdp->joinchar = joinchar;
        tdp->arrptr = &altpm->u.arr;
+       altpm->node.flags &= ~PM_DECLAREDNULL;

        pm->gsu.s = &tiedarr_gsu;
        pm->u.data = tdp;

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: One possible answer to typeset vs. unset
  2020-11-28 19:49 One possible answer to typeset vs. unset Bart Schaefer
                   ` (2 preceding siblings ...)
  2020-12-01  8:54 ` Felipe Contreras
@ 2020-12-02 17:18 ` Vincent Lefevre
  2020-12-02 18:03   ` Bart Schaefer
  3 siblings, 1 reply; 15+ messages in thread
From: Vincent Lefevre @ 2020-12-02 17:18 UTC (permalink / raw)
  To: zsh-workers

On 2020-11-28 11:49:12 -0800, Bart Schaefer wrote:
> The typeset -AEFHLRTZailux options are applied upon the first
> assignment to the variable. Explicit unset before the first assignment
> discards all of those properties. If any option is applied to an
> existing name, historic behavior is unchanged.

OK for the second sentence (about unset), but I don't understand the
first sentence. Could you explain the following behavior?

zira% ./zsh -c 'typeset -i x; echo $x; echo $((x+3)); unset x; echo $((x+3));'

3
3
zira% ./zsh -c 'typeset -E x; echo $x; echo $((x+3)); unset x; echo $((x+3));'

3.
3
zira%

Why do I get "3." if the -E option isn't supposed to be applied yet?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: One possible answer to typeset vs. unset
  2020-12-02 17:18 ` Vincent Lefevre
@ 2020-12-02 18:03   ` Bart Schaefer
  0 siblings, 0 replies; 15+ messages in thread
From: Bart Schaefer @ 2020-12-02 18:03 UTC (permalink / raw)
  To: Zsh hackers list

On Wed, Dec 2, 2020, 9:19 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> On 2020-11-28 11:49:12 -0800, Bart Schaefer wrote:
> > The typeset -AEFHLRTZailux options are applied upon the first
> > assignment to the variable.
>
> Could you explain the following behavior?
>
> zira% ./zsh -c 'typeset -E x; echo $x; echo $((x+3)); unset x; echo $((x+3));'
>
> 3.
> 3
> zira%
>
> Why do I get "3." if the -E option isn't supposed to be applied yet?

The short answer would be "because math context is magic."

The longer answer is that $((x)) is not the same as ${x} or $(($x)),
and the quoted sentence is more a description of behavior than of
implementation.

What the branch attempts to do is create a "null" concept by combining
two flags, a new one PM_DECLARED (actually an overload of one that is
used only at shell startup) plus PM_UNSET.  When a variable is
assigned, both are cleared.  When a variable is unset, PM_DECLARED is
cleared and PM_UNSET is asserted if necessary.  When a variable is
dereferenced in the normal ${x} way, PM_UNSET results in empty string
being returned no matter what the declared type is.  With the
exception of adding PM_DECLARED, this is the way that locally scoped
variables already work.

Math context doesn't care about PM_UNSET in the same way; it grabs the
value from the union in the parameter struct, which I deliberately
left unchanged as a zero-value double.  This is one reason "null" is
represented in the PM_ flags rather than in the union itself.  So
$((x)) comes back 0.0 instead of empty string, and $((x+3)) works like
it always did.


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: One possible answer to typeset vs. unset
  2020-12-01  8:54 ` Felipe Contreras
@ 2020-12-03 21:19   ` Bart Schaefer
  2020-12-04 11:04     ` Felipe Contreras
  0 siblings, 1 reply; 15+ messages in thread
From: Bart Schaefer @ 2020-12-03 21:19 UTC (permalink / raw)
  To: Zsh hackers list; +Cc: Felipe Contreras

On Tue, Dec 1, 2020 at 12:55 AM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> I don't know what would be the proper solution for tied variables, but
> I used this hack to make the tests pass:

I looked at this for a while yesterday evening.  My conclusion is that
tied variables are already a bit of a hack.

It would be nice to be able to determine null-ness (however that ends
up being defined) in bin_typeset where we are actually examining the
"assigns" list of names+values, but the determination of whether a
parameter is being localized or is having its type changed in a
value-preserving compatible way (e.g., typeset -F SECONDS) is down in
typeset_single.  And typeset_single is called twice for tied
variables, always in the same order no matter which of the pair is
being initialized, which is then cleaned up afterward in bin_typeset.
So something convoluted has to be done, especially if both parts of
the pair are supposed to appear "null" when neither is given an
initial value.

Consequently I don't know if your patch would cause a different test
for unset-ness (that hasn't been written yet) to fail, but something
like that patch may be unavoidable.


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: One possible answer to typeset vs. unset
  2020-12-03 21:19   ` Bart Schaefer
@ 2020-12-04 11:04     ` Felipe Contreras
  2020-12-04 15:49       ` Bart Schaefer
  2020-12-05  0:51       ` Bart Schaefer
  0 siblings, 2 replies; 15+ messages in thread
From: Felipe Contreras @ 2020-12-04 11:04 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

On Thu, Dec 3, 2020 at 3:19 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Tue, Dec 1, 2020 at 12:55 AM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > I don't know what would be the proper solution for tied variables, but
> > I used this hack to make the tests pass:
>
> I looked at this for a while yesterday evening.  My conclusion is that
> tied variables are already a bit of a hack.

Indeed. It might not be worthwhile to look at them at this point.

> Consequently I don't know if your patch would cause a different test
> for unset-ness (that hasn't been written yet) to fail, but something
> like that patch may be unavoidable.

I can't parse that. What would such unset-ness test do?

Anyway. I don't see the two approaches particularly different. If
nobody can argue that "typeset var" and "typeset -i var" should behave
differently (one with no value and the other with value), then some
kind of flag like PM_DECLARED would be needed. I'll add that to my
approach.

Next, I think all the instances in which PM_UNSET is checked should be
verified, to see if PM_DECLAREDNULL makes sense in those. I'll do
that.

Next, we need a way to make sure $empty[(i|I)] returns something
sensible (that would be for both approaches).

And I think that's it. All that's left is deciding what flag would
turn this mode on.

Lastly, I don't know if there is any low-hanging fruit, for example;
doing the same as bash 5.0 with localvar_inherit and localvar_unset.
In my opinion localvar_inherit should also be the default (and
presumably that's what POSIX will eventually decide). I don't quite
get localvar_unset, but seems to also be a sensible default. Or maybe
that's an entirely new topic.

Cheers.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: One possible answer to typeset vs. unset
  2020-12-04 11:04     ` Felipe Contreras
@ 2020-12-04 15:49       ` Bart Schaefer
  2020-12-04 19:47         ` Bart Schaefer
  2020-12-05  0:28         ` Bart Schaefer
  2020-12-05  0:51       ` Bart Schaefer
  1 sibling, 2 replies; 15+ messages in thread
From: Bart Schaefer @ 2020-12-04 15:49 UTC (permalink / raw)
  To: Felipe Contreras; +Cc: Zsh hackers list

On Fri, Dec 4, 2020 at 3:04 AM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> On Thu, Dec 3, 2020 at 3:19 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > I looked at this for a while yesterday evening.  My conclusion is that
> > tied variables are already a bit of a hack.

Part of my latest commit log on the declarednull branch:

The scalar struct param of a tied pair stores a direct pointer to the
internal array value of the array struct param, and upon assignment
modifies it without referring to the containing struct. This means
that there's no opportunity to clear the PM_DECLAREDNULL bits on both
structs when the scalar is assigned. Conversely, assigning to the
array does use the struct for the scalar.

I think this can be fixed but I don't want it to become inefficient.
OTOH, tied parameters (other than specials, which are different in
several ways) may not be used (or updated when they are) very much.

> > Consequently I don't know if your patch would cause a different test
> > for unset-ness (that hasn't been written yet) to fail, but something
> > like that patch may be unavoidable.
>
> I can't parse that. What would such unset-ness test do?

Check that both elements of the pair appear to be unset when neither
has been initialized.

As it currently stands on the branch, following

typeset -T TIED_SCALAR tied_array

These

typeset -p TIED_SCALAR
typeset -p tied_array

print differing initializers.


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: One possible answer to typeset vs. unset
  2020-12-04 15:49       ` Bart Schaefer
@ 2020-12-04 19:47         ` Bart Schaefer
  2020-12-05  0:22           ` Bart Schaefer
  2020-12-05  0:28         ` Bart Schaefer
  1 sibling, 1 reply; 15+ messages in thread
From: Bart Schaefer @ 2020-12-04 19:47 UTC (permalink / raw)
  To: Zsh hackers list

On Fri, Dec 4, 2020 at 7:49 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> The scalar struct param of a tied pair stores a direct pointer to the
> internal array value of the array struct param, and upon assignment
> modifies it without referring to the containing struct.This means
> that there's no opportunity to clear the PM_DECLAREDNULL bits

I've just noticed that the D04 test "Unsetting and recreation of tied
normal parameters" silently crashes the test harness.  The fix for
this is probably closely related to correcting the flags.


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: One possible answer to typeset vs. unset
  2020-12-04 19:47         ` Bart Schaefer
@ 2020-12-05  0:22           ` Bart Schaefer
  0 siblings, 0 replies; 15+ messages in thread
From: Bart Schaefer @ 2020-12-05  0:22 UTC (permalink / raw)
  To: Zsh hackers list

On Fri, Dec 4, 2020 at 11:47 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> I've just noticed that the D04 test "Unsetting and recreation of tied
> normal parameters" silently crashes the test harness.  The fix for
> this is probably closely related to correcting the flags.

Not so closely related after all.  Unset of a tied local scalar left
it using tiedarr_gsu, even though the tie data was null.

That seems like an accident waiting to happen; I tested the patch
below on the master branch, and it still passes the full test suite.
I suggest it be applied there (it's already pushed to the declarednull
branch).

diff --git a/Src/params.c b/Src/params.c
index a0d4caf52..1a047d9e0 100644
--- a/Src/params.c
+++ b/Src/params.c
@@ -3659,6 +3659,8 @@ unsetparam_pm(Param pm, int altflag, int exp)
        }

        zsfree(altremove);
+       if (!(pm->node.flags & PM_SPECIAL))
+           pm->gsu.s = &stdscalar_gsu;
     }

     /*


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: One possible answer to typeset vs. unset
  2020-12-04 15:49       ` Bart Schaefer
  2020-12-04 19:47         ` Bart Schaefer
@ 2020-12-05  0:28         ` Bart Schaefer
  1 sibling, 0 replies; 15+ messages in thread
From: Bart Schaefer @ 2020-12-05  0:28 UTC (permalink / raw)
  To: Zsh hackers list

On Fri, Dec 4, 2020 at 7:49 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> The scalar struct param of a tied pair stores a direct pointer to the
> internal array value of the array struct param, and upon assignment
> modifies it without referring to the containing struct.
>
> I think this can be fixed but I don't want it to become inefficient.

Fix for this is now pushed to the declarednull branch.  It requires an
extra getnode() the first time a tied scalar is assigned after being
declared, and only when both the scalar and the array were declared
uninitialized.  So unless one is repeatedly creating/discarding tied
pairs, it shouldn't make much difference.


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: One possible answer to typeset vs. unset
  2020-12-04 11:04     ` Felipe Contreras
  2020-12-04 15:49       ` Bart Schaefer
@ 2020-12-05  0:51       ` Bart Schaefer
  2020-12-05 22:17         ` Bart Schaefer
  2020-12-23 23:00         ` Felipe Contreras
  1 sibling, 2 replies; 15+ messages in thread
From: Bart Schaefer @ 2020-12-05  0:51 UTC (permalink / raw)
  To: Felipe Contreras; +Cc: Zsh hackers list

On Fri, Dec 4, 2020 at 3:04 AM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> Next, I think all the instances in which PM_UNSET is checked should be
> verified, to see if PM_DECLAREDNULL makes sense in those. I'll do
> that.

In cases I've discovered so far, it's actually more likely that one
has to check whether PM_UNSET and PM_DECLARED are boolean different,
rather than whether both are (not) set.

> Next, we need a way to make sure $empty[(i|I)] returns something
> sensible (that would be for both approaches).

That's the last thing on my list, too.

> And I think that's it. All that's left is deciding what flag would
> turn this mode on.

I'm leaning toward POSIXBUILTINS.

> Lastly, I don't know if there is any low-hanging fruit, for example;
> doing the same as bash 5.0 with localvar_inherit and localvar_unset.

I thoroughly dislike localvar_inherit.  I wonder if it's in bash 5.0
just to be able to compare the suggested semantics from that rejected
POSIX proposal we've previously discussed.  I may be biased by long
use of the zsh semantic, but treating global -> local like environ ->
global seems weird, unless there's also a way to "export" a local back
to global.

> I don't quite get localvar_unset, but seems to also be a sensible default.

If I'm reading the bash manual correctly, localvar_unset means that
"unset foo" behaves like "local foo; unset foo".  Thus (Chet will
probably correct me):

fn1() {
  unset foo
}
fn2() {
  local foo=something
  fn1
  echo ${foo-nil} # is nil
}
fn3() {
  local foo=something
  shopt localvar_unset
  fn1
  echo ${foo-nil} # is something
}


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: One possible answer to typeset vs. unset
  2020-12-05  0:51       ` Bart Schaefer
@ 2020-12-05 22:17         ` Bart Schaefer
  2020-12-23 23:00         ` Felipe Contreras
  1 sibling, 0 replies; 15+ messages in thread
From: Bart Schaefer @ 2020-12-05 22:17 UTC (permalink / raw)
  To: Felipe Contreras; +Cc: Zsh hackers list

On Fri, Dec 4, 2020 at 4:51 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Fri, Dec 4, 2020 at 3:04 AM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>
> > Next, we need a way to make sure $empty[(i|I)] returns something
> > sensible (that would be for both approaches).
>
> That's the last thing on my list, too.

Unexpected complication here:  On the master branch for empty="" ,
both of those return 0, rather than 0 and 1 as they do for empty=().
They return empty string for an unset, including for missing array
elements (including missing hash elements).


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: One possible answer to typeset vs. unset
  2020-12-05  0:51       ` Bart Schaefer
  2020-12-05 22:17         ` Bart Schaefer
@ 2020-12-23 23:00         ` Felipe Contreras
  1 sibling, 0 replies; 15+ messages in thread
From: Felipe Contreras @ 2020-12-23 23:00 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

Hello Bart,

Sorry about the delay, I've been busy with other projects.

I merged my approach and your approach and I'll be sending a patch to
show the resulting differences.

On Fri, Dec 4, 2020 at 6:52 PM Bart Schaefer <schaefer@brasslantern.com> wrote:

> On Fri, Dec 4, 2020 at 3:04 AM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > Next, I think all the instances in which PM_UNSET is checked should be
> > verified, to see if PM_DECLAREDNULL makes sense in those. I'll do
> > that.
>
> In cases I've discovered so far, it's actually more likely that one
> has to check whether PM_UNSET and PM_DECLARED are boolean different,
> rather than whether both are (not) set.

Literally the first instance of PM_USET I checked shows a discrepancy
between my approach and your approach.

  f () {
    local var
    print ${(t)var}
  }
  f

With my approach this prints "scalar-local" (I think correctly). With
your approach it doesn't print anything.

> > And I think that's it. All that's left is deciding what flag would
> > turn this mode on.
>
> I'm leaning toward POSIXBUILTINS.

Would ksh emulation enable this flag?

> > Lastly, I don't know if there is any low-hanging fruit, for example;
> > doing the same as bash 5.0 with localvar_inherit and localvar_unset.
>
> I thoroughly dislike localvar_inherit.  I wonder if it's in bash 5.0
> just to be able to compare the suggested semantics from that rejected
> POSIX proposal we've previously discussed.  I may be biased by long
> use of the zsh semantic, but treating global -> local like environ ->
> global seems weird, unless there's also a way to "export" a local back
> to global.

After considering it further I don't think it makes sense to have this
as default.

No other language does something like that.

> > I don't quite get localvar_unset, but seems to also be a sensible default.
>
> If I'm reading the bash manual correctly, localvar_unset means that
> "unset foo" behaves like "local foo; unset foo".  Thus (Chet will
> probably correct me):

If so I don't think it makes sense to have this as default.

-- 
Felipe Contreras


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2020-12-23 23:00 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-28 19:49 One possible answer to typeset vs. unset Bart Schaefer
2020-11-28 20:00 ` Bart Schaefer
2020-11-28 20:21 ` Bart Schaefer
2020-12-01  8:54 ` Felipe Contreras
2020-12-03 21:19   ` Bart Schaefer
2020-12-04 11:04     ` Felipe Contreras
2020-12-04 15:49       ` Bart Schaefer
2020-12-04 19:47         ` Bart Schaefer
2020-12-05  0:22           ` Bart Schaefer
2020-12-05  0:28         ` Bart Schaefer
2020-12-05  0:51       ` Bart Schaefer
2020-12-05 22:17         ` Bart Schaefer
2020-12-23 23:00         ` Felipe Contreras
2020-12-02 17:18 ` Vincent Lefevre
2020-12-02 18:03   ` Bart Schaefer

zsh-workers

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/zsh-workers

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-workers zsh-workers/ http://inbox.vuxu.org/zsh-workers \
		zsh-workers@zsh.org
	public-inbox-index zsh-workers

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git