[patch] 3.1: man page corrections
When viewing the bash man page with 'man bash' in a locale that
supports UTF-8 (for example), the single-quote character "'" doesn't
necessarily display as we want. For a literal single-quote character,
"\(aq" is needed in the groff input.
Original bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177051
This patch is necessary in order to enable cut-and-pasting of examples
etc.
Tim.
*/
--- bash-3.1/doc/bash.1.aq 2006-01-06 16:40:40.0 +
+++ bash-3.1/doc/bash.1 2006-01-06 16:46:36.0 +
@@ -977,7 +977,7 @@
.B PARAMETERS
below).
.PP
-Words of the form \fB$\fP'\fIstring\fP' are treated specially. The
+Words of the form \fB$\fP\(aq\fIstring\fP\(aq are treated specially. The
word expands to \fIstring\fP, with backslash-escaped characters replaced
as specified by the ANSI C standard. Backslash escape sequences, if
present, are decoded as follows:
@@ -1011,7 +1011,7 @@
.B \e\e
backslash
.TP
-.B \e'
+.B \e\(aq
single quote
.TP
.B \e\fInnn\fP
@@ -1845,7 +1845,7 @@
Example:
.RS
.PP
-\fBMAILPATH\fP='/var/mail/bfox?"You have mail":~/shell\-mail?"$_ has mail!"'
+\fBMAILPATH\fP=\(aq/var/mail/bfox?"You have mail":~/shell\-mail?"$_ has
mail!"\(aq
.PP
.B Bash
supplies a default value for this variable, but the location of the user
@@ -1979,7 +1979,7 @@
included.
.IP
If this variable is not set, \fBbash\fP acts as if it had the
-value \fB$'\enreal\et%3lR\enuser\et%3lU\ensys\t%3lS'\fP.
+value \fB$\(aq\enreal\et%3lR\enuser\et%3lU\ensys\t%3lS\(aq\fP.
If the value is null, no timing information is displayed.
A trailing newline is added when the format string is displayed.
.TP
@@ -2708,7 +2708,7 @@
.B IFS
is null, no word splitting occurs.
.PP
-Explicit null arguments (\^\f3"\^"\fP or \^\f3'\^'\fP\^) are retained.
+Explicit null arguments (\^\f3"\^"\fP or \^\f3\(aq\^\(aq\fP\^) are retained.
Unquoted implicit null arguments, resulting from the expansion of
parameters that have no values, are removed.
If a parameter with no value is expanded within double quotes, a
@@ -2930,7 +2930,7 @@
After the preceding expansions, all unquoted occurrences of the
characters
.BR \e ,
-.BR ' ,
+.BR \(aq ,
and \^\f3"\fP\^ that did not result from one of the above
expansions are removed.
.SH REDIRECTION
@@ -4495,8 +4495,8 @@
.B \e"
literal "
.TP
-.B \e'
-literal '
+.B \e\(aq
+literal \(aq
.RE
.PD
.PP
@@ -4544,7 +4544,7 @@
Unquoted text is assumed to be a function name.
In the macro body, the backslash escapes described above are expanded.
Backslash will quote any other character in the macro text,
-including " and '.
+including " and \(aq.
.PP
.B Bash
allows the current readline key bindings to be displayed or modified
@@ -7320,7 +7320,7 @@
In addition to the standard \fIprintf\fP(1) formats, \fB%b\fP causes
\fBprintf\fP to expand backslash escape sequences in the corresponding
\fIargument\fP (except that \fB\ec\fP terminates output, backslashes in
-\fB\e'\fP, \fB\e"\fP, and \fB\e?\fP are not removed, and octal escapes
+\fB\e\(aq\fP, \fB\e"\fP, and \fB\e?\fP are not removed, and octal escapes
beginning with \fB\e0\fP may contain up to four digits),
and \fB%q\fP causes \fBprintf\fP to output the corresponding
\fIargument\fP in a format that can be reused as shell input.
@@ -8037,7 +8037,7 @@
\fBPathname Expansion\fP are enabled.
.TP 8
.B extquote
-If set, \fB$\fP'\fIstring\fP' and \fB$\fP"\fIstring\fP" quoting is
+If set, \fB$\fP\(aq\fIstring\fP\(aq and \fB$\fP"\fIstring\fP" quoting is
performed within \fB${\fP\fIparameter\fP\fB}\fP expansions
enclosed in double quotes. This option is enabled by default.
.TP 8
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
bash-3.1.1: source does not work in conjunction with process substitution
Hi,
The "source" builtin does not work in conjunction with process
substitution:
$ bash -ec 'cat <(echo echo 1)'
echo 1
$ bash -ec '. <(echo echo 1)'
$ strace -e trace=file,desc bash -ec '. <(echo echo 1)'
[...]
stat64("/dev/fd/63", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
open("/dev/fd/63", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
read(3, "", 0) = 0
close(3)= 0
Original bug report:
https://bugzilla.altlinux.org/show_bug.cgi?id=7475
--
ldv
pgpul0xh6XyNY.pgp
Description: PGP signature
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
bash-3.1.1: unable to feed "trap -p" output into a pipe
Hi, A "trap -p" output doesn't feed into a pipe: $ trap -p $ trap "echo ..." EXIT $ trap -p EXIT trap -- 'echo ...' EXIT $ trap -p EXIT |wc -l 0 Original bug report: https://bugzilla.altlinux.org/show_bug.cgi?id=7610 -- ldv pgpPAM07UBzQ6.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Conditional expression problem: both "-a file" and "! -a file" return true
Hi.
Excuse me if I've got things somewhat confused here (I'm a complete Unix
newbie), but I've found what I think is a bug.
If I create a file using:
[EMAIL PROTECTED]:~$ touch testFile
and then run the following two lines, I get conflicting results:
[EMAIL PROTECTED]:~$ [ -a testFile ] && echo true || echo false
true
[EMAIL PROTECTED]:~$ [ ! -a testFile ] && echo true || echo false
true
Like I said, I'm only a Unix newbie, so I'm really unsure whether this is a
problem, or whether it's expected behaviour, but in my searching for
information, I found:
http://www.faqs.org/faqs/unix-faq/shell/bash/
and point E1 ("Why is the bash builtin `test' slightly different from
/bin/test?") seems to indicate that the two results should be the "opposite"
of each other.
By the way, here's some information created by running bashbug on my machine:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib
-g -O2
uname output: Linux machine 2.6.12-10-686 #1 Thu Dec 22 11:55:07 UTC 2005
i686 GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 3.0
Patch Level: 16
Release Status: release
Anyway, I'd really appreciate any comment from anyone who can shed light on
this...
Thank you,
Dave
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
I wish hash -r (or something like it) would happen automaticly
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 uname output: Linux greenwood 2.6.8-1-k7 #1 Thu Nov 25 04:13:37 UTC 2004 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.1 Patch Level: 0 Release Status: release Description: I sometimes forget to run hash -r after sticking something new in my path, and get confused. One thing I've always been hazy on is whether there is a way in unix to connect to a 'dir-contents-changed' signal or the like, but if so I would much prefer my interactive shells at least to automaticly notice new binaries as they show up in $PATH. Its especially confusing because the 'which' command, which is the first one people learn to find out which binaries they are running. Or maybe there is already such functionality? Repeat-By: I'm sure the maintainers are familiar with how this happens. Fix: Not sure the best way, but as I said above an option to do this, with a few refs to it in appropriate places in the documentation, would be most welcome, and I think it would be good if it were the default behavior. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
