[PATCH v2] doc/bash.1: fix references to sections not present in builtins.1

2017-01-31 Thread Nikola Forró
When SHELL BUILTIN COMMANDS section from bash.1 is included into
builtins.1, references to other sections in bash.1 become invalid.

This patch adds conditions to make those references refer
to bash(1) in case builtins.1 man page is viewed.

Signed-off-by: Nikola Forró 
---
I've updated the patch to apply cleanly on current master.
Can it be merged?

 doc/bash.1 | 194 ++---
 1 file changed, 161 insertions(+), 33 deletions(-)

diff --git a/doc/bash.1 b/doc/bash.1
index 9a7a384..4d8978c 100644
--- a/doc/bash.1
+++ b/doc/bash.1
@@ -7441,7 +7441,12 @@ apply to ``empty'' command completion; that is, 
completion attempted on a
 blank line.
 .sp 1
 The process of applying these completion specifications when word completion
-is attempted is described above under \fBProgrammable Completion\fP.
+is attempted is described
+.ie \n(zZ=1 \{ in
+.BR bash (1)
+\}
+.el above
+under \fBProgrammable Completion\fP.
 .sp 1
 Other options, if specified, have the following meanings.
 The arguments to the \fB\-G\fP, \fB\-W\fP, and \fB\-X\fP options
@@ -7712,12 +7717,18 @@ to give variables attributes:
 .B \-a
 Each \fIname\fP is an indexed array variable (see
 .B Arrays
-above).
+.ie \n(zZ=1 \{ in
+.BR bash (1)).
+\}
+.el above).
 .TP
 .B \-A
 Each \fIname\fP is an associative array variable (see
 .B Arrays
-above).
+.ie \n(zZ=1 \{ in
+.BR bash (1)).
+\}
+.el above).
 .TP
 .B \-f
 Use function names only.
@@ -7726,7 +7737,11 @@ Use function names only.
 The variable is treated as an integer; arithmetic evaluation (see
 .SM
 .B "ARITHMETIC EVALUATION"
-above) is performed when the variable is assigned a value.
+.ie \n(zZ=1 \{ in
+.BR bash (1))
+\}
+.el above)
+is performed when the variable is assigned a value.
 .TP
 .B \-l
 When the variable is assigned a value, all upper-case characters are
@@ -7789,7 +7804,11 @@ an attempt is made to assign a value to a readonly 
variable,
 an attempt is made to assign a value to an array variable without
 using the compound assignment syntax (see
 .B Arrays
-above), one of the \fInames\fP is not a valid shell variable name,
+.ie \n(zZ=1 \{ in
+.BR bash (1)),
+\}
+.el above),
+one of the \fInames\fP is not a valid shell variable name,
 an attempt is made to turn off readonly status for a readonly variable,
 an attempt is made to turn off array status for an array variable,
 or an attempt is made to display a non-existent function with \fB\-f\fP.
@@ -8546,7 +8565,10 @@ Each
 is an arithmetic expression to be evaluated (see
 .SM
 .B "ARITHMETIC EVALUATION"
-above).
+.ie \n(zZ=1 \{ in
+.BR bash (1)).
+\}
+.el above).
 If the last
 .I arg
 evaluates to 0,
@@ -8846,7 +8868,12 @@ The characters in
 .SM
 .B IFS
 are used to split the line into words using the same rules the shell
-uses for expansion (described above under \fBWord Splitting\fP).
+uses for expansion (described
+.ie \n(zZ=1 \{ in
+.BR bash (1)
+\}
+.el above
+under \fBWord Splitting\fP).
 The backslash character (\fB\e\fP) may be used to remove any special
 meaning for the next character read and for line continuation.
 Options, if supplied, have the following meanings:
@@ -8873,7 +8900,11 @@ is coming from a terminal,
 (see
 .SM
 .B READLINE
-above) is used to obtain the line.
+.ie \n(zZ=1 \{ in
+.BR bash (1))
+\}
+.el above)
+is used to obtain the line.
 Readline uses the current (or default, if line editing was not previously
 active) editing settings.
 .TP
@@ -9059,7 +9090,11 @@ or a \fIcompound command\fP
 (see
 .SM
 .B SHELL GRAMMAR
-above), exits with a non-zero status.
+.ie \n(zZ=1 \{ in
+.BR bash (1)),
+\}
+.el above),
+exits with a non-zero status.
 The shell does not exit if the
 command that fails is part of the command list immediately following a
 .B while
@@ -9087,7 +9122,11 @@ This option applies to the shell environment and each 
subshell environment
 separately (see
 .SM
 .B "COMMAND EXECUTION ENVIRONMENT"
-above), and may cause
+.ie \n(zZ=1 \{ in
+.BR bash (1)),
+\}
+.el above),
+and may cause
 subshells to exit before executing all the commands in the subshell.
 .if t .sp 0.5
 .if n .sp 1
@@ -9119,7 +9158,10 @@ by default for interactive shells on systems that support
 it (see
 .SM
 .B JOB CONTROL
-above).
+.ie \n(zZ=1 \{ in
+.BR bash (1)).
+\}
+.el above).
 All processes run in a separate process group.
 When a background job completes, the shell prints a line
 containing its exit status.
@@ -9170,7 +9212,12 @@ Same as
 .BR \-H .
 .TP 8
 .B history
-Enable command history, as described above under
+Enable command history, as described
+.ie \n(zZ=1 \{ in
+.BR bash (1)
+\}
+.el above
+under
 .SM
 .BR HISTORY .
 This option is on by default in interactive shells.
@@ -9182,7 +9229,10 @@ The effect is as if the shell command
 had been executed
 (see
 .B Shell Variables
-above).
+.ie \n(zZ=1 \{ in
+.BR bash (1)).
+\}
+.el above).
 .TP 8
 .B keyword
 Same as
@@ -9237,7 +9287,11 @@ from the POSIX standard to match the standard (\fIposix 
mode\fP).
 See
 .SM
 .B "SEE AL

Re: history vs. poweroff

2017-01-31 Thread Greg Wooledge
On Tue, Jan 31, 2017 at 10:13:46AM +0800, ? Dan Jacobson wrote:
> However on slower systems, at the end of the day when the user issues
> the poweroff(8) command, all this might not complete, resulting in the
> entire day's of history getting thrown away.

I'm confused.  You don't logout before shutting down your computer?
I would strongly recommend doing so, unless it's an emergency.

If there's an issue with your operating system's shutdown sequence
being unnecessarily brutal to running processes, then you would need to
address that with your OS support people.  It's not bash's place to try
to document the behavior of systemd or upstart or System V init or any
other low-level operating system behaviors.



Re: null pointer deref, segfault

2017-01-31 Thread Bob Proulx
Chet Ramey wrote:
> On 1/24/17 2:07 AM, Brian 'geeknik' Carpenter wrote:
> > Going through some ancient bug reports and I came across
> > https://savannah.gnu.org/support/index.php?108884 which apparently nobody
> > uses anymore.
> > 
> > <<$(()())|>_[$($(<<0)) crashes bash on Debian, Red Hat, FreeBSD, etc.
> 
> It's marked as `Done'.

Since it is both marked as Done and also reported to be resolved in
bash 4.4 then I have closed the ticket.

Bob




Re: history vs. poweroff

2017-01-31 Thread 積丹尼 Dan Jacobson
GW> I'm confused.  You don't logout before shutting down your computer?
GW> I would strongly recommend doing so, unless it's an emergency.

All I know is I want to issue one command to turn off the computer.
If I logged off first, how could I issue that (poweroff(8)) command?

OK you people turn off your computers by pressing buttons. I see. It is
my problem.



Re: history vs. poweroff

2017-01-31 Thread Greg Wooledge
On Wed, Feb 01, 2017 at 03:13:45AM +0800, ? Dan Jacobson wrote:
> GW> I'm confused.  You don't logout before shutting down your computer?
> GW> I would strongly recommend doing so, unless it's an emergency.
> 
> All I know is I want to issue one command to turn off the computer.
> If I logged off first, how could I issue that (poweroff(8)) command?

Log out, log back in as root, issue the command, and accept that root's
(very short) shell history will be lost.

> OK you people turn off your computers by pressing buttons. I see. It is
> my problem.

Yes, most people probably do it this way.



Re: history vs. poweroff

2017-01-31 Thread Greg Wooledge
On Wed, Feb 01, 2017 at 03:31:57AM +0800, ? Dan Jacobson wrote:
> GW> Log out, log back in as root, issue the command, and accept that root's
> GW> (very short) shell history will be lost.
> 
> Well mention that on the man page.
> I.e., the man page should address the paradox of saving a complete
> history vs. being able to turn off one's computer.

I do not believe that it is bash(1)'s job to teach basic Unix system
administration.



Re: history vs. poweroff

2017-01-31 Thread 積丹尼 Dan Jacobson
GW> Log out, log back in as root, issue the command, and accept that root's
GW> (very short) shell history will be lost.

Well mention that on the man page.
I.e., the man page should address the paradox of saving a complete
history vs. being able to turn off one's computer.



Re: history vs. poweroff

2017-01-31 Thread Hankins, Jonathan
This is discussed a bit here, along with a common pain point for
tmux/screen users:

https://news.ycombinator.com/item?id=10164053

zsh gets around both issues with a variety of options to have a synchronous
and interleaved history file.

-Jonathan Hankins

On Tue, Jan 31, 2017 at 1:40 PM Greg Wooledge  wrote:

> On Wed, Feb 01, 2017 at 03:31:57AM +0800, ? Dan Jacobson wrote:
> > GW> Log out, log back in as root, issue the command, and accept that
> root's
> > GW> (very short) shell history will be lost.
> >
> > Well mention that on the man page.
> > I.e., the man page should address the paradox of saving a complete
> > history vs. being able to turn off one's computer.
>
> I do not believe that it is bash(1)'s job to teach basic Unix system
> administration.
>
>

-- 
This e-mail is intended only for the recipient and may contain confidential 
or proprietary information. If you are not the intended recipient, the 
review, distribution, duplication or retention of this message and its 
attachments is prohibited. Please notify the sender of this error 
immediately by reply e-mail, and permanently delete this message and its 
attachments in any form in which they may have been preserved.