Well
┌─none:/home/phi
└─PW$ type sleep
sleep is hashed (/usr/bin/sleep)
So sleep is not a builtin here.
Strange, on BASH_VERSION='5.1.16(1)-release' sleep don't get interupted by
SIGWINCH
┌─none:/home/phi
└─PW$ trap 'echo $LINES.$COLUMNS' SIGWINCH
┌─none:/home/phi # Resizing window here
└─PW$ 79.80
└─PW$ 78.80
└─PW$ 77.80
└─PW$ 76.80
└─PW$ 75.80
^C
┌─none:/home/phi
└─PW$ sleep # Resizing w
The sleep builtin currently doesn't do much in the way of signal
management, so for example it will return on SIGWINCH, which I think most
users will be particularly surprised by the first time they notice a sleep
ending early due to a window resize.
I looked at adding more signal handling to the
On Fri, Jun 30, 2023, 05:16 Eli Schwartz wrote:
> On 6/29/23 4:39 PM, Chet Ramey wrote:
> > On 6/25/23 2:38 PM, Eli Schwartz wrote:
> >> compgen is a useful builtin for inspecting information about the shell
> >> context e.g. in scripts -- a good example of this is compgen -A function
> >> or com
On 6/29/23 4:39 PM, Chet Ramey wrote:
> On 6/25/23 2:38 PM, Eli Schwartz wrote:
>> compgen is a useful builtin for inspecting information about the shell
>> context e.g. in scripts -- a good example of this is compgen -A function
>> or compgen -A variable.
>>
>> But it's not always available depend
On Thu, 29 Jun 2023 16:39:52 -0400
Chet Ramey wrote:
> On 6/25/23 2:38 PM, Eli Schwartz wrote:
> > compgen is a useful builtin for inspecting information about the shell
> > context e.g. in scripts -- a good example of this is compgen -A function
> > or compgen -A variable.
> >
> > But it's not
On 6/26/23 8:07 AM, Martin D Kealey wrote:
hmm, declare -p used to print an array like
ˋˋˋ
declare -a array='([0]="value" [1]="value")'
ˋˋˋ
At some stage declare -p stopped printing the extra outer quotes, so that
my approach also stops working.
Back in bash-4.4.
There was a huge discussion on
On 6/25/23 2:38 PM, Eli Schwartz wrote:
compgen is a useful builtin for inspecting information about the shell
context e.g. in scripts -- a good example of this is compgen -A function
or compgen -A variable.
But it's not always available depending on how bash is built, which
results in people la
On 6/29/23 11:43 AM, Sebastian Carlos wrote:
Hello,
The manual seems to repeat the same information two paragraphs apart:
Thanks for the report.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU
On 6/29/23 1:28 PM, Martin D Kealey wrote:
On Thu, 29 Jun 2023 at 19:45, Denys Vlasenko wrote:
IIRC bash used to allow numeric constants of the
BASE#DIGITS form even if the DIGITS part was empty.
IOW: not only "64#0", but "64#" too was accepted
as a valid zero constant.
This no longer works i
On 6/29/23 1:17 PM, Steffen Nurpmeso wrote:
I now only wondered why you did not also mention the bash bug
$ echo $((0?2/0:7))
7
$ echo $((0?2**-1:7))
-bash: 0?2**-1:7: exponent less than 0 (error token is ":7")
Probably because it doesn't have anything to do with hex constants?
Th
On 6/29/23 5:45 AM, Denys Vlasenko wrote:
Good day.
IIRC bash used to allow numeric constants of the
BASE#DIGITS form even if the DIGITS part was empty.
IOW: not only "64#0", but "64#" too was accepted
as a valid zero constant.
Yes, that was clearly wrong, and it changed in bash-5.1.
However
On Fri, Jun 30, 2023 at 03:28:36AM +1000, Martin D Kealey wrote:
> On Thu, 29 Jun 2023 at 19:45, Denys Vlasenko wrote:
>
> > IIRC bash used to allow numeric constants of the
> > BASE#DIGITS form even if the DIGITS part was empty.
> > IOW: not only "64#0", but "64#" too was accepted
> > as a valid
On Thu, 29 Jun 2023 at 23:42, Greg Wooledge wrote:
> The answer to this is [...] just ssh in as root instead of nonroot + sudo.
>
> Some folks will scream that this is a bad idea, horrible practice, can't
> do it, etc. These folks are idiots. Ssh can be configured to allow root
> logins only w
On Thu, 29 Jun 2023 at 19:45, Denys Vlasenko wrote:
> IIRC bash used to allow numeric constants of the
> BASE#DIGITS form even if the DIGITS part was empty.
> IOW: not only "64#0", but "64#" too was accepted
> as a valid zero constant.
>
> This no longer works in 5.2.15, probably better than
> fo
Denys Vlasenko wrote in
<54f87d1b-e700-e1d3-bf70-400c11145...@redhat.com>:
|IIRC bash used to allow numeric constants of the
|BASE#DIGITS form even if the DIGITS part was empty.
|IOW: not only "64#0", but "64#" too was accepted
|as a valid zero constant.
|
|This no longer works in 5.2.15, pr
On Thu, 29 Jun 2023 12:10:37 -0400
Chet Ramey wrote:
> On 6/29/23 8:51 AM, Chet Ramey wrote:
>
> > It should be consistent, at least. I think the string assignment behavior
> > is the most reasonable: assignments return 1 but there's no assignment
> > error. I'll look at how compound assignments
On 6/29/23 8:51 AM, Chet Ramey wrote:
It should be consistent, at least. I think the string assignment behavior
is the most reasonable: assignments return 1 but there's no assignment
error. I'll look at how compound assignments are different.
I have reconsidered this. Making assignments that a
Hello,
The manual seems to repeat the same information two paragraphs apart:
On Section 3.5 Shell Expansions, a paragraph reads:
> After these expansions are performed, quote characters present in the
original word are removed unless they have been quoted themselves (quote
removal).
Then, after
On 6/29/23 9:38 AM, Kerin Millar wrote:
On Thu, 29 Jun 2023 08:51:58 -0400
Chet Ramey wrote:
On 6/28/23 1:14 PM, Kerin Millar wrote:
This report is based on an observation made within the depths of this thread:
https://lists.gnu.org/archive/html/bug-bash/2023-06/msg00094.html.
Attempting to
On Thu, 29 Jun 2023 11:55:12 +0200
Sebastian Luhnburg wrote:
> #!/usr/bin/env bash
>
> initial_password="\$abc&xyz"
> echo "initial password: " $initial_password
> printf -v password '%q' $initial_password
> echo "initial password with escaped characters: " $password
> bash << EOF
> echo "passwo
On Thu, Jun 29, 2023 at 11:33:15AM +0200, Sebastian Luhnburg wrote:
> I want to use this password in an here document, which inject some
> commands into a SSH-Connection (for simplification, I use the bash instead
> of ssh in the test script below).
Skipping the "is it a bug or not" part, which ha
On Thu, 29 Jun 2023 08:51:58 -0400
Chet Ramey wrote:
> On 6/28/23 1:14 PM, Kerin Millar wrote:
> > This report is based on an observation made within the depths of this
> > thread: https://lists.gnu.org/archive/html/bug-bash/2023-06/msg00094.html.
> >
> > Attempting to assign an array to any of
Hello,
I'm not sure, if I found a bug or if I miss some understanding, but I
want to report it, if it is a bug. Please tell me more, if I'm right or
if it is my mistake.
I have a script, in which I have an password (I get it from a password
manager - no excitement ;D ). The password begin wi
On 6/28/23 1:14 PM, Kerin Millar wrote:
This report is based on an observation made within the depths of this thread:
https://lists.gnu.org/archive/html/bug-bash/2023-06/msg00094.html.
Attempting to assign an array to any of the following variables with the
declare builtin causes bash to immed
Sebastian Luhnburg wrote on Thu, Jun 29, 2023 at 11:55:12AM +0200:
> initial_password="\$abc&xyz"
> echo "initial password: " $initial_password
> printf -v password '%q' $initial_password
> echo "initial password with escaped characters: " $password
> bash << EOF
> echo "password in here document:
The fix in the most recent push did not fix the issue:
$ x=([9223372036854775805]=foo)
$ x+=( {1..5} )
$ echo "${x[@]}"
3 4 5 foo 1 2
It behaves exactly the same way: no error is printed, some elements are
prepended instead of appended, and there are invalid indices in the
output of decl
Hello,
I'm sending this mail a past minutes ago, but I was not a member of this
mailing list. The mail was not listed in the archive, so I send it
again, with membership of the mailing list. I hope I don't sending it
twice to you.
I'm not sure, if I found a bug or if I miss some understandi
Good day.
IIRC bash used to allow numeric constants of the
BASE#DIGITS form even if the DIGITS part was empty.
IOW: not only "64#0", but "64#" too was accepted
as a valid zero constant.
This no longer works in 5.2.15, probably better than
former behavior, "64#" looked quite confusing.
However,
If the last redirection list in a group / subshell / substitution has
a heredoc and the following connector is a semicolon, the connector is
incorrectly skipped over.
This happens only outside of function definitions, so I think it's an
issue only for pretty-print mode.
bash --pretty-print <<<$'(
If there are multiple commands in a row that each require printing the
connector prior to the heredoc body, the connector ends up in the wrong
place for commands after the first:
fun() {
cat second);
- PRINT_DEFERRED_HEREDOCS ("");
+ if (was_heredoc)
+ PRINT_DEFERRED_HER
31 matches
Mail list logo
