Re: waiting for process substitutions

how most people *think* wait -n currently works. The common use case for "wait -n" is a loop that tries to process N jobs at a time. Such as this one: greg@remote:~$ cat ~greybot/factoids/wait-n; echo Run up to 5 processes in parallel (bash 4.3): i=0 j=5; for elem in "${array[@]

Re: pwd and prompt don't update after deleting current working directory

On Fri, Jul 12, 2024 at 10:26:54 +0700, Robert Elz wrote: > Is it supposed to continually run "stat($PWD, ...)" forever (after > all the directory might be removed from elsewhere while you're in > the middle of typing a command - what do you expect to happen then?) It's even worse: let's say a

Re: Local variable can not unset within shell functions

On Thu, Jul 11, 2024 at 15:39:41 -0400, Lawrence Velázquez wrote: > I won't speculate about the issue, but your subject goes too far. > The variable really is unset here: > > % cat /tmp/x.bash > x() { > local x=y > declare -p x > echo "x is

Re: Env var feature request

On Tue, Jul 09, 2024 at 20:14:27 +, Erik Keever wrote: > A --debug-envvars flag which will, when passed to bash, catch every time an > environment variable is set and print the file/line that is setting it. To > restrict it, "--debug-envvars FOO,BAR" to catch only instances of FOO or BAR >

Re: waiting for process substitutions

On Mon, Jul 08, 2024 at 22:45:35 +0200, alex xmb sw ratchev wrote: > On Mon, Jul 8, 2024, 22:15 Chet Ramey wrote: > > > On 7/8/24 4:02 PM, alex xmb sw ratchev wrote: > > > > > hi , one question about .. > > > if a cmd contains more substitions like >( or <( , how to get all $! > > > maybe make

Re: proposed BASH_SOURCE_PATH

On Sun, Jul 07, 2024 at 21:23:15 +0200, alex xmb sw ratchev wrote: > hi .. > i dont get the BASH_SOURCE[n] one > the point of prefix $PWD/ infront of relative paths is a static part of > fitting into the first lines of the script , assigning vars > .. if u cd first then want the old relative path

Re: waiting for process substitutions

On Fri, Jul 05, 2024 at 15:16:31 -0400, Chet Ramey wrote: > They're similar, but they're not jobs. They run in the background, but you > can't use the same set of job control primitives to manipulate them. > Their scope is expected to be the lifetime of the command they're a part > of, not run in

Re: printf fails in version 5.2.026-3

On Wed, Jul 03, 2024 at 22:24:43 +0200, szige...@delg0.elte.hu wrote: > Description: > printf works in version 5.2.026-2, fails in version 5.2.026-3 What exactly are these version numbers? Are they packages from some Linux distrbution? > Repeat-By: > contents of tmp.sh begins

Re: feature suggestion: ability to expand a set of elements of an array or characters of a scalar, given their indices

On Fri, Jun 28, 2024 at 08:50:50 -0400, Zachary Santer wrote: > Is "${array[@]( "${indeces[@]}" )}" ugly? Does that matter? It seems > like a good way to write what's happening. I still have to look up > some of the less-commonly-used parameter expansions every time I use > them. I think people

Re: feature suggestion: ability to expand a set of elements of an array or characters of a scalar, given their indices

On Wed, Jun 26, 2024 at 14:09:13 -0400, Zachary Santer wrote: > > > Imagine this functionality: > > > $ array=( zero one two three four five six ) > > > $ printf '%s\n' "${array[@]( 1 5 )}" > > > one > > > five > I did want to see if others would find this valuable, and no one spoke > up, so it's

Re: readarray leaves a NULL char embedded in each element

On Mon, Jun 24, 2024 at 20:01:45 +0200, Davide Brini wrote: > $ ./printarg "${X[0]}A" > 65 32 65 0 83 > > That is, "A", a space, and "A" again (which is the result of the quoted > expansion), 0 for the string terminator, and a random 83 which is > whatever follows in memory (strangely, it seems

Re: readarray leaves a NULL char embedded in each element

On Mon, Jun 24, 2024 at 10:50:15 -0600, Rob Gardner wrote: > Description: > When using space or newline as a delimiter with readarray -d, > > elements in the array have the delimiter replaced with NULL, > > which is left embedded in each element of the array. This isn't

Re: bash crashes when splitcurl script try download non existent file

On Fri, Jun 21, 2024 at 22:26:07 +0500, Mikhail Gavrilov wrote: > On Fri, Jun 21, 2024 at 10:06 PM Chet Ramey wrote: > > Bash allows recursive trap handlers. > > Ok. But it's very suspicious for me because the script ended without > any issues on macOS. > > mikhail@MBP-Mikhail ~> ./splitcurl.sh

Re: Question that baffles AI (all of them)

On Sat, Jun 15, 2024 at 05:30:17PM -0400, Saint Michael wrote: > in this code: > data="'1,2,3,4','5,6,7,8'" > how can I get my (a) and (b) arguments right? > The length of both strings is unpredictable. > a="1,2,3,4" and b="5,6,7,8"" This is a parsing problem. Bash is not a particularly good

Re: set -a leads to truncated output from ps

On Sat, Jun 15, 2024 at 07:48:42AM +0300, Oğuz wrote: > Right now, if you're dealing with such a program while `set -a' is in > effect, in order to suppress COLUMNS you need to unexport it before every > command: Or just turn off checkwinsize.

Re: set -a leads to truncated output from ps

On Fri, Jun 14, 2024 at 11:36:19AM +, Alain BROSSARD wrote: > ps axww isn’t impacted, but the scripts use ‘ps ax’. Oh. Well then, that's the most obvious thing to fix.

Re: set -a leads to truncated output from ps

t:~$ COLUMNS=60 ps ww -fp 192331 UID PIDPPID C STIME TTY STAT TIME CMD greg 192331 192024 0 07:11 tty1 Sl 0:00 /opt/google/chrome/chrome --type=renderer --crashpad-handler-pid=192013 --enable-crash-reporter=CB81BA40-8F5C-190E-68BD-10B3F798FC39, --change-stack-guar

Re: Poor messages when the '#!' file isn't found

On Fri, Jun 14, 2024 at 02:13:37AM +0800, Dan Jacobson wrote: > $ echo \#!/usr/bin/python > k > $ chmod +x k > $ ./k > bash: ./k: cannot execute: required file not found > > Bash should really mention what file it is talking about. Bash doesn't KNOW what file is missing. All it knows is that

Re: set -a leads to truncated output from ps

On Thu, Jun 13, 2024 at 06:12:21PM +0200, Andreas Schwab wrote: > Why do you think this is a bug in bash? You are telling the shell to > export any modified variable, and you get what you asked for. I started writing something like this as well but deleted it. I think there's still a bit of

Re: it, soRE: set -a leads to truncated output from ps

On Thu, Jun 13, 2024 at 06:28:23PM +, Alain BROSSARD via Bug reports for the GNU Bourne Again SHell wrote: >My conclusion is that the variable COLUMNS gets “reset” when there is a > pipe in a command and further gets EXPORTED if “set -a” was set before hand : > > host:/$ COLUMNS=80 >

Re: Echoing commands

On Thu, Jun 13, 2024 at 11:51:13AM -0400, Dale R. Worley wrote: > For instance, how should this be logged? > > $ { echo foo ; echo bar ; } >/dev/null > + echo foo > + echo bar I'm 99% sure I know what answer the OP of this thread will give: "It should write '{ echo foo ; echo bar ; }

Re: Echoing commands

On Thu, Jun 13, 2024 at 10:01:16AM +0200, Angelo Borsotti wrote: > @echo-on > cat f1.txt f1.txt > f1.tmp > @echo-off > > I.e. the command is not entirely displayed. Yeah. This is what I mentioned originally: set -x does not show redirections. Ever. There is no workaround for this currently. A

Re: Echoing commands

On Wed, Jun 12, 2024 at 07:31:13PM +0200, Angelo Borsotti wrote: > "set -x" makes the ensuing commands be printed, but prefixed > with "+ ", which makes the result look ugly, not to mention that > the following "set +x" is echoed too (there are hacks to suppress > the "set +x" output, but they are

Re: REQUEST - bash floating point math support

On Wed, Jun 05, 2024 at 01:31:20PM -0400, Saint Michael wrote: > the most obvious use of floating variables would be to compare > balances and to branch based on if a balance is lower than a certain > value > I use: > t=$(python3 -c "import math;print($balance > 0)") > and the > if [ "$t" ==

Re: REQUEST - bash floating point math support

On Wed, Jun 05, 2024 at 09:57:26PM +0700, Robert Elz wrote: > Also note that to actually put floating support in the shell, more is > needed than just arithmetic, you also need floating comparisons in test > (or in bash, in [[ ) and a whole bunch more odds and ends that aren't > obvious until you

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

Y TIME CMD 1152 pts/300:00:00 bash 542197 pts/300:00:00 sleep 542200 pts/300:00:00 ps unicorn:~$ ps -fp 542197 UID PID PPID C STIME TTY TIME CMD greg 542197 1 0 08:59 pts/300:00:00 sleep 37 wait -n *does* appear to acknowledge the

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

  1   2   3   4   5   6   7   8   9   10   >