Is PR 412: "ksh: command | read produces null/unset variables" a bug?

Hi,

PR 412
<http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=421>
describes the following problem:

$ echo 1 2 | read a b
$ echo $a $b

Should print
1 2

But as the manual page states, this does not happen with the pd version of ksh.

I tried various incarnations of the bourne shell, korn shell and bash on various OSes and all have the same behavior: the last command is executed in a subshell.

Digging deeper, I found out that the original (AT&T) ksh has changed with respect to this. Versions prior to the 1988 ksh did execute the last command of a pipe in a subshell. Versions from 1988 and newer do execute the last command in the current environment.

See <http://www.kornshell.com/doc/faq.html>, Q13 and M.i. Bolsky and D.G. Korn, The Kornshell Command and Programming Language, 1989, page 190.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related openbsd.org Links advocacy announce bugs ipv6 misc ports ports-changes security-announce smp source-changes tech Request more information about Pantek

Today, a lot of systems (like OpenBSD) use the pd version of ksh, which cleary states it uses a subshell for the last command in a pipe:
<http://web.cs.mun.ca/~michael/pdksh/NOTES> and the manual page.

I do not know how the original SysV sh handles this, but I the Open Group Single Unix Specifications version 2
<http://www.opengroup.org/onlinepubs/007908799/xcu/
chap2.html#tag_001_012> specifies that:

"Some systems have implemented the last stage of a pipeline in the current environment so that commands such as:

command | read foo

set variable foo in the current environment. This extension is allowed, but not required; therefore, a shell programmer should consider a pipeline to be in a subshell environment, but not depend on it."

Version 3 of the Single Unix Specifications
<http://www.opengroup.org/onlinepubs/007904975/utilities/
xcu_chap02.html#tag_02_12> says in the corresponding section:

"Command substitution, commands that are grouped with parentheses, and asynchronous lists shall be executed in a subshell environment. Additionally, each command of a multi-command pipeline is in a subshell environment; as an extension, however, any or all commands in a pipeline may be executed in the current environment. All other commands shall be executed in the current shell environment."

Although the OpenBSD ksh handles pipes differently from more recent versions of the original (AT&T) ksh, I think it makes sense to classify this PR as "not a bug", since the current behavior is allowed by Single Unix and programmers are discouraged to rely on the specific subprocess related behavior of pipes. Furthermore, the current behavior is clearly documented in the man page.

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related openbsd.org Links advocacy announce bugs ipv6 misc ports ports-changes security-announce smp source-changes tech Request more information about Pantek

        -Otto Received on Sat May 24 06:15:45 2003