Re: Fwd: valid kernel patch? using -e to catch errors?

Date:Mon, 29 Jul 2019 01:02:37 -0700 From:L A Walsh Message-ID: <5d3ea81d.4020...@tlinx.org> | I didn't see this come back from the list and it was sent | 45 minutes ago (vs. other emails of mine that have come | back in under a minute). | Did anyone else see

Re: ulimit call lists invalid options

The ulimit usage lists all the limits that bash supports. Of those, the ones that actually work are the ones that your system also supports. On my system (like yours) ulimit -P and ulimit -k fail, as while the system has pseudo tty's and kqueues, there are no per process limits on how many can be

ulimit call lists invalid options

in bash 4.4.12, giving an invalid option to ulimit gives a usage: ulimit: usage: ulimit [-SHabcdefiklmnpqrstuvxPT] [limit] -SH are for Soft/Hard, so they don't count and -a is for all, so skipping the first 4, the rest: but the rest: ops=$(ulimit -h |& perl -ne 'm{\[([^\]]++)\]} && print "$1\n"')

Re: x[

> On 7/29/19 6:01 PM, Martijn Dekker wrote: > > Because that command is empty in this instance, bash does not bother to > > substitute a file name, and the <() is substituted by nothing. I didn't know this behavior. I tried several commands and found that if there is a space between ( and ), it

Re: x[

On 7/29/19 6:01 PM, Martijn Dekker wrote: > As others pointed out, it's the start of an array assignment, and > associative array indexes can contain newlines. Yeah, I think that was a bit of a retrospective lightbulb moment for a bunch of people on #bash > <(Process substitution) may look

Re: x[

Op 29-07-19 om 19:09 schreef Eli Schwartz: The initial workaround discovered, was to use $ function _[ () { echo hello; }; <() _[ hello The use of <() somehow suppresses the glitch in the same way that quoting it does. If it were just glob expansion, then why should that be so? As others

Re: How does this wait -n work to cap parallelism?

On Mon, Jul 29, 2019 at 07:12:42PM +0100, Earnestly wrote: > The question is about how the example works in order to maintain > parallelism capped at num_proc. Thanks to emg on #bash for explaining how what is essentially going on. Bash essentially maintains a list of completed jobs until wait -n

Re: How does this wait -n work to cap parallelism?

On Mon, Jul 29, 2019 at 02:38:48PM -0400, Greg Wooledge wrote: > The same happens for my_job 7, and my_job 8. Each one is preceded by > a wait -n, so it waits for one of the existing jobs to terminate before > the new job is launched. This aspect of the behaviour isn't in question. Without

Re: How does this wait -n work to cap parallelism?

On Mon, Jul 29, 2019 at 07:12:42PM +0100, Earnestly wrote: > #!/usr/bin/env bash > > # number of processes to run in parallel > num_procs=5 > > # function that processes one item > my_job() { > printf 'Processing %s\n' "$1" > sleep

Re: x[

On 7/29/19 12:55 PM, Isabella Bosia wrote: > haven't really looked into why this happens but x[ seems to trigger some > funny parser behavior > > x[ newline should not prompt with PS2 Yes, it should. It's the start of an array assignment, and an assignment statement is a valid part of a

How does this wait -n work to cap parallelism?

This mail was spurred on by users in the #bash IRC channel. It started after reading where the article introduces an example using 'wait -n' as a means to provide capped parallism: #!/usr/bin/env bash # number of processes to run

Re: x[

2019-07-29 17:55:58 +0100, Isabella Bosia: > haven't really looked into why this happens but x[ seems to trigger some > funny parser behavior > > x[ newline should not prompt with PS2 > > it can't be defined as a normal sh function, but it can be defined with the > function keyword [...] x[

Re: x[

On Mon, Jul 29, 2019 at 01:09:28PM -0400, Eli Schwartz wrote: > On 7/29/19 1:01 PM, Clint Hepner wrote: > > The ``[`` begins a valid shell pattern, so the parser continues to > > accept input until the closing ``]`` is found. Pathname expansion > > (apparently) does not apply to the first

Re: x[

On 7/29/19 1:01 PM, Clint Hepner wrote: > The ``[`` begins a valid shell pattern, so the parser continues to > accept input until the closing ``]`` is found. Pathname expansion > (apparently) does not apply to the first "argument" of the > ``function`` command. The initial workaround discovered,

Re: x[

> On 2019 Jul 29 , at 12:55 p, Isabella Bosia wrote: > > haven't really looked into why this happens but x[ seems to trigger some > funny parser behavior > > x[ newline should not prompt with PS2 > > it can't be defined as a normal sh function, but it can be defined with the > function

x[

haven't really looked into why this happens but x[ seems to trigger some funny parser behavior x[ newline should not prompt with PS2 it can't be defined as a normal sh function, but it can be defined with the function keyword it can't be called like a normal function, but things like "x["

Re: Have var+func sourced in a subroutine but they don't seem to end up in same scope

On 29.7. 09:25, L A Walsh wrote: The library-include function allows me to source a library file that is in a relative path off of PATH (a feature not in bash, unfortunately). [...] I tried putting exporting the data and the function with export but it ended up the same. The variables

Re: Have var+func sourced in a subroutine but they don't seem to end up in same scope

On Sun, Jul 28, 2019 at 11:25:24PM -0700, L A Walsh wrote: > util_fn () { > > declare [-x] foo=1 > declare [-x] bar=${foo}2 > > real_util_fn() { > makes use of bar to get 'foo2' > } > > real_util_fn "$@" > } You do realize that despite your indentation, and despite the definition

Re: T/F var expansion?

2019-07-28 21:17:43 -0700, L A Walsh: > Is there a T/F var expansion that does: > > var=${tst:+$yes}${tst:-$no} > > but with yes/no in 1 expansion? [...] You can also do: no_yes=(no yes) echo "${no_yes[${var+1}]}" For the reverse: echo "${no_yes[!0${var+1}]}" See also: map=(unset

Re: T/F var expansion?

On Mon, 29 Jul 2019 at 14:18, L A Walsh wrote: > > Is there a T/F var expansion that does: [...] > > Sorry if this is already implemented in some form, I'm just > not remembering there being one. Your message is not a bug report. The list help-b...@gnu.org> exists to help with questions like

Fwd: valid kernel patch? using -e to catch errors?

I didn't see this come back from the list and it was sent 45 minutes ago (vs. other emails of mine that have come back in under a minute). Did anyone else see it? Sorry for the repeat if it did. FWIW, the below is from the publicly posted change notes for the 5.2.3 patch. Original

Re: T/F var expansion?

On 2019/07/28 22:01, Martin Schulte wrote: > Hello! > >> Is there a T/F var expansion that does: >> var=${tst:+$yes}${tst:-$no} >> but with yes/no in 1 expansion? >> > > At least if you are only working with numbers you can use > ((var=(tst!=0?42:31))) > But is this a question for

valid kernel patch? using -e to catch errors?

I wonder if this patch that went into the linux kernel, 5.2.3, will do what they think it will since posix changed the meaning. If not, maybe Greg should go over and explain it to them! commit df324bab425f70bf2a1d11f5880c88940b7e403d Author: Masahiro Yamada Date: Tue Jun 25 16:26:22 2019

Have var+func sourced in a subroutine but they don't seem to end up in same scope

I have a shell script that includes a util script via a library-include function. The library-include function allows me to source a library file that is in a relative path off of PATH (a feature not in bash, unfortunately). What I just noticed was a problem where the included file has local