Re: /dev/tcp feature request...

On Tue, Apr 8, 2025 at 7:04 AM Greg Wooledge wrote: > > On Tue, Apr 08, 2025 at 06:34:50 +0300, Oğuz wrote: > > On Tuesday, April 8, 2025, A. James Lewis wrote: > > > I have however found it extremely frustrating to open TCP connections > > > via /dev/tcp, because there appears to be no way to co

Re: Bug: please document extended and alternate for loop syntax

On Mon, Mar 10, 2025 at 10:54 AM John Wiersba via Bug reports for the GNU Bourne Again SHell wrote: > > 2) However, if the alternate syntax is actively supported, then I think it > *should* be documented, even if it is considered error-prone and if > "best-practice" is to avoid it. > The alterna

Re: "printf %d ''" should diagnose the empty string

On Mon, Feb 10, 2025 at 2:43 PM Lawrence Velázquez wrote: > > This accepts many valid expressions, not just literals. > > phi() { > (($1)) || (($1==0)) > } phi 'i[$( date >&2 )]' Whoopsie-daisy. https://mywiki.wooledge.org/BashPitfalls#read_num.3B_echo_.24.28.28nu

Re: "printf %d ''" should diagnose the empty string

Once again left a dumb mistake in my bash snippet. On Mon, Feb 10, 2025 at 11:34 AM Zachary Santer wrote: > > And then this isn't even half as good: > int_regex='^([+-]?)0*([[:digit:]]+)$' > if [[ ${var} =~ ${int_regex} ]]; then > var="${BASH_REMATCH[1]}${

Re: "printf %d ''" should diagnose the empty string

On Mon, Feb 10, 2025 at 11:48 AM Chet Ramey wrote: > > On 2/10/25 11:34 AM, Zachary Santer wrote: > > On Mon, Feb 10, 2025 at 9:20 AM Phi Debian wrote: > >> > >> If 'best *general*' refer to the shortest line noise does > >> > >> $((

Re: "printf %d ''" should diagnose the empty string

On Mon, Feb 10, 2025 at 9:20 AM Phi Debian wrote: > > If 'best *general*' refer to the shortest line noise does > > $((${i/?([-+])/&10#})) > > Qualify for better than best ? :-) And then this isn't even half as good: int_regex='([+-]?)0*([[:digit:]]+)' if [[ ${var} =~ ${int_regex} ]]; then var

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

On Tue, Dec 24, 2024 at 12:10 PM Zachary Santer wrote: > > On Mon, Dec 23, 2024 at 11:50 AM Chet Ramey wrote: > > > > On 12/20/24 11:04 AM, Zachary Santer wrote: > > > > > Explicitly attempting to expand any one of those with a parameter > > > expans

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

On Tue, Dec 24, 2024 at 7:51 PM Lawrence Velázquez wrote: > > On Tue, Dec 24, 2024, at 12:10 PM, Zachary Santer wrote: > > Some other nonsense real quick: > > > > zsant@Zack2021HPPavilion MSYS ~/repos/bash > > $ : ${| REPYL="whatever"} > > ;

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

On Mon, Dec 23, 2024 at 11:50 AM Chet Ramey wrote: > > On 12/20/24 11:04 AM, Zachary Santer wrote: > > > Explicitly attempting to expand any one of those with a parameter > > expansion when it's unset and 'set -u' is active will cause bash to > > err

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

On Fri, Dec 20, 2024 at 11:50 AM Greg Wooledge wrote: > > On Fri, Dec 20, 2024 at 11:04:35 -0500, Zachary Santer wrote: > > On Thu, Dec 19, 2024 at 11:08 AM Chet Ramey wrote: > > > So you're saying that bash looking at a specific variable and using its > > > va

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

On Thu, Dec 19, 2024 at 11:08 AM Chet Ramey wrote: > > On 12/18/24 9:39 PM, Zachary Santer wrote: > > > If one wants to use funsubs that don't expand to anything as a > > workaround like this, it might be more efficient to use the ${| > > command; } form

${| command; } funsub not setting REPLY does not error out with 'set -u' active

Was "waiting for process substitutions". On Sat, Oct 12, 2024 at 10:09 AM Zachary Santer wrote: > > On Sun, Jul 14, 2024 at 8:40 PM Zachary Santer wrote: > > > > On Tue, Jul 9, 2024 at 2:37 PM Zachary Santer wrote: > > > > > > On the

Re: String substitution bug

On Mon, Nov 25, 2024 at 9:48 PM Martin D Kealey wrote: > > On Mon, 25 Nov 2024 at 22:22, Zachary Santer wrote: >> >> People can write bad code in any language. > > Yeah, that includes English, apparently. > > The problem is that the Shell makes it hard to write good

Re: String substitution bug

On Mon, Nov 25, 2024 at 5:07 AM Martin D Kealey wrote: > > How about this for a concrete proposal: let's split the current man page > into a page per topic. The following list is alphabetical, though I should > probably put it in some kind of narrative order. > >[...] You mostly just reinvent

Re: String substitution bug

On Sun, Nov 24, 2024 at 7:52 AM Martin D Kealey wrote: > > When one already knows how it works, that's obvious, and it's hard to see > how it could mean anything else. > > When one *doesn't *already know how it works, “using the syntax *[:class:]*” > could just as easily mean using *:class:* insid

Re: [PATCH] lib/readline/doc makefiles clean targets

On Thu, Nov 7, 2024 at 6:06 PM Chet Ramey wrote: > > If you find yourself in this sitution, it's easy enough to remove > parser-built and y.tab.c and run make again before I fix it. $ git clean -xfdq In MSYS2 on Windows, all the generated executables end in ".exe", which of course the .gitignore

Re: bash -xv issue with stderr

On Mon, Nov 4, 2024 at 3:21 AM Christoph Zimmermann wrote: > > As I can't seem to find this: https://git.savannah.gnu.org/git/bash.git

Re: posix vs default mode nonsense

On Tue, Oct 22, 2024 at 11:30 AM Chet Ramey wrote: > > but that won't help with the portability problems. You can't even use arrays or [[ ... ]] and be portable, right? It might be easier to install bash on whatever it is at that point.

Re: posix vs default mode nonsense

On Mon, Oct 21, 2024 at 5:07 PM Lawrence Velázquez wrote: > > On Mon, Oct 21, 2024, at 4:23 PM, Zachary Santer wrote: > > On Mon, Oct 21, 2024 at 11:53 AM Chet Ramey wrote: > >> > >> That changed to an application requirement in 2001. > > > > P

Re: posix vs default mode nonsense

On Mon, Oct 21, 2024 at 11:50 AM Chet Ramey wrote: > > On 10/21/24 12:15 AM, Zachary Santer wrote: > > > > The nontrivial stuff I do is still being run by bash 4.2 at the > > moment, and I'm not willing to give up procsubs. > > Probably something to take up with

posix vs default mode nonsense

Was "'wait -n' with and without id arguments" On Sun, Oct 20, 2024 at 10:30 PM Grisha Levit wrote: > > > On Sun, Oct 20, 2024, 20:52 Zachary Santer wrote: >> >> >> Item 8 is just odd and is on the verge of being a dealbreaker. Not to >> go of

Re: 'wait -n' with and without id arguments

On Thu, Oct 17, 2024 at 6:14 PM Chet Ramey wrote: > > On 9/29/24 12:55 PM, Zachary Santer wrote: > > On Wed, Sep 25, 2024 at 11:06 AM Chet Ramey wrote: > >> > > I might argue that calling 'jobs' within a script being executed > > normally shoul

Re: waiting for process substitutions

On Sat, Oct 12, 2024 at 12:33 PM Oğuz wrote: > > On Saturday, October 12, 2024, Zachary Santer wrote: >> >> Backwards compatibility with people's expectations > > No one expects children of the same parent to be able to wait for eachother. > It'

Re: waiting for process substitutions

On Sun, Jul 14, 2024 at 8:40 PM Zachary Santer wrote: > > On Tue, Jul 9, 2024 at 2:37 PM Zachary Santer wrote: > > > > On the other hand, do funsubs give us the answer here? > > > > shopt -s lastpipe > > declare -a pid=() > > command-1 | tee >( c

Re: 'wait -n' with and without id arguments

it-n-failure::main explicit_pids monitor notify posix Got one run where it waited for one process and called it quits. No error message from 'sleep', so who knows? Got a 104 / 100 at one point. 100s are more prevalent than in the last case. Job ids are able to creep up from 1 throughout ex

Re: 'wait -n' with and without id arguments

after only waiting for one. On Tue, Sep 17, 2024 at 2:46 PM Chet Ramey wrote: > > On 9/9/24 10:45 AM, Zachary Santer wrote: > > >> He wants interactive shells to notify the user less frequently about job > >> status changes so `wait -n' works better. > > > >

Bash - Errors in German help echo documentation (and other languages)

On Mon, Sep 9, 2024 at 9:04 AM secretuser56 wrote: > > There are errors in the German 'help echo' command in po/de.po and po/de.gmo. > The descriptions for the following escape sequences are missing: \u > \U > Besides that there are two backslashs missing. One in front of \a\tAlarm an

Re: 'wait -n' with and without id arguments

On Mon, Sep 9, 2024 at 9:06 AM Chet Ramey wrote: > > On 9/8/24 11:13 PM, Oğuz wrote: > > On Monday, September 9, 2024, Zachary Santer > <mailto:zsan...@gmail.com>> wrote: > > > > Slightly improved wait-n-failure attached. > > > > > > It

Re: 'wait -n' with and without id arguments

Slightly improved wait-n-failure attached. On Thu, Sep 5, 2024 at 12:10 PM Chet Ramey wrote: > > On 8/30/24 11:06 PM, Zachary Santer wrote: > > CWRU/CWRU.chlog: > > >8/26 > > > > > > > > execute_cmd.c > > > [...] > >

Re: 'wait -n' with and without id arguments

t when bash is in posix mode. I don't understand what posix mode changes relative to the existing behavior if not that. > jobs.c > - notify_and_cleanup: make interactive shells notifying during sourced > scripts dependent on the shell compatibility level and inactive in > v

Re: eval '<$(;)' causes Segmentation Fault

On Sun, Aug 25, 2024 at 8:57 PM wrote: > > All the following scripts can create a Segmentation Fault > > eval '<$[;]' > > eval '<$(;)' > > eval '<${;}' > > eval '<$[|]' > > eval '<$(|)' > > eval '<${|}' Configuration Information [Automatica

Re: 'wait -n' with and without id arguments

On Wed, Aug 14, 2024 at 11:22 PM Zachary Santer wrote: > > The implicit 'jobs' isn't happening before each PS1, but after each > command completes. Thus, all the > > [1] Donerandom_sleep > notifications when sourcing wait-n-failure, before

Re: 'wait -n' with and without id arguments

On Wed, Aug 14, 2024 at 3:26 PM Chet Ramey wrote: > > On 8/12/24 11:57 AM, Zachary Santer wrote: > > > > Nobody had any answers in my help-bash > > thread on this topic, but does the devel branch have any build > > dependency that differs from those of the maste

Re: 'wait -n' with and without id arguments

On Wed, Aug 14, 2024 at 3:22 PM Chet Ramey wrote: > > On 8/7/24 2:47 PM, Zachary Santer wrote: > > > Now I understand that this is because the list of terminated child > > processes that 'wait -n' currently ignores is only used in the > > interactive shell.

Re: 'wait -n' with and without id arguments

On Mon, Aug 12, 2024 at 11:13 AM Chet Ramey wrote: > > On 8/7/24 2:47 PM, Zachary Santer wrote: > > > Now I understand that this is because the list of terminated child > > processes that 'wait -n' currently ignores is only used in the > > interactive shell.

Re: 'wait -n' with and without id arguments

On Mon, Aug 12, 2024 at 11:12 AM Chet Ramey wrote: > > That stuff changed last month, after bash-5.3-alpha was released. Before > that change, neither interactive nor non-interactive shells checked the > list of saved statuses. The difference was when the user was notified of > a process's exit st

Re: 'wait -n' with and without id arguments

On Fri, Aug 9, 2024 at 10:38 AM Chet Ramey wrote: > > When I source your script on macOS with the current devel build, I get the > set of notification messages and termination with a false argument, and an > infinite loop with a true argument. So basically, 'wait -n' should be implemented such th

Re: 'wait -n' with and without id arguments

On Fri, Aug 9, 2024 at 2:52 PM Greg Wooledge wrote: > > The problem is that our entire understanding of what "wait -n" DOES has > been annihilated. We thought it would "trigger" exactly once for every > completed background process, regardless of whether they completed > before or after calling "

Re: 'wait -n' with and without id arguments

On Fri, Aug 9, 2024 at 10:38 AM Chet Ramey wrote: > > OK, I see what's happening. When the shell is interactive, it notifies > the user when a background job terminates and prints a message to the > terminal. That's the series of > > [2] Donerandom_sleep > > messages you see.

Re: 'wait -n' with and without id arguments

On Wed, Aug 7, 2024 at 11:06 AM Chet Ramey wrote: > > On 7/31/24 11:40 AM, Zachary Santer wrote: > > > > I think I was missing more than that. Was the original 'wait -n' > > discussion from January specific to its use within the interactive > > shell? >

Re: waiting for process substitutions

On Wed, Aug 7, 2024 at 10:27 AM Chet Ramey wrote: > > On 8/5/24 11:00 PM, Zachary Santer wrote: > > On Mon, Aug 5, 2024 at 5:10 PM Chet Ramey wrote: > >> > >> But in the end, if you're waiting for a process that isn't going to > >> term

Re: waiting for process substitutions

On Tue, Aug 6, 2024 at 3:20 PM Oğuz wrote: > > To me it just shows how lost you are, sorry. Perhaps you should consider > other languages, or write a utility that makes setting up FIFOs easier, I > don't know. All the scripts I've discussed in this email list run and act on the output of extern

Re: waiting for process substitutions

On Tue, Aug 6, 2024 at 10:21 AM Oğuz wrote: > > On Tuesday, August 6, 2024, Zachary Santer wrote: >> >> How bash is actually used should guide its development. > > Correct. No one waits for procsubs in their scripts or on the command line. On Wed, Jul 3, 2024 at 8:40 

Re: waiting for process substitutions

On Tue, Aug 6, 2024 at 9:09 AM Oğuz wrote: > > On Tue, Aug 6, 2024 at 2:58 PM Zachary Santer wrote: > > I can not think of a time when I called 'wait' from the command line > > that wasn't just for testing something. Even using process > > substitutions o

Re: waiting for process substitutions

On Tue, Aug 6, 2024 at 1:19 AM Oğuz wrote: > > The benefit is they're separate from async jobs and don't get in your way. > `wait' waiting for the last procsub is acceptable, `wait' waiting for a > procsub that I forgot about and that won't be listed by `jobs' is not. I can not think of a time

Re: waiting for process substitutions

On Mon, Aug 5, 2024 at 5:10 PM Chet Ramey wrote: > > But in the end, if you're waiting for a process that isn't going to > terminate, you're going to be waiting for a long time. So, even with wait without id arguments restricted to the final procsub, if its process id is the same as $!, it's stil

Re: waiting for process substitutions

On Mon, Aug 5, 2024 at 9:54 AM Chet Ramey wrote: > > On 7/31/24 11:48 AM, Zachary Santer wrote: > > > > $ wait -n > >( cat ) > > would hang, in the event that there are no other un-waited-for child > > processes, right? > > Yes, it will wait for the ne

Re: 'wait -n' with and without id arguments

On Wed, Jul 31, 2024 at 11:40 AM Zachary Santer wrote: > > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: msys > Compiler: gcc > Compilation CFLAGS: -g -O2 > uname output: MSYS_NT-10.0-19045 Zack2021HPPavilion > 3.5.3-d8b21b8c

Re: waiting for process substitutions

On Fri, Jul 26, 2024 at 10:19 AM Chet Ramey wrote: > > You could have looked at the actual commit, which contains the change log, > which says > > - wait_for_any_job: check for any terminated procsubs as well as any >terminated background jobs > > wait_for_any_job is the function that backs `w

Re: 'wait -n' with and without id arguments

On Fri, Jul 26, 2024 at 10:37 AM Chet Ramey wrote: > > On 7/20/24 1:50 PM, Zachary Santer wrote: > > > > 'wait' without -n or pid arguments doesn't look in the list of saved > > pids and statuses simply because it would serve no purpose for it to > >

'wait -n' with and without id arguments

ents; wait -n can wait for process substitutions if supplied pid arguments On Thu, Jul 18, 2024 at 12:36 PM Chet Ramey wrote: > > On 7/14/24 8:40 PM, Zachary Santer wrote: > > > On Fri, Jul 5, 2024 at 2:38 PM Chet Ramey wrote: > >> > >> There is code tagged > &g

Re: waiting for process substitutions

On Thu, Jul 18, 2024 at 5:02 PM Chet Ramey wrote: > > It's not in the set of changes to `wait -n' I just pushed, but it will be > in the next push. Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: msys Compiler: gcc Compilation CFLAGS: -g -O2 uname output: M

Re: anonymous pipes in recursive function calls

On Sun, Jul 7, 2024 at 9:40 PM Zachary Santer wrote: > > On Sun, Jul 7, 2024 at 2:44 PM Chet Ramey wrote: > > > > Why not check the releases -- with patches -- between the two? They're > > all available via git if you don't want to download tarballs. > >

Re: waiting for process substitutions

hr (string, '/') != (char *)NULL || - (char *)mbschr (string, '\\') != (char *)NULL) + (char *)mbschr (string, '\\') != (char *)NULL); #endif } On Tue, Jul 9, 2024 at 2:37 PM Zachary Santer wrote: > > On the other hand, do funsubs give us the answer here? > &g

Re: waiting for process substitutions

On Tue, Jul 9, 2024 at 6:12 AM Zachary Santer wrote: > > command-1 | tee >( command-2 ) >( command-3 ) >( command-4 ) > wait > > The workaround for this not working would of course be named pipes, > which is somewhat less trivial. > Bash is already tracking the pi

Re: waiting for process substitutions

On Fri, Jul 5, 2024 at 2:38 PM Chet Ramey wrote: > > On 6/29/24 10:51 PM, Zachary Santer wrote: > > so you were then able to wait for each process substitution individually, > as long as you saved $! after they were created. `wait' without arguments > would sti

Re: anonymous pipes in recursive function calls

On Sun, Jul 7, 2024 at 2:44 PM Chet Ramey wrote: > > On 7/1/24 8:08 PM, Zachary Santer wrote: > > > > Would still like to know roughly when these issues were resolved. > > Why not check the releases -- with patches -- between the two? They're > all available via g

Re: waiting for process substitutions

On Wed, Jul 3, 2024 at 11:21 AM Chet Ramey wrote: > > Process substitutions are word expansions, with a scope of a single > command, and are not expected to survive their read/write file descriptors > becoming invalid. You shouldn't need to `wait' for them; they're not > true asynchronous processe

Re: waiting for process substitutions

On Tue, Jul 2, 2024 at 9:59 PM Zachary Santer wrote: > > I *am* seeing a difference between having lastpipe enabled (and job > control off) or not when running your example in the interactive > shell, though: > SECONDS=0; echo $'foo\nbar' | tee >(echo first ; exit 1)

Re: waiting for process substitutions

On Tue, Jul 2, 2024 at 4:56 PM Mark March wrote: > > lastpipe takes effect only if job control is off. From the man page: > > lastpipe > If set, and job control is not active, the shell > > With laspipe on and job control off, 'wait' appears to wait for all process

Re: anonymous pipes in recursive function calls

On Mon, Jul 1, 2024 at 5:06 AM konsolebox wrote: > > But then you're allowing multiple processes and pipes to be open at > the same time, unnecessarily allowing more room for unexpected errors. > Isn't that worse? It doesn't matter if bash seamlessly allows > multiple recursion-generated pipes or

Re: waiting for process substitutions

On Sat, Jun 29, 2024 at 2:07 PM Oğuz wrote: > > There is a limit to the number of jobs Bash can remember, once it's exceeded > the oldest job is overwritten. Do we really want process substitutions to > count against that limit? They might already. Now I'm wondering if the documentation just ne

Re: anonymous pipes in recursive function calls

On Sat, Jun 29, 2024 at 2:29 PM konsolebox wrote: > > On Sat, Jun 29, 2024 at 10:23 PM Zachary Santer wrote: > > > > The intention here is to report as many error conditions as possible > > before exiting. > > You can print an error message before calling return.

Re: waiting for process substitutions

On Sat, Jun 29, 2024 at 11:30 AM Oğuz wrote: > > On Saturday, June 29, 2024, Zachary Santer wrote: >> >> Couldn't you do the exact same thing with regular background processes >> forked with &? > > > But the shell notifies me when they terminate and

Re: waiting for process substitutions

On Sat, Jun 29, 2024 at 9:02 AM Oğuz wrote: > > What if I substitute thousands of processes and never call wait? Couldn't you do the exact same thing with regular background processes forked with &? That's on you.

Re: anonymous pipes in recursive function calls

On Sat, Jun 29, 2024 at 4:40 AM konsolebox wrote: > > You can avoid pipe recursions by storing the output first in an array. So is this a known issue? > There's also no need to use an error flag variable. Just make sure > return calls are chained. The intention here is to report as many error

waiting for process substitutions

>From the manual: wait [-fn] [-p varname] [id ...] Wait for each specified child process and return its termination status. Each id may be a process ID or a job specification; if a job spec is given, all processes in that job's pipeline are waited for. If id is not given, wait waits for all running

anonymous pipes in recursive function calls

Was "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 5:29 PM Zachary Santer wrote: > ( 2 ) > A script that I've written more recently generates some arrays > describing everythi

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 9:11 AM Greg Wooledge wrote: > > I'm still wondering when you'd ever use this in a shell script. In my case, I've got a couple of things: (1) One script has an array of names for named pipes. It might only need two of the six for a given invocation, so why create all six

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

On Tue, Jun 11, 2024 at 6:48 AM Zachary Santer wrote: > > The ( ) within the parameter expansion would be roughly analogous to > the right hand side of a compound assignment statement for an indexed > array. The values found therein would be taken as the indices of array > element

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

On Thu, Jun 27, 2024 at 9:12 AM Zachary Santer wrote: > > This, though I would add the caveat that 'set -u'/'set -o nounset' > should cause this expansion to fail and the script to error out if you > supply an index without a matching value. > And I guess my &q

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

On Thu, Jun 27, 2024 at 1:08 AM Oğuz wrote: > > Why not extend the arithmetic expansion syntax to allow generating multiple > results when subscripting indexed arrays? Like `${a[1; 2; 4]}', `${a[3..5; > 7]}', `${a[1..10..3]}', etc. Doing this, you lose the ability to provide the list of indices

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 11:50 PM Martin D Kealey wrote: > > > > On Thu, 27 Jun 2024 at 06:30, Chet Ramey wrote: >> >> On 6/26/24 2:18 PM, Zachary Santer wrote: >> >> >> On Tue, Jun 11, 2024, 12:49 PM Zachary Santer wrote: >> >&

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 2:30 PM Chet Ramey wrote: > > On 6/26/24 2:18 PM, Zachary Santer wrote: > > >> On Tue, Jun 11, 2024, 12:49 PM Zachary Santer wrote: > >>> > >>> $ array=( zero one two three four five six ) > >>> $ printf '%s\n

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 11:19 AM alex xmb sw ratchev wrote: > > printf %s\\n "${arr[@]:1:5}" For my array below, this would give you one two three four five > On Tue, Jun 11, 2024, 12:49 PM Zachary Santer wrote: >> >> $ array=( zero one two three four five si

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 10:58 AM Chet Ramey wrote: > > On 6/11/24 6:48 AM, Zachary Santer wrote: > > > My mind returns to this nonsense, as I find a use for it. > > > > Imagine this functionality: > > $ array=( zero one two three four five six ) > > $ pri

Re: function names starting with %

On Mon, Jun 24, 2024 at 2:37 PM Oğuz wrote: > $ %f > bash: fg: %f: no such job > $ '%f' > bash: fg: %f: no such job > $ \%f > bash: fg: %f: no such job Set +m won't fix this either. $ %f(){ :;} $ %f -bash: fg: %f: no such job $ set +m $ %f -bash: fg: no job control Unlike ! in an arithmetic con

Re: Proposal for a New Bash Option: failfast for Immediate Pipeline Failure

On Tue, Jun 25, 2024 at 4:05 AM Martin D Kealey wrote: > • Normally it's expected that if any part of a pipeline exits, all > preceding parts would eventually receive SIGPIPE upon writing to stdout. To expand on this a bit, when a process exits because of receiving a signal like SIGPIPE, it will

'declare -i var=var' for var initially declared in calling scope

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: msys Compiler: gcc Compilation CFLAGS: -march=nocona -msahf -mtune=generic -O2 -pipe -D_STATIC_BUILD uname output: MINGW64_NT-10.0-19045 Zack2021HPPavilion 3.5.3.x86_64 2024-06-03 06:22 UTC x86_64 Msys Machine T

Re: REQUEST - bash floating point math support

On Mon, Jun 17, 2024 at 3:48 AM Léa Gris wrote: > > Le 17/06/2024 à 09:17, Koichi Murase écrivait : > >declare -i numvar=${localeFormatted/[!0-9]/.} > > This would break with negative numbers. > > I know no other radix separator than comma or dot. If there are other > radix to replace, it can

Re: REQUEST - bash floating point math support

On Sat, Jun 15, 2024 at 10:56 AM Léa Gris wrote: > > On 15/06/2024 à 15:29, Koichi Murase wrote : > > at which point does the conversion happens > > The conversion to LC_NUMERIC format only happens during variable > expansion outside of a numerical context. > The numerical context can be explicit

Re: REQUEST - bash floating point math support

On Thu, Jun 6, 2024 at 6:34 AM Léa Gris wrote: > > Le 06/06/2024 à 11:55, Koichi Murase écrivait : > > > Though, I see your point. It is inconvenient that we cannot pass the > > results of arithmetic evaluations to the `printf' builtin. This > > appears to be an issue of the printf builtin. I thin

Re: Examples of concurrent coproc usage?

On Mon, Jun 10, 2024 at 1:07 PM Robert Elz wrote: > > The next POSIX will include O_CLOFORK and FD_CLOFORK (or names > similar to those) for open (etc) and fcntl(FDFLAGS)) - that is > analogs of O_CLOEXEC and FD_CLOEXEC but applying to fork() rather > than exec*(). Well there you go. Once people

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

Was "bash tries to parse comsub in quoted PE pattern" On Wed, Oct 18, 2023 at 8:19 AM Zachary Santer wrote: > > In Bash 5.2: > $ array=( zero one two three four five six ) > $ printf '%s\n' "${array["{2..6..2}"]}" > two > four >

Re: Examples of concurrent coproc usage?

On Sat, Jun 8, 2024 at 9:38 PM Martin D Kealey wrote: > > > On Wed, 10 Apr 2024 at 03:58, Carl Edquist wrote: >> >> Note the coproc shell only does this with pipes; it leaves other user >> managed fds like files or directories alone. >> >> I have no idea why that's the case, and i wonder whether

Re: REQUEST - bash floating point math support

On Wed, Jun 5, 2024 at 4:08 PM Robert Elz wrote: > > That's a perfect case for scaled integers - no-one ever deals with > fractions of cents in this kind of thing (a bank won't ever tell you > that your balance is $5678.17426 for example, even if the interest > calculations computed accurately mig

REQUEST - bash floating point math support

On Tue, Jun 4, 2024 at 4:01 PM Saint Michael wrote: > > > > > It's time to add floating point variables and math to bash. > > It just makes so much easier to solve business problems without external > calls to bc or Python. > Please let's overcome the "shell complex". Let's treat bash a real langu

Re: readonly inconsistency with arrays

On Mon, Jun 3, 2024 at 6:16 PM Will Allan via Bug reports for the GNU Bourne Again SHell wrote: > > init_vars () { readonly string="foo" readonly int=100 readonly array=(1 2) My understanding is that the readonly builtin isn't supposed to handle compound assignment syntax like the declare and

Re: printf -u "$fd"?

On Wed, May 22, 2024 at 12:32 AM Zachary Santer wrote: > > In my Rocky Linux 9.1 VM: > $ bash --version > GNU bash, version 5.1.8(1)-release [...] > $ exec {fd_A}> >( cat > file_A.txt ) > $ exec {fd_B}> >( cat > file_B.txt ) > $ printf 'words\n'

Re: printf -u "$fd"?

On Tue, May 21, 2024 at 3:06 PM Chet Ramey wrote: > > On 5/21/24 11:14 AM, Zachary Santer wrote: > > On Tue, May 21, 2024 at 9:01 AM Chet Ramey wrote: > >> > >> On 5/21/24 6:17 AM, Zachary Santer wrote: > >> > >>> I was wondering what the relat

Re: printf -u "$fd"?

On Tue, May 21, 2024 at 9:01 AM Chet Ramey wrote: > > On 5/21/24 6:17 AM, Zachary Santer wrote: > > > I was wondering what the relationship between the devel and master > > branches was. > > No mystery: the devel branch captures ongoing development, gets the latest &g

Re: printf -u "$fd"?

On Mon, May 20, 2024 at 3:03 PM Chet Ramey wrote: > > On 5/17/24 10:53 PM, Zachary Santer wrote: > > > So here's another tangent, but has it been considered to add an option > > to the printf builtin to print to a given file descriptor, rather than > > stdout? If p

printf -u "$fd"?

Was «difference between read -u fd and read <&"$fd"» on help-b...@gnu.org On Thu, May 16, 2024 at 12:51 AM Kerin Millar wrote: > > On Thu, 16 May 2024, at 3:25 AM, Peng Yu wrote: > > Hi, > > > > It appears to me that read -u fd and read <&"$fd" achieve the same > > result. But I may miss corner c

Re: Examples of concurrent coproc usage?

On Sat, Apr 27, 2024 at 1:01 PM Carl Edquist wrote: > > On Mon, 22 Apr 2024, Martin D Kealey wrote: > > > On Mon, 22 Apr 2024, 09:17 Carl Edquist, wrote: > > > >> But yeah currently a pipe with a series of records and multiple > >> cooperating/competing readers perhaps only works if the records h

Re: Erasing sensitive data from memory?

On Sun, Apr 21, 2024 at 3:05 PM Greg Wooledge wrote: > > 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 or two away from being a password > intercepter. Would you believ

Erasing sensitive data from memory?

C23 provides memset_explicit() to ensure memory containing sensitive data is cleared.[1] Using a function like this is necessary to avoid compilers optimizing out the operation. Of course, bash isn't optimizing your script for you, but consider this kind of naive solution: $ IFS='' read -e -r -s -

Re: Examples of concurrent coproc usage?

On Tue, Apr 16, 2024 at 3:56 AM Andreas Schwab wrote: > > On Apr 16 2024, Carl Edquist wrote: > > > Well, you _can_ shovel binary data too: (*) > > > > while IFS= read -rd '' X; do printf '%s\0' "$X"; done > > > > and use that pattern to make a shell-only version of tee(1) (and I suppose > >

Re: Examples of concurrent coproc usage?

On Mon, Apr 15, 2024 at 1:57 PM Carl Edquist wrote: > > the thing discussed in my last email to the list (about > coproc fds being set close-on-exec) makes them unusable for anything > beyond stdin/stdout/stderr. > > [It might sound like an obscure use case, but once you realize what you > can do

Re: Examples of concurrent coproc usage?

On Sat, Apr 13, 2024 at 4:10 PM Chet Ramey wrote: > > The original intent was to allow the shell to drive a long-running process > that ran more-or-less in parallel with it. Look at examples/scripts/bcalc > for an example of that kind of use. $ ./bcalc equation: -12 ./bcalc: line 94: history: -1:

Re: Examples of concurrent coproc usage?

On Sat, Apr 13, 2024 at 2:45 PM Chet Ramey wrote: > > On 4/8/24 11:44 PM, Zachary Santer wrote: > > > The fact that the current implementation allows the coproc fds to get > > into process substitutions is a little weird to me. A process > > substitution, in combinatio

  1   2   >