Re: bash-5.1.8 does not compile anymore on HP-UX due to invalid shell syntax

On Tue, Aug 17, 2021 at 06:03:36PM +0300, Ilkka Virta wrote: > I have this in the configure script: > > if test $ac_compiler_gnu = yes; then > GCC=yes > else > GCC= > fi > > I don't know which part of autoconf exactly generates it. It comes from the AC_PROG_CC macro. On my system, this brin

Re: EPOCHREALTIME

On Thu, Aug 19, 2021 at 10:30:39AM -0400, Chet Ramey wrote: > On 8/19/21 9:41 AM, Léa Gris wrote: > > This will fail because of questionable design decision of having a mutable > > argument format: > > > > LC_NUMERIC=fr_FR@UTF-8; printf 'Pi: %2.4f\n` "$(bc -l <<<'4*a(1)')" > > > > Note how the fo

Re: EPOCHREALTIME

On Thu, Aug 19, 2021 at 06:18:46PM +0200, Léa Gris wrote: > printf arguments are program source even if argument comes from a variable. I don't agree with this. I'd say that the *first* argument of printf is part of the program source code, and any additional arguments given are typically data, b

Re: @K transformation

The fact that "${a[@]@K}" expands to a single word is surprising to me. I know someone else already mentioned it in this thread (sorry, I forgot who it was), but it would be nice if there were a similar one that gave a list of multiple words. unicorn:~$ printf '<%s> ' "${a[@]@Q}"; echo <'1'> <'2'>

Re: EPOCHREALTIME does not behave correctly before 1970

On Sun, Aug 22, 2021 at 10:30:26PM +0200, Alex fxmbsw7 Ratchev wrote: > why disregard or invalid, mark 0 is that date, less is minus, .. all working It's not that simple. Calendars get really *interesting* if you go farther back in history. The switch from the Julian to the Gregorian calendar di

bug-bash@gnu.org

On Sun, Aug 22, 2021 at 10:33:13PM -0400, Lawrence Velázquez wrote: > An example in the original post asserted that tmp_var "will not > exist when PS1 is expanded", so it must be inserted when PS1 is > defined. This requirement seems pretty contrived to me (why can't > tmp_var be kept around, exac

Re: efficient way to use matched string in variable substitution

On Mon, Aug 23, 2021 at 11:36:52AM -0700, L A Walsh wrote: > Starting with a number N, is there > an easy way to print its digits into an array? "Easy"? Or "efficient"? Your subject header says one, but your body says the other. > arr=(${N//[0-9]/\1 }) > arr=(${N//[0-9]/$1 }) Obviously those

Re: efficient way to use matched string in variable substitution

On Mon, Aug 23, 2021 at 12:41:58PM -0700, L A Walsh wrote: > > > On 2021/08/23 12:10, Greg Wooledge wrote: > > On Mon, Aug 23, 2021 at 11:36:52AM -0700, L A Walsh wrote: > > > Starting with a number N, is there > > > an easy way to print its digits into an array

Re: efficient way to use matched string in variable substitution

On Tue, Aug 24, 2021 at 01:31:35PM +0200, Léa Gris wrote: > Le 23/08/2021 à 21:41, L A Walsh écrivait : > > > > > > On 2021/08/23 12:10, Greg Wooledge wrote: > > > On Mon, Aug 23, 2021 at 11:36:52AM -0700, L A Walsh wrote: > > > > Starting with a numbe

Re: efficient way to use matched string in variable substitution

On Tue, Aug 24, 2021 at 03:09:55PM +0200, Mike Jonkmans wrote: > This seems to be the fastest: > f12 () { [[ "$1" =~ ${1//?/(.)} ]]; local arr=( "${BASH_REMATCH[@]:1}" ); } > time for ((i=1; i<=1; i++)); do f0 682390; done > real0m0,296s > user0m0,296s > sys 0m0,000s Your CPU is a

Re: efficient way to use matched string in variable substitution

On Tue, Aug 24, 2021 at 04:16:46PM +0200, Léa Gris wrote: > string2array() { > # Splits the string's characters into the array > # $1: The input string > # $2: The output array name > [[ "$1" =~ ${1//?/(.)} ]] > # shellcheck disable=SC2178 # shellcheck broken nameref type check > local

Re: Squiggly heredoc - new feature request

On Mon, Aug 30, 2021 at 10:06:37PM +0200, Přemysl Šťastný wrote: > I think, it would be nice, if you implemented Squiggly heredoc, which solves > this problem by ignoring both leading spaces and leading tabs. eg. > > func()( >   cat <<~ EOF >     blabla >   EOF > ) This would break backward compa

Re: Squiggly heredoc - new feature request

On Mon, Aug 30, 2021 at 04:28:40PM -0400, Greg Wooledge wrote: > On Mon, Aug 30, 2021 at 10:06:37PM +0200, Přemysl Šťastný wrote: > > I think, it would be nice, if you implemented Squiggly heredoc, which solves > > this problem by ignoring both leading spaces and leading tabs. eg

Re: LINENO is affected by sync

On Wed, Sep 01, 2021 at 10:36:21AM +0100, David Collier wrote: > Version: > > GNU bash, version 5.0.3(1)-release (arm-unknown-linux-gnueabihf) > > Raspberry Pi using Raspbian. > > Installed from repo? > > LINENO goes backwards when run sync > > echo "== At this point \$LINE

Re: LINENO is affected by sync

On Wed, Sep 01, 2021 at 04:52:29PM +0100, David Collier wrote: > greg - I'm sorry - I assume there is a proper place for me to post > follow-up info, can you let me know where it is? On the bug-bash mailing list is fine. If the script is too big to post on bug-bash, then it'

Re: Interactive commands cant be backgrounded if run from bashrc

On Wed, Sep 01, 2021 at 09:37:02PM -0400, Dale R. Worley wrote: > "C. Yang" writes: > > emacs test.txt & > > > > fg > > > bash: fg: no job control > It sounds like Bash doesn't activate the job-control features until > .bashrc is completed. Well, there's an easy fix for that. Just put "set -m"

Re: Interactive commands cant be backgrounded if run from bashrc

On Wed, Sep 01, 2021 at 09:28:55PM -0500, Dennis Williamson wrote: > On Wed, Sep 1, 2021, 8:42 PM Greg Wooledge wrote: > > I tested with "set -m" and "vim & fg" just now, and it appeared to work. > > Do processes started in .bashrc have a terminal? I would

Re: Interactive commands cant be backgrounded if run from bashrc

On Thu, Sep 02, 2021 at 12:15:35PM -0400, C. Yang wrote: > I can confirm that adding `set -m` before the emacs command in .bashrc results > > in the behavior I want with CTRL+Z. As I understand, `set -m` will enable job > > control features. This suffices for my use case. > > > > However, is

Re: LINENO is affected by where it is

On Sat, Sep 04, 2021 at 04:04:05PM -0700, L A Walsh wrote: > LINENO isn't the number of lines executed, but is the > linenumber in the source file it is running in (or the line > in a function for functions already in memory before you > access it. The OP of this thread replied to me that they sov

Re: ?maybe? RFE?... read -h ?

On Sat, Sep 04, 2021 at 04:18:09PM -0700, L A Walsh wrote: > I know how -h can detect a symlink, but I was wondering, is > there a way for bash to know where the symlink points (without > using an external program)? Nope.

Re: ?maybe? RFE?... read -h ?

On Mon, Sep 06, 2021 at 08:41:33AM +0200, Alex fxmbsw7 Ratchev wrote: > btw in the help you pasted there is the -a arr in question Can you for the love of glob please STOP top-posting? > On Mon, Sep 6, 2021, 08:36 felix wrote: > > It would be nice if builtins intended to produce *answer* use mor

Re: Why tail coreutil cannot work as its input is from tee

On Mon, Sep 06, 2021 at 07:38:03AM +, Budi wrote: > How come tail coreutil cannot work as its input is from tee > > $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tail -1 > 1 > > But : > > $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tee >(head -1) |tail -1 > 9 > > Please help explain It would be better if yo

Re: BASH_BUILTINS(1) | 'man bash_builtins' | Manual not found

On Thu, Sep 30, 2021 at 11:50:36AM +0300, Ricky Tigg wrote: > Hello. > > For reference | Execute 'man ' e.g 'man alias'; this opens a > BASH_BUILTINS(1) titled manual. The obvious is then noticeable: a manual > entry for bash_builtins does exist. Once it is searched with 'man', it is > no longer f

Re: BASH_BUILTINS(1) | 'man bash_builtins' | Manual not found

On Thu, Sep 30, 2021 at 01:37:57PM +0200, Alex fxmbsw7 Ratchev wrote: > i havent read official 'man alias' either > maybe you meant help alias No, they probably have a /usr/share/man/man1/alias.1.gz -> bash-builtins.1.gz symlink or something, set up by their OS vendor. We do not. Because we're

Re: BASH_BUILTINS(1) | 'man bash_builtins' | Manual not found

On Thu, Sep 30, 2021 at 01:56:45PM +0200, Andreas Schwab wrote: > On Sep 30 2021, Greg Wooledge wrote: > > > No, they probably have a /usr/share/man/man1/alias.1.gz -> > > bash-builtins.1.gz > > symlink or something, set up by their OS vendor. > >

mapfile -t doesn't always remove the delimiter

The mapfile builtin command doesn't correctly strip delimiters (when requested with the -t option) in all cases. unicorn:~$ echo "$BASH_VERSION" 5.1.4(1)-release unicorn:~$ printf $'a\xffb\xffc\xff' | { mapfile -t -d $'\xff' array; declare -p array; } declare -a array=([0]=$'a\377' [1]=$'b\377'

Re: EXIT trap is not executed after an exec failure in a non-interactive shell

> On Fri, Oct 1, 2021, 01:25 Mark March wrote: > > > If execfail is set, a failed exec does not cause a non-interactive shell > > to exit, but it seems to reset the EXIT trap: It also appears to reset the EXIT trap in an interactive shell. unicorn:~$ shopt -s execfail unicorn:~$ trap 'echo exit

Re: Request change to output of declare -f funcname

On Sat, Oct 02, 2021 at 01:41:35PM +0200, Léa Gris wrote: > $ declare -f hello > > hello () > { > echo 'hello'; > echo 'world' > } > > The issue is that in some circumstances, newline characters may be handled > as space, making the function declaration invalid. Can you show an example w

Re: Request change to output of declare -f funcname

On Sat, Oct 02, 2021 at 04:52:38PM +0200, Alex fxmbsw7 Ratchev wrote: > in pasted mails where newlines get converted to spaces > > On Sat, Oct 2, 2021, 15:21 Greg Wooledge wrote: > > > On Sat, Oct 02, 2021 at 01:41:35PM +0200, Léa Gris wrote: > > > $ declare

Re: Request change to output of declare -f funcname

world OK, that's news to me. But that looks like a bug in sudo. Asking bash to change its behavior to work around a bug in some other program seems like misdirected effort. unicorn:~$ sudo ~greg/bin/args $'one\ntwo' three 2 args: unicorn:~$ sudo -i ~greg/bin/args $'one\ntwo&#x

Re: read built-in command has a problem in shell function

On Mon, Oct 11, 2021 at 03:28:18PM +0900, Hyunho Cho wrote: > If i want to know whether there are input available from stdin > then i use "read -t 0" command like this > > if read -t 0; then# first check input available > while read line; do ... done > ... > fi What are you actually trying to

Re: current bash.git.devel segfaults on my code

On Sat, Oct 23, 2021 at 03:03:31AM +0200, Alex fxmbsw7 Ratchev wrote: > ./bash --noprofile --norc > > bash-5.1# ./bash ../xbl5/xbl > > malloc: unknown:0: assertion botched > malloc: 0x3000211ab0: allocated: last allocated from glob.c:1150 > realloc: underflow detected; mh_nbytes out of range > Ab

Re: Option for read to handle incomplete last line

On Sun, Oct 24, 2021 at 06:41:59PM +0900, Koichi Murase wrote: > > my apologies if there's a much easier solution for the following > > problem - in this case please let me know! > > We can always define a shell function (which would work in all the > POSIX shells): > > read_line() { read line ||

Re: Option for read to handle incomplete last line

On Sun, Oct 24, 2021 at 04:26:44PM +0200, Martin Schulte wrote: > Hi Greg, hi *! > > > For bash scripts using this, I'd go a little bit fancier: > > > > read_line() { > > if (($# == 0)) || [[ ${!#} = -* ]]; then > > declare -n _rl_lastvar=REPLY

Re: unexpected exit code for integer operation

On Wed, Oct 27, 2021 at 09:09:29PM +0200, Toralf Förster wrote: > unexpected: > $ i=0; ((i++)); echo $? > 1 https://mywiki.wooledge.org/BashFAQ/105

Re: Arbitrary command execution from test on a quoted string

On Thu, Oct 28, 2021 at 08:33:22PM +, elettrino via Bug reports for the GNU Bourne Again SHell wrote: > > user@machine:~$ USER_INPUT='x[$(id>&2)]' > user@machine:~$ test -v "$USER_INPUT" > uid=1519(user) gid=1519(user) groups=1519(user),100(users) > user@machine:~$ Whoo. This uses a feature

Re: Arbitrary command execution from test on a quoted string

On Fri, Oct 29, 2021 at 07:37:13AM +0200, Léa Gris wrote: > A safe way to replace: > test -v "$USER_INPUT" > > Would be: > test "${USER_INPUT@Q}" > > But it is not backward-compatible with older bash versions. test -v is fairly recent as well. That was introduced in 4.2, and the @Q syntax in 4.

Re: Arbitrary command execution from test on a quoted string

On Fri, Oct 29, 2021 at 12:48:57PM +0300, Ilkka Virta wrote: > Not that I'm sure the upper one is still safe against every input. I think > issues with associative array keys have been > discussed on the list before. Sadly, yes. Bash is the exploding barbed wire death match of programming languag

Re: Arbitrary command execution in shell - by design!

On Fri, Oct 29, 2021 at 11:59:02AM -0700, L A Walsh wrote: > How much lameness Chett has introduced into bash to accommodate > the wrong users. This is quite unfair. The major systemic problems with bash (and sh) weren't introduced by Chet Ramey. They've been baked in from the very beginning. M

Re: Why should `break' and `continue' in functions not break loops running outside of the function?

On Sat, Oct 30, 2021 at 02:39:19PM +0300, Oğuz wrote: > I found that this behavior had been introduced in 2014, with the > following commit message: > > > set loop_level to 0 > > when entering a function so break and continue in functions don't > > break loops running outside of the function. Fix

Re: Why should `break' and `continue' in functions not break loops running outside of the function?

On Sat, Oct 30, 2021 at 08:45:05PM +0300, Oğuz wrote: > I know, it's great. Though I still couldn't figure out how to have a > command run on login and it drives me mad. Depends on *how* you log in.

Re: Arbitrary command execution from test on a quoted string

On Sun, Oct 31, 2021 at 09:05:22AM +0100, felix wrote: > Unfortunely, this won't be useable with associative array, like: > >declare -A AssocVar='([Some string.]=foo)' >test -v AssocVar['Some string.'] && echo yes || echo no >yes >isvar AssocVar['Some string.'] && echo yes || echo

Re: Possible bug with redirect.

On Mon, Nov 01, 2021 at 04:23:32PM +0100, Rikke Rendtorff wrote: > I'm very new to linux, so I apologize if I'm reporting a non-bug. > > I wanted to do this: date > `date +"%Y-%m-%d"`.txt to put the date into a > file called 2021-10-16.txt > > But I accidentally forgot the backticks, so it became

Re: some unknown bug, says : command not found

On Mon, Nov 01, 2021 at 04:53:12PM +0100, Alex fxmbsw7 Ratchev wrote: > coming from non -x : > > . ~/.bashrc > > bash: : command not found > bash: : command not found Because this is you, I can't be sure whether you are correctly pasting the output from your terminal into email, or retyping it w

Re: some unknown bug, says : command not found

On Mon, Nov 01, 2021 at 05:29:08PM +0100, Alex fxmbsw7 Ratchev wrote: > how, or what, is a non breaking space https://en.wikipedia.org/wiki/Non-breaking_space In HTML it's represented by   In Unicode it's code point U+00A0 In UTF-8 it's encoded as 0xc2 0xa0 On my system, with Debian's X Compos

Re: some unknown bug, says : command not found

On Mon, Nov 01, 2021 at 06:34:45PM +0100, Alex fxmbsw7 Ratchev wrote: > the hd one gives me, i think its the only two cat cases : > > 0410 0a 6d 76 20 2d 2d 20 22 24 74 74 22 20 22 24 74 |.mv -- "$tt" > "$t| > 0420 74 74 22 0a 0a 24 78 62 6c 70 70 20 3c 28 0a 20 |tt"..$xblpp > <(. |

Re: some unknown bug, says : command not found

On Tue, Nov 02, 2021 at 03:23:15AM +0700, Robert Elz wrote: > Date:Mon, 1 Nov 2021 12:03:48 -0400 > From: Greg Wooledge > Message-ID: > > | > bash: : command not found > | > bash: : command not found > | > | Because this is yo

Re: some unknown bug, says : command not found

On Tue, Nov 02, 2021 at 04:52:24AM +0100, Alex fxmbsw7 Ratchev wrote: > to answer around what was written, i dont have a cat alias > > but what mr andreas wrote seems much similiar to what i do, process sub.. > ill check the vars carefully but i dont get it fully unicorn:~$ bash unicorn:~$ $xyz <

Re: bash conditional expressions

On Fri, Nov 12, 2021 at 10:36:01AM +0100, Mischa Baars wrote: > All of my makefiles only compile source files and link object files that > are NEW, as in the modification timestamp is newer than OR EQUAL TO the > access timestamp, That's not how Makefiles work. Makefiles compare the mtimes of two

Re: bash conditional expressions

On Fri, Nov 12, 2021 at 02:21:15PM +0100, Mischa Baars wrote: > It is how my makefiles work :) Then they aren't Makefiles. They're BaarsBuilder files or something. > Do you realize how much time it takes to load the stat executable on all > source files [...] What the hell. You're writing

Re: Document -x and -vx give the same results

On Mon, Nov 15, 2021 at 12:40:22AM +0800, 積丹尼 Dan Jacobson wrote: > Man page says: >-vPrint shell input lines as they are read. >-xPrint commands and their arguments as they are executed. > Perhaps mention that -x and -vx give the same results, often or always. > GNU

Re: Document -x and -vx give the same results

On Mon, Nov 15, 2021 at 04:04:36AM +0800, 積丹尼 Dan Jacobson wrote: > I was testing -xeu vs. -vxeu on > > set -xeu > set /var/lib/exim4/config.autogenerated > cp $@ /tmp > update-exim4.conf --verbose > diff /tmp $@||: > set update-exim4.conf.conf > echo . $PWD/$@-jidanni > /tmp/$@ > diff $@ /tmp >

Re: bash conditional expressions

On Sun, Nov 14, 2021 at 09:57:49PM -0500, Dale R. Worley wrote: > One thing you have to worry about is how "touch" behaves, and whether > *that* has changed between Fedora versions. I've run a few test uses of > "touch" (in Fedora 34) and examined the consequences with "stat", and > it's not clear

Re: I've found a vulnerability in bash

On Wed, Nov 17, 2021 at 04:16:36AM -0500, Marshall Whittaker wrote: > --- SNIP --- > [marshall@jerkon]{04:09 AM}: [~/bashful] $ touch -- '--version' > [marshall@jerkon]{04:09 AM}: [~/bashful] $ mv * b This isn't a vulnerability in bash. It's a bug in your script. Use this instead: mv -- * b

Re: I've found a vulnerability in bash

On Wed, Nov 17, 2021 at 03:47:15PM +0200, Ilkka Virta wrote: > I don't see this in BashFAQ, though. Is it because it's not strictly about > Bash? Greg? https://mywiki.wooledge.org/BashPitfalls#pf3

Re: Unclosed quotes on heredoc mode

On Wed, Nov 17, 2021 at 06:30:08PM +, João Almeida Santos wrote: > Thank you for your reply Robert and Lawrence! > > I understand the description alone is hard to follow, so I think the image > below should make it clearer. Otherwise let me know! > > > Kind regards, > João Almeida Santos N

Re: Unclosed quotes on heredoc mode

On Wed, Nov 17, 2021 at 06:45:05PM +, João Almeida Santos wrote: > bash-5.1$ cat << $PATH That's not how a here-document is intended to be used. A here-document lets you drop a blob of text directly into your script and use that as standard input for some command, without needing to store the

Re: bash conditional expressions

On Thu, Nov 18, 2021 at 07:26:51AM +0100, Michael J. Baars wrote: > So now we have a relation for 'older than' and for 'newer than', but how > about 'oldest' (executable), and 'newest' (executable)? https://mywiki.wooledge.org/BashFAQ/099 The bot in libera's #bash also has this factoid for it:

Re: unbalanced parenthesis not recognized

On Thu, Nov 18, 2021 at 10:34:40AM +0100, Harald Dunkel wrote: > Hi folks, > > I am not sure, but shouldn't bash 5.1.4 complain about > > : ${SSLDIR}:="${JM_WORK}/ssl"} There's no syntax error here. It may be a bug, in the sense that it doesn't do what you wanted it to do, but from the sh

Re: unbalanced parenthesis not recognized

On Fri, Nov 19, 2021 at 08:02:19AM +0100, Harald Dunkel wrote: > On 2021-11-18 17:52:29, Robert Elz wrote: > > Date:Thu, 18 Nov 2021 10:34:40 +0100 > > From:Harald Dunkel > > Message-ID: > > > >| at least due to unbalanced parenthesis? > > > > Greg's reply wa

Re: unbalanced parenthesis not recognized

On Mon, Nov 22, 2021 at 09:03:39AM +0100, Harald Dunkel wrote: > > : ${SSLDIR}:="${JM_WORK}/ssl"} > Surely I can just speak for myself, but to me it appears obvious that > there is something weird and that there is one closing bracket too much > in this line. I understand that bash doesn't produce

Re: some.. bug .. ?

On Thu, Dec 02, 2021 at 05:44:14PM +0100, Alex fxmbsw7 Ratchev wrote: > well no idea > > printf 'e=. ; (( $# > 1 )) && $e afile "${@:1:$# -1}"' >afile ; set -x ; . > afile 1 2 3 4 ; set +x > + . afile 1 2 3 4 > ++ e=. > ++ (( 4 > 1 )) > ++ '' afile 1 2 3 >bash: : command not

Re: Zero-length indexed arrays

On Tue, Dec 21, 2021 at 10:48:07PM -0500, Dale R. Worley wrote: > Lawrence Velázquez writes: > > Did you mean to say that ${#FOO[*]} causes an error? Because > > ${FOO[*]} does not, a la $*: > > The case that matters for me is the Bash that ships with "Oracle Linux". > Which turns out to be vers

Re: Suggestion for .bashrc

On Thu, Dec 30, 2021 at 08:46:16PM -0800, Kevin O'Gorman wrote: > So I propose extending the stanza near the end of .bashrc: > if [ -f ~/.bash_aliases ]; then > . ~/.bash_aliases > fi That code was written by your operating system vendor, or by your system administrator, or by you. It's not

Re: Suggestion for .bashrc

On Tue, Jan 04, 2022 at 03:34:05PM -0500, Matthew Persico wrote: > On Fri, Dec 31, 2021 at 10:33 AM Greg Wooledge wrote: > > You can edit the file yourself and make it work however you like. You > > have the right idea, but I'd write it like this: > > > > if

Re: error in hours given by date -d @anyNumber

On Mon, Jan 17, 2022 at 09:10:59PM +0100, Girod Valentin wrote: > Description: > when using date -d @customNumber +%H, > it returns 1 more hour that the expected hour. First thing to note: date(1) is not part of bash. It's part of GNU coreutils, if you're on a GNU/Linux system. You're re

Re: bash dislikes empty functions or flow control bodies

On Tue, Jan 18, 2022 at 12:44:46PM +0100, l.bash...@scarydevilmonastery.net wrote: >a: defining an empty function will throw a syntax error >b: defining an empty bodies flow control construct will thow a syntax error This has been the case since the original Bourne shell in the 1970s. The

Re: Bash not escaping escape sequences in directory names

On Mon, Jan 24, 2022 at 07:53:03PM +0100, Andreas Kusalananda Kähäri wrote: > I was honestly a bit surprised to see bash picking up PS1 from the > environment. Why would people want it to do that (i.e. export PS1)? It removes the need for bash to re-set it from .bashrc every time a new interactiv

Re: Incorrect alias expansion within command substitution

On Fri, Feb 04, 2022 at 02:52:34AM +0700, Robert Elz wrote: > You could instead use: > > my() > { > local A= > while [ $# -gt 0 ] > do > case "$1" in > int)A="${A} -i";; > ma

Re: i had a read not work..

On Sun, Feb 06, 2022 at 01:43:57AM +0100, Alex fxmbsw7 Ratchev wrote: > this is on a friends os x, where brew install bash and gawk, resulted > in good versions > > i tried > > gawk ' print ; fflush' > > with a read -r varname, also read -r -d $'\n' varname > > it never_ returned result

Re: Corrupted multibyte characters in command substitutions fixes may be worse than problem.

On Sun, Feb 06, 2022 at 11:11:43PM +0100, Alex fxmbsw7 Ratchev wrote: > [[ Regarding nul bytes discarded by command substitution ]] > can't these \0 bytes be encoded at least when a utf8 locale is used as > \u0 instead of dropping ? and a null, ... just > prefix the utf 8 encoding chars to the nul

[5.1+] wait may return wrong status from function with EXIT trap

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O3 -feliminate-unused-debug-types -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -Wformat -Wformat-security -m64 -fasynchronous-unwind-tables -Wp,-D_REENTRANT

Re: Long variable value get corrupted sometimes

On Wed, Feb 16, 2022 at 04:10:40PM +0800, Daniel Qian wrote: > FOO=$(cat /tmp/foo.txt) > got_md5=$(echo "$FOO" | md5sum -b | cut -d ' ' -f 1) In addition to what other people have said... echo is not reliable. It may alter your text, if you feed it backslashes, or arguments like "-e" or "-n". te

Re: Long variable value get corrupted sometimes

On Wed, Feb 16, 2022 at 02:53:43PM +0100, Léa Gris wrote: > Le 16/02/2022 à 13:43, Greg Wooledge écrivait : > > text=$(cat /tmp/foo.txt; printf x) > > text=${text%x} > > or read -r -d '' text > witch saves a sub-shell You forgot IFS= there. Without that

Re: command line not saved after "event not found" error

On Sun, Feb 20, 2022 at 05:38:06PM +0100, Andrea Monaco wrote: > on my bash 5.0.3, when I input > > $ foo!\ > > I get "bash: !\: event not found", which I think is appropriate, but the > line doesn't get saved in history. The same doesn't happen for other > errors, for example "command not fou

Re: 'hash foo' may fail, and would require something like 'hash /usr/bin/foo'

On Tue, Feb 22, 2022 at 08:51:06PM +0100, Benoit Lacelle wrote: > / # bash > > bash-5.1# type -a npm > > bash: type: npm: not found Can you investigate further at this point? Show us the content of PATH, show us any and all npm files that are in every directory in PATH (including the permission

Re: Bash Manual section 6.7 Arrays should mention array append notation

On Tue, Mar 08, 2022 at 10:55:15AM -0500, Zachary Santer wrote: > Talking about the lines with "+=", obviously. I only learned I could > do this when I found it in existing code. It's mentioned in the PARAMETERS section: uated. When += is applied to an array variable using compound assig

Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code

On Mon, Mar 21, 2022 at 05:00:29PM +0800, Michaelll Lee wrote: > By the way, apparently the content about "non-printing characters" in that > man page has not been modified across the several versions of Bash, for > example in my machine, "3.2.57(1)-release" and "5.1.0(1)-release" share > nearly t

Re: for loop over parameter expansion of array can miss resulted empty list

Stop. Posting. Upside-down. > > On Sun, Mar 20, 2022, 22:07 Alexey via Bug reports for the GNU Bourne > > > Repeat-By: > > > Code: x=("/"); for i in "${x[@]%/}"; do echo "i is '$i'"; done > > > Result: none > > > Expected result: i is '' > On 2022-03-21 14:40, Alex fxmbsw7 Ratchev wrote: > > i

Re: for loop over parameter expansion of array can miss resulted empty list

On Mon, Mar 21, 2022 at 02:47:12PM -0400, Lawrence Velázquez wrote: > On Mon, Mar 21, 2022, at 8:50 AM, Alexey via Bug reports for the GNU Bourne > Again SHell wrote: > > I can add one more example, which change array size while it's not > > expected behavior: > > x=("/"); y=("${x[@]%/}"); echo "

Re: for loop over parameter expansion of array can miss resulted empty list

On Tue, Mar 22, 2022 at 08:05:21PM -0700, L A Walsh wrote: > > > > > Repeat-By: > > > > >Code: x=("/"); for i in "${x[@]%/}"; do echo "i is '$i'"; done > > > > >Result: none > > > > >Expected result: i is '' > Sorry, I got sidetracked. In this case it wouldn't matter, > if you have n

Re: parameter expansion null check fails for arrays when [*] or [@] is used

On Wed, Mar 23, 2022 at 01:48:48AM -0700, L A Walsh wrote: > On 2022/03/23 00:25, Ilkka Virta wrote: > > The POSIX phraseology is that "null" means the empty string. > >POSIX phraseology applies to the POSIX language. > > In 'C' > > char *s = NULL > is not the same as > char *s=""; Yes,

Re: Bash Manual section 6.7 Arrays should mention array append notation

On Thu, Mar 24, 2022 at 11:12:25AM -0400, Zachary Santer wrote: > I'm consulting the online manual > , so if > you're looking for a version number, that would be 5.1. > > I just now looked at doc/bash.pdf in the git repo on Savannah. N

Re: forwarded weirdness report

On Mon, Mar 28, 2022 at 04:18:05PM -0400, Chet Ramey wrote: > On 3/28/22 3:06 PM, Martin Schulte wrote: > > on Mon, 28 Mar 2022 20:34:40 +0200 Alex fxmbsw7 Ratchev > > wrote: > > > https://pastebin.com/raw/T7ZnFapt > > > > Here's a somewhat stripped down version: > > > > $ bash --noprofile --no

Re: defuncted printf process when using wpa_supplicant

o1 -c/dev/fd/63 > root 1530 0.0 0.0 0 0 ?Z07:19 0:00 \_ > [3.wpa] Whatever ps command you're using here isn't showing the parent process ID. You'll need the parent PID to know which program isn't cleaning up its defunct children (zombies). The

Re: defuncted printf process when using wpa_supplicant

On Wed, Mar 30, 2022 at 04:52:16PM +0200, Alex fxmbsw7 Ratchev wrote: > cool mate i halfway understand but great peaceful explaintion :) The most important thing here is that zombies are mostly harmless. They aren't using any memory or CPU. The only thing they're using is a PID, and the kernel re

Re: Buffer Overflow

On Tue, Apr 12, 2022 at 02:45:15PM -0400, Sergio Fuentes wrote: > Please, run the following 3 commands to reproduce the bug: > > echo '. ./poc.sh' > poc.sh > chmod +x poc.sh > bash -c './poc.sh' You're performing an infinite recursion. Eventually, you'll overflow the stack, and bash will crash.

Re: bash 5.1 heredoc pipes problematic, shopt needed

On Mon, Apr 25, 2022 at 12:26:46AM +0400, Alexey via Bug reports for the GNU Bourne Again SHell wrote: > My pipe size is 4kb, but... > ulimit -p > 8 $ ulimit -a [...] pipe size(512 bytes, -p) 8 Always check the units.

Re: bash 5.1 heredoc pipes problematic, shopt needed

On Mon, Apr 25, 2022 at 11:43:31PM +0400, Alexey via Bug reports for the GNU Bourne Again SHell wrote: > Annex: with reading to buffer there is some problem: if I want to read first > part to variable and rest of pipe pass to external program... Bash could be > an additional pipe layer for next pr

Re: bash 5.1 heredoc pipes problematic, shopt needed

On Thu, Apr 28, 2022 at 07:26:19PM +0400, Alexey via Bug reports for the GNU Bourne Again SHell wrote: > Hello. > > I promised you more examples, and here they are: > Very common case to build a list of files for further processing: > declare -a FILES > #1 > FILES=(); time readarray -t FILE

Re: bash (all versions) screws up display when a multiply is given

On Wed, May 04, 2022 at 09:11:01AM +0200, n952162 wrote: > Please disregard that ... there's something there, but I haven't > distilled it yet. > > On 5/4/22 9:06 AM, n952162 wrote: > > In vi mode > > > > if you enter, .e.g. 2f) (put the cursur on the second following > > occurance of a right par

Re: Possible bug in bash

On Fri, May 13, 2022 at 10:36:56PM -0400, Dale R. Worley wrote: > Reading your message, I believe that the rule can be stated as follows, > and I'd thank you to check it: && and || have the same precedence, and > they both "associate left". So for example > x && yy || zz > is equivalent (as a

Re: Inconsistency between fc and C-x C-e

On Wed, Jun 08, 2022 at 06:06:51PM -0300, Luciano wrote: > I had the terrible idea to set my EDITOR variable to something too > complex. I had to pass some options with whitespace to vim, so i decided > to use `eval`. [...] You could create a wrapper script, put it in your $HOME/bin/ directory (an

Re: builtin man page for wait omits information from SIGNALS

On Tue, Jun 14, 2022 at 10:46:45PM -0700, AA via Bug reports for the GNU Bourne Again SHell wrote: > This > is for a simple doc addition to the wait manpage, Bash does not ship a man page named "wait". What are you actually reading? It's possible that your system is set up with the POSIX man pa

Re: builtin man page for wait omits information from SIGNALS

On Wed, Jun 15, 2022 at 12:14:22PM -0700, AA via Bug reports for the GNU Bourne Again SHell wrote: > Greg:  I included a link to the github. There are only 3 PRs, one of which > is mine. That's why I was suspicious it's the wrong place. > > Here is a link to the

Re: builtin man page for wait omits information from SIGNALS

On Wed, Jun 15, 2022 at 03:32:02PM -0400, Greg Wooledge wrote: > On Wed, Jun 15, 2022 at 12:14:22PM -0700, AA via Bug reports for the GNU > Bourne Again SHell wrote: > > Greg:  I included a link to the github. There are only 3 PRs, one of which > > is mine. That's why I

Re: [ ! ! hey ] -> [: too many arguments

On Thu, Jun 23, 2022 at 05:58:23PM -0400, Chet Ramey wrote: > On 6/23/22 5:08 PM, Steffen Nurpmeso wrote: > >bash -c 'if [ ! ! hey = hey ]; then echo du; fi' > Sure. This one isn't a common idiom for shell programmers, apparently. I've seen it used in a math context, inside PS1. Like so: co

Re: [Unknown error when running a simple bash script]

On Mon, Jul 04, 2022 at 06:15:27PM +0200, Alex fxmbsw7 Ratchev wrote: > On Mon, Jul 4, 2022, 18:07 wrote: > > When I am running the script, it says "[[: not found." You're running the script with sh, not with bash. If you are typing "sh myscript", that immediately identifies the source of the pr

Re: Revisiting Error handling (errexit)

On Mon, Jul 04, 2022 at 09:33:28PM +0300, Yair Lenga wrote: > Thanks for taking the time to review my post. I do not want to start a > thread about the problems with ERREXIT. Instead, I'm trying to advocate for > a minimal solution. Oh? Then I have excellent news. The minimal solution for dealin

Re: Feature request

On Wed, Jul 06, 2022 at 01:25:38PM +1000, Brad Hayes wrote: > source "$__DIR/file.ext" #$__DIR == the absolute path to the current > scripts location. https://mywiki.wooledge.org/BashFAQ/028

<    1   2   3   4   5   6   7   8   9   10   >