Re: In the bash man page the entry for the 'read' command has two spaces after it instead of one.

[Bob Proulx]

Andreas Schwab wrote:
> Ángel González writes:
> > entering  «/^ *read⤶» may be easier to type (and remember)
> 
> It won't match, though.

It matches fine for me.  Although I suggest adding the square bracket
so as to avoid the other false positives as long as one knows that
read has options documented.  This works.

  /^  *read  *\[

Bob

Multi-line bash strings that end in ! improperly treated as event designator

[Lane Schwartz]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCO$
uname output: Linux cl 3.13.0-61-generic #100-Ubuntu SMP Wed Jul 29
11:21:34 UTC 2015 x86_64 $
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.3
Patch Level: 11
Release Status: release

Description:
Per the Bash Reference Manual, section 9.3.1 "Event Designators", a
bare exclamation point should be treated as "Start[ing] a history
substitution, except when followed by a space, tab, the end of line, '=',
or '('". Bash fails to respect this behavior when a multi-line string ends
in a bare exclamation point. In such cases, the exclamation point is in
fact followed by the end of line. Despite this fact, Bash treats the
exclamation point as the start of a history substitution. In contrast, this
errant behavior is not observed when a bare exclamation point terminates a
single-line string.

Repeat-By:
$ echo "He didn't fall? Inconceivable!"

$ echo "He didn't fall?
> Inconceivable!"

Re: [ PATCH 1/1 ] l10n: zh_{CN,TW} localization update for bash 4.3

[Eric Blake]

On 08/21/2015 11:58 AM, Chet Ramey wrote:

>>> Bash bugs should be reported using `bashbug'.  That's why it's listed
>>> in the help output.
> 
>> Where?
> 
> Run bash --help to get it, like the coding standards say.

I did.

> $ ./bash --help
> GNU bash, version 4.3.42(28)-release-(x86_64-apple-darwin12.5.0)


> That last line has been in the --help output forever.

Then I see what happened - my downstream distro decided to patch that
line OUT of bash --help output :(

I guess they thought that reporting bugs through downstream bug database
is better, but then they should have _replaced_ the upstream line rather
than _removing_ it. I'm filing a downstream bug.

https://bugzilla.redhat.com/show_bug.cgi?id=1255886

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [ PATCH 1/1 ] l10n: zh_{CN,TW} localization update for bash 4.3

[Chet Ramey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/21/15 2:45 PM, Eric Blake wrote:
> On 08/21/2015 08:22 AM, Chet Ramey wrote:
>> On 8/21/15 10:06 AM, Eric Blake wrote:
>>
>>> GNU Coding Standards recommend that '$program --help' should list the
>>> preferred bug-reporting address, and that the corresponding .po file
>>> should then expand that information to ALSO list the preferred address
>>> for reporting translation bugs in that .po file.
>>
>> Bash bugs should be reported using `bashbug'.  That's why it's listed
>> in the help output.
> 
> Where?

Run bash --help to get it, like the coding standards say.

https://www.gnu.org/prep/standards/standards.html#g_t_002d_002dhelp

> 
> $ bash --version | head -n1
> GNU bash, version 4.3.39(1)-release (x86_64-redhat-linux-gnu)
> $ bash --help | grep bug
>   --debug
>   --debugger

Please.

$ ./bash --help
GNU bash, version 4.3.42(28)-release-(x86_64-apple-darwin12.5.0)
Usage:  ./bash [GNU long option] [option] ...
./bash [GNU long option] [option] script-file ...
GNU long options:
--debug
--debugger
--dump-po-strings
--dump-strings
--help
--init-file
--login
--noediting
--noprofile
--norc
--posix
--rcfile
--restricted
--verbose
--version
Shell options:
-ilrsD or -c command or -O shopt_option (invocation only)
-abefhkmnptuvxBCHP or -o option
Type `./bash -c "help set"' for more information about shell options.
Type `./bash -c help' for more information about shell builtin commands.
Use the `bashbug' command to report bugs.

That last line has been in the --help output forever.
- -- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlXXdNMACgkQu1hp8GTqdKsFswCeJkKzwIOvTrtUXMwbCYvQndCK
X4wAnReLcyuhugQ2qrjHjH12o00dcEi6
=6U6r
-END PGP SIGNATURE-

Re: [ PATCH 1/1 ] l10n: zh_{CN,TW} localization update for bash 4.3

[Eric Blake]

On 08/21/2015 08:22 AM, Chet Ramey wrote:
> On 8/21/15 10:06 AM, Eric Blake wrote:
> 
>> GNU Coding Standards recommend that '$program --help' should list the
>> preferred bug-reporting address, and that the corresponding .po file
>> should then expand that information to ALSO list the preferred address
>> for reporting translation bugs in that .po file.
> 
> Bash bugs should be reported using `bashbug'.  That's why it's listed
> in the help output.

Where?

$ bash --version | head -n1
GNU bash, version 4.3.39(1)-release (x86_64-redhat-linux-gnu)
$ bash --help | grep bug
--debug
--debugger

Oh, I see. On the devel branch of bash.git:

$ ./bash --help | grep bug
--debug
--debugger
Use the `bashbug' command to report bugs.

So in 4.4, you have indeed fixed the bug of not being compliant to GNU
Coding Standards recommendation, and translators should then be prodded
to fix their translations of this new line to include their translation
bug reporting instructions.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Bug-readline] Fwd: Re: Feature proposal/request: input line highlighting

[Chet Ramey]

> >> On 11 Jun 2015 18:10, Thomas Wolff wrote:
> >> > as opposed to having a fancy colored prompt, I would like to be 
> >> able to
> >> > set up coloring of the whole bash command input line (but not the
> >> > following command output). This could be achieved by adding a variable
> >> > like "AFTERPROMPT_COMMAND" which is executed after a prompt line is
> >> > completed (or "PS9" which is output after a prompt line is completed).
> >> > It could even be a nice idea to configure this behavior separately for
> >> > bash and readline, so the users have a choice whether to color just
> >> > command input, readline-handled program input, or both.
> >> > I would appreciate this feature, and maybe even supply a patch if I 
> >> had
> >> > a clue where to hook it in...
> >>
> >> this is already doable -- leave the end of PS1 enabling color.
> >> PS1='\[\e[0;33m\]$ \[\e[34;1m\]'
> >>
> >> this will color the input buffer blue

> thanks for your response, but that's not what I meant because the output 
> of the invoked programs will stay blue. I'll illustrate my idea with the 
> attached screenshot, showing a few possible options.

So the problem is reduced to restoring the normal color before any invoked
program has a chance to produce output.

There are a couple of ways to do it using bash-specific functionality.
Using only readline is hard because readline doesn't really have anything
that just prints text to the terminal -- it's designed to manage an input
buffer.

This bash-specific one is easiest to describe.

1.  Append the character sequence that changes the terminal to the desired
color to PS1, making sure to bracket it correctly:

PS1='\u@\h\$ \[\e1;34m\]'

2.  Define a DEBUG trap that will restore the default terminal color settings
before invoking a command:

trap -- 'printf "\e[0m"' DEBUG

There are ways to make this work using `bind -x' and readline's key binding
to macros, but that is much more complicated.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: In the bash man page the entry for the 'read' command has two spaces after it instead of one.

[Andreas Schwab]

Ángel González  writes:

> entering  «/^ *read⤶» may be easier to type (and remember)

It won't match, though.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: In the bash man page the entry for the 'read' command has two spaces after it instead of one.

[Ángel González]

On Andreas Schwab wrote:
> Try searching for '^ {7}read ' instead.  There are commands that 
> aren't followed by options in the description.

entering  «/^ *read⤶» may be easier to type (and remember)

Re: -e does not take effects in subshell

[Ángel González]

On jue, 20-08-2015 a las 17:38 -0700, Linda Walsh wrote:
> Functions are a collection of many commands.  They are not a single,
> simple statement.  I remember using their return value in some cases.
> 
> With the change, I couldn't run a func and have it return the
> value in $? (1 byte, I know) -- but about 128x as flexible 
> as "ok"/"die" (i.e. any non-zero value triggers the behavior
> now, but before, it didn't).
> 
> My simplistic view was that -e was there to auto-exit if an external
> command failed because they are "out of your control".  But if 
> I write a function -- I design the behavior.  Even if I designed in
> a bug -- it's still "my code" that has the problem not some
> -_e_xternal command

If you design the function, you can put an exit 0 on them, so they
never return a non-zero status.
It is completely sensible that if "echo foo > /dev/full" fails, it
behaves the same way no matter if it's /bin/echo or a builtin what is
run by "echo".

Note that Windows has a similar deviation between binaries and batch
scripts.
A .bat containing:
foo
bar

will run foo.exe then bar.exe if there's an executable named foo.exe,
but only foo.bat will be run if it happens to be a .bat script (ie.
acts as if prefixed by exec(1) when it's a .bat). And you can't know
beforehand (even worse, someone may have installed a .bat with the same
name as a .exe in order to slightly augment it).


Treating all of them consistently is the way to go.


>   cf. perl's option "autodie" -- you can say you want the "open
> builtin" to just die on errors, then for simple scripts you don't
> have
> to put extra code to handle each problem.  I.e. -- it's not really 
> something you want in production code, but I write far more throw
> away quick and dirty scripts than production ones.  

I would to like to have a way to automatically set -e all functions
defined after that, but it's orthogonal to treating them as commands.

> 

Re: [ PATCH 1/1 ] l10n: zh_{CN,TW} localization update for bash 4.3

[Chet Ramey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/21/15 10:06 AM, Eric Blake wrote:

> GNU Coding Standards recommend that '$program --help' should list the
> preferred bug-reporting address, and that the corresponding .po file
> should then expand that information to ALSO list the preferred address
> for reporting translation bugs in that .po file.

Bash bugs should be reported using `bashbug'.  That's why it's listed
in the help output.

- -- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlXXQk0ACgkQu1hp8GTqdKuVcwCdE3Y5aEyeUb3hGQMqgxeCyJjF
x1AAn06QkWrfHeLW9TxHSpbg8i1jJo5H
=Q7zm
-END PGP SIGNATURE-

Re: [ PATCH 1/1 ] l10n: zh_{CN,TW} localization update for bash 4.3

[Chet Ramey]

On 8/20/15 7:19 PM, Jeff Bai wrote:
> Hello, and here is a patch set for both zh_CN and zh_TW localization update.
> I will send a separate message for bash 4.4.

Please use the GNU Translation project as the clearinghouse for translation
files.

http://translationproject.org/domain/bash.html

I believe you can simply send them your zh_CN files.  I'm sure they would
be happy to get updates for bash-4.3 and bash-4.4-alpha.  Thanks for your
help.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: [ PATCH 1/1 ] l10n: zh_{CN,TW} localization update for bash 4.3

[Eric Blake]

On 08/20/2015 04:19 PM, Jeff Bai wrote:
> Hello, and here is a patch set for both zh_CN and zh_TW localization update.
> I will send a separate message for bash 4.4.

Thanks, but please don't.  Spamming the wrong list with 600k of
information that the majority of list readers can't read is
inappropriate.  Instead, send your patches to the appropriate
translation teams.

See the following for more details:
http://translationproject.org/domain/bash.html
http://translationproject.org/team/zh_CN.html
http://translationproject.org/team/zh_TW.html

Once the appropriate translation teams incorporate your work on
translationproject.org, then it can automatically be picked up by
distros, without upstream bash having to do anything.

However, to make this relevant to the upstream list:

GNU Coding Standards recommend that '$program --help' should list the
preferred bug-reporting address, and that the corresponding .po file
should then expand that information to ALSO list the preferred address
for reporting translation bugs in that .po file.  For example:

$ ls --help | tail -n2

GNU coreutils online help: 
For complete documentation, run: info coreutils 'ls invocation'
$ LC_ALL=zh_CN.UTF-8 ls --help | tail -n3
GNU coreutils online help: 
请向 报告ls 的翻译错误
要获取完整文档，请运行：info coreutils 'ls invocation'

Unfortunately, 'bash --help' violates this rule in the original English.
 But .po writers could STILL at least add their preferred
translation-bug reporting address into bash's (incomplete) --help output.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: In the bash man page the entry for the 'read' command has two spaces after it instead of one.

[Andreas Schwab]

Jerry Marbas  writes:

>   I use the manpage of bash a lot and when I want to find a command I usually 
> type:  \[
>   But for 'read' entry has two spaces between 'read' and the '[' making me 
> type: read  \[

Try searching for '^ {7}read ' instead.  There are commands that aren't
followed by options in the description.

> Remove the extra space.

The extra space is part of justifying the text.  Depending on the line
length there may be different amount of space to spread out.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

In the bash man page the entry for the 'read' command has two spaces after it instead of one.

[Jerry Marbas]

Hi I ran bashbug on the command line and entered all the information for my
bug report but then when I tried to submit it I got the following error:

$ jmarbas@jmarbas-System:~/linux/quiz$ bashbug
Send bug report to bug-bash@gnu.org,b...@packages.debian.org? [y/n] y
/usr/bin/bashbug: 267: /usr/bin/bashbug: rmail: not found
/usr/bin/bashbug: mail failed: report saved in /home/jmarbas/dead.bashbug

So I decided to send it to you as an attachment to this email instead.
Hope this is ok.

Thanks,
Jerry


dead.bashbug
Description: Binary data

Re: trap RETURN not set in calling function is overwritten by callee

[Chet Ramey]

On 8/19/15 2:48 AM, jtmoon+bash...@extrahop.com wrote:

> Fix:
>   For some reason the RETURN traps are not being stacked.  Instead, the
>   current RETURN trap is just overwritten.

There is only a single RETURN trap.  Functions do not have local traps.  If
a return trap is set when a function returns, it will be executed.  Nor are
there local functions; all functions are at the global scope.

Function tracing mode (for the debugger) changes this somewhat, but you're
not using it.
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: -e does not take effects in subshell

[Chet Ramey]

On 8/20/15 8:38 PM, Linda Walsh wrote:
> 
> 
> Chet Ramey wrote:
>>> The earlier spec had -e only exit a script if a *simple* (external)
>>> command failed.  It didn't include builtins nor functions.
>>
>> This is not; builtins and functions are simple commands.
> ---
> The builtins are _complex_ binary blobs that replace external commands.
> 
> Functions are a collection of many commands.  They are not a single,
> simple statement.  I remember using their return value in some cases.

`Simple command' is a specific term with a specific meaning.  It doesn't
have anything to do with perceived implementation complexity.

> 
> With the change, I couldn't run a func and have it return the
> value in $? (1 byte, I know) -- but about 128x as flexible as "ok"/"die"
> (i.e. any non-zero value triggers the behavior
> now, but before, it didn't).

That's fine, even clever, but fundamentally incompatible with the idea
that 0 means success and everything else means failure.

> My simplistic view was that -e was there to auto-exit if an external
> command failed because they are "out of your control".

That's an incomplete view.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/