Re: sh vs. bash -xc 'a=b c=$a'

On Thu, May 23, 2024 at 06:56:01AM +0800, Dan Jacobson wrote: > It seems these should both make one line "+ a=b c=b" output, > > for s in sh bash > do $s -xc 'a=b c=$a' > done > > I mean they give the same results, but bash splits it into > two lines, so the user reading the bash -x output

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Tue, May 21, 2024 at 10:12:55AM +, Matheus Afonso Martins Moreira wrote: > > the schizophrenic nature of the feature > > First the feature was "irritating" ... Now it's "schizophrenic" ? > I must be mentally ill for trying to contribute this? > > Yeah, I'm done. I don't think

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Mon, May 20, 2024 at 07:43:10PM +0200, Andreas Kähäri wrote: > On Mon, May 20, 2024 at 05:31:05PM +, Matheus Afonso Martins Moreira > wrote: > > >> Why not add a -p option to '.' to specify the path to search. > > >> That is > > >>. -p "${BASH_SEARCH_PATH-${PATH}}" file > > >> would

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Sat, May 18, 2024 at 08:39:57AM -0300, Matheus Afonso Martins Moreira wrote: > > Setting the variable at all is opting in to new behavior, and you do > > that at your own risk, after reading the documentation and deciding > > that this is what you want. > > As the user, it should be my

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Fri, May 17, 2024 at 03:32:23PM +, Matheus Afonso Martins Moreira wrote: > > You don't have to export variables. I would recommend not exporting > > such a variable to begin with unless you're sure of its effects. > > It could be made safe so that it's possible to export it. > Then it can

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Fri, May 17, 2024 at 01:42:43PM +0700, Robert Elz wrote: > [GLOBSORT] > Possibly useful I guess - though I'm not really sure about a possible > need to stat() every file from a glob result because that got set to > one of the options that needs it. "nosort" seems likely to be the most > useful

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Fri, May 17, 2024 at 02:23:10AM +, Matheus Afonso Martins Moreira wrote: > It's also important to consider the opposite situation: > distributions and/or users setting BASH_SOURCE_PATH globally > which then results in existing scripts _not_ getting the historical > behavior which matches

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Thu, May 16, 2024 at 11:31:55AM -0400, Chet Ramey wrote: > On 5/15/24 11:31 AM, Koichi Murase wrote: > > Maybe it was not clear to use `source name' and `source -i name' to > > describe the idea. I meant I assumed the search domain being > > > > * BASH_SOURCE_PATH + PATH + PWD without the

Re: proposed BASH_SOURCE_PATH

On Thu, May 16, 2024 at 10:51:01AM +0700, Robert Elz wrote: > Personally, I don't think there is anything common here at all, most > scripts don't fetch bits from other places, everything simply goes in > the script, and the need for the '.' command at run time is avoided. > > In general, I

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Tue, May 14, 2024 at 03:51:10PM -0400, Chet Ramey wrote: > On 5/13/24 6:37 AM, Matheus Afonso Martins Moreira wrote: > > Passing the -i option to the source builtin > > enables isolated sourcing mode which restricts > > its search path to the directories defined by > > the BASH_SOURCE_PATH

Re: bug in bash

On Sun, May 12, 2024 at 03:33:12PM +0200, Andreas Schwab wrote: > > On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote: > >> I found a bug when i tried with syntax <(cmd). this is an example > >> cat <(wc -l) < bk > Since the redirection fails and the cat command is never started, bash >

Re: bug in bash

On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote: > I found a bug when i tried with syntax <(cmd). this is an example > cat <(wc -l) < bk What is "wc -l" supposed to read from? It counts lines of standard input, until EOF is reached. But its standard input is a terminal. And you're

Re: [sr #111058] Problem transmitting script arguments

On Wed, May 08, 2024 at 02:07:55PM -0400, Dale R. Worley wrote: > "Kerin Millar" writes: > > On Mon, 6 May 2024, at 7:01 PM, Dale R. Worley wrote: > >> anonymous writes: > >>> [...] > > > It's likely that your reply will never be seen by the anonymous > > Savannah issue filer. > > OK. Now

Re: [PATCH 0/4] Add import builtin

On Sun, May 05, 2024 at 03:32:04PM -0400, Lawrence Velázquez wrote: > Much like the periodic requests for XDG-organized startup files, a > BASH_SOURCE_PATH might be convenient but is not groundbreaking and > probably doesn't merit significant changes to the shell. I'm not > even convinced it

Re: [Help-bash] difference of $? and ${PIPESTATUS[0]}

On Mon, Apr 22, 2024 at 08:13:16AM +0200, felix wrote: > Then after some tests: > > if ls /wrong/path | wc | cat - /wrong/path | sed 'w/wrong/path' >/dev/null > ; then > echo Don't print this' > fi ; echo ${?@Q} ${PIPESTATUS[@]@A} $(( $? ${PIPESTATUS[@]/#/+} )) > > ls: cannot

Re: Erasing sensitive data from memory?

On Sun, Apr 21, 2024 at 02:16:57PM -0400, Zachary Santer wrote: > $ IFS='' read -e -r -s -p 'password: ' password > password: seems to be relevant here. I won't say that you have malicious intent here, but a script that behaves in this way is just a step

Re: [sr #111051] New commands: `-h`, `--help`

On Thu, Apr 18, 2024 at 03:20:21PM +0700, Robert Elz wrote: > ps: bash could probably lose the "be a login shell" '-' from argv[0][0] > for error messages. It isn't helpful. It's a tiny bit helpful for someone who knows what it means, and harmless for people who don't know. I'd prefer it to be

Re: [sr #111051] New commands: `-h`, `--help`

On Thu, Apr 18, 2024 at 03:03:32AM -0400, anonymous wrote: > they gave me reply: > > 'There isn't command `-h` on my Limux' > > Therefore, after calling -h/--help, I suggest displaying a message like: Adding a /usr/bin/-h command or whatever sounds like overkill to me. I wouldn't want that

Re: syntax error with lone > or < as string in [ ] tests with -a or -o operators

On Mon, Apr 15, 2024 at 08:13:23PM +0200, Emanuel Attila Czirai wrote: > On Mon, Apr 15, 2024 at 7:56 PM Greg Wooledge wrote: > > Sounds like you've found a nontrivial bug in FreeBSD (in the adduser > > script, not in sh). I hope this gets reported and fixed, and in any case

Re: syntax error with lone > or < as string in [ ] tests with -a or -o operators

On Mon, Apr 15, 2024 at 07:04:23PM +0200, Emanuel Attila Czirai wrote: > In my superficial report, I definitely didn't think of that. I even forgot > to mention that it works when escaped like "\>" > > I've encountered it in the "adduser" FreeBSD sh script that runs as root, > while trying to set

Re: syntax error with lone > or < as string in [ ] tests with -a or -o operators

On Sun, Apr 14, 2024 at 11:16:27AM +0200, Emanuel Attila Czirai wrote: > $ [ -n ">" -a -n "something" ] || echo hmm > bash: [: syntax error: `-n' unexpected > hmm Don't do this. You're in the land of unspecified behavior here. Use multiple test or [ commands instead, or use bash's [[ command.

Re: echo test >& "quote'test"

On Tue, Apr 09, 2024 at 01:37:08AM +, squeaky wrote: > Bash Version: 5.2 Patch Level: 21 Release Status: release > > Description: > > Running > echo test >& "quote'test" > should create the file "quote'test", but it creates "quotetest" > instead. I can

Re: Potential Bash Script Vulnerability

On Mon, Apr 08, 2024 at 02:23:18PM +0300, ad...@osrc.rip wrote: > Btw wouldn't it be possible (and worth) temporarily revoking write access to > the user while it's being executed as root, and restoring original rights > after execution? I think that would be a huge overreach. It would also lead

Re: Potential Bash Script Vulnerability

On Mon, Apr 08, 2024 at 12:40:55PM +0700, Robert Elz wrote: > or perhaps better just: > > main() { ... } ; main "$@" You'd want to add an "exit" as well, to protect against new lines of code being appended to the script.

Re: Potential Bash Script Vulnerability

On Mon, Apr 08, 2024 at 12:23:38AM +0300, ad...@osrc.rip wrote: > - Looks for list of PIDs started by the user, whether it's started in > terminal or command line, and saves them into $DotShProcessList > - Takes $DotShProcessList and filters out those that don't have root access. > Those that

Re: Scope change in loops with "read" built-in

On Thu, Apr 04, 2024 at 08:39:51PM -0400, Dale R. Worley wrote: > To circumvent that, I've sometimes done things like > > exec 3<( ... command to generate stuff ... ) > while read VAR <&3; do ... commands to process stuff ... ; done > exec 3<- Please note that the syntax for closing

Re: Scope change in loops with "read" built-in

On Tue, Apr 02, 2024 at 08:08:57PM +, Linde, Evan wrote: > In a loop constructed like `... | while read ...`, changes to > variables declared outside the loop only have a loop local > scope, unlike other "while" or "for" loops. https://mywiki.wooledge.org/BashFAQ/024

Re: > /dev/stderr 2>&-

On Fri, Mar 29, 2024 at 09:02:12PM +1100, Reuben wrote: > $ echo cat /dev/stderr > bug > $ bash bug 2>&- > cat /dev/stderr I don't understand what you were trying to do here. > calling bash script 2>&- on linux > seems to make /dev/stderr refer to script, > though &2 seems unaffected. > using

Re: Docco

On Wed, Mar 27, 2024 at 10:00:06AM +0100, Phi Debian wrote: > $ man bash > ... > CONDITIONAL EXPRESSIONS > ... > >-a file > True if file exists. >-e file > True if file exists. > ... > > 'May be' would be nice for newbies to precise which options are [

Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax

On Sun, Mar 24, 2024 at 03:54:10PM -0500, Dennis Williamson wrote: > The @K transform outputs key value pairs for indexed arrays as well as > associative arrays (you used the @k transform which does word splitting and > loses the k-v sequence). The @K (capital) transformation gives you quoted

Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax

On Sun, Mar 24, 2024 at 07:46:46PM +0200, Oğuz wrote: > On Sunday, March 24, 2024, Zachary Santer wrote: > > > > Yeah, but what can you do with @k? > > > It helps when reconstructing an associative array as a JSON object in JQ > > $ declare -A a=([x]=1 [y]=2) > $ jq --args -n

Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax

On Sun, Mar 24, 2024 at 01:04:38PM -0400, Zachary Santer wrote: > On Fri, Mar 22, 2024 at 11:23 AM Chet Ramey wrote: > > > > This is what you can do with @K. > > > > https://lists.gnu.org/archive/html/bug-bash/2021-08/msg00119.html > > > > Word splitting doesn't happen on the rhs of an assignment

Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax

On Fri, Mar 22, 2024 at 02:09:23PM -0400, Lawrence Velázquez wrote: > On Fri, Mar 22, 2024, at 12:54 PM, Greg Wooledge wrote: > > Also, I don't see the lower-case k transformation in the man page. > > It's at the end of the list: > > https://git.savannah.gnu.org/cgit/bash.g

Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax

On Fri, Mar 22, 2024 at 11:23:35AM -0400, Chet Ramey wrote: > This is what you can do with @K. > > https://lists.gnu.org/archive/html/bug-bash/2021-08/msg00119.html > > Word splitting doesn't happen on the rhs of an assignment statement, so you > use eval. The @K quoting is eval-safe. It would

Re: ${var@A}; hypothetical, related parameter transformations

On Wed, Mar 20, 2024 at 03:05:56PM -0400, Zachary Santer wrote: > I want a declare command, no matter what ${var@A} gives me. I have to > write a function for that: generate_declare_command (). That function > can work a couple of reasonable ways: This seems rather theoretical to me. If the

Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax

On Wed, Mar 20, 2024 at 12:53:07PM +0100, alex xmb sw ratchev wrote: > On Wed, Mar 20, 2024, 12:49 Greg Wooledge wrote: > > > On Wed, Mar 20, 2024 at 07:11:34AM -0400, Zachary Santer wrote: > > > On Wed, Mar 20, 2024 at 12:29 AM Lawrence Velázquez > > wrote: &

Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax

On Wed, Mar 20, 2024 at 07:11:34AM -0400, Zachary Santer wrote: > On Wed, Mar 20, 2024 at 12:29 AM Lawrence Velázquez wrote: > > A couple of previous discussions: > > - https://lists.gnu.org/archive/html/bug-bash/2020-12/msg00066.html > > -

Re: nameref and referenced variable scope, setting other attributes (was "local -g" declaration references local var in enclosing scope)

On Thu, Mar 14, 2024 at 10:15:35AM -0400, Zachary Santer wrote: > > $ cat ./nameref-what > > #!/usr/bin/env bash > > > > func_1 () { > > local var_3='EGG' > > func_2 > > printf '%s\n' "func_1:" > > local -p var_3 > > } > > > > func_2 () { > > local -n nameref_3='var_3' > >

Re: nameref and referenced variable scope, setting other attributes (was "local -g" declaration references local var in enclosing scope)

On Thu, Mar 14, 2024 at 08:29:47AM -0400, Zachary Santer wrote: > Alright, that's all fair. But this? > > On Sun, Mar 10, 2024 at 7:29 PM Zachary Santer wrote: > > > > Additionally, a nameref variable referencing a variable declared in a > > calling function hides that variable in the scope of

Re: nameref and referenced variable scope, setting other attributes (was "local -g" declaration references local var in enclosing scope)

On Thu, Mar 14, 2024 at 08:27:33AM +0100, alex xmb sw ratchev wrote: > how to unset a nameref Look at "help unset". Specifically the -n option.

Re: multi-threaded compiling

On Tue, Mar 12, 2024 at 09:42:22AM +0100, Mischa Baars wrote: > Here's the script and the Makefile using "printf '<%s>'": Sadly, your mail user agent chose to attach "Makefile" with content-type application/octet-stream, which my MUA (mutt) refuses to show inline, or to include in a reply as

Re: multi-threaded compiling

On Tue, Mar 12, 2024 at 02:15:38PM +0700, Robert Elz wrote: > Date:Mon, 11 Mar 2024 17:25:57 -0400 > From:Chet Ramey > Message-ID: <322e10a6-3808-49be-aa9d-a1d367a90...@case.edu> > > | OK, here's the longer answer. When the shell is interactive, and job > |

Re: multi-threaded compiling

On Tue, Mar 12, 2024 at 10:33:36AM +0100, Mischa Baars wrote: > bash -c 'set +m; seconds=1; for (( i=0;i<32;i++ )); do exit ${i} & done; > sleep ${seconds}; for (( i=0;i<32;i++ )); do wait -p pid; e=${?}; echo > "$(printf %3u ${i}) pid ${pid} exit ${e}"; done;' "wait -p pid" is not correct here.

Re: multi-threaded compiling

On Mon, Mar 11, 2024 at 10:19:26PM +0100, Mischa Baars wrote: > On Mon, 11 Mar 2024, 21:08 Kerin Millar, wrote: > > The pid can be obtained with the -p option, as of 5.1. Below is a > > synthetic example of how it might be put into practice. I'd forgotten about that one. A recent addition, and

Re: multi-threaded compiling

> On Mon, Mar 11, 2024, 20:13 Mischa Baars > wrote: > > > Also I don't think that gives you an exit status for each 'exit $i' > > started. I need that exit status. "wait -n" without a PID won't help you, then. You don't get the PID or job ID that terminated, and you don't get the exit status.

Re: multi-threaded compiling

On Mon, Mar 11, 2024 at 07:22:39PM +0100, Mischa Baars wrote: > On Mon, Mar 11, 2024 at 6:22 PM alex xmb sw ratchev > wrote: > > > i also completly dont get ur issue > > > > f=( a.c b.c .. ) threads=$( nproc ) i=-1 r= > > > > while [[ -v f[++i] ]] ; do > > (( ++r > threads )) && > > wait -n >

Re: multi-threaded compiling

On Mon, Mar 11, 2024 at 06:51:54PM +0100, Mischa Baars wrote: > SECONDS=5; for (( i=0;i<32;i++ )); do { exit ${i}; } & pid[${i}]=${!}; done; > sleep ${SECONDS}; for (( i=0;i<32;i++ )); do wait -n ${pid[${i}]}; e=${?}; > echo "$(printf %3u ${i}) pid ${pid[${i}]} exit ${e}"; done; > /bin/bash:

Re: "local -g" declaration references local var in enclosing scope

On Sun, Mar 10, 2024 at 06:39:19PM -0400, Lawrence Velázquez wrote: > On Sun, Mar 10, 2024, at 5:36 PM, Greg Wooledge wrote: > > Here it is in action. "local -g" (or "declare -g") without an assignment > > in the same command definitely does things. > >

Re: "local -g" declaration references local var in enclosing scope

On Sun, Mar 10, 2024 at 04:01:10PM -0400, Lawrence Velázquez wrote: > Basically, without an assignment, "local -g" does nothing. Well, the original purpose of -g was to create variables, especially associative arrays, at the global scope from inside a function. I think this thread has been

Re: Unable to close a file descriptor using exec command

On Sun, Mar 03, 2024 at 10:29:17PM +, Venkat Raman via Bug reports for the GNU Bourne Again SHell wrote: > Repeat-By: > exec 2> commands freezes the terminal and unable to close the > fd. > > Fix: > [Is there a sane way to close the fd?] You're using the wrong syntax. To

Re: possible bash bug bringing job. to foreground

On Sat, Feb 17, 2024 at 07:41:43PM +, John Larew wrote: > After further examination, the examples with "fg $$" and "fg $!" clearly do > not bring the subshell into the foreground, as they are evaluated prior to > the subshells background execution. > I'm trying to bring the subshell to the

Re: possible bash bug bringing job. to foreground

On Sat, Feb 17, 2024 at 01:30:00PM +, John Larew wrote: > Repeat-By: 1: (sleep 15s; set -m; fg %%; exit ) & 2: (sleep 15s; set -m; fg > %+; exit ) &  You're using %% or %+ inside a shell where there have NOT been any background jobs created yet. The sleep 15s runs in the foreground,

Re: printf - strange behaviour in debug mode (BASH_VERSION="5.2.21(1)-release")

On Thu, Feb 08, 2024 at 05:48:18PM +0200, Timotei Campian wrote: > The culprit function is *printargs() { printf "%s|" "$@"; echo; }* > > calling it with no arguments it prints as expected the pipe: "|" > while in debug mode (set -x), only a *blank line* is printed: > > $ printargs > printargs >

Re: set-e and command expansion

On Sun, Feb 04, 2024 at 08:27:56PM +0300, Van de Bugger wrote: > Case 3: echo $(false) > > $ cat ./test > #!/bin/bash > set -e > echo before > echo $(false) > echo after > > $ ./test > before > > after > > Oops, in this case the script is NOT terminated before "echo after", but >

Re: glob-expand-word and vi-command mode

On Fri, Feb 02, 2024 at 03:39:54PM +0100, Mike Jonkmans wrote: > [ mkdir test; cd test; touch file1 file2 ] > > Going into `vi-command' mode on the line `ls *' puts the cursor on the `*'. > Then `glob-expand-word' does nothing with the `*', it just inserts a space. > Resulting in `ls *' (cursor

Re: incorrect cursor position when navigating with 'ALT-b'

On Thu, Feb 01, 2024 at 01:55:50PM +0100, Korneel Dumon wrote: > Repeat-By: > Execute the following command: > > curl -X POST -H "Content-Type: application/json" > https://ec.europa.eu/taxation_customs/vies/rest-api/check-vat-test-service > -d '{"countryCode":"BE",

Re: wait -n misses signaled subprocess

On Mon, Jan 29, 2024 at 08:52:37PM +0700, Robert Elz wrote: > Date:Mon, 29 Jan 2024 13:54:10 +0100 > From:Andreas Schwab > Message-ID: > > | n = next? This was my assumption as well. > That would be a reasonable interpretation, I guess, but > unfortunately not

Re: wait -n misses signaled subprocess

On Sun, Jan 28, 2024 at 10:26:27PM -0500, Dale R. Worley wrote: > The man page doesn't make clear that if you don't specify "-n" and do > supply ids and one of them has already terminated, you'll get its status > (from the terminated table); the wording suggests that "wait" will > always *wait

Re: Path of exported variable not set as source

On Fri, Jan 26, 2024 at 03:28:11PM +0200, Ricky Tigg wrote: > $ export EDITOR='/usr/bin/nano' && source $HOME/.bashrc > $ echo $EDITOR > /usr/bin/vim > > Expected: Latest command's output to be "/usr/bin/nano" instaed of > "/usr/bin/vim". It's really unclear to me why you expected this. You're

Re: ./script doesn't work in completion function

On Mon, Jan 22, 2024 at 12:17:12PM +0200, Oğuz wrote: > On Monday, January 22, 2024, Martin D Kealey > wrote: > > > > You seem to have created an invalid executable. It seems that scripts > > without a #! can only be run with help from the debugger library > > > > Hi Martin, POSIX shells

Re: document that read built-in can't return zero-length string in the middle of input

On Sat, Jan 13, 2024 at 02:06:08AM +0700, Robert Elz wrote: > Date:Fri, 12 Jan 2024 07:15:35 -0500 > From: Greg Wooledge > Message-ID: > > | This was one of the things I tested: > > Perhaps intended to, but didn't, or not in this example: >

Re: document that read built-in can't return zero-length string in the middle of input

On Fri, Jan 12, 2024 at 03:26:31PM +0700, Robert Elz wrote: > Date:Thu, 11 Jan 2024 20:02:04 -0500 > From: Greg Wooledge > Message-ID: > > | What actually counts is how many > | characters are *stored* in the variable, not how many characte

Re: document that read built-in can't return zero-length string in the middle of input

On Thu, Jan 11, 2024 at 08:02:04PM -0500, Greg Wooledge wrote: > And this for the help text: > > -N nchars return only after storing exactly NCHARS characters, unless >EOF is encountered or read times out, ignoring any NUL or >delimiter chara

Re: document that read built-in can't return zero-length string in the middle of input

On Fri, Jan 12, 2024 at 01:29:19AM +0100, Ángel wrote: > One might say "reading exactly nchars characters into the name", I would still find that confusing. What actually counts is how many characters are *stored* in the variable, not how many characters are *read* from the input. > but > given

Re: document that read built-in can't return zero-length string in the middle of input

On Thu, Jan 11, 2024 at 09:29:03AM -0500, Chet Ramey wrote: > The read builtin skips over NUL characters because you can't store them > as part of the value of a shell variable. That seems obvious. I would argue that it's not obvious at all when using -N. The help text for -N says "return only

Re: mapfile weirdness ^@ is added it would seem if output is quoted

On Mon, Jan 01, 2024 at 04:38:20PM -0500, Federer Fanatic wrote: > Consider the following: > > shopt -s extdebug > mapfile -d" " < <(declare -F Results in the array MAPFILE having 3 entries with '2' entry containing the > filename > of bash function initial defining line I don't think this is

Re: Multi-line PS1 color disappearance problem

On Fri, Dec 22, 2023 at 07:25:30AM +, email--- via Bug reports for the GNU Bourne Again SHell wrote: > On 2023-12-21 17:32, Alex Ratchev wrote: > > > do u really PS1=\[\033 etc ? > > > > try PS1='\[\e...' > > > > in ' quotes > > I forgot quotes from the email. But I did not know that '\e'

Re: Unexpected Quick Substitution in string literals

On Thu, Dec 14, 2023 at 09:41:17AM +0530, Sundeep Agarwal wrote: > Thanks for the correction on my second example. I had assumed ^ wasn't > special inside double quotes since the documentation mentions only the ! > character for history expansion ( >

Re: funsub questions

On Thu, Dec 14, 2023 at 04:44:07AM +, Kerin Millar wrote: > On Wed, 13 Dec 2023 23:16:11 -0500 > Zachary Santer wrote: > > > On Wed, Dec 13, 2023 at 11:06 PM Greg Wooledge wrote: > > > Is that on a system that lacks a process manager? Something like > > > &

Re: funsub questions

On Wed, Dec 13, 2023 at 10:48:59PM -0500, Zachary Santer wrote: > On Wed, Dec 13, 2023 at 9:17 PM Greg Wooledge wrote: > > If you'd like to read the contents of a file into a variable, the > > "read" and "readarray" (aka "mapfile") builtins are usuall

Re: funsub questions

On Thu, Dec 14, 2023 at 02:39:04AM +, Kerin Millar wrote: > On Wed, 13 Dec 2023 21:17:05 -0500 > Greg Wooledge wrote: > > > On Wed, Dec 13, 2023 at 08:50:48PM -0500, Zachary Santer wrote: > > > Would there be a purpose in implementing ${< *file*; }

Re: funsub questions

On Wed, Dec 13, 2023 at 08:50:48PM -0500, Zachary Santer wrote: > Would there be a purpose in implementing ${< *file*; } to be the equivalent > of $(< *file* )? Does $(< *file* ) itself actually fork a subshell? $(< file) does indeed fork. The only difference between $(< file) and $(cat file) is

Re: Unexpected Quick Substitution in string literals

On Wed, Dec 13, 2023 at 10:50:16AM +0530, Sundeep Agarwal wrote: > $ echo "fig > ^mango" > bash: :s^mango": substitution failed I can confirm this happens in every version of bash, at least back to bash-2.05b which is as far as I can go, but only when history expansion is enabled (set -H or set

Re: Add example of bind readline-command-line

On Tue, Dec 12, 2023 at 10:06:49PM +0800, Dan Jacobson wrote: > bash man page says > -v Display readline variable names and values in such a way > that they can be re-read. > Perhaps add an example of rereading via the bind command: The man page also

Re: $((expr)) allows the hexadecimal constant "0x"

On Tue, Dec 12, 2023 at 12:10:02AM +0900, Koichi Murase wrote: > https://lists.gnu.org/archive/html/bug-bash/2019-06/threads.html#00039 Four years later, i=$(( ${i%%[!+-]*}10#${i#[-+]} )) is still horrible. Well, to be fair, five years since the original suggestion

Re: bash encountered a coredump issue with stepping on memory

On Wed, Dec 06, 2023 at 05:28:19PM +0800, wang yuhang via Bug reports for the GNU Bourne Again SHell wrote: > When the for loop reaches env, the values of each env are: > [...] > (gdb) p env[16] > $21 = 0x7ffce3c2e25a "DIRNAME_ALIAS" > (gdb) p env[17] > $22 = 0x7ffce3c2e279 "PID=" The

Re: Missing documentation "-bash_input"

On Wed, Nov 29, 2023 at 12:37:55AM +, Klaus Frank wrote: > One thing though, I probably should already know that, but why is a $0 > needed even though a command was already specified? Shouldn't the command > itself be $0? It's simply how sh -c has always worked. The first argument after -c

Re: Missing documentation "-bash_input"

On Tue, Nov 28, 2023 at 10:33:20PM +, Klaus Frank wrote: > sorry, but this is not true, I can clearly see that it exists. It may be an > distro addition though. Is it specific to ArchLinux? Here's what I get on Debian: unicorn:~$ bash -bash_input foobar -c 'read; declare -p REPLY' bash: -_:

Re: Command hangs when using process substitution

On Sat, Nov 18, 2023 at 08:36:06AM -0500, dbarrett--- via Bug reports for the GNU Bourne Again SHell wrote: > echo foo | tee >(xclip -i) | tr o x > > The command does print "fxx" but then it hangs. > > The same command behaves correctly when run in zsh. For the record, here's what processes

Re: posix command search and execution

On Sat, Nov 11, 2023 at 09:14:41AM +0100, Mike Jonkmans wrote: > On Fri, Nov 10, 2023 at 08:07:31PM -0500, Chet Ramey wrote: > > On 11/9/23 11:17 AM, Mike Jonkmans wrote: > > > On Thu, Nov 09, 2023 at 10:12:06PM +0700, Robert Elz wrote: > > > > > > On Ubuntu 22.04 `getconf path' returns

Re: the portability of seq(1) (was: Idea: jobs(1) -i to print only :%ID:s)

On Fri, Nov 10, 2023 at 01:09:29PM -0600, G. Branden Robinson wrote: > At 2023-11-10T10:54:52-0800, Eric Pruitt wrote: > > From _seq(1)_ on FreeBSD: > > > > > The seq command first appeared in Version 8 AT UNIX. A seq command > > > appeared in NetBSD 3.0, and was ported to FreeBSD 9.0. This

Re: Idea: jobs(1) -i to print only :%ID:s

On Fri, Nov 10, 2023 at 10:54:52AM -0800, Eric Pruitt wrote: > > A seq command appeared in Version 8 AT UNIX. This version of seq > > appeared in NetBSD 3.0 and was ported to OpenBSD 7.1. Ah, I'm a year and a half behind. OpenBSD 7.1 was released April 2022.

Re: Idea: jobs(1) -i to print only :%ID:s

On Fri, Nov 10, 2023 at 06:59:10PM +0100, Steffen Nurpmeso wrote: > Sequences are also bash-only (though seq(1) is > everywhere). It most definitely is *not* everywhere. It's part of GNU coreutils, and is generally not present on any system that does't use those (BSDs and commercial Unixes for

Re: Idea: jobs(1) -i to print only :%ID:s

On Thu, Nov 09, 2023 at 10:17:35PM +0100, Andreas Schwab wrote: > On Nov 09 2023, Greg Wooledge wrote: > > > re='^\[([0-9]+)\]' > > jobspecs=() > > while IFS= read -r line; do > > if [[ $line =~ $re ]]; then > > jobspecs+=( &q

Re: Idea: jobs(1) -i to print only :%ID:s

On Thu, Nov 09, 2023 at 08:09:23PM +0100, Steffen Nurpmeso wrote: > j() { > local j= a=${AWK:-awk} > [ $# -gt 0 ] && j='&& $2 !~ /(^| )('$(echo "$@" | tr ' ' '|')')( |$)/' > j=$(jobs -l | $a -F '[][]' '/^[[]/'"$j"'{print "%" $2}{next}') > echo $j > } Classic code injection

Re: nullglob is documented incorrectly

On Mon, Nov 06, 2023 at 08:56:11AM -0500, Chet Ramey wrote: > The null string (NULL) and the empty string ("") are not the same thing. If this is true, then the man page has many inconsistencies that need to be cleared up. For example, in the definition of PATH: PATH The search path

Re: Regex: A case where the longest match isn't being found

On Thu, Oct 26, 2023 at 10:50:13AM -0700, Dan Bornstein wrote: > I found a case where the regex evaluator doesn't seem to be finding the > longest possible match for a given expression. The expression works as > expected on an older version of Bash (3.2.57(1)-release > (arm64-apple-darwin22)).

Re: BUG: Colorize background of whitespace

On Wed, Oct 25, 2023 at 02:48:20PM +, David wrote: > On Wed, 25 Oct 2023 at 11:51, Greg Wooledge wrote: > > On Wed, Oct 25, 2023 at 10:29:32AM +0200, Holger Klene wrote: > > > Repeat-By: > > > run the following command line: > > > clear; seq 50; p

Re: BUG: Colorize background of whitespace

On Wed, Oct 25, 2023 at 10:29:32AM +0200, Holger Klene wrote: > Description: > The initial bash background is hardcoded to some default (e.g. black) and > cannot be colorized by printing "transparent" tabs/newlines with > ANSI-ESC-codes. > Only after a vertical scrollbar appears, the whitespace

Re: bash tries to parse comsub in quoted PE pattern

On Wed, Oct 18, 2023 at 09:39:36AM -0400, Zachary Santer wrote: > I guess I still want to hear about "${#@}" and $[ ]. $[ ] is officially deprecated, and users are advised to stop using it. It was originally going to be the syntax for arithmetic expansion, and made it as far as some POSIX rough

Re: bash tries to parse comsub in quoted PE pattern

On Wed, Oct 18, 2023 at 08:19:35AM -0400, Zachary Santer wrote: > On Tue, Oct 17, 2023 at 5:56 PM Emanuele Torre > wrote: > > > bash-5.1$ letters=( {a..z} ); echo "${letters["{10..15}"]}" > > k l m n o p > > > > Then there's the question "Was that even supposed to work like that?" This

Re: wrong variable name in error message about unbound variable?

On Tue, Oct 17, 2023 at 04:46:22AM +0200, Christoph Anton Mitterer wrote: > But why does it even try to evaluate the subscript "key" as arithmetic > expression? Because that's how indexed arrays work. Everything inside the square brackets is an arithmetic expression, and in an arithmetic

Re: variable set in exec'ing shell cannot be unset by child shell

On Sat, Oct 14, 2023 at 12:55:21PM -0400, Ti Strga wrote: > it's just the "[[ -v > foo ]]" tests to see where along the cloning process we are. *Shudder* I foresee so much more pain in your future. Seriously, this is going to blow up in your face at some point. -v peeks into some incredibly

Re: variable set in exec'ing shell cannot be unset by child shell

On Fri, Oct 13, 2023 at 02:21:59PM -0400, Dale R. Worley wrote: > I was too lazy to chew through your example, but I coded an instance of > your description (above), and it does not show the dubious behavior that > you report. Specifically, > > $ bash -version > GNU bash, version

Re: "here document" causing failures. Implementation is inconsistent and not documented.

On Wed, Oct 11, 2023 at 11:56:42AM +1100, Jim McD wrote: > Bug: > Trailing white space after the delimiting tag cause the here document to > fail with an error like > /./: line : warning: here-document at line > delimited by end-of-file (wanted `msg_end')Trailing white > space/ > > Trailing

Re: error message lacks useful debugging information

On Thu, Oct 05, 2023 at 07:04:26AM +0200, Phi Debian wrote: > Since we are on the error path (not the perf path) may be the shell could > go the extra miles and try some more diag, has it does for shebang, on > ENOENT, the shell could try to open the a.out, if OK try some other > euristics, [...]

Re: error message lacks useful debugging information

On Wed, Oct 04, 2023 at 08:05:41PM -0400, Dave Cigna via Bug reports for the GNU Bourne Again SHell wrote: > Attempting to tun an executable file (not a bash script) with the following > command: > > ./Candle > > the following error message is reported by bash: > > bash: ./Candle: cannot

Re: bug:

On Tue, Oct 03, 2023 at 12:54:45PM +, queency jones via Bug reports for the GNU Bourne Again SHell wrote: > BASH_VERSION='5.1.4(1)-release'PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"no > compile needed > i made a fifo file by typing: mkfifo gdbout.fifo > i coded a resource file named  :

Re: Prompt messed up if PS1 contains ANSI escape sequences

On Thu, Sep 07, 2023 at 04:03:39PM +0200, Gioele Barabucci wrote: > The following snippet shows that, even with the final \], Bash produces the > same erroneous output and miscalculates the cursor position (it just needs a > longer prompt): > > $ long_name="$(printf 'abcdef0123456789/%.0s'

Re: Prompt messed up if PS1 contains ANSI escape sequences

On Thu, Sep 07, 2023 at 03:46:23PM +0200, Gioele Barabucci wrote: > On 07/09/23 15:00, alex xmb ratchev wrote: > > u have to \[ esc-seq \] > > eg inside \[ and \] > > > > PS1=$'\u\[\e[1m\]\h\[\e[0m- ' > > > > should display hostname bold > > Thanks for the suggestion, but adding \] does not

  1   2   3   4   5   6   7   8   9   10   >