On 2021/06/29 16:51, Greg Wooledge wrote:
On Tue, Jun 29, 2021 at 04:29:05PM -0700, L A Walsh wrote:
njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
Which is detected as "illegal input" and disallowed. If you don't enable
some security errors, they can't be as easil
On Tue, Jun 29, 2021 at 10:11:31PM -0400, Eli Schwartz wrote:
> On 6/29/21 7:29 PM, L A Walsh wrote:
> >>> njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
> It also rejects this perfectly reasonable code, which I arbitrarily
> decided not to support because if you want this you're weird:
>
On 6/29/21 7:29 PM, L A Walsh wrote:
> On 2021/06/29 15:49, Greg Wooledge wrote:
>> On Tue, Jun 29, 2021 at 02:58:28PM -0700, L A Walsh wrote:
>>
>>> njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
>>>
>>> Using that with your input:
>>>
>>> njobs 'x[0$(date >&2)]'
>>>
>>> bash: printf: `
On Tue, Jun 29, 2021 at 04:29:05PM -0700, L A Walsh wrote:
> > > njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
>Which is detected as "illegal input" and disallowed. If you don't enable
> some security errors, they can't be as easily introduced.
Are you *still* insisting that your f
On 2021/06/29 15:49, Greg Wooledge wrote:
On Tue, Jun 29, 2021 at 02:58:28PM -0700, L A Walsh wrote:
njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
Using that with your input:
njobs 'x[0$(date >&2)]'
bash: printf: `x[0$(date': not a valid identifier
This is because you didn
On Tue, Jun 29, 2021 at 02:58:28PM -0700, L A Walsh wrote:
> njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
>
> Using that with your input:
>
> njobs 'x[0$(date >&2)]'
>
> bash: printf: `x[0$(date': not a valid identifier
This is because you didn't quote "$1". Since you only ever test
On 2021/06/29 14:02, Greg Wooledge wrote:
declare, printf -v, local -n, eval -- they're mostly equivalent. Some
of them may prevent *some* possible code injections, but none of them
prevent *all* possible code injections.
unicorn:~$ njobs2() { printf -v "$1" %s 42; }
unicorn:~$ njobs2 'x[0$(date
On Tue, Jun 29, 2021, at 4:38 PM, Jay K wrote:
> diff -u input_avail.c.orig input_avail.c
> --- input_avail.c.orig 2019-12-26 13:59:17.0 -0800
> +++ input_avail.c 2021-06-29 12:48:19.407119600 -0700
> @@ -110,7 +110,7 @@
> #if defined(HAVE_SELECT)
> fd_set readfds, exceptfds;
>
Bash on Tru64
make[1]: Entering directory '/usr/users/jay/s/bash-5.1.8/lib/sh'
cc -c -I. -I../.. -I../.. -I../../lib -I../../include -I. -I../../lib/intl
-I/usr/users/jay/s/bash-5.1.8/lib/intl -DHAVE_CONFIG_H -DSHELL -g
-Wno-parentheses -Wno-format-security input_avail.c
cc: Error: input_av
On Tue, Jun 29, 2021 at 02:05:46PM -0700, L A Walsh wrote:
>That would be 'me', so I'm going to rule out malicious
> code injection! :-), but that's also why I used printf to
> write the output, the worst that could happen is some varname
> is overwritten with the answer, no?
Sadly, this is no
On Tue, 29 Jun 2021 17:02:16 -0400
Greg Wooledge wrote:
> On Tue, Jun 29, 2021 at 09:47:30PM +0100, Kerin Millar wrote:
> > On Tue, 29 Jun 2021 16:35:28 -0400
> > Greg Wooledge wrote:
> >
> > > unicorn:~$ njobs() { local _n=$(jobs | wc -l); eval "$1=\$_n"; }
> > > unicorn:~$ njobs walsh
> > > u
On 2021/06/29 13:35, Greg Wooledge wrote:
unicorn:~$ njobs() { local _n=$(jobs | wc -l); eval "$1=\$_n"; }
---
ARG...I thought about that and rejected it because I
thought the "jobs|wc-l" would be in a sub-shell and not pickup
the background jobs! Double arg, this works as well:
sjobs() { lo
On 2021/06/29 13:35, Eli Schwartz wrote:
Well, if you don't think this is a bug in bash, but something you need
help figuring out, maybe you'd prefer to use the "help-bash" list?
Actually
-
The original message was received at Tue, 29 Jun 2021 13:06:34 -0700
The following
On Tue, Jun 29, 2021 at 09:47:30PM +0100, Kerin Millar wrote:
> On Tue, 29 Jun 2021 16:35:28 -0400
> Greg Wooledge wrote:
>
> > unicorn:~$ njobs() { local _n=$(jobs | wc -l); eval "$1=\$_n"; }
> > unicorn:~$ njobs walsh
> > unicorn:~$ echo "$walsh"
> > 3
> >
> > Now you just need to add sanity-c
On Tue, 29 Jun 2021 16:35:28 -0400
Greg Wooledge wrote:
> On Tue, Jun 29, 2021 at 01:21:44PM -0700, L A Walsh wrote:
> > I hope a basic question isn't too offtopic.
>
> More of a help-bash question, in my opinion, but close enough.
>
> > Say I have some number of jobs running:
> >
> > > jobs|
On 6/29/21 4:21 PM, L A Walsh wrote:
> I hope a basic question isn't too offtopic.
Well, if you don't think this is a bug in bash, but something you need
help figuring out, maybe you'd prefer to use the "help-bash" list?
> Say I have some number of jobs running:
>
>> jobs|wc -l
> 3
> ---
> in
On Tue, Jun 29, 2021 at 01:21:44PM -0700, L A Walsh wrote:
> I hope a basic question isn't too offtopic.
More of a help-bash question, in my opinion, but close enough.
> Say I have some number of jobs running:
>
> > jobs|wc -l
> 3
OK.
> Would like to pass a varname to njobs to store the answe
I hope a basic question isn't too offtopic.
Say I have some number of jobs running:
jobs|wc -l
3
---
in a function (have tried shopt -s/-u lastpipe; neither way worked)
njobs() {
jobs |wc -l
}
njobs
3
Would like to pass a varname to njobs to store the answer in, like:
njobs() {
jobs|wc -l
On 6/22/21 3:52 AM, Phi Debian wrote:
When doing
$ echo foo "bar" /tm
I got /tm expanded to /tmp/ that is indeed correct.
But if I do
$ echo foo "bar
more bar" /tm
No completion is done. My question is doest this behavior a feature or a
bug?
Neither, really, it's just a consequence of rea
I'll try to build bash 5 for Cygwin and reply here
On 29.06.2021 11:00, Andreas Schwab wrote:
> On Jun 29 2021, Basin Ilya wrote:
>
>> However, shell-backward-kill-word erases the word immedeately
>> preceding the caret plus it erases one additional space.
>
> Does it? Not for me.
>
> Andreas.
On Jun 29 2021, Basin Ilya wrote:
> However, shell-backward-kill-word erases the word immedeately
> preceding the caret plus it erases one additional space.
Does it? Not for me.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9
21 matches
Mail list logo
