jobs -Z will destory environ variables

jobs -Z will destory environ variables

[Han Pingtian]

Hi,

Looks like "jobs -Z new_name" will destory the environ of current zsh.
After running of it, some programs like "less", "vim" won't work
correctly:

% ls | less
WARNING: terminal is not fully functional
-  (press RETURN)


There is no setproctitle() available on linux, bug there is a prctl()
which can set proc name to a string which length not big than 16 bytes.
I wondering if we can use it instead of modifying argv directly.

Thanks.

Re: jobs -Z will destory environ variables

[Bart Schaefer]

On Nov 17,  4:56pm, Han Pingtian wrote:
} 
} Looks like "jobs -Z new_name" will destory the environ of current zsh.

Hmm, this is a new bug.  It works (or at least doesn't destroy the
environment) in 4.2.x even on hosts where it fails in 5.0.

Which means it's not directly related to the hackzero code in bin_fg,
but must instead be related to changes in the handling of the environ
strings themselves -- probably the introduction of setenv / unsetenv
for environment management where previously it was always copied to
new memory space.

So what we need is likely this:

Index: Src/jobs.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/jobs.c,v
retrieving revision 1.92
diff -u -r1.92 jobs.c
--- Src/jobs.c  11 Oct 2012 16:36:14 -0000      1.92
+++ Src/jobs.c  17 Nov 2012 17:35:45 -0000
@@ -1743,12 +1743,14 @@
            goto done;
        p = strchr(q, 0);
     }
+#if !defined(HAVE_PUTENV) && !defined(USE_SET_UNSET_ENV)
     for(; *envp; envp++) {
        q = *envp;
        if(q != p+1)
            goto done;
        p = strchr(q, 0);
     }
+#endif
     done:
     hackspace = p - hackzero;
 #endif

Re: jobs -Z will destory environ variables

[Han Pingtian]

On Sat, Nov 17, 2012 at 09:36:46AM -0800, Bart Schaefer wrote:
> On Nov 17,  4:56pm, Han Pingtian wrote:
> } 
> } Looks like "jobs -Z new_name" will destory the environ of current zsh.
> 
> Hmm, this is a new bug.  It works (or at least doesn't destroy the
> environment) in 4.2.x even on hosts where it fails in 5.0.
> 
> Which means it's not directly related to the hackzero code in bin_fg,
> but must instead be related to changes in the handling of the environ
> strings themselves -- probably the introduction of setenv / unsetenv
> for environment management where previously it was always copied to
> new memory space.
> 
> So what we need is likely this:
> 
> Index: Src/jobs.c
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Src/jobs.c,v
> retrieving revision 1.92
> diff -u -r1.92 jobs.c
> --- Src/jobs.c  11 Oct 2012 16:36:14 -0000      1.92
> +++ Src/jobs.c  17 Nov 2012 17:35:45 -0000
> @@ -1743,12 +1743,14 @@
>             goto done;
>         p = strchr(q, 0);
>      }
> +#if !defined(HAVE_PUTENV) && !defined(USE_SET_UNSET_ENV)
>      for(; *envp; envp++) {
>         q = *envp;
>         if(q != p+1)
>             goto done;
>         p = strchr(q, 0);
>      }
> +#endif
>      done:
>      hackspace = p - hackzero;
>  #endif
This patch works just fine. Thanks a lot.

Re: jobs -Z will destory environ variables

[Bart Schaefer]

On Nov 18, 10:31am, Han Pingtian wrote:
} Subject: Re: jobs -Z will destory environ variables
}
} On Sat, Nov 17, 2012 at 09:36:46AM -0800, Bart Schaefer wrote:
} > 
} > Which means it's not directly related to the hackzero code in bin_fg,
} > but must instead be related to changes in the handling of the environ
} > strings themselves -- probably the introduction of setenv / unsetenv
} > for environment management where previously it was always copied to
} > new memory space.
} 
} This patch works just fine. Thanks a lot.

Thanks for confirming.

Point of interest -- I looked up the original code for setproctitle(),
which the BSD manual page says was stolen from sendmail 8.7.3 (well,
strictly speaking I looked at 8.13 which I happen to have handy), and
found that sm_setproctitle() is doing exactly the same thing as zsh's
"hackzero" trick, including shifting the environment to new memory so
there's more space for the process title to work with.

8.7.3 is from 1995, so I'm pretty sure zsh's use of this trick predates
that in sendmail by 2 or 3 years.  I wonder where it came from before
that ... or if sendmail got it from zsh.

Re: jobs -Z will destory environ variables

[Valodim Skywalker]

[-- Attachment #1: Type: text/plain, Size: 232 bytes --]

This is still not working correctly. On 5.0.1, it seems to be limited to
six characters.

% echo $ZSH_VERSION
5.0.1
% jobs -Z 'sortalongname'
% ps $$
  PID TTY      STAT   TIME COMMAND
  21082 pts/3    S      0:00 sortal

 - V

:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: jobs -Z will destory environ variables

[Bart Schaefer]

On Dec 21,  2:35pm, Valodim Skywalker wrote:
} 
} This is still not working correctly. On 5.0.1, it seems to be limited to
} six characters.

It's working as well as it can without stomping the environment.

Try this:

% zsh -is these arguments are the space available for jobs -Z to write
% jobs -Z 123456789a123456789b123456789c123456789d123456789e123456789f


As I said before, jobs -Z has always been a hack.  Maybe the thing to
do is to *both* hack the argv/envp space *and* call prctl() when it is
available.

Re: jobs -Z will destory environ variables

[Valodim Skywalker]

[-- Attachment #1: Type: text/plain, Size: 321 bytes --]

Bart Schaefer(schaefer@brasslantern.com)@Fri, Dec 21, 2012 at 07:56:21AM -0800:
> As I said before, jobs -Z has always been a hack.  Maybe the thing to
> do is to *both* hack the argv/envp space *and* call prctl() when it is
> available.
> 

Either way is fine I guess, as long as it's in the docs.

 - V

:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: jobs -Z will destory environ variables

[Valodim Skywalker]

[-- Attachment #1: Type: text/plain, Size: 138 bytes --]

Ugh. I only looked at the docs after I wrote my last mail and noticed it
says "truncated to fit". Never mind that last mail :)

 - V

:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]