Re: The behavior of `jobs -p` is definitely, without a doubt, a bug

2016-05-18 Thread Geoff Nixon

 On Wed, 18 May 2016 14:03:59 -0700 Harald van Dijk  
wrote  
> Hi, 
> 
> On 13/05/16 04:06, Geoff Nixon wrote: 
> > Let me start with a couple of corrections to that previous thread. 
> > 
> > 
> > 1. The line: jobs -p > /tmp/pids # this works 
> > 
> > Does *not*, in fact, work. Meaning there is *no* instance in which it 
> works. 
> 
> This should work just fine. Do you have a short test script where it 
> does not work for you? 

Sorry, you are absolutely right, this does *does* work. I could have sworn it
didn't when I tried before, but perhaps I was conflating it with something like
`jobs -p | tee /tmp/pids`, which doesn't work.

> > But they do not. The present behavior is to simply dump the process 
> IDs directly 
> > to the TTY, it seems. Which is not, at all, what the specification 
> dictates. 
> 
> That's not what happens. While there are a lot of contexts where you can 
> reasonably argue that jobs -p should output PIDs to stdout and where 
> dash doesn't, when it doesn't, it doesn't output anything. It doesn't 
> somehow start dumping PIDs elsewhere. 

Indeed, you are correct again; my mistake. Due to my incorrect conclusion
(that `jobs -p > /tmp/pids` fails), along with the fact that the
output of `jobs` fails in a pipeline, I drew the incorrect assumption that the
output of `jobs` *never* was sent to stdout. Apologies.

> > In review, a subshell inherits a duplicate of the parent environment, 
> which 
> > includes the asynchronous list of background tasks, and the shell 
> environment is 
> > *explicitly* not to be changed, unless otherwise specified. Which it 
> is not. 
> 
> This is the main point of your message...

Yes, that is the core of my argument.

>  and it's reasonable, but it's 
> not clearly right or clearly wrong. ksh and mksh agree with your 
> interpretation. bash comes across as inconsistent (but there may be a 
> logic that's simply not immediately obvious). dash disagrees with your 
> interpretation, and zsh appears to disagree as well. 
> 
> sleep 1 & 
> echo $(jobs -p) 
> (jobs -p) 
> jobs -p 
> 
> ksh and mksh print the PID thrice. 
> bash prints the PID twice, it omits it in (jobs -p). 
> dash prints the PID once. 
> zsh is a bit unclear since its -p option has a more limited effect, but 
> appears to work like dash, only printing one (non-empty) line of output. 

Oops! I somehow forgot to include the results of my tests with other
shells. You are correct, and in addition to what you mention above: pdksh, oksh,
and yash all also exhibit the "thrice" behavior, while busybox's ash
(at least my old 1.20.0 version) exhibits the same behavior as bash -- that is,
`(jobs -p)` does not work, but the others do.

I don't think zsh should be considered here, since it is explicitly
documented that `jobs -p` does something entirely different (process groups):
http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Commands.html

> Your logic relies on the list of jobs being a property of the 
> environment. That's a reasonable interpretation, but not the only one. 
> Another interpretation is the environment that started a job being a 
> property of the job. In that interpretation, that information is not 
> part of the environment and hence not copied when duplicating the 
> environment.

While it's not really worth bickering about, I do in fact believe my
"interpretation" is *specified*. It's not on the `jobs` page, but in
"Shell Command Language", where it dictates that the environment includes:
" - Process IDs of the last commands in asynchronous lists known to this
shell environment".

> And it wouldn't be the first time that the "Application 
> Usage" section of a utility contradicts the normative requirements. 

True ;)

> That said, it does seem extremely likely that trivial examples such as 
> echo $(jobs -p) 
> are intended to work the way you expect, regardless of whether the 
> standard manages to state the requirements correctly. Other cases are 
> not so clear, not when looking at the standard, and also not when 
> looking at what other shells do. This makes it difficult to come up with 
> a complete fix.

Again, speaking for myself, I think the standard is actually pretty clear here.
Referring again to the "Shell Command Language" page:

The format for grouping commands is as follows:
(compound-list)
Execute compound-list in a *subshell environment*...

That is, I believe the behavior of bash and busybox does not fully adhere to the
the standard; pdksh, ksh93, mksh, yash, and oksh are compliant.

> Personally, I feel that even if your interpretation is wrong (and I'm 
> not saying it is), it is still less undesirable than dash's current 
> behaviour. If there's a reasonable chance a patch for it would be 
> accepted, I'd be willing to try to make it so. 

Agreed. I'd very much like to see a patch for this; and I certainly hope it
would be accepted!

At the *very, very least*, I think the fact that `jobs -p` can have 

Re: man fixes

2016-05-18 Thread Harald van Dijk

Hi,

On 18/05/16 11:07, Svyatoslav Mishyn wrote:

just found some typos and mdocml warnings.


iff is not a typo. It's a fairly commonly used short form for "if and 
only if". Perhaps that could be made clearer somehow.


Cheers,
Harald van Dijk
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


man fixes

2016-05-18 Thread Svyatoslav Mishyn
Hello,

just found some typos and mdocml warnings.


-- 
https://www.juef.tk/
>From 745af83b0953eb16ab31ed67f26808665576a46e Mon Sep 17 00:00:00 2001
From: Svyatoslav Mishyn 
Date: Fri, 13 May 2016 09:47:54 +0300
Subject: [PATCH 1/2] man: fix mandoc warnings

They are:
 * prologue macros out of order: Dt after Os
 * skipping paragraph macro: Pp before Bd
 * whitespace at end of input line
 * skipping empty macro: Cm
 * skipping paragraph macro: Pp before It
 * sections out of conventional order: Sh ENVIRONMENT
 * skipping -width argument: Bl -item
---
 src/dash.1 | 41 ++---
 1 file changed, 18 insertions(+), 23 deletions(-)

diff --git a/src/dash.1 b/src/dash.1
index 832eae7..57e731a 100644
--- a/src/dash.1
+++ b/src/dash.1
@@ -32,9 +32,9 @@
 .\"
 .\"@(#)sh.18.6 (Berkeley) 5/4/95
 .\"
-.Dd January 19, 2003
-.Os
+.Dd May 13, 2016
 .Dt DASH 1
+.Os
 .Sh NAME
 .Nm dash
 .Nd command interpreter (shell)
@@ -694,7 +694,6 @@ Builtin commands grouped into a (list) will not affect the 
current shell.
 The second form does not fork another shell so is slightly more efficient.
 Grouping commands together this way allows you to redirect
 their output as though they were one program:
-.Pp
 .Bd -literal -offset indent
 { printf \*q hello \*q ; printf \*q world\\n" ; } \*[Gt] greeting
 .Ed
@@ -1183,7 +1182,7 @@ option turns off the effect of any preceding
 .Fl P
 options.
 .It Xo echo Op Fl n
-.Ar args... 
+.Ar args...
 .Xc
 Print the arguments on the standard output, separated by spaces.
 Unless the
@@ -1417,7 +1416,6 @@ and
 and the option
 .Op c ,
 which requires an argument.
-.Pp
 .Bd -literal -offset indent
 while getopts abc: f
 do
@@ -1431,7 +1429,6 @@ shift `expr $OPTIND - 1`
 .Ed
 .Pp
 This code will accept any of the following as equivalent:
-.Pp
 .Bd -literal -offset indent
 cmd \-acarg file file
 cmd \-a \-c arg file file
@@ -1522,7 +1519,6 @@ variables.
 With the
 .Fl p
 option specified the output will be formatted suitably for non-interactive use.
-.Pp
 .It Xo printf Ar format
 .Op Ar arguments  ...
 .Xc
@@ -1814,7 +1810,7 @@ If n is greater than the number of positional parameters,
 .Ic shift
 will issue an error message, and exit with return status 2.
 .It test Ar expression
-.It \&[ Ar expression Cm ]
+.It \&[ Ar expression No \&]
 The
 .Ic test
 utility evaluates the expression and, if it evaluates
@@ -2176,7 +2172,6 @@ the current limit is displayed.
 Limits of an arbitrary process can be displayed or set using the
 .Xr sysctl 8
 utility.
-.Pp
 .It umask Op Ar mask
 Set the value of umask (see
 .Xr umask 2 )
@@ -2233,15 +2228,6 @@ will throw you into command VI command mode.
 Hitting
 .Aq return
 while in command mode will pass the line to the shell.
-.Sh EXIT STATUS
-Errors that are detected by the shell, such as a syntax error, will cause the
-shell to exit with a non-zero exit status.
-If the shell is not an
-interactive shell, the execution of the shell file will be aborted.
-Otherwise
-the shell will return the exit status of the last command executed, or
-if the exit builtin is used with a numeric argument, it will return the
-argument.
 .Sh ENVIRONMENT
 .Bl -tag -width MAILCHECK
 .It Ev HOME
@@ -2318,12 +2304,21 @@ command.
 The process ID of the parent process of the shell.
 .El
 .Sh FILES
-.Bl -item -width HOMEprofile
-.It
-.Pa $HOME/.profile
-.It
-.Pa /etc/profile
+.Bl -tag -width "$HOME/.profileXX" -compact
+.It Pa $HOME/.profile
+User's login profile.
+.It Pa /etc/profile
+System login profile.
 .El
+.Sh EXIT STATUS
+Errors that are detected by the shell, such as a syntax error, will cause the
+shell to exit with a non-zero exit status.
+If the shell is not an
+interactive shell, the execution of the shell file will be aborted.
+Otherwise
+the shell will return the exit status of the last command executed, or
+if the exit builtin is used with a numeric argument, it will return the
+argument.
 .Sh SEE ALSO
 .Xr csh 1 ,
 .Xr echo 1 ,
-- 
2.8.0

>From 8a8a9d25a3a784c225d9fdb99c1b1eec5604c953 Mon Sep 17 00:00:00 2001
From: Svyatoslav Mishyn 
Date: Fri, 13 May 2016 11:01:17 +0300
Subject: [PATCH 2/2] man: fix a typo

iff => if
---
 src/dash.1 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/dash.1 b/src/dash.1
index 57e731a..9ef14a8 100644
--- a/src/dash.1
+++ b/src/dash.1
@@ -606,10 +606,10 @@ and
 .Dq ||
 are AND-OR list operators.
 .Dq &&
-executes the first command, and then executes the second command iff the
+executes the first command, and then executes the second command if the
 exit status of the first command is zero.
 .Dq ||
-is similar, but executes the second command iff the exit status of the first
+is similar, but executes the second command if the exit status of the first
 command is nonzero.
 .Dq &&
 and
-- 
2.8.0