(In reply to Karl Hastings from comment #0)
> The upstream bash fix is using %% for the fix (perhaps for this reason?)...
> http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-027

As far as I can tell, this makes no difference.

$ unset a%%
ksh: unset: a%%: invalid variable name

Why is ksh exposing variables through 'set' that it then will not allow to be unset? That sounds like a problem in ksh that existed prior to the bash fix.  Bash intentionally refuses to expose any inherited name/value pair from the environment through 'set' if the name does not match what bash is able to handle.

As proof that bash refuses to expose garbage through 'set':

$ env 'a|b=c' bash -c 'set | grep a.b'
BASH_EXECUTION_STRING='set | grep a.b'
$ env 'a|b=c' ksh -c 'set | grep a.b'
a|b=c

Removed Regression keyword - this never worked in ksh.

This is not a bug, as it's not a proper variable from ksh's point of view.

Excerpt from POSIX (http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap08.html):

Environment variable names used by the utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001 consist solely of uppercase letters, digits, and the '_' (underscore) from the characters defined in Portable Character Set and do not begin with a digit. Other characters may be permitted by an implementation; applications shall tolerate the presence of such names.

And tolerate it's existence is exactly what ksh does, nothing more, nothing less.

Anyway, I will ask upstream if they want to change this.

PS: There won't be any visible change anyway. As per posix request, those variables are tolerated, but as they are not recognized by ksh, you won't be able to print them, change them or unset them. Even if they won't be listed in set's output, they will still be passed to children.

(In reply to Michal Hlavinka from comment #6)
> This is not a bug, as it's not a proper variable from ksh's point of view.

It seems to be a bug to me to expose something via a shell built-in that you will not then allow to be undone using the reverse shell built-in, e.g. unset. The user visible change from suppressing the output from 'set' would be that something like the following would work and not cause a shell script to bomb.

bash$ ksh
ksh$  envkeep="^PATH|^LOGNAME|^PS1"
ksh$ export envkeep
ksh$ set -e
ksh$  for var in $(set | egrep -v $envkeep |  awk -F= '{print $1}') ; do echo $var ; unset $var ; done
_
BASH_FUNC_a()
ksh: unset: BASH_FUNC_a(): invalid variable name
bash$

(In reply to Jon Stanley from comment #8)
> The user visible change from suppressing the output from 'set' would
> be that something like the following would work and not cause a shell script
> to bomb.

Of course, in this example BASH_FUNC_a() would continue to be exported to children, and that's fine and expected. If that's what you meant by no user-visible change, then I agree with that :)

The "bomb" is a little strong wording here imho :)

The fact is that such variable would stay in the environment either way.

So you can't expect that the example you've pasted would clear everything. Which is equal to unset failure (for whatever reason). If you use something like 'env' instead of 'set' you would get that unwanted variable even in case that set would change its behavior. So, from my point of view that change would not achieve much (I would say anything at all).

Anyway, the patch itself is not a problem, it'd be really simple, but upstream's opinion is what matters here - whether that patch would be accepted or not. I've asked them already. Waiting for answer. (Beware, it can take a while.)

dash has a similar problem.  By the way, POSIX further requires that 'set' used without parameters shall have the following property:
"The output shall be suitable for reinput to the shell, setting or resetting, as far as possible, the variables that are currently set;"

which means 'eval $(set)' should be safe; but trying to eval "a|b=''" tries to invoke the command named 'a', which is NOT safe.

Actually, it looks to me like this *is* a regression in ksh.

From ksh-20100621-19.el6_4.3.x86_64:

$ set|fgrep BASH_FUNC
BASH_FUNC_module()=$'() {  eval `/usr/bin/modulecmd bash $*`\n}'

From ksh-20100621-6.el6.x86_64 on the same box (I just rpm2cpio'ed the rpm and ran bin/ksh93):

$ set | fgrep BASH_FUNC
$ exit

Also, Eric's 'a|b' test above in comment #5 also delivers the expected result. The only reason I noticed that was I was scratching my head as to why I couldn't reproduce on another, older box.

Seems upstream agrees with fixing this.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1450.html