Re: PATCH: Add jobdirs association to parameter module

Re: PATCH: Add jobdirs association to parameter module

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
> 
> It's a shame we didn't have more specific names for parameters, since the
> parameter module is quiet heavily used in completion, so there is quite a
> lot of name space pollution.  They stop being special if made local, but
> it's still a problem.  The ksh mechanism ${.param.jobdirs} would be
> excellent for this.

When I last added parameters to it, I asked if I should rename them to 
`z...' -- we decided against that.

I agree that it would be nice to have this cleaner so I just tried to 
allow dots in parameter names by simply adding `typtab['.'] |= IIDENT;'
to inittyptab(). It /seems/ to work, only `$.a.b' doesn't (but
`${.a.b}' does), haven't found the place where it fails yet -- mainly
because I haven't really searched for it.

So, can anyone think of a good reason why we shouldn't do that? Like
Peter (at least I think Peter meant that) I prefer the solution with
the dots over the solution with just prepending a `z' before every
parameter name. It's clean, it's extensible...

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: Add jobdirs association to parameter module

[Zefram]

Sven Wischnowsky wrote:
>                                     only `$.a.b' doesn't

Not sure you *want* that to work.  You certanly don't want `$a.b' to be
treated as `${a.b}'.

-zefram

RE: PATCH: Add jobdirs association to parameter module

[Andrej Borsenkow]

>
> I agree that it would be nice to have this cleaner so I just tried to
> allow dots in parameter names by simply adding `typtab['.'] |= IIDENT;'
> to inittyptab(). It /seems/ to work, only `$.a.b' doesn't (but
> `${.a.b}' does), haven't found the place where it fails yet -- mainly
> because I haven't really searched for it.
>

I do not think it is a problem. We already have a lot of modifiers that are
valid only inside of ${...} So, we could just as well state, that ${.x.y.z}
refers to object z defined in namespace .x.y.

As long as .x.y.z=foo and typeset .x.y.z work - I think, this restriction is
acceptable.

/andrej

RE: PATCH: Add jobdirs association to parameter module

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > I agree that it would be nice to have this cleaner so I just tried to
> > allow dots in parameter names by simply adding `typtab['.'] |= IIDENT;'
> > to inittyptab(). It /seems/ to work, only `$.a.b' doesn't (but
> > `${.a.b}' does), haven't found the place where it fails yet -- mainly
> > because I haven't really searched for it.
> >
> 
> I do not think it is a problem. We already have a lot of modifiers that are
> valid only inside of ${...} So, we could just as well state, that ${.x.y.z}
> refers to object z defined in namespace .x.y.
> 
> As long as .x.y.z=foo and typeset .x.y.z work - I think, this restriction is
> acceptable.

Well, if someone wants to see if he can find any problems with this,
it would be the patch below...

Note to maintainers: dunno if this should be applied right now, maybe
there are problems I don't see.

And if we find no problems or the solutions for them, we should of
course also change the docs. And decide about the standard way to form 
the namespace: `.<module>.<param>' or `<module>.<param>' or
`.zsh.<module>.<param>' or `zsh.<module>.<param>' or ... (I know that
you know that -- I just wanted to write them down to be able to have a 
look at them to find out which one I like the most; still don't know;
the ones with the dot at the beginning look a bit zstyle'ish, don't
they? the ones with the `zsh' are a bit longish... hm).


Bye
 Sven

diff -ru ../z.old/Src/utils.c Src/utils.c
--- ../z.old/Src/utils.c	Tue Dec 14 14:13:35 1999
+++ Src/utils.c	Tue Dec 14 14:22:20 1999
@@ -2234,6 +2234,7 @@
 	typtab[t0] = typtab[t0 - 'a' + 'A'] = IALPHA | IALNUM | IIDENT | IUSER | IWORD;
     for (t0 = 0240; t0 != 0400; t0++)
 	typtab[t0] = IALPHA | IALNUM | IIDENT | IUSER | IWORD;
+    typtab['.'] |= IIDENT;
     typtab['_'] = IIDENT | IUSER;
     typtab['-'] = IUSER;
     typtab[' '] |= IBLANK | INBLANK;

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: Add jobdirs association to parameter module

[Sven Wischnowsky]

Zefram wrote:

> Sven Wischnowsky wrote:
> >                                     only `$.a.b' doesn't
> 
> Not sure you *want* that to work.  You certanly don't want `$a.b' to be
> treated as `${a.b}'.

Right. In the meantime I had thought again (well, ok, I had started
thinking at all) and came to the same conclusion.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: Add jobdirs association to parameter module

[Felix Rosencrantz]

Peter Stephenson wrote:
> What is this chunk for?  It's going to mean the parameters are permanently
> stuck in the parameter table, even if the module is unloaded, and if the
> module is reloaded the parameters won't be.  Sven just fixed this a week or
> so ago.

Sigh...  I'm terribly embarrassed.  I made the change more than a week ago, and
wanted to try it before sending it.  Then I made the patch with the latest
version of parameter.c rather than the original version.

> It's a shame we didn't have more specific names for parameters, since the
> parameter module is quiet heavily used in completion, so there is quite a
> lot of name space pollution.  They stop being special if made local, but
> it's still a problem.  The ksh mechanism ${.param.jobdirs} would be
> excellent for this.

I agree, there is a problem with the name space pollution.  I would suggest
that zsh is included in the name, like  ${.zshparam.jobdirs} or
${.zsh.param.jobdirs} (I'm not familiar with ksh).  I think if we say that
parameters beginning with zsh are reserved for future expansion, then there is
room for expansion without stepping on people's toes.

-FR.
__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

PATCH: Add jobdirs association to parameter module

[Felix Rosencrantz]

This proposed patch adds a new association to the parameter module
called jobdirs.  This provides an association with job numbers and the
directories in which the jobs were started.

I decided to use the name jobdirs instead of jobpwds since the "jobs"
builtin uses the "-d" to list these directories.  Though I could see
that jobpwds might also be appropriate.

It is possible to use the "jobs -d" command to get this same
information with a little processing. Though adding an association
seems to be a cleaner way for zsh functions or scripts to get this
information.

-FR
--- old/Src/Modules/parameter.c Mon Dec  6 02:26:32 1999
+++ Src/Modules/parameter.c     Sun Dec 12 20:58:25 1999
@@ -1325,6 +1325,83 @@
     }
 }
 
+/* Functions for the jobdirs special parameter. */
+
+/**/
+static char *
+pmjobdir(int job)
+{
+    char *ret;
+
+    ret = dupstring(jobtab[job].pwd);
+    return ret;
+}
+
+/**/
+static HashNode
+getpmjobdir(HashTable ht, char *name)
+{
+    Param pm = NULL;
+    int job;
+
+    HEAPALLOC {
+       pm = (Param) zhalloc(sizeof(struct param));
+       pm->nam = dupstring(name);
+       pm->flags = PM_SCALAR | PM_READONLY;
+       pm->sets.cfn = NULL;
+       pm->gets.cfn = strgetfn;
+       pm->unsetfn = NULL;
+       pm->ct = 0;
+       pm->env = NULL;
+       pm->ename = NULL;
+       pm->old = NULL;
+       pm->level = 0;
+
+       if ((job = atoi(name)) >= 1 && job < MAXJOB &&
+           jobtab[job].stat && jobtab[job].procs &&
+           !(jobtab[job].stat & STAT_NOPRINT))
+           pm->u.str = pmjobdir(job);
+       else {
+           pm->u.str = dupstring("");
+           pm->flags |= PM_UNSET;
+       }
+    } LASTALLOC;
+
+    return (HashNode) pm;
+}
+
+/**/
+static void
+scanpmjobdirs(HashTable ht, ScanFunc func, int flags)
+{
+    struct param pm;
+    int job;
+    char buf[40];
+
+    pm.flags = PM_SCALAR | PM_READONLY;
+    pm.sets.cfn = NULL;
+    pm.gets.cfn = strgetfn;
+    pm.unsetfn = NULL;
+    pm.ct = 0;
+    pm.env = NULL;
+    pm.ename = NULL;
+    pm.old = NULL;
+    pm.level = 0;
+
+    for (job = 1; job < MAXJOB; job++) {
+       if (jobtab[job].stat && jobtab[job].procs &&
+           !(jobtab[job].stat & STAT_NOPRINT)) {
+           sprintf(buf, "%d", job);
+           pm.nam = dupstring(buf);
+           if (func != scancountparams &&
+               ((flags & (SCANPM_WANTVALS|SCANPM_MATCHVAL)) ||
+                !(flags & SCANPM_WANTKEYS)))
+               pm.u.str = pmjobdir(job);
+           func((HashNode) &pm, flags);
+       }
+    }
+}
+
 /* Functions for the nameddirs special parameter. */
 
 /**/
@@ -1833,6 +1910,9 @@
     { "jobstates", PM_READONLY,
       getpmjobstate, scanpmjobstates, hashsetfn,
       NULL, NULL, stdunsetfn, NULL },
+    { "jobdirs", PM_READONLY,
+      getpmjobdir, scanpmjobdirs, hashsetfn,
+      NULL, NULL, stdunsetfn, NULL },
     { "nameddirs", 0,
       getpmnameddir, scanpmnameddirs, setpmnameddirs,
       NULL, NULL, stdunsetfn, NULL },
@@ -1889,8 +1969,7 @@
            if (def->hsetfn)
                def->pm->sets.hfn = def->hsetfn;
        } else {
-           if (!(def->pm = createparam(def->name, def->flags | PM_HIDE |
-                                       PM_REMOVABLE)))
+           if (!(def->pm = createparam(def->name, def->flags | PM_HIDE)))
                return 1;
            def->pm->sets.afn = def->setfn;
            def->pm->gets.afn = def->getfn;
--- old/Src/Modules/parameter.mdd       Wed Nov  3 03:07:27 1999
+++ Src/Modules/parameter.mdd   Fri Dec 10 11:34:25 1999
@@ -1,3 +1,3 @@
-autoparams="parameters commands functions dis_functions funcstack builtins
dis_builtins reswords dis_reswords options modules dirstack history
historywords jobtexts jobstates nameddirs userdirs aliases dis_aliases galiases
dis_galiases"
+autoparams="parameters commands functions dis_functions funcstack builtins
dis_builtins reswords dis_reswords options modules dirstack history
historywords jobtexts jobdirs jobstates nameddirs userdirs aliases dis_aliases
galiases dis_galiases"
 
 objects="parameter.o"
--- old/zsh/Doc/Zsh/mod_parameter.yo    Wed Nov  3 03:07:19 1999
+++ Doc/Zsh/mod_parameter.yo    Fri Dec 10 11:32:09 1999
@@ -110,6 +110,10 @@
 item(tt(historywords))(
 A special array containing the words stored in the history.
 )
+vindex(jobdirs)
+item(tt(jobdirs))(
+This association maps job numbers to the directories from which the job was
started (which may not be the current directory of the job).
+)
 vindex(jobtexts)
 item(tt(jobtexts))(
 This association maps job numbers to the texts of the command lines


__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

Re: PATCH: Add jobdirs association to parameter module

[Peter Stephenson]

Felix Rosencrantz wrote:
> This proposed patch adds a new association to the parameter module
> called jobdirs.  This provides an association with job numbers and the
> directories in which the jobs were started.
> @@ -1889,8 +1969,7 @@
>             if (def->hsetfn)
>                 def->pm->sets.hfn = def->hsetfn;
>         } else {
> -           if (!(def->pm = createparam(def->name, def->flags | PM_HIDE |
> -                                       PM_REMOVABLE)))
> +           if (!(def->pm = createparam(def->name, def->flags | PM_HIDE)))
>                 return 1;
>             def->pm->sets.afn = def->setfn;
>             def->pm->gets.afn = def->getfn;

What is this chunk for?  It's going to mean the parameters are permanently
stuck in the parameter table, even if the module is unloaded, and if the
module is reloaded the parameters won't be.  Sven just fixed this a week or
so ago.

It's a shame we didn't have more specific names for parameters, since the
parameter module is quiet heavily used in completion, so there is quite a
lot of name space pollution.  They stop being special if made local, but
it's still a problem.  The ksh mechanism ${.param.jobdirs} would be
excellent for this.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>