Re: Variables declared in arithmetic expressions have no i flag

2020-11-26 Thread Chet Ramey
On 11/24/20 8:30 AM, Léa Gris wrote:
> Should variables automatically created within arithmetic constructs have
> the integer flag implied?

No. There's no reason to do this. If you want an integer variable, declare
it as such beforehand.

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



Re: How is it explained about the `local` is valid variable

2020-11-25 Thread Chet Ramey
On 11/24/20 8:06 PM, Budi wrote:
> Can we validly write a line
> 
> unset local a b c d e f g h i
> 
> to mean:   local a b c d e f g h i;unset a b c d e f g h i

No.

> if yes, how come local=9 is valid variable 'local' normally ? thanks much

Variables and builtin commands are in different namespaces.

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



Re: Possible race condition in bash

2020-11-21 Thread Chet Ramey
On 11/21/20 2:32 PM, Andreas Schwab wrote:
> On Nov 21 2020, Chet Ramey wrote:
> 
>> but since the shell always ignores SIGTERM,
> 
> Even a non-interactive shell?

No, you're right, it's SIGQUIT the shell always ignores. It catches SIGTERM
if there is an EXIT trap so it can run the trap on EXIT before exiting.

>> I'd also try it with one of the bash-5.1 testing releases, since I did
>> some reworking of how the shell handles SIGTERM back in April.
> 
> 5.1-rc3 has the same issue.

OK, I instrumented bash a little bit, and discovered that the second
child doesn't start running, or at least doesn't get to the point in the
subshell initialization where it resets the signal handlers, until after
the parent sends SIGTERM.

That means the trap handler is still set to catch SIGTERM by the time
the signal arrives. However, the child is not allowed to run the trap
handler; it's supposed to reset the dispositions to the default. This
is the race condition.

It's a dilemma. I could block SIGTERM (all trapped signals, really) until
the child resets the signal dispositions, but that seems like a long time
to keep signals blocked. I'll look at it some more after bash-5.1 is
released.

Chet

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



Re: Possible race condition in bash

2020-11-21 Thread Chet Ramey
On 11/21/20 1:35 PM, Nikolay Borisov wrote:

> I can see setting of SIGTERM handler for both 2 subshells _after_ receiving 
> the signal. What exactly should I be looking at?

That's your race condition.

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



Re: Possible race condition in bash

2020-11-21 Thread Chet Ramey
On 11/21/20 1:25 PM, Andreas Schwab wrote:
> On Nov 21 2020, Chet Ramey wrote:
> 
>> This is a potential race condition, but it's not with the shell.
> 
> The race with the trap command in the function is obvious, but that
> should not result in the signal to be ignored.  There should always be a
> trap active, either the main one or the one in the function, and neither
> ignores the signal.

No.

"A subshell environment shall be created as a duplicate of the shell
environment, except that signal traps that are not being ignored shall be
set to the default action."

In this case, bash resets the signal disposition to the what it had when
the shell started. That should be SIG_DFL, but since the shell always
ignores SIGTERM, it's not clear from the description here what the signal
handler gets set to. That's why I suggested looking at strace output.

I'd also try it with one of the bash-5.1 testing releases, since I did
some reworking of how the shell handles SIGTERM back in April.

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



Re: Problems with command substitution and command alias

2020-11-21 Thread Chet Ramey
On 11/21/20 10:04 AM, Hyunho Cho wrote:
> 
> ### 2.
> 
> alias-expand-line readline function affects not only command line but also
> heredoc contents

Yes, that is how it works. The alias-expand-line function just takes what
is in the current readline line buffer, identifies tokens that are in a
command position, and alias expands them. It, like most of the readline
key bindings, is not aware of the shell's parsing state.

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



Re: Possible race condition in bash

2020-11-21 Thread Chet Ramey
On 11/21/20 3:06 AM, Nikolay Borisov wrote:

> The output is:
> 
> my pid 12186
> 12186 subfun xxx 0
> funpid=12186 twopid=12187 mypid=12185
> killing 12186 12187
> waiting on everything
> my pid 12187
> 12187 subfun yyy 0
> received term for xxx
> 12187 subfun yyy 1
> 12187 subfun yyy 2
> 12187 subfun yyy 3
> 
> 
> and 12187 keeps printing. It would seem there $! can return a pid of the
> subshell before it's in a state that it can be killed. 

This is a potential race condition, but it's not with the shell. The
parent shell sets $! as soon as the child pid returns from fork(), and
that doesn't have anything to do with when the child gets scheduled or
runs. You might have better luck running this under strace or truss and
seeing what happens with the timing: whether the child sets SIGTERM to
the trap handler before the signal arrives, or whether the child resets
the SIGTERM handler to what the parent had before the trap before the
signal arrives.


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



Bash-5.1-rc3 available

2020-11-18 Thread Chet Ramey
mand, `jobs' now reports the status of completed jobs.

dd. New `U', `u', and `L' parameter transformations to convert to uppercase,
convert first character to uppercase, and convert to lowercase,
respectively.

ee. PROMPT_COMMAND: can now be an  array variable, each element of which can
contain a command to be executed like a string PROMPT_COMMAND variable.

ff. `ulimit' has a -R option to report and set the RLIMIT_RTTIME resource.

gg. Associative arrays may be assigned using a list of key-value pairs within
a compound assignment. Compound assignments where the words are not of
the form [key]=value are assumed to be key-value assignments. A missing or
empty key is an error; a missing value is treated as NULL. Assignments may
not mix the two forms.

hh. New `K' parameter transformation to display associative arrays as key-
value pairs.

ii. Writing history to syslog now handles messages longer than the syslog max
length by writing multiple messages with a sequence number.

jj. SECONDS and RANDOM may now be assigned using arithmetic expressions, since
they are nominally integer variables. LINENO is not an integer variable.

kk. Bash temporarily suppresses the verbose option when running the DEBUG trap
while running a command from the `fc' builtin.

ll. `wait -n' now accepts a list of job specifications as arguments and will
wait for the first one in the list to change state.

mm. The associative array implementation can now dynamically increase the
size of the hash table based on insertion patterns.

nn. HISTFILE is now readonly in a restricted shell.

oo. The bash malloc now returns memory that is 16-byte aligned on 64-bit
systems.

4. New Features in Readline

a. If a second consecutive completion attempt produces matches where the first
   did not, treat it as a new completion attempt and insert a match as
   appropriate.

b. Bracketed paste mode works in more places: incremental search strings, vi
   overstrike mode, character search, and reading numeric arguments.

c. Readline automatically switches to horizontal scrolling if the terminal has
   only one line.

d. Unbinding all key sequences bound to a particular readline function now
   descends into keymaps for multi-key sequences.

e. rl-clear-display: new bindable command that clears the screen and, if
   possible, the scrollback buffer (bound to emacs mode M-C-l by default).

f. New active mark and face feature: when enabled, it will highlight the text
   inserted by a bracketed paste (the `active region') and the text found by
   incremental and non-incremental history searches. This is tied to bracketed
   paste and can be disabled by turning off bracketed paste.

g. Readline sets the mark in several additional commands.

h. Bracketed paste mode is enabled by default.

i. Readline tries to take advantage of the more regular structure of UTF-8
   characters to identify the beginning and end of characters when moving
   through the line buffer.

j. The bindable operate-and-get-next command (and its default bindings) are
   now part of readline instead of a bash-specific addition.

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



Re: is it a bug

2020-11-17 Thread Chet Ramey

On 11/17/20 7:56 AM, Greg Wooledge wrote:

On Mon, Nov 16, 2020 at 10:36:48PM -0800, L A Walsh wrote:

or (to reproduce error):
  an_alias='res=() t=""
for ci in "${!foo[@]}"; do \


Nice detective work there.  I can confirm this in Debian's bash 5.0.3:

unicorn:~$ alias foo='a=() b=""

for i in 1; do echo hi; done'

unicorn:~$ foo
bash: syntax error near unexpected token `;'
unicorn:~$ alias bar='a=()

b=""
for i in 1; do echo hi; done'

unicorn:~$ bar
hi


Interesting. Thanks for the simple reproducer, both of you. I'll take a
look after bash-5.1 is out.

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



Re: [ping] declare -c still undocumented.

2020-11-13 Thread Chet Ramey

On 11/13/20 3:50 PM, L A Walsh wrote:

On 2020/11/13 09:01, Chet Ramey wrote:

On 11/12/20 6:19 PM, Léa Gris wrote:
declare -c to capitalize first character of string in variable 


Thanks for the reminder. I keep forgetting to turn this off. It's too late
for bash-5.1, but I have it tagged to flip to disabled by default in
config-top.h in bash-5.2.

---
    It is replaced with something else?


There's nothing to directly replace `declare -c', which was a bad idea to
begin with. You can use the new @u parameter transformation operator to
replace ${v~}. The ability to use the pattern in @{v~[pattern]} wasn't a
great idea either.


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



Re: [ping] declare -c still undocumented.

2020-11-13 Thread Chet Ramey
On 11/12/20 6:19 PM, Léa Gris wrote:
> Necroposting for still valid issue:
> 
> declare -c to capitalize first character of string in variable is still
> undocumented as of GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)

Thanks for the reminder. I keep forgetting to turn this off. It's too late
for bash-5.1, but I have it tagged to flip to disabled by default in
config-top.h in bash-5.2.

Chet

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



Re: set -e in subshell

2020-11-13 Thread Chet Ramey
On 11/13/20 11:15 AM, Aron Griffis wrote:
> GNU bash, version 5.0.17(1)-release (x86_64-redhat-linux-gnu)
> 
> $ (set -e; false; echo BANG) || echo whimper
> BANG

`set -e' doesn't have any effect on the LHS of an and-or list, and enabling
it has no effect. There have been many discussions about this.

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



Re: History search: wrong pos. after `Bksp` over typo

2020-11-10 Thread Chet Ramey
On 11/10/20 12:54 AM, Michael Allan wrote:
> Configuration Information [Automatically generated]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: x86_64-pc-linux-gnu-gcc
> Compilation CFLAGS: -march=native -O2 -pipe -Wno-parentheses 
> -Wno-format-security
> uname output: Linux primeval 5.4.30-gentoo #33 SMP Wed Jul 29 00:03:46 EDT 
> 2020 x86_64 AMD Ryzen 7 3700X 8-Core Processor AuthenticAMD GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
> 
> Bash Version: 5.0
> Patch Level: 17
> Release Status: release
> 
> Description:
> During history search, Bash allows one to correct the search term
> by backspacing, e.g. after making a typo, but it fails to correct
> the search position in response.
> 
> A typo is like a ‘wrong turn at Albuquerque’, it can get one lost.
> Backspacing and erasing part of the search term *should* take one
> back to Albuquerque, but does not; while it corrects the search
> term, it fails to correct the search position (inconsistency)
> which leaves one lost.

Thanks for the suggestion. This is a request for an enhancement, since
readline has never worked like this. I'll consider it for a future
version.

Chet

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



Re: Disabling automatic assoc rehashing

2020-11-10 Thread Chet Ramey
On 11/10/20 2:16 PM, Tavis Ormandy wrote:
> Hello, I was just checking the new release candidate for compatability with my
> builtin and noticed that assoc arrays are now automatically rehashed on 
> insertion.
> 
> I knew this day would come :-)

(I confess that I have not looked at your code.)

> I had been (ab)using the fact that if you created the array with
> assoc_create(1), the order of elements would be maintained. This is
> because you were effectively creating a linked list rather than a hash
> table.

Why not just use a list then? The bash code uses lists (WORD_LIST, etc.)
all over the place. Or does something you're doing require associative
arrays?

> I expect the answer is "too bad", but it would be nice if the rehashing could
> be toggled with a flag in the HASH_TABLE, rather than based on the HASH_CREATE
> parameter, what do you think?

Maybe at some point, but not this close to bash-5.1.

> I'm aware not many people use native builtins, my code is here, it
> allows you to use native libraries in bash scripts:
> 
> https://github.com/taviso/ctypes.sh
> 
> The reason I need assocs that maintain order is so that you can
> manipulate and access C structures in bash. For example, if you had a
> struct stat, you might want to echo ${stat[st_mtim.tv_sec]}. This
> currently works with ctypes.sh, but I think it might not be possible if
> there's no way to disable automatic rehashing.

Hmmm...I see. You could use dynamic variables and construct the array on
the fly. But that would require more work in your builtin.

> Also, I noticed the definition of ARRAY is now ABI incompatible with builtins
> from previous versions because a new member (lastref) was added in the middle
> (rather than at the end).

Bash has never guaranteed ABI compatibility between versions, but I don't
see any problem with rearranging the ARRAY structure before bash-5.1 is
released.

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



Re: Unexpected code injection with [[ -v ]]

2020-11-10 Thread Chet Ramey
On 11/9/20 6:29 PM, Greg Wooledge wrote:
> bash version 5.0.3(1)-release, Debian package 5.0-4, amd64.
> 
> Prompted by a discussion with someone in IRC.
> 
> unicorn:~$ key='$(date >&2)'
> unicorn:~$ declare -A aa
> unicorn:~$ aa[$key]=foo
> unicorn:~$ echo "${aa[$key]}"
> foo
> unicorn:~$ [[ -v aa[$key] ]]
> Mon Nov  9 18:17:30 EST 2020
> bash: aa: bad array subscript
> unicorn:~$ [[ -v 'aa[$key]' ]]
> unicorn:~$ 
> 
> It's well-known that handing an unsanitized index to an *indexed* array
> causes code injection when the index is evaluated in a math context, but
> the code injection from -v with an *associative* array is a new one to me.
> It's especially confusing because it doesn't happen with assignments or
> expansions -- just with -v.

When executing the conditional command, each word is expanded once. The
difference between [[ and [ is that the word isn't split, and that's why
you get an error when you try this with test/[. Then the array subscript is
expanded to determine whether or not it's set, as usual.

When you use assignments or expansions, the subscript is expanded once.

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



Re: Add configure switch to define USE_XON_XOFF

2020-11-09 Thread Chet Ramey
On 11/6/20 1:25 PM, Ivan Kozlov wrote:
> Readline tests that macro and suppresses software flow control. This is quite 
> handy: I want software flow control, just not *in bash*, where it is not 
> useful and I would like C-s to do incremental search instead. With 
> USE_XON_XOFF, it is inactive in bash and is restored before executing a 
> command alongside other termios settings. It is probably possible to hack 
> this with PROMPT_COMMAND/PS0, but clearly this is a much cleaner and readily 
> available option. The only thing lacking is a configure switch.
> 

Thanks for the suggestion. I will look at this for a future bash version.

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



Re: Error in bash documentation for builtin declare

2020-11-06 Thread Chet Ramey
On 11/6/20 12:21 PM, Edouard Thiel wrote:

>>> By the way, I have seen that the nameref works more or less for functions:
>>> $ foo() { echo "hello" ;}
>>> $ declare -n bar=foo
>>> but the reference has to be dereferenced when calling:
>>> $ ${!bar}
>>> hello
>>>
>>> is it still the case in bash 5?
>> Sure, it seems harmless to allow it.
> I mean, I was surprised I couldn't simply run
> $ bar

What would be reasonable to expect that to do? There's no word expansion,
so no opportunity to perform any kind of nameref expansion.

You can either use namerefs as you did above, or have no nameref attribute
and use ${bar}.

Chet

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



Re: Error in bash documentation for builtin declare

2020-11-06 Thread Chet Ramey
On 11/6/20 11:53 AM, Edouard Thiel wrote:
> 
> 
> Le 06/11/2020 à 17:01, Greg Wooledge a écrit :
>> On Fri, Nov 06, 2020 at 02:07:36PM +0100, Edouard Thiel wrote:
>>> there is an error in the bash documentation:
>>>  https://www.gnu.org/software/bash/manual/bash.html#Bash-Builtins
>>>
>>> In the 'declare' builtin, option '-n',  last sentence:
>>>  "The nameref attribute cannot be applied to array variables"
>>> is actually wrong: it can be applied to indexed and associative arrays
>>> (since bash 4.3+)
>>>
>>> (tested for bash version : 4.3.48(1)-release (x86_64-pc-linux-gnu))
>> The relevant section in the 5.0 man page under PARAMETERS says:
>>
>>    Array variables cannot be given the nameref attribute.  However,
>>    nameref variables can  reference  array  variables and  subscripted
>>    array  variables.
>>
>> What, exactly, did you test?
> This is more clear, and in fact, ok for me (if subscripted means
> associative?);
> the link above is not up to date.

The same language appears in the "Shell Parameters" section of the manual
at the above link, just as it does in the "PARAMETERS" section of the
manual page.

> 
> By the way, I have seen that the nameref works more or less for functions:
> $ foo() { echo "hello" ;}
> $ declare -n bar=foo
> but the reference has to be dereferenced when calling:
> $ ${!bar}
> hello
> 
> is it still the case in bash 5?

Sure, it seems harmless to allow it.


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



Re: Error in bash documentation for builtin declare

2020-11-06 Thread Chet Ramey
On 11/6/20 8:07 AM, Edouard Thiel wrote:
> Hello,
> 
> there is an error in the bash documentation:
>     https://www.gnu.org/software/bash/manual/bash.html#Bash-Builtins
> 
> In the 'declare' builtin, option '-n',  last sentence:
>     "The nameref attribute cannot be applied to array variables"
> is actually wrong: it can be applied to indexed and associative arrays
> (since bash 4.3+)

Is this what you mean, or something else?

$ cat x3
echo $BASH_VERSION

declare -a foo=(a b c)
declare -n foo

declare -A bar=( [one]=1 [two]=2 )
declare -n bar

declare -an flip=(a b c)
declare -An flop=( [one]=1 [two]=2 )

declare -p foo bar flip flop
$ ../bash-5.0-patched/bash x3
5.0.18(9)-release
x3: line 4: declare: foo: reference variable cannot be an array
x3: line 7: declare: bar: reference variable cannot be an array
x3: line 9: declare: flip: reference variable cannot be an array
x3: line 10: declare: flop: reference variable cannot be an array
declare -a foo=([0]="a" [1]="b" [2]="c")
declare -A bar=([two]="2" [one]="1" )
declare -a flip=([0]="a" [1]="b" [2]="c")
declare -A flop=([two]="2" [one]="1" )


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



Re: Problem with reverse-i-search in 5.1.0(1)-rc1

2020-11-05 Thread Chet Ramey
On 11/5/20 9:13 AM, Detlef Vollmann wrote:
> On 11/5/20 3:01 PM, Chet Ramey wrote:
>> On 11/5/20 3:12 AM, Detlef Vollmann wrote:
>>> On 11/4/20 9:06 PM, Detlef Vollmann wrote:
>>>> What I don't understand yet is the highlighting.
>>>> Sometimes (but rarely) I see the matched string highlighted
>>>> (actually only starting with the second character).
>>>> But most of the time nothing is highlighted while doing
>>>> reverse-i-search.
>>> Sorry, it's as mentioned before:
>>> I have "set enable-bracketed-paste Off" in my .inputrc.
>>> So no highlighting as expected.
>>
>> Try it with bash-5.1-rc2.
> I did.
> What I'm seeing is no highlighting with "set enable-bracketed-paste Off"
> Should have anything changed here?

That's what should happen. There were cases in bash-5.1-rc1 where
incremental search results would be highlighted even when bracketed paste
was disabled.

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



Re: Problem with reverse-i-search in 5.1.0(1)-rc1

2020-11-05 Thread Chet Ramey
On 11/5/20 3:12 AM, Detlef Vollmann wrote:
> On 11/4/20 9:06 PM, Detlef Vollmann wrote:
>> What I don't understand yet is the highlighting.
>> Sometimes (but rarely) I see the matched string highlighted
>> (actually only starting with the second character).
>> But most of the time nothing is highlighted while doing
>> reverse-i-search.
> Sorry, it's as mentioned before:
> I have "set enable-bracketed-paste Off" in my .inputrc.
> So no highlighting as expected.

Try it with bash-5.1-rc2.

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



Bash-5.1-rc2 available

2020-11-04 Thread Chet Ramey
D variable.

ff. `ulimit' has a -R option to report and set the RLIMIT_RTTIME resource.

gg. Associative arrays may be assigned using a list of key-value pairs within
a compound assignment. Compound assignments where the words are not of
the form [key]=value are assumed to be key-value assignments. A missing or
empty key is an error; a missing value is treated as NULL. Assignments may
not mix the two forms.

hh. New `K' parameter transformation to display associative arrays as key-
value pairs.

ii. Writing history to syslog now handles messages longer than the syslog max
length by writing multiple messages with a sequence number.

jj. SECONDS and RANDOM may now be assigned using arithmetic expressions, since
they are nominally integer variables. LINENO is not an integer variable.

kk. Bash temporarily suppresses the verbose option when running the DEBUG trap
while running a command from the `fc' builtin.

ll. `wait -n' now accepts a list of job specifications as arguments and will
wait for the first one in the list to change state.

mm. The associative array implementation can now dynamically increase the
size of the hash table based on insertion patterns.

nn. HISTFILE is now readonly in a restricted shell.

oo. The bash malloc now returns memory that is 16-byte aligned on 64-bit
systems.

4. New Features in Readline

a. If a second consecutive completion attempt produces matches where the first
   did not, treat it as a new completion attempt and insert a match as
   appropriate.

b. Bracketed paste mode works in more places: incremental search strings, vi
   overstrike mode, character search, and reading numeric arguments.

c. Readline automatically switches to horizontal scrolling if the terminal has
   only one line.

d. Unbinding all key sequences bound to a particular readline function now
   descends into keymaps for multi-key sequences.

e. rl-clear-display: new bindable command that clears the screen and, if
   possible, the scrollback buffer (bound to emacs mode M-C-l by default).

f. New active mark and face feature: when enabled, it will highlight the text
   inserted by a bracketed paste (the `active region') and the text found by
   incremental and non-incremental history searches.

g. Readline sets the mark in several additional commands.

h. Bracketed paste mode is enabled by default (for now).

i. Readline tries to take advantage of the more regular structure of UTF-8
   characters to identify the beginning and end of characters when moving
   through the line buffer.

j. The bindable operate-and-get-next command (and its default bindings) are
   now part of readline instead of a bash-specific addition.

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



Re: [bash-5.1-rc2.] Do not leave /tmp/fchist-nnnn, please.

2020-11-04 Thread Chet Ramey
On 11/3/20 7:55 PM, Kiyoshi KANAZAWA wrote:
> Hello,
> Testing bash-5.1-rc2.
> make & make check passed, but /tmp/fchist- is made and not removed in 
> make check ( seems to be precess id).

Thanks for the report. The script in question removes the file in an exit
trap, but the history gets written after the exit trap is executed. I'll
fix it.

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



Re: Segfaults over a glob with quoted UTF-8 characters

2020-11-03 Thread Chet Ramey
On 11/3/20 4:09 PM, Frédéric Brière wrote:
>   $ echo $BASH_VERSION
>5.1.0(1)-rc1
>   $ echo $LC_ALL
>C.UTF-8
>   $ echo é/*
>é/*
>   $ echo 'é'/*
>Segmentation fault (core dumped)
> 
> The same occurs when escaping with a backslash.  Whether or not the glob
> actually matches something does not appear to matter.

Thanks for the report. This has already been fixed, the result of

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972286

The fix is in bash-5.1-rc2.

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



Re: Regression - extra terminal escape codes emitted

2020-11-02 Thread Chet Ramey
On 11/2/20 12:29 PM, Joe Nahmias wrote:
> Hello bash team,
> 
> I've noticed a regression in one of my test suites for a program using the
> python pexpect library, after upgrading from 5.0.3(1)-release to
> 5.1.0(1)-rc1. 

Thanks for the report. These are the escape sequences that enable and
disable the terminal's bracketed paste mode, which is enabled by default.
Bash-5.1-rc2 will inhibit these sequences if the terminal name is "dumb"
or unknown.

Chet

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



Re: Bash-5.1-rc1 available

2020-11-02 Thread Chet Ramey
On 11/2/20 10:12 AM, Tomas Janousek wrote:
> Hi Chet,
> 
> On Mon, Oct 26, 2020 at 10:12:59AM -0400, Chet Ramey wrote:
>> Yes, you can disable bracketed paste mode. I'll make sure that turning off
>> bracketed paste mode disables the active region for incremental searches.
> 
> Would you please consider making this configurable separately? I'd love to
> keep bracketed paste mode enabled, but I find the highlighting annoying (and a
> bit buggy, more on that later). It seems I'm not alone:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972344

I'm going to see what the reaction is with bash-5.1 and go from there. The
entire rationale for including this feature was to highlight the text a
bracketed paste inserts. Since there was no separate use, and the
contributed patch didn't include a configuration option, I didn't add one.

> 
> Also, the changelog says "when enabled", but there's currently no way to
> disable it:

You mean there is no separate way to disable it, which is true.

> 
>> f. New active mark and face feature: when enabled, it will highlight the text
>>inserted by a bracketed paste (the `active region') and the text found by
>>incremental and non-incremental history searches.
> 
> Now for the "bit buggy" part:
> 
> 1. PS1='$ '
> 2. echo -n x
> 3. paste something
> 4. press left arrow
> 
> Now the terminal shows "x$somethingg" instead of "x$ something".

If Readline doesn't start in column 0, all bets are off. The redisplay
needs to know where the physical cursor is in order to make decisions
about how and where to overwrite characters. If it doesn't know there
is a character in the last column, it's not going to try to overwrite it.
If it doesn't have to rewrite the prompt, it's not going to: it will
simply move the cursor to the physical location at the end of the prompt
string and output the line.

Chet

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



Re: Problem with reverse-i-search in 5.1.0(1)-rc1

2020-11-02 Thread Chet Ramey
On 11/2/20 9:17 AM, Detlef Vollmann wrote:

> BTW, if you want me to check it you could send me a patch or push
> a commit to git.savannah.gnu.org/git/bash.

It will be in the next devel branch push.

Chet

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



Re: bash: please provide an easy way to spawn a new process group from script

2020-11-01 Thread Chet Ramey
On 11/1/20 5:13 AM, clime wrote:

> Work with process groups should be natural in bash. It can't be that
> complex. I struggled with this for several hours and found lots of
> people on the net that struggled with the same problem too.

It is natural, and job control is the most natural way to do it. If you
don't want to use job control for some reason, the `setpgid' loadable
builtin exists, as others have noted.

If you don't want to use the loadable builtin, you can easily write a
standalone program that, when executed, becomes a process group leader
and execs the remaining arguments.

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



Re: Problem with reverse-i-search in 5.1.0(1)-rc1

2020-11-01 Thread Chet Ramey
On 10/31/20 11:00 AM, Detlef Vollmann wrote:
> Hello,
> 
> since Bash-5.1-rc1  doesn't work for me as previously.
> I have the following entries in my history:
> man a
> man b
> 
> Now I type ' m a n' and get:
> (reverse-i-search)`man': man b
> 
> Now I type '' again.
> What I would expect (and what I got with 5.0) is:
> (reverse-i-search)`man': man a
> 
> Instead I get
> (reverse-i-search)`': man b
> 
> Note the empty search string.

Thanks for the report. It's not easy to reproduce, and, as you later note,
requires the `C' or `POSIX' locales and things to be done in a certain
order, but I believe I was able to track it down. It will be fixed in
bash-5.1-rc2.

Chet

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



Re: possible bugs with colored-stats

2020-10-29 Thread Chet Ramey
On 10/29/20 6:38 AM, Arnaud wrote:
> Le 29.10.20 à 06:54, Clark Wang a écrit :
>>
>> I can reproduce the similar issue with my bash 4.4.12 and PS0="\[\e[0m\]"
>> fix it for me.
>>
>> -clark
>>
> 
> I had to change at one point the PS0="\[\e[0m\] to PS0="\[\e[38;5;15m\].

Except for this changing the default color to light grey, which I have
trouble seeing, everything looks fine.

I'm testing on macOS Terminal.

If you want to look further, my guess is that the terminal is still using
the PS1 color when it prints the colored possible completions, and
reverting to the "normal" color after printing each possible completion
messes up the terminal's idea of the current color somehow.

Either way, the functions you want to look at are

colored_stat_start
colored_stat_end

which are called when the completion code prints colored possible
completions.

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



Re: possible bugs with colored-stats

2020-10-28 Thread Chet Ramey
On 10/28/20 4:10 PM, Arnaud wrote:

> Bash Version: 5.0
> Patch Level: 17
> Release Status: release
> 
> Description:
> I have colored my prompt with colors, using PS1 and PS0.
> 
> PS1 ends with a color definition, so the command entered is colored.
> PS0 resets the color so the output has the standard colors.

I'm not sure what terminal emulator you're using, but that PS0 is what
turns the `normal' color to light grey on mine. It's pretty tough to see.

> I have actived colored-stats, so when I use tab completion, the 
> colors I use in the command doesn't show in the tab completion.
> 
> Problem 1
> If the list starts with a file, only the 1st file is colored with the 
> PS1 color.
> If the list starts with a folder, the colors are ok.

I can't reproduce this.

> Problem 2
> when I list the content of a folder with ls, the color is ok (white 
> in my case, until I reach a folder,
> it then switches the color of the following files to grey.

Nor this.

> 
> I tried looking in the bash code to try to find the problem, but I 
> cannot locate the part of the code for that (not experienced in C)
> Normally, readline should be the part I am looking for, but I also 
> have readline installed in my system, so it should be in it?

This is part of readline, yes.


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



Re: GNU Bash profile code execution vulnerability enquiry

2020-10-28 Thread Chet Ramey
On 10/28/20 1:11 PM, Rachel Alderman wrote:
> Hi Bash Maintainers,
> 
> I've been made aware of a GNU Bash profile code execution vulnerability 
> https://exchange.xforce.ibmcloud.com/vulnerabilities/173116 reported last 
> December (2019-12-16)
> Description: GNU Bash could allow a remote attacker to execute arbitrary 
> code on the system, caused by improper access control by the Bash profile. 
> By persuading a victim to open the Bash terminal, an attacker could 
> exploit this vulnerability to execute arbitrary code on the system. 

Hi, Rachel. Thanks for the report. This does not describe a bash
vulnerability. Executing a profile file at shell startup is a standard
shell feature. If an  attacker has write access to a user's profile file,
they can modify it to include potentially malicious commands, but this does
not constitute a bash vulnerability.

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



Re: New feature in bash 5.1/readline-8.1 rc1 breaks python-pexpect

2020-10-28 Thread Chet Ramey
On 10/28/20 10:51 AM, Dr. Werner Fink wrote:
> On 2020/10/28 10:23:57 -0400, Chet Ramey wrote:
>> On 10/16/20 9:28 AM, Chet Ramey wrote:
>>> On 10/16/20 9:16 AM, Dr. Werner Fink wrote:
>>>
>>>> Also a warning hint in the manual page could
>>>> help users before enabling this feature :)
>>>
>>> I agree, and the manual page in the release will reflect bracketed paste's
>>> default setting. However, readline doesn't try to enable bracketed paste if
>>> tcgetattr fails, which it will on an fd that's not a terminal, so I am
>>> fairly sure that expect/pexpect use ptys to masquerade as terminals.
>>>
>>> The biggest problem with bracketed paste is that right now, there's simply
>>> no way to determine whether or not a particular terminal supports it.
>>
>> I wonder if it would make sense for bash to compile its version of readline
>> with bracketed paste on by default, but the standalone readline library
>> version have it off. Or is that too clever by half?
> 
> Ohmm ... this makes no diffference here as bash (and all other tools)
> uses, if ever possible, the system libraries by policy.  And the readline
> library is a system library.  That means if there is a security issue within
> such a system library it has to be fixed only once.

Then it seems like the best way to address these competing requirements is
to allow readline to be configured with the default one way or another. I
already added a #define that can be used to set the default value of
enable-bracketed-paste.

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



Re: New feature in bash 5.1/readline-8.1 rc1 breaks python-pexpect

2020-10-28 Thread Chet Ramey
On 10/16/20 9:28 AM, Chet Ramey wrote:
> On 10/16/20 9:16 AM, Dr. Werner Fink wrote:
> 
>> Also a warning hint in the manual page could
>> help users before enabling this feature :)
> 
> I agree, and the manual page in the release will reflect bracketed paste's
> default setting. However, readline doesn't try to enable bracketed paste if
> tcgetattr fails, which it will on an fd that's not a terminal, so I am
> fairly sure that expect/pexpect use ptys to masquerade as terminals.
> 
> The biggest problem with bracketed paste is that right now, there's simply
> no way to determine whether or not a particular terminal supports it.

I wonder if it would make sense for bash to compile its version of readline
with bracketed paste on by default, but the standalone readline library
version have it off. Or is that too clever by half?


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



Re: read with very small timeout sometime hand on stdin

2020-10-28 Thread Chet Ramey
On 10/28/20 7:06 AM, felix wrote:

> Bash Version: 5.1
> Patch Level: 0
> Release Status: rc1
> 
> Description:
> Trying to see limits of timeout with `read -t`, I encounter strange
> and unconstant result: sometime `read -t .01` don't consider
> timeout, when running fastly multiple time.

I can't reproduce this using the following stripped-down reproducer:

trap 'echo $f ; exit' SIGINT

for f in {1..1}; do
read -t .01 v
if [ $? -ne 142 ]; then
echo $f: $?
fi
done


> Ok, then microsecond seem to by smallest value.

Yes, the smallest granularity is microseconds. The code uses interval
timers and timevals.

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



Re: Behavior change

2020-10-27 Thread Chet Ramey
On 10/27/20 10:10 AM, Gregory Heytings wrote:
> 
>>> Okay.  I just set "set enable-bracketed-paste off" in my /etc/inputrc.
>>> Perhaps this change should be documented in CHANGES, and in the man page
>>> (where enable-bracketed-paste is said to have the default value Off).
>>
>> The manual page in the released version will reflect the default setting
>> of bracketed paste. While it will probably remain on by default, there
>> have already been several reports of the bracketed paste enable/disable
>> escape sequences interfering with program-driven readline use cases, so
>> it's not certain it will.
>>
> 
> FWIW, I've been using bash for twenty years (starting with version 2.05
> IIRC), and it's the first time I see changes that I find disturbing and
> want to turn off.  The paste behavior with enable-bracketed-paste on also
> disturbed me, but I wasn't sure how to explain it.

I understand. There are folks on the other side of that discussion who are
just as passionate in their belief that the default bash behavior is broken
and leads to security issues. Bracketed paste is currently the only way to
determine whether or not input comes from a paste or some other source.

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



Re: Behavior change

2020-10-27 Thread Chet Ramey
On 10/27/20 9:55 AM, Gregory Heytings wrote:

> 
> Okay.  I just set "set enable-bracketed-paste off" in my /etc/inputrc.
> Perhaps this change should be documented in CHANGES, and in the man page
> (where enable-bracketed-paste is said to have the default value Off).

The manual page in the released version will reflect the default setting of
bracketed paste. While it will probably remain on by default, there have
already been several reports of the bracketed paste enable/disable escape
sequences interfering with program-driven readline use cases, so it's not
certain it will.


Chet

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



Re: Bash 5 increase in RAM from loop with many interations that append to file

2020-10-27 Thread Chet Ramey
On 10/27/20 12:11 AM, Scott Kostyshak wrote:
> The following example uses more peak RAM on new bash versions than old 
> versions:
> 
> for i in {1..100}; do
>   echo "${i}" >> example.txt
> done
> 
> By measuring peak memory usage with time (/usr/bin/time -f "%E %P %M"),
> I get that newer versions of Bash use about 284M, where older versions
> use about 191M.
> 
> Is this perceived increase in memory usage worth looking more into or is
> it intended?

My guess is that the huge list that results from the brace expansion caused
the bash malloc to cross over into a larger memory bin because of unrelated
memory allocation patterns that changed between bash versions. Once you
allocate that much memory, a binary bin allocation method is going to waste
some. In bash-5.0, that large allocation is going to use mmap, which adds
some overhead of its own.

If you can use valgrind or a similar tool to identify a memory leak, that
would be useful.

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



Re: Behavior change

2020-10-27 Thread Chet Ramey
On 10/26/20 5:58 PM, Gregory Heytings via Bug reports for the GNU Bourne
Again SHell wrote:
> 
> Hi,
> 
> I just installed Bash 5.1 rc1.  I have IGNOREEOF set, and in 5.0 (and
> earlier version) when pressing C-d one sees:
> 
> $ Use "logout" to leave the shell.
> 
> With 5.1 rc1 there is a newline between the prompt and the message:
> 
> $
> Use "logout" to leave the shell.
> 
> Is this change intentional?

It's bracketed paste, which is enabled by default in bash-5.1-rc1. The
escape sequence that readline sends to the terminal to turn off bracketed
paste ends with a carriage return, to avoid confusing the Linux terminal
driver about the physical location of the cursor, so the cursor ends up at
column 0. If readline has seen EOF, the shell is going to print something
one way or another, and that text will overwrite what is on the current
screen line. Readline outputs a newline to compensate.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903936 for an
example.

Chet

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



Re: issue with vredir6.sub and AIX - bash (sub-shell) is crashing durig manual replication of test

2020-10-26 Thread Chet Ramey
On 10/24/20 1:17 PM, Michael Felt wrote:
> OK. Thanks for the reply - and apologies for slow response.
> 
> I was expecting a summary of the test results. I thought the other
> projects you lead ended with test summaries.

No, there have never been summaries.

> If you care to help me find where the wrong error number is being
> returned I'll try and come up with a PR to fix this test for AIX. If
> not, we can consider this thread 'closed'.

It's just AIX interpreting the error condition differently. I think
POSIX permits both interpretations. Since bash just prints the error
message corresponding to errno, and the test is ensuring that the shell
prints an error message on this condition, it's dependent on what the
system call returns. I don't think it's worth trying to work around it.

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



Re: Bash-5.1-rc1 available

2020-10-26 Thread Chet Ramey
On 10/20/20 4:44 PM, Bob Proulx wrote:
> Chet Ramey wrote:
>> This release fixes several outstanding bugs in bash-5.0 and introduces
>> several new features.
> 
> An unlisted change (I couldn't locate it in the changes) is that
> 'reverse-search-history (C-r)' now highlights the search pattern.

You quoted it in your message:

f. New active mark and face feature: when enabled, it will highlight the text
   inserted by a bracketed paste (the `active region') and the text found by
   incremental and non-incremental history searches.

>  Is
> that because it is the search pattern or because it now sets the region?

Because it sets the region, and when bracketed paste mode is enabled, the
new active region feature is enabled.

> I find the reverse video highlight to be very difficult to read.  For
> me it is extreme eye strain.  Is there a way to disable the reverse
> video?  For both the paste text and the search text?

Yes, you can disable bracketed paste mode. I'll make sure that turning off
bracketed paste mode disables the active region for incremental searches.

Chet

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



Re: Command "read -N " doesn't respect UTF-8 encoding

2020-10-26 Thread Chet Ramey
On 10/24/20 3:51 PM, i...@kablex.ru wrote:

> Bash Version: 4.3
> Patch Level: 30
> Release Status: release
> 
> Description:
> UTF-8 string piped to read command goes corrupt with -N option, e.g.
>   printf "привет"|(read -N 100500 var_text; printf  "$var_text" )
>  returns some corrupt output "�#��#��#��#��#��#�"

Thanks for the report. This was fixed in bash-5.0.


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



Re: Typo in the bash man page

2020-10-24 Thread Chet Ramey
On 10/23/20 2:05 PM, Luc Ducazu wrote:

> Bash Version: 5.0
> Patch Level: 17
> Release Status: release
> 
> Description:
> Typo in section 'CONDITIONAL EXPRESSIONS'
> 
> Repeat-By:
> $ man bash
> 
> Fix:
> [...]The test  abd  [ commands  determine  their  behavior[...]
> Should be
> [...]The test  and  [ commands  determine  their  behavior[...]

Thanks for the report.

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



Re: Outdated links to GNU downloads

2020-10-19 Thread Chet Ramey
On 10/19/20 4:59 AM, Daniels Umanovskis wrote:
> Documentation issue, applies to all configurations, both on master and 5.1
> testing branches.
> 
> The links to GNU downloads in the docs are broken. The downloads have been
> unavailable over plain FTP for over 2 years now. ftp://ftp.gnu.org/pub is
> disabled, and accessing the downloads over HTTPS is the current way.

This just isn't the case. I just retrieved bash-5.1-rc1 from ftp.gnu.org
using a plain old ftp client.

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



Re: problem with using ctrl-x ctrl-e ( open vi editor )

2020-10-19 Thread Chet Ramey
On 10/18/20 10:34 PM, Hyunho Cho wrote:

> Bash Version: 5.0
> Patch Level: 17
> Release Status: release
> 
> #
> 
> bash$ cat <<\EOF  # without using ctrl-x ctrl-e there is no problem
> occurred.
>> 111
>> 222
>> EOF
> 111
> 222
> 
> ---
> 
> bash$ cat <<\EOF
>> 111
>>  < in this line open vi editor with ctrl-x ctrl-e
> and add another 222 line then :wq
> 
> 
> bash$ cat <<\EOF
>> 111
>>
> cat <<\EOF
> 111
> 222
> EOF
> 111< successfully executed cat command with heredoc
> 222
>>
>>
>>
>> ^C   < but does not end ">" prompt until enter ctrl-c

Thanks for the report. Since the commands in the file are executed in a
different execution context, and do not interrupt the parsing of the
current command, what do you think this should do? Bash could simply
disallow that construct if it's in the middle of parsing a compound
command, as other shells do, but it's always done its best to continue
with the compound command.


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



Re: Name collision with nameref and local variable

2020-10-18 Thread Chet Ramey
On 10/16/20 11:23 AM, gri...@sun.stat.cwru.edu wrote:

> Bash Version: 5.0
> Patch Level: 18
> Release Status: release
> 
> Description:
> This worked just fine on Bash 4.2:
> 
> foo() {
> local -a args=("${!1}")
> echo "[IN] ${args[@]}"
> }
> 
> declare -a args=("$@")
> echo "Bash ${BASH_VERSION}"
> echo "[OUT] ${args[@]}"
> foo args[@]
> 
> eg.
> $ ./test.sh 1 2 3

Thanks for the report. There aren't any nameref variables there; this is
an order-of-evaluation problem resulting from the local array variable
declaration with the same name as the variable used in the word
expansion -- it doesn't depend on the indirect variable expansion. It was
fixed back in April, before bash-5.1-alpha was released.

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



Re: New feature in bash 5.1/readline-8.1 rc1 breaks python-pexpect

2020-10-16 Thread Chet Ramey
On 10/16/20 9:16 AM, Dr. Werner Fink wrote:

> Also a warning hint in the manual page could
> help users before enabling this feature :)

I agree, and the manual page in the release will reflect bracketed paste's
default setting. However, readline doesn't try to enable bracketed paste if
tcgetattr fails, which it will on an fd that's not a terminal, so I am
fairly sure that expect/pexpect use ptys to masquerade as terminals.

The biggest problem with bracketed paste is that right now, there's simply
no way to determine whether or not a particular terminal supports it.

As for the hint, the man page is the wrong place for it. It's one of the
items in CHANGES:

h. Bracketed paste mode is enabled by default (for now).

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



Re: issue with vredir6.sub and AIX - bash (sub-shell) is crashing durig manual replication of test

2020-10-16 Thread Chet Ramey
On 10/16/20 6:31 AM, Michael Felt wrote:

> OK. While - perhaps the root cause is differences in error-codes, or
> something like that - and not to be overly concerned about (as I am not
> with the UTF-8 'errors') I am concerned that 'make test' terminates at
> this point - rather than continuing with the rest of the test suite.

There is no "rest of the test suite." That is the last test script. Bash
runs all the tests to completion.

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



Re: New feature in bash 5.1/readline-8.1 rc1 breaks python-pexpect

2020-10-16 Thread Chet Ramey
On 10/16/20 5:41 AM, Dr. Werner Fink wrote:
> Hi,
> 
> after build rc1 of bash 5.1 as well as readline-8.1 I've set up test
> staging process.  During build the package python-pexpect throws errors
> in its test suite, e.g.
> 
> [  260s] self =  testMethod=test_async_replwrap_multiline>
> [  260s] 
> [  260s] def test_async_replwrap_multiline(self):
> [  260s] bash = replwrap.bash()
> [  260s] coro = bash.run_command("echo '1 2\n3 4'", async_=True)
> [  260s] res = run(coro)
> [  260s] >   self.assertEqual(res.strip().splitlines(), ['1 2', '3 4'])
> [  260s] E   AssertionError: Lists differ: ['\x1b[?2004l', 
> '\x1b[?2004h\x1b[?2004l', '1 2', '3 4', '\x1b[?2004h'] != ['1 2', '3 4']
> [  260s] E   
> [  260s] E   First differing element 0:
> [  260s] E   '\x1b[?2004l'
> [  260s] E   '1 2'
> [  260s] E   
> [  260s] E   First list contains 3 additional elements.
> [  260s] E   First extra element 2:
> [  260s] E   '1 2'
> [  260s] E   
> [  260s] E   - ['\x1b[?2004l', '\x1b[?2004h\x1b[?2004l', '1 2', '3 4', 
> '\x1b[?2004h']
> [  260s] E   + ['1 2', '3 4']
> 
> I found this is caused by (_rl_)enable[-_]bracketed[-_]paste as the sequences
> are defined in rlprivate.h
> 
>  #define BRACK_PASTE_INIT  "\033[?2004h"
>  #define BRACK_PASTE_FINI  "\033[?2004l\r"
> 
> indeed it is a nice feature to see highlighted paste content on the 
> interactive
> command line, but why this interferes with tools like pexpect using bash in
> interactive mode?

Yes, bracketed paste is currently enabled by default. I may change that by
the time 5.1 is released.

I don't understand your question about tools like pexpect. If bracketed
paste mode is on, it's on. How is readline supposed to know whether or not
its stdin and stdout are connected to expect? How is the interactive shell
run by pexpect different from one connected to a terminal?

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



Re: issue with vredir6.sub and AIX - bash (sub-shell) is crashing durig manual replication of test

2020-10-15 Thread Chet Ramey
On 10/15/20 3:03 AM, Michael Felt wrote:
> Hi.
> 
> I don't actually use bash myself - so something that would be apparent
> to a bash user is invisible to me.
> 
> As part of the packaging of bash-5.0.18 (i.e., 5.0 at patch level 18) I
> ran the test suite.
> 
> a) is there a flag I can pass so that it ignores the UTF-8 tests? I do
> not want to not build UTF-8 support - for anyone who does load those
> language filesets, but I would prefer to not see that test show up as
> failed - rather as skipped.

There isn't. There isn't any way to make any part of the test suite
optional. I'd argue that UTF-8 support is the rule, rather than the
exception, anyway.

> 
> b) I have - apparently - been a LONG time since I last ran `make test`
> for bash, as I get the same error on bash-4.4 patch level 23, and on
> bash-5.0 patch level 11 and bash-5.0 patch level 18.
> 
> run-vredir
> 14,16c14,16
> < ./vredir.tests: line 25: $v: A file descriptor does not refer to an
> open file.
> < ./vredir.tests: line 26: $v: A file descriptor does not refer to an
> open file.
> < ./vredir.tests: line 27: $v: A file descriptor does not refer to an
> open file.
> ---
>> ./vredir.tests: line 25: $v: Bad file descriptor
>> ./vredir.tests: line 26: $v: Bad file descriptor
>> ./vredir.tests: line 27: $v: Bad file descriptor
> 90,91c90,91
> < ./vredir6.sub: redirection error: cannot duplicate fd: The process
> file table is full.
> < ./vredir6.sub: line 13: /dev/null: The process file table is full.
> ---
>> ./vredir6.sub: redirection error: cannot duplicate fd: Invalid argument
>> ./vredir6.sub: line 13: /dev/null: Invalid argument

These are simply different error messages for the same underlying error
(AIX is famous for these) or system calls returning different values of
errno for the same underlying failure (the last example above is EMFILE
vs. EINVAL, for instance). Some of the tests warn about this:

warning: the text of a system error message may vary between systems and
warning: produce diff output.


> $ exec  $ exit

You changed the shell's input -- from where it is reading commands -- to
/dev/null, the next read returned EOF, and the shell exited. It printed
`exit' so you know what's going on, just as if you had typed ^D at an
interactive shell prompt. This doesn't happen when you're executing a
script because the shell is reading commands from the script file.

> root@x065:[/data/prj/gnu/bash/bash-5.0.18]
> 
> ```
> 
> As you can see by the return of the original PS1 - the sub-shell
> (./bash) 'crashed' -- I did not type 'exit' - that is a result of the
> 'exec http://tiswww.cwru.edu/~chet/



Re: Bad substitution breaks conditional statement

2020-10-14 Thread Chet Ramey
On 10/13/20 11:43 PM, Martin Schulte wrote:

> Consider the following script:
> 
>>>>
> #!/bin/bash
> 
> echo "${x;:-}" ; echo "Not executed"
> echo "Executed"
> 
> echo "${x:-}" ;; echo "Not executed"
> echo "Not executed"
> <<<
> 
> It just a source of problems that the two syntactical errors (both caused by 
> an extra semicolon) lead to different behaviour.

They are not both syntax errors. The first is a word expanion error. The
second is a syntax error because `;;' is an operator and it's not valid in
that context.


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



Re: Bad substitution breaks conditional statement

2020-10-14 Thread Chet Ramey
On 10/13/20 4:42 PM, Martin Schulte wrote:
> Hi Chet, hi all!
> 
>> In general, variable expansion errors cause posix-mode shells to exit and
>> bash default mode shells to abort execution of the current command and
>> return to the top level, whether that is the command line or the next
>> command in the script. This aborts lists and other compound commands.
>> Bash has always behaved this way.
>>
>> However, invalid parameter transformation operators are not considered
>> fatal errors, even in posix mode. Maybe they should be.
> 
> Yes, please :-)

There are a couple of ways to go. The obvious one is to make it a fatal
error when non-interactive and non-fatal in interactive shells. The posix
mode setting should not matter because this is not a posix expansion.

> 
> Or no error at all.

No, that doesn't seem useful.

Chet

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



Re: Subject: Pressing Ctrl-C during any subshell evaluation terminates the shell

2020-10-13 Thread Chet Ramey
On 10/13/20 3:38 AM, felix wrote:
> Issue 627 in direnv's github project show:
> 
> To reproduce this simply:
> 
> PROMPT_COMMAND="trap -- '' SIGINT; sleep 0.1; trap SIGINT;"
> read foo
> ^C   -- will exit current shell --

Thanks, this is easy to work with.

The fix is to note that the shell is to set the default SIGINT handler for
interactive shells when running the second trap command, even though the
shell is not interactive while running PROMPT_COMMAND.

Chet

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



Re: Bad substitution breaks conditional statement

2020-10-12 Thread Chet Ramey
On 10/12/20 1:23 AM, Martin Schulte wrote:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-2bxm7h/bash-5.0=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wall 
> -Wno-parentheses -Wno-format-sec$
> uname output: Linux t1 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) 
> x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
> 
> Bash Version: 5.0
> Patch Level: 3
> Release Status: release
> 
> Description:
> 
> It looks as if a bad substitution detected inside a case of if continues the 
> script flow immediately after the conditional statement skipping the 
> remaining statements inside the conditional. Please take a look into section 
> "Repeat-By:".

In general, variable expansion errors cause posix-mode shells to exit and
bash default mode shells to abort execution of the current command and
return to the top level, whether that is the command line or the next
command in the script. This aborts lists and other compound commands.
Bash has always behaved this way.

However, invalid parameter transformation operators are not considered
fatal errors, even in posix mode. Maybe they should be.

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



Re: Subject: Pressing Ctrl-C during any subshell evaluation terminates the shell

2020-10-11 Thread Chet Ramey
On 10/9/20 7:23 PM, Daniel Farina wrote:

> Bash Version: 5.0
> Patch Level: 17
> Release Status: release
> 
> Description:
> 
> Pressing Ctrl-C during any subshell evaluation terminates the shell.  I
> noticed this when using direnv and emacs together: Ctrl-C would not cancel
> a subprocess started by the shell, but would exit the entire shell.
> 
> Relaying this from: https://github.com/direnv/direnv/issues/627
> 
> Repeat-By:
> 
> Per https://github.com/direnv/direnv/issues/627#issuecomment-635611930
> 
> $ cat bash.rc
> eval "$(direnv hook bash)"

What commands does this `direnv' command output?

> 
> $ bash --rcfile bash.rc
> bash$ echo $PROMPT_COMMAND
> _direnv_hook

What does `direnv_hook' do?

> bash$ $(sleep 10) # pressing ^C during those 10 seconds will terminate the
> shell
> ^C
> $ # inner shell terminated

My guess is that it messes with the controlling terminal somehow, causing
the shell to get EOF or -1/EIO when it attempts to read input.

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



Re: Bash-5.1-beta available

2020-10-08 Thread Chet Ramey
On 10/8/20 12:37 PM, Andreas Schwab wrote:
> On Okt 08 2020, Chet Ramey wrote:
> 
>> There's no good way to tell whether or not a terminal supports bracketed
>> paste, but I suppose this is as good a start as any. Remember that gdb
>> can always turn it off while running the test suite.
> 
> It needs to be controllable from the outside. 

It is controllable from the outside.

> the testsuite framework sets INPUTRC=/dev/null on purpose (to avoid any
> disturbance).

This is not a good general solution. What gdb is doing is relying on the
default readline settings to be appropriate, if not for every situation,
at least for running its tests. There's no way it can guarantee that such
an unrepresentative environment will handle the defaults, as we've seen
here.

It would be easy enough to use the standard INPUTRC=file mechanism to
control (and disable) what it needs.

Now, in the end, it's not going to matter here. Turning off bracketed paste
when the terminal name is "dumb" will probably work for gdb's purposes. The
thing is, it's probably going to bite someone else down the road.

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



Re: Bash-5.1-beta available

2020-10-08 Thread Chet Ramey
On 10/7/20 12:42 PM, Andreas Schwab wrote:
> On Sep 10 2020, Chet Ramey wrote:
> 
>> h. Bracketed paste mode is enabled by default (for now).
> 
> Shouldn't that be disabled on a dumb terminal?  This wrecks havoc on the
> gdb testsuite.  It sets TERM=dumb to tell readline not to do any fancy
> output, but this no longer works.

There's no good way to tell whether or not a terminal supports bracketed
paste, but I suppose this is as good a start as any. Remember that gdb
can always turn it off while running the test suite.


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



Re: Bash-5.1-beta available

2020-10-07 Thread Chet Ramey
On 10/7/20 12:42 PM, Andreas Schwab wrote:
> On Sep 10 2020, Chet Ramey wrote:
> 
>> h. Bracketed paste mode is enabled by default (for now).
> 
> Shouldn't that be disabled on a dumb terminal?  This wrecks havoc on the
> gdb testsuite.  It sets TERM=dumb to tell readline not to do any fancy
> output, but this no longer works.

Does gdb have access to set readline variables from its test suite? (Other
than specifying an INPUTRC file, of course.)

If so, it can run

rl_variable_bind ("enable-bracketed-paste", "off");


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



Re: Bash-5.1-beta available

2020-10-07 Thread Chet Ramey
On 10/7/20 12:42 PM, Andreas Schwab wrote:
> On Sep 10 2020, Chet Ramey wrote:
> 
>> h. Bracketed paste mode is enabled by default (for now).
> 
> Shouldn't that be disabled on a dumb terminal?  This wrecks havoc on the
> gdb testsuite.  It sets TERM=dumb to tell readline not to do any fancy
> output, but this no longer works.

The gdb test suite tests pasting?

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



Re: Broken $! behavior

2020-10-07 Thread Chet Ramey
On 10/7/20 7:56 AM, Paul Fox wrote:
> It seems like consecutive $! are mis-processed. This has always worked -
> since csh days and bash 1.x. But sometime after 4.1 or 4.2, it got broken.
> Heres my system info and version data

Thanks for the report. The shell rejects the second history expansion
because it takes it for a `$!' word expansion. I'll look at this after
bash-5.1 is released.

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



Re: background process in command substitution

2020-10-07 Thread Chet Ramey
On 10/7/20 10:39 AM, Hyunho Cho wrote:
> There are cases that need not wait until background process finish

Thanks. I'll look at this for a future version.

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



Re: Things that work in bash-5.0 but not work in bash-5.1-rc1

2020-10-07 Thread Chet Ramey
On 10/7/20 3:50 AM, Hyunho Cho wrote:
> < bash-5.0 >
> 
> $ read rows cols < <(stty size)

These are all the same issue. It's the same thing described in

https://lists.gnu.org/archive/html/bug-bash/2020-09/msg00024.html

I'll see if there is a partial solution to the issue that doesn't require
stdin to be set to /dev/null. You end up with this weird hybrid: an
asynchronous non-job-control process still connected to the terminal.


> < bash-5.0 >
> 
> $ ( trap 'uname' CHLD; date )
> Wed Oct  7 16:39:55 KST 2020
> Linux
> 
> < bash-5.1-rc1 >
> 
> $ ( trap 'uname' CHLD; date )   # some strange warning messages appear
> Wed Oct  7 16:40:05 KST 2020
> Linux
> bash: warning: run_pending_traps: recursive invocation while running
> trap for signal 17

You're comparing a debug message from a non-release version with a release
version.

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



Bash-5.1-rc1 available

2020-10-06 Thread Chet Ramey
oc now returns memory that is 16-byte aligned on 64-bit
systems.

4. New Features in Readline

a. If a second consecutive completion attempt produces matches where the first
   did not, treat it as a new completion attempt and insert a match as
   appropriate.

b. Bracketed paste mode works in more places: incremental search strings, vi
   overstrike mode, character search, and reading numeric arguments.

c. Readline automatically switches to horizontal scrolling if the terminal has
   only one line.

d. Unbinding all key sequences bound to a particular readline function now
   descends into keymaps for multi-key sequences.

e. rl-clear-display: new bindable command that clears the screen and, if
   possible, the scrollback buffer (bound to emacs mode M-C-l by default).

f. New active mark and face feature: when enabled, it will highlight the text
   inserted by a bracketed paste (the `active region') and the text found by
   incremental and non-incremental history searches.

g. Readline sets the mark in several additional commands.

h. Bracketed paste mode is enabled by default (for now).

i. Readline tries to take advantage of the more regular structure of UTF-8
   characters to identify the beginning and end of characters when moving
   through the line buffer.

j. The bindable operate-and-get-next command (and its default bindings) are
   now part of readline instead of a bash-specific addition.

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



Re: coproc does not work in subshell

2020-10-02 Thread Chet Ramey
On 10/2/20 7:59 AM, Hyunho Cho wrote:

> bash$ ( echo "1 + 5" >& ${COPROC[1]}; read -r <& ${COPROC[0]}; echo
> $REPLY )  # ERROR : subshell does not work
> bash: ${COPROC[1]}: Bad file descriptor
> bash: ${COPROC[0]}: Bad file descriptor
> 3

Yes, this is correct. Subshells close coproc file descriptors they inherit.
This is to prevent deadlock and processes not terminating because there are
still open file descriptors to child processes. If you want to manage the
file descriptors yourself, you can dup the coproc file descriptors and make
sure they're closed appropriately for your needs.

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



Re: execve E2BIG (Argument list too long)

2020-09-30 Thread Chet Ramey
On 9/30/20 3:12 AM, Michael Green wrote:

> Bash Version: 5.0
> Patch Level: 17
> Release Status: release
> 
> Description:
> 
> The included short script when run with the following command results
> in execve "E2BIG (Argument list too long) errors".

The argument list includes the size of the environment, and your script
creates a huge environment variable.

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



Re: Change in indirect expansion behavior from 4.4 to 5.0

2020-09-30 Thread Chet Ramey
On 9/30/20 12:28 AM, Jason Miller wrote:
> Gentoo linux, GNU bash, version 5.0.18(1)-release (x86_64-pc-linux-gnu)
> 
> On the above vesion of bash, the following script will not run the echo 
> command
> and print an error.  On bash 4.4 it appears to  treat the ${!foo} the same as
> expanding an unset variable and thus outputs "bar":
> 
>   unset foo
>   echo ${!foo} bar

This is the result of

https://lists.gnu.org/archive/html/bug-bash/2016-11/msg00123.html

I explained the reasoning in

https://lists.gnu.org/archive/html/bug-bash/2016-11/msg00165.html

The basic idea is that indirect expansion is just a string substitution,
so indirecting an unset variable is the logically same thing as ${},
which is an expansion error.

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



Re: Implement BASH_DIRTRIM_TEXT

2020-09-29 Thread Chet Ramey
On 9/28/20 1:54 PM, Mustafa Mohamad wrote:
> 
> See for example 
> https://github.com/zaufi/paludis-autopatches/blob/master/ebuild_unpack_post/app-shells/bash/bash-4.2-unicode-triple-dot-trim-path.patch
> 
> Which replace the default '...' text w/ a single unicode character '…'
> 
> I propose adding such an option in future version to make it much easier to 
> change this.

Thanks for the suggestion.

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



Re: Confusing documentation of `ENV` in section "Bash variables"

2020-09-23 Thread Chet Ramey
On 9/22/20 6:27 PM, Reuben Thomas via Bug reports for the GNU Bourne Again
SHell wrote:
> The documentation says:
> 
> 'ENV'
>  Similar to 'BASH_ENV'; used when the shell is invoked in POSIX Mode
>  (*note Bash POSIX Mode::).

Hmmm, I can see that. How about, as you suggest, something like

"Expanded and executed similarly to BASH_ENV when an interactive shell is
invoked in POSIX Mode."

The behavior is described pretty completely in the INVOCATION section.


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



Re: O_DIRECT "packet mode" pipes on Linux

2020-09-23 Thread Chet Ramey
On 9/22/20 11:23 PM, Vito Caputo wrote:
> Hello list,
> 
> Is there any chance we could get a | modifier for enabling O_DIRECT on the
> created pipe?  "Packet" style pipes have some interesting and potentially
> useful properties, it would be nice if bash made them more accessible.

Is there a general need, especially since they're Linux-specific? What kind
of modifier would you suggest?

Does anyone want to take a shot at implementing this idea?


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



Re: bash -c 'sleep 5 &' vs. ssh user@host 'sleep 5 &'

2020-09-22 Thread Chet Ramey
On 9/22/20 5:07 AM, Robert Elz wrote:

>   | Then, how should we explain that
>   |
>   |   $ ssh -t 127.0.0.1 'sleep 120 &'
>   |
>   | would complete immediately?
> 
> With -t, there's no pty
The opposite -- -t forces pty allocation.

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



Re: Build fails with Xcode 12

2020-09-22 Thread Chet Ramey
On 9/21/20 11:57 AM, Adam Stewart wrote:
> Thanks Chet,
> 
> That patch did the trick! All tests pass now. Thanks again for your help!

Glad to help.

> P.S. I'm going to add this patch to the Spack package manager. Would you or 
> anyone else be interested in "maintaining" Spack's bash build recipe? You 
> don't have to be a Spack expert, it just gives us someone to ping when users 
> report build errors or submit PRs to modify the recipe. If so, just send me 
> your GitHub handle(s).

I'm going to have to decline, sorry.

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



Re: Build fails with Xcode 12

2020-09-21 Thread Chet Ramey
On 9/21/20 11:13 AM, Adam Stewart wrote:
> Thanks Chet,
> 
> When I apply your patch it solves the string.h issue but now I see an issue 
> with _stdio.h:

[...]

> 
> Do you have a patch for this as well?

I have a combined patch. You can apply the second hunk.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
*** ../bash-5.0-patched/aclocal.m4  2018-12-05 09:31:34.0 -0500
--- aclocal.m4  2020-09-21 09:23:20.0 -0400
***
*** 301,305 
  AC_CACHE_VAL(bash_cv_have_strsignal,
  [AC_TRY_LINK([#include 
! #include ],
  [char *s = (char *)strsignal(2);],
   bash_cv_have_strsignal=yes, bash_cv_have_strsignal=no)])
--- 301,306 
  AC_CACHE_VAL(bash_cv_have_strsignal,
  [AC_TRY_LINK([#include 
! #include 
! #include ],
  [char *s = (char *)strsignal(2);],
   bash_cv_have_strsignal=yes, bash_cv_have_strsignal=no)])
***
*** 4069,4072 
--- 4070,4074 
[AC_TRY_RUN([
  #include 
+ #include 
  
  main()


Re: Build fails with Xcode 12

2020-09-21 Thread Chet Ramey
On 9/19/20 12:45 PM, Adam Stewart wrote:
> I recently updated to Xcode 12 on macOS 10.15.6. Xcode 12 comes with Apple 
> Clang 12.0.0 (LLVM Clang 10.0.0), which fails to compile bash 5.0.18. This 
> can be reproduced with the typical `./configure; make; make install` logic. 

Thanks for the report. I just upgraded to Xcode 12 myself. This was fixed
about a year ago in the bash devel branch, and the fix is in bash-5.1,
currently in beta.

If you want to test the fix yourself, I've attached a patch to aclocal.m4.
You'll have to run `autoconf' to regenerate `configure', then re-run
`configure'.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
*** ../bash-5.0-patched/aclocal.m4  2018-12-05 09:31:34.0 -0500
--- aclocal.m4  2020-09-21 09:23:20.0 -0400
***
*** 301,305 
  AC_CACHE_VAL(bash_cv_have_strsignal,
  [AC_TRY_LINK([#include 
! #include ],
  [char *s = (char *)strsignal(2);],
   bash_cv_have_strsignal=yes, bash_cv_have_strsignal=no)])
--- 301,306 
  AC_CACHE_VAL(bash_cv_have_strsignal,
  [AC_TRY_LINK([#include 
! #include 
! #include ],
  [char *s = (char *)strsignal(2);],
   bash_cv_have_strsignal=yes, bash_cv_have_strsignal=no)])


Re: Bash-5.1-beta available

2020-09-18 Thread Chet Ramey
On 9/17/20 5:13 PM, Robert Elz wrote:

>   | I don't have list-specific email configs.
> 
> Are there any lists for which you want to direct replies to yourself
> rather than the list? 

That doesn't have much to do with my email configs, which are not specific
to mailing lists, since those constitute a small portion of my email.

  And aside from me, do you encounter almost anyone
> whose MUA actually implements Reply-To properly, and replies only to you?

I don't pay a lot of attention to it.


>   | Because that's where the incentives are. Nobody cares if you implement
>   | "what is right" if you fail a standards conformance test.
> 
> I guess that depends upon your objectives.   I don't care in the
> slightest about conformance tests, or their results - which is why
> I won't implement "cd -L" and why NetBSD refuses to supply exec'able
> forms of "cd" "umask" ...

Sure, but others do. You're fortunate not to have to.


>   | Then the standard needs to be clarified, doesn't it?
> 
> Yes, we were kind of at that point earlier ... and we know the result
> can only be "unspecified" which isn't really very helpful.

You never know. Geoff might just say "well, it's obviously this."

> It would be nicer if before that happens we could just agree on what
> is the better result, and do that, and try to get mksh and ksh93 to
> do the same.   Then perhaps the standard would not need to say "unspecified".

We already have two camps, and netbsd/freebsd/historical sh are the ones
that print \"A\". Bash (current beta version), yash, dash, ksh93, and mksh
print "A".

Chet

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



Re: Bash-5.1-beta available

2020-09-17 Thread Chet Ramey
On 9/16/20 6:45 PM, Robert Elz wrote:
> Date:Wed, 16 Sep 2020 11:35:41 -0400
> From:    Chet Ramey 
> Message-ID:  <210592e5-f42c-32ee-7c85-9418d3e29...@case.edu>
> 
>   | That's what gives the impression that the standards committees are a
>   | private club.
> 
> This one isn't confined to the standards industry, it exists everywhere.
> At a particular time, in a particular community, there tends to be a
> common understanding of all kinds of things.  Different time, different
> community, and that understanding just isn't there any more.

That's why I find yash so interesting to test against. It's written by
someone with almost no contact with the standards community, yet attempts
to implement the letter of POSIX.


>   | I read it all. The hills are littered with bodies.
> 
> Would be nice if you could delete the Reply-To your messages all
> carry, since it is (every time I have seen anyway) the same as the
> From it is useless if intended as a From replacement, and I kind of
> doubt that you always want to request that no-one reply to the list.

I don't have list-specific email configs.

> 
>   | The problem is the standard has changed over the years, and now we all
>   | have compatibility issues dealing with past attempts to implement what
>   | ended up being a moving target.
> 
> Yes, that is a problem.  Partly caused by trying to implement the
> standard, instead of implementing what is right, and then making sure
> the standard says what is implemented.

Because that's where the incentives are. Nobody cares if you implement
"what is right" if you fail a standards conformance test.


>   | Of course it can. It can check and throw an error if desired.
> 
> That isn't ensuring that there are an even number of quotes, it is
> objecting when there aren't.  The two are related, but are not the
> same thing.

The  shell implementation still has to do something, even if the user is
supposed to ensure it, and that something really should try to reflect what
the user intends (determining that is always a tricky business).

> But to go back to the original issue, in a here-doc, the " is always just
> a character, it is never special, and hence a \" combination in a here doc
> (except in those cases where a new quoting context is established - which
> it isn't in a ${foo+word} expansion - never has been) should always
> generate \"

Then the standard needs to be clarified, doesn't it? Current experience
shows the wording to be ambiguous, since the world is divided into two
camps here.

Chet

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



Re: Bash-5.1-beta available

2020-09-16 Thread Chet Ramey
On 9/15/20 2:09 PM, Robert Elz wrote:
> Date:Tue, 15 Sep 2020 11:47:58 -0400
> From:    Chet Ramey 
> Message-ID:  
>
>
>   | This wouldn't be the first time the standard relied on readers
>   | drawing an inference that's not explicit.
>
> No, it isn't.  It is really hard to avoid that however, as quite often
> when the text is written, everyone simply assumes that the meaning is
> obvious.

That's what gives the impression that the standards committees are a
private club. Well, that and the "it was a bad idea in 1988, so it's
a good idea now!"

> Same with the Reply-To discussion happening on the austin list
> (where it doesn't really belong, and wouldn't have happened if they
> hadn't butchered the list) where the ancient text in RFC822 has been
> read to justify behaviour that makes no sense, and was never intended.
> (And I really hope that you personally are paying attention!)

I read it all. The hills are littered with bodies.

>
>   | when no-one is relying
>   | > upon stuff like
>   | > "${var:-"unquoted-text"}"
>   | > any more.
>   |
>   | I don't think you can rely on this right now.
>
> No you can't.   The standard says (or is going to say) it is unspecified,
> and some implementations have started doing bizarre things.  It certainly
> never documented the weird 7th edn sh (and everything else in the early days)
> behaviour.

The problem is the standard has changed over the years, and now we all
have compatibility issues dealing with past attempts to implement what
ended up being a moving target.

>
> My point was that even though this usage has become obsolete, we
> can't fix the quoting anyway, because of "${var:-text that is quoted}"
>
>   | The last time we talked about the "even number" sentence, we all just
>   | hand-waved it away by characterizing it as an "application requirement,"
>
> Yes, but there's nothing else it can be, even with:
>
>   | even though there's no mention of "the application shall ensure" there.
>
> as if there's a requirement, then either the implementation or the
> application (or both) needs to be bound by it.

That's the issue. Even if it's an application requirement, the shell
implementation still has to do some enforcement, and that means checking
that embedded quotes are properly paired.


   Here the implementation
> can't ensure there are an even number of quotes, it isn't writing the
> text, so this has to be directed at the application.

Of course it can. It can check and throw an error if desired.

>
> The implementation can error out if it wants if it detects the error
> (I don't think anyone does) but the error is that of the application.
> It must be.

But that doesn't matter. The burden is still on the implementation to check
it and react accordingly. Previous versions of the standard required it.

>   | The xyz is semi-quoted, because no matter what else the inner quotes
might
>   | do, they are supposed to prevent recognizing the closing brace. If it
were
>   | not `xyz' but `x}z', the inner quotes are supposed to `protect' the brace
>   | there.
>
> Actually I disagree (and not because you used backticks as opening quotes
> there).

It's a typographical convention of many years.

>
> There's no issue in something like
>
>   ${var-"}"}
>
> in that one there is an enclosed quoted string (whether double or
> single quoted - backslash quoted works too). but in
>
>   "${var-"}"}"
>
> there is no enclosed quoted string, the (lexically) second " char either
> closes the quoted string opened by the first, or has unspecified behaviour,
> but it isn't creating a new quoted string.

It might be unspecified in the current draft of the upcoming version of the
standard, or at some time in the future, but even the currently published
version of the standard talks about embedded quoted strings without
qualification. It's unclear whether or not the standard really means the
quotes within the braces constitute a separate quoted string, but there is
broad consensus that the inner pair of double quotes prevent the brace from
ending the parameter expansion.


> (I think it glosses over the \
> escaping rules in "" strings though, the '}' needs to be added to the list
> of chars that \ escapes, and I don't think that is ever explicitly done, it
> is simply implied that it ought to work that way).

The current standard says

"an even number of unescaped double-quotes or single-quotes, if any, shall
occur. A preceding  character shall be used to escape a literal
'{' or '}'"

so it's there.


>   | The current version of the standard makes that clear, shells have
>   | implemente

Re: Do a readline function execution inside bash

2020-09-15 Thread Chet Ramey
On 9/14/20 9:57 PM, Budi wrote:
> simply run a readline function among lines codes of bash script such a
> menu-complete, or menu-complete repeated thrice, or etc etc

In this model, where would readline get its data? Readline functions
operate on pieces of an input line, or an entire input line, so where
would this line come from?

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



Re: Bash-5.1-beta available

2020-09-15 Thread Chet Ramey
On 9/14/20 2:56 PM, Robert Elz wrote:

>   | "However, the double-quote character ( '"' ) [edited, since the HTML on 
> the
>   | web site is malformed]
> 
> So it is, what a mess, the pdf formatted version is fine, so that is just
> a conversion error.   Wonder if it is fixed yet?   If not you should file
> an Online Pubs bug about it.  I know some similar ones were fixed, but
> I don't see any immediate mention of that one (ref bugs 955 & 1060 for
> similar issues).
> 
>   | shall not be treated specially within a here-
>   | document, except when the double-quote appears within "$()", "``", or
>   | "${}"."
> 
> The first $() is clear, that starts a new quoting context,  just thinking
> about the 2nd almost makes my head explode, I have no idea what should be
> done with that one, or how it can be justified, the ${} case (since it is
> in a here doc, is already quoted, and hence the only defined quotes are
> after # ## % or %% operators - so that's what it must be referring to).

Plausible, perhaps likely. But it's not clear. This wouldn't be the first
time the standard relied on readers drawing an inference that's not
explicit.


> For a long time I was hoping that by making what happens with quotes inside
> a var expansion (the substring forms excepted) unspecified, and hence not
> something that applications can rely upon, would mean that eventually (perhaps
> way into the future) shells would be able to do things properly, rather than
> all follow the original shell because scripts break otherwise(the reason
> apparently that Korn switched ksh back from sane) when no-one is relying
> upon stuff like
>   "${var:-"unquoted-text"}"
> any more.

I don't think you can rely on this right now. The only thing the currently-
published version of the standard dares to say about that is "an even
number of unescaped double quotes shall occur" and the "matching closing
brace shall be determined by ... skipping over enclosed quoted strings ...".

The last time we talked about the "even number" sentence, we all just
hand-waved it away by characterizing it as an "application requirement,"
even though there's no mention of "the application shall ensure" there.
The upcoming issue8 makes it explicitly unspecified, but the damage is
already done.

The situation with the "matching closing brace" text isn't any better.
The word "enclosed" is gone in the current draft, but "quoted string"
is still there, and we still have shells implementing the current
standard's language.

It's all just a mess, and the standard is avoiding saying anything definitive.


> I'm rambling   Never mind.

:-)


> So that just leaves
>   ${foo+"xyz"}
> 
> Interpreting those double quote chars as quoting the xyz in a here doc,
> when, whatever they do, they definitely don't quote the xyz elswhere if
> (to emulate a here doc) this appears in a double quoted string
> 
>   "${foo+"xyz"}"
> 
> whatever those "inner" quotes do (original Bourne shell had ${foo+ quoted,
> and the final }, and xyz unquoted), these days almost anything is possible,
> except for making xyz quoted (it would be without the inner double quotes).

The xyz is semi-quoted, because no matter what else the inner quotes might
do, they are supposed to prevent recognizing the closing brace. If it were
not `xyz' but `x}z', the inner quotes are supposed to `protect' the brace
there. The current version of the standard makes that clear, shells have
implemented it that way, and I'm sure there are scripts somewhere that rely
on it.

> Anyway, making the quotes when they appear in a here doc become quoting
> chars, when they don't when not in a here doc, when in a here doc double
> quote chars normally aren't quoting chars, would be simply bizarre.
> 
> If POSIX needs even more attention to this, then I guess that's what we
> need to do (but we know that as soon as we do that, the result will be
> that the meaning will become unspecified...)

There's no meaning now! At least if it's explicitly unspecified we can at
some point -- maybe -- specify something. And who knows? The discussion
may prove illuminating.

Chet

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



Re: Bash-5.1-beta available

2020-09-14 Thread Chet Ramey
On 9/13/20 4:51 PM, Robert Elz wrote:

>   | The specific construct is
>   |
>   | P=A
>   | cat <   | ${P+\"$P\"}
>   | EOF
> 
> That should output \"A\"

OK, let's discuss it.

> 
>   | In this case, the usual proscription on double quotes in here-documents
>   | does not apply, since the double quote appears within ${}.
> 
> Huh?   Where does that come from, at best a " inside a quoted ${} is
> unspecified.   But in a here doc, " is simply not a quoting char at all.

"However, the double-quote character ( '"' ) [edited, since the HTML on the
web site is malformed] shall not be treated specially within a here-
document, except when the double-quote appears within "$()", "``", or
"${}"."

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04

That implies that the double quote *is* treated specially when it appears
within a ${} expansion inside the body of a here-document, so the backslash
quotes it. The question is how special [insert eye-roll emoji], and what
rules you follow. It seems like shells follow the double-quoting rules if
they follow any.

(There's also whether or not the double quotes in the above text are
grammatical or syntactically significant.)

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



Re: Bash-5.1-beta available

2020-09-14 Thread Chet Ramey
On 9/13/20 2:45 PM, Andreas Schwab wrote:
> You have a regression here though:
> 
> cat < \"
> EOF

Thanks, you're right. I'll take a look.

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



Re: Feature request: Enable possibility of colored stderr output

2020-09-14 Thread Chet Ramey
On 9/13/20 5:59 AM, A M wrote:
> Hello, I would like to submit a feature request/suggestion on Bash. (I was
> told submitting to this mailing list was the right way to do it.)
> 
> Feature request: Enable possibility of colored stderr output.

Let's separate the two cases: bash coloring its own output to stderr, which
is usually warnings and errors, and output to stderr by processes bash runs.

We can discard the latter case right away -- bash doesn't, and shouldn't,
have any effect on another process's stderr other than redirecting it.
That's something that should be left to the other process. If you really
want it, you can do things outside of bash itself to achieve it.

The first case is different: would there be any advantage to having bash
color its own error messages? And how about other information that gets
printed to stderr, like warnings or job status messages?


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



Re: Bug in aclocal.m4 / configure ? BASH_STRUCT_WEXITSTATUS_OFFSET

2020-09-14 Thread Chet Ramey
On 9/13/20 6:17 PM, Andreas K. Hüttel wrote:
> Hi, 
> 
> in aclocal.m4 (and thus also configure), the test for 
> BASH_STRUCT_WEXITSTATUS_OFFSET contains
> 
>   /* crack s */
>   for (i = 0; i < (sizeof(s) - 8); i++)
> 
> Shouldnt this be 
> 
>   /* crack s */
>   for (i = 0; i < (sizeof(s) * 8); i++)
> 
> (* instead of -), see attached trivial patch? The minus sign makes no sense 
> at 
> all since even on x86-64 sizeof(int)=4 ...

Yes, thanks. It's a typo, but has no effect on obtaining the right answer.
On some weird yet-to-be-encountered system, if the exit status were not
available at some offset in the status word, it would result in an infinite
loop.

Chet


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



Re: Bash-5.1-beta available

2020-09-13 Thread Chet Ramey
On 9/13/20 8:21 AM, Andreas Schwab wrote:
> On Sep 10 2020, Chet Ramey wrote:
> 
>> qqq. Fixed a bug that could cause backslashes quoting double quotes in here
>>  document bodies to not be removed when expanding the body.
> 
> Are you sure about this?  My reading of POSIX says that a backslash
> before a double quote should not be removed, as double quotes are not
> special in here docs.

The specific construct is

P=A
cat <https://lists.gnu.org/archive/html/bug-bash/2019-01/msg00193.html .

In this case, the usual proscription on double quotes in here-documents
does not apply, since the double quote appears within ${}.

This change makes the above and

echo "${P+\"$P\"}"

echo the same thing.

The bash-5.1 behavior is consistent with what other shells claiming POSIX
conformance, except the BSD ash-based shells, produce. There's pretty wide
variance in behavior between shells with all of the variants of putting a
double quote inside a parameter expansion inside a here-document, and
POSIX has basically thrown its hands in the air in disgust.

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



Re: Bash-5.1-beta available

2020-09-11 Thread Chet Ramey
On 9/11/20 6:39 AM, Andreas Schwab wrote:
> On Sep 10 2020, Chet Ramey wrote:
> 
>> yy. Process substitution processes now get their input from /dev/null, since
>> they are asynchronous, not interactive, and not jobs.
> 
> That breaks scripts that want to filter stdin with a process
> substitution, eg:
> 
> while read ...; do ...; done < <(filter)
> 
> The reason for using a process substitution is so that the loop can set
> shell variables.

The problem is that asynchronous processes should not be able to change
the terminal or terminal settings, and you don't want the process
substitution and parent process to be trying to read from the terminal at
the same time. Job control and process groups usually take care of that,
but process substitution is not a job control process and runs in the same
process group (and terminal process group) as the parent.

Look at something like

https://lists.gnu.org/archive/html/bug-bash/2019-09/msg00061.html

Maybe it would be better to do this only if the shell is interactive and
the standard input is a terminal.

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



Bash-5.1-beta available

2020-09-10 Thread Chet Ramey
fault bindings) are
   now part of readline instead of a bash-specific addition.

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



Re: How get last commnda history line number directly

2020-09-08 Thread Chet Ramey
On 9/6/20 4:18 PM, L A Walsh wrote:

> history 3
> 2983  echo "this is on what history line? ($HISTCMD)"
> 2984  echo $(($HISTCMD-2))
> 2985  history 3
> 
> Seems to only give correct line from history by subtracting 2?
> Maybe its different in 5.x?

When readline stores history entries, it stores them in an array starting
from 0, and it increments the history number after storing an entry so it's
an accurate count of the number of entries in the list. That means the
history number has to be offset somehow if it's already been stored and the
number of entries has been incremented.

When bash implements command-oriented history, it has to manage using the
same history entry as the first line of the command, after the history
library has already incremented the history number. The same thing happens
when it implements literal history.

There are two cases to consider: the expansion is being performed as part
of PS1 or another prompt expansion, in which case the shell should use the
current history number (unless the line is part of a multi-line command),
or whether it's being expanded as part of command execution, in which case
the history entry has already been stored and the history number has to be
offset.

I made several changes in early 2017 based on

https://lists.gnu.org/archive/html/bug-bash/2017-03/msg00081.html

and bash-5.1 will have additional changes for $HISTCMD.

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



Re: How get last commnda history line number directly

2020-09-01 Thread Chet Ramey
On 9/1/20 5:14 AM, almahdi wrote:
> How to get last commnda history line number purely & directly on bash script
> or prompt ?
> 
> as it's pure & directly viable in PS1 env. var.
> PS1=`echo \!`

HISTCMD
   The history number, or index in the history list, of the current
   command.  Assignments to HISTCMD are ignored.  If HISTCMD is un-
   set, it loses its special properties, even if it is subsequently
   reset.

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



Re: Bash parameter expansion (remove largest trailing match, remove largest leading match, pattern replacement) does not work

2020-08-31 Thread Chet Ramey
On 8/29/20 9:12 PM, Lawrence Velázquez wrote:

>> Actually, it works (portably) with
>> separator2=$'\057'
> 
> (a) $'...' is not POSIX. For instance, dash does not recognize it.

I believe it made the cut and will be in the next edition of the standard.


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



Re: Bash parameter expansion (remove largest trailing match, remove largest leading match, pattern replacement) does not work

2020-08-31 Thread Chet Ramey
On 8/29/20 3:54 PM, Bruce Lilly wrote:

> It's a bit more complicated than that; if, for example, some excerpt ended
> up in regression tests, there would be a question about whether or not
> there was a copyright violation.

This is not at all the same thing, and could (and would) be handled
separately.

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



Re: Bash parameter expansion (remove largest trailing match, remove largest leading match, pattern replacement) does not work

2020-08-31 Thread Chet Ramey
On 8/29/20 3:25 PM, Bruce Lilly wrote:
> Unfortunately, because bash is GPL, I can't post the copyrighted script
> which is covered by a non-GPL license.

This is ridiculous on its face. A script that bash executes doesn't have
any relevance to bash's copyright.

You might have reasons for not wanting to publicly post a copyrighted
script, but bash being GPL is not one of them.

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



Re: Bash parameter expansion (remove largest trailing match, remove largest leading match, pattern replacement) does not work

2020-08-31 Thread Chet Ramey
On 8/29/20 10:22 AM, Bruce Lilly wrote:

> Bash Version: 5.0
> Patch Level: 17
> Release Status: release
> 
> Description:
>Bash parameter expansion (remove largest trailing match, remove
> largest leading match, pattern replacement) does not work
> Tested on OpenSUSE Leap 15.2, bash version 4.4.2.3(1)-release
> (x86_64-suse-linux-gnu)
> OpenBSD 6.7 bash version 5.0.17(1)-release (x86_64-unknown-openbsd6.7)
> NetBSD 9.0 bash version 5.0.17(1)-release (x86_64--netbsd)
> FreeBSD 12.1-STABLE bash version 5.0.18(2)-release (amd64-portbld-freebsd12.1)
> 
> Same results in all cases; this report posted from NetBSD 9.0.

There are a number of things wrong with this report; I think later messages
in the thread cover them. In short,

1. BRE bracket expression matching doesn't perform backslash-interpretation
   of anything, except to quote the next character, much less octal
   constant expansion;
2. You need `shopt -s extglob' to enable the pattern matching you want to
   use.

Chet

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



Re: Incorrect / Inconsistent behavior with nameref assignments in functions

2020-08-31 Thread Chet Ramey
On 8/28/20 11:28 AM, Greg Wooledge wrote:

> 
> You've got a local variable with the same name as the global variable
> that you're attempting to pass by reference.  This will not work.
> 
> Namerefs (declare -n) in bash are *not* like uplevel commands in Tcl.
> They cause the referenced variable name to be evaluated just like any
> other variable would be, starting at the current function scope, then
> going up to the caller, and so on.

Namerefs don't change bash's dynamic variable scoping. The two conflict
and make namerefs less useful than they might be.

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



Re: Incorrect / Inconsistent behavior with nameref assignments in functions

2020-08-31 Thread Chet Ramey
On 8/28/20 4:56 AM, Binarus wrote:

> Bash Version: 4.4
> Patch Level: 12
> Release Status: release
> 
> 
> Description:
> 
> 
> Under certain circumstances, assignments of namerefs to local variables
> in functions behaves in a way which makes namerefs completely useless.
> Furthermore, the behavior is not consistent.

There is an order of evaluation problem as explained later in the thread,
not specific to namerefs. It's fixed in bash-5.1.

The underlying issue is making `declare [options] foo=bar' expand the
argument like an assignment statement as POSIX specifies. This makes
`declare' more like a hybrid reserved word instead of a builtin. In some
cases, the options matter and affect how the argument gets expanded. You
end up having to do something like `declare [options] foo; foo=bar' to get
the expansion right, but that introduces several corner cases.

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



Re: [PATCH] Fix segfault with self-modifying array PROMPT_COMMAND

2020-08-31 Thread Chet Ramey
On 8/30/20 9:36 PM, Koichi Murase wrote:

> Bash Version: 5.1
> Patch Level: 0
> Release Status: release
> 
> Description:
> 
>   In the devel branch (e4d38c2d: commit bash-20200819 snapshot), a
>   segmentation fault occurs when a prompt command stored in the array
>   version of PROMPT_COMMAND unsets the corresponding element in
>   PROMPT_COMMAND.

Thanks for the report.

Chet


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



Re: [PATCH] Bash 5.0+: Fix a problem that interactive sessions close with `eval {'

2020-08-31 Thread Chet Ramey
On 8/27/20 8:33 PM, Koichi Murase wrote:

> Bash Version: 5.1
> Patch Level: 0
> Release Status: release
> 
> Description:
> 
>   When a command string with an incomplete construct is supplied to
>   the `eval' builtin in interactive sessions, the process will be
>   terminated.  This does not happen before Bash 5.0.  This does not
>   happen in non-interactive modes.

Thanks for the report. I appreciate your attention to detail.

Chet

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



Re: Is this a bug?

2020-08-26 Thread Chet Ramey
On 8/25/20 8:21 PM, George R Goffe wrote:

> I could try running strace during all of this. Would it help?

It might indicate the order in which things are happening.


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



Re: Is this a bug?

2020-08-26 Thread Chet Ramey
On 8/25/20 3:47 PM, George R Goffe wrote:
> Chet,
> 
> I appreciate your help with this.
> 
> Do "we" know that bash IS trying to generate an alarm?

Yes, we are fairly sure that bash is trying to `ring' the bell. When I
run

bind 'set bell-style audible'

and type the common prefix of a set of filenames in the current directory,
then hit TAB, bash rings the bell.

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



Re: Is this a bug?

2020-08-24 Thread Chet Ramey
On 8/24/20 4:15 PM, George R Goffe wrote:
> Chet,
> 
> I'm not seeing any visual "bells". The audio part of this computer is 
> broken... NO sound...

I'm not sure what I can do about that. If the visual bell doesn't work and
the sound is broken, you're not going to get much of an indication no
matter what you do.

Chet

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



Re: Bug with new lines

2020-08-24 Thread Chet Ramey
On 8/24/20 3:05 PM, Шкіпер Десна wrote:
> Hello!
> If I use something like `user@localhost:/folder$ echo -n 123`, then in a
> new line before 'user...' I see '123', but it's yet normal, but if I use
> something like `user@localhost:/folder$ echo -n $(echo 123)` or
> `user@localhost:/folder$ printf %s 123`, it may seem that everything is in
> order, but if I tap up (to copy previous command) and then tap down (to
> back), Bash will leave from start so many chars, like 'user@localhost:/folder$
> ' has, i.e., I'll get 'user@localhost:/folde'. The only way to repair it is
> to press "enter". If I just press up after `user@localhost:/folder$ printf
> %s 123`, then nothing unusual happens — it appends the previous command
> after '...$ ', like usual ('123' in the beginning doesn't disappear). If I
> tap it again, some many times, again nothing unusual, but once it will cut
> the ending of 'user@localhost:/folder$ '. I don't know exactly where the
> logic is. If I tap up twice or more, but the ending yes hasn't been
> clipped,  I can tap down and it won't be clipped, for except the last tap,
> when I get the current command.

This isn't a bug. Readline assumes it can use the entire line for redisplay
and that it starts in column 0. Any text can be overwritten otherwise.

Here are a few links to recent discussions of the issue.

https://lists.gnu.org/archive/html/bug-bash/2020-01/msg5.html
https://lists.gnu.org/archive/html/bug-bash/2020-02/msg2.html

Chet

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



Re: Feature request: Enable case-insensitive reverse-search-history (C-r)

2020-08-24 Thread Chet Ramey
On 8/20/20 12:13 PM, A M wrote:
> Hello, I would like to make a feature request/suggestion on Bash. (I was
> told submitting to this mailing list was the right way to do it.)
> 
> Feature request: Enable reverse-search-history (C-r) to be case-insensitive.
> 
> Currently reverse-search-history is case-sensitive and cannot be changed to
> be insensitive. As the evolution of Bash has progressed, more and more
> functions have gotten the ability to be case-insensitive, but this is a
> function that remains it seems.
> 
> It would be nice to have this functionality.

Thanks for the suggestion. I would probably do it with an option that made
all searches case-insensitive instead of adding case-insensitive versions
of a number of search commands.



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



  1   2   3   4   5   6   7   8   9   10   >