Re: simple prob?
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:
>
> $ declare -A jobs
> $ njobs 'jobs[first run]'
> error: invalid characters [ ] found in var 'jobs[first run]'
> hacker detected...
It's not the weirdest thing I've seen. Without your validation:
unicorn:~$ declare -A jobs
unicorn:~$ njobs 'jobs[first]'
All cool, right? Uh
unicorn:~$ touch jobss
unicorn:~$ njobs 'jobs[second]'
unicorn:~$ declare -p jobs
declare -A jobs=([first]=$'0\n' )
unicorn:~$ declare -p jobss
declare -- jobss="0
"
Failure to quote strikes again. What if we fix it?
unicorn:~$ nqjobs() { printf ${1:+-v "$1"} "%s\n" "$(jobs |wc -l)"; }
unicorn:~$ nqjobs 'jobs[third]'
unicorn:~$ nqjobs 'jobs[sixth]'
unicorn:~$ declare -p jobs
declare -A jobs=([sixth]=$'0\n' [first]=$'0\n' [third]=$'0\n' )
Now it works even if there's a file which matches the glob pattern.
> Well, the diagnostic jumped to a conclusion that is probably false.
Your validation is too strict in this case. Right idea, wrong
implementation. Of course, one might argue that allowing an array with
an index is a dangerous precedent, and stick with your strict validation
on principle. That's a design decision, and I could see either one
being correct depending on the goals.
Oh, and by the way, there's at least one more category of errors that
failure-to-quote is susceptible to:
unicorn:~$ unset foo bar
unicorn:~$ njobs 'foo -v bar'
unicorn:~$ declare -p foo bar
bash: declare: foo: not found
declare -- bar="0
"
Without quotes, we get printf -v foo -v bar '%s\n' "$(jobs|wc -l)"
with the result shown.
With quotes, we get:
unicorn:~$ nqjobs 'foo -v bar'
bash: printf: `foo -v bar': not a valid identifier
It's not robust against code injection attacks (we need actual validation
for that), but at least it gives a sensible error message in some common
cases.
tl;dr: When in doubt, quote it. There is a REASON we beat this into
people's heads.
Re: simple prob?
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: `x[0$(date': not a valid identifier
>>>
>>
>> This is because you didn't quote "$1".
>
> $1 should never be quoted -- it is an identifier, and as such
> cannot contain a space. By quoting it, you are allowing inputs that
> would otherwise be filtered out because they are not valid variable
> names.
You do no filtering right now.
Here's how you filter:
njobs() {
if [[ $(id -un) = lindawalsh ]]; then
# Linda agrees to never misuse this function or let
# anyone else run code on her computer which does
:
elif [[ $1 = *[^a-zA-Z0-9_]* ]]; then
echo "error: invalid characters ${1//[a-zA-Z0-9_]} found in var
${1@Q}" >&2
echo "hacker detected..." >&2
# can be exit 13 if used in a script
return 1
fi
printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)";
}
Now, since I am not Linda and I am a big dummy when it comes to code
reuse and I *am* concerned I might stupidly use this code on input
provided by my friend the huge practical joker, I get this:
$ njobs 'x[0$(date >&2)]'
error: invalid characters [$( >&)] found in var 'x[0$(date >&2)]'
hacker detected...
Of course, I don't bother to quote $1 -- I cherish my right to not quote
that variable. But I know it's safe to do so -- if it has word splitting
tokens, they will raise an error.
Greg's fixed example is still caught by my code (unless the code is
running as the Linda login account):
$ njobs 'x[0$(date>&2)]'
error: invalid characters [$(>&)] found in var 'x[0$(date>&2)]'
hacker detected...
It also rejects this perfectly reasonable code, which I arbitrarily
decided not to support because if you want this you're weird:
$ declare -A jobs
$ njobs 'jobs[first run]'
error: invalid characters [ ] found in var 'jobs[first run]'
hacker detected...
Well, the diagnostic jumped to a conclusion that is probably false.
>> Since you only ever tested
>> the cases where $1 was a valid variable name
>
> It is only designed to work with $1 being an optional, valid variable
> name.
> Anything else should fail. There are times when putting quotes around a
> var will enable problems.
>> , you never ran into that particular result... until now.
>>
>
> I never ran into "invalid input" because I didn't program it to
> accept anything other than a variable name there.
You did program it to accept anything other than a variable name there.
You then made a "gentleman's agreement" to not *use* anything other than
a variable name there.
But "use" is a different word than "accept".
>> As you can see, the unquoted $1 underwent word splitting, so you're
>> effectively running printf -v 'x[0$(date' '>&2)]' '%s\n' "...".
>>
>
> Which is detected as "illegal input" and disallowed. If you don't
> enable
> some security errors, they can't be as easily introduced. I assert that
> you
> should never put quotes around something that is supposed to be a
> variable name
> since valid variable names can not be word-split. Many of the items on
> your
> website about bash cautions, are because bash disallows some sketchy
> constructs.
> That's not a bash-caveat, but a bash feature!
This is a ridiculous argument and you know it. You, personally, are
writing code which does not get used in security contexts, which is your
right. This in no way means that refusing to quote variables which
"cannot be word-split" stops *any* security errors. The "illegal input"
was not related to the security bypass (as Greg points out, removing the
space prevents word splitting and executes the same security bypass code).
Your response should have been:
"""
I assert that you should never put quotes around something that is
supposed to be a variable name since valid variable names can not be
word-split and quoting them implies you would like to handle them as
variable names anyway.
Quotes aren't a security feature. I don't care about security features,
because I don't misuse the code and try to hack my own system. But if
you do want security features, you should detect anything that isn't a
valid variable name and raise an error, then go ahead and use the
variables unquoted.
"""
And hey, I'd even agree with you on that. But I'm also an overly
restrictive person who grumps at people trying to set:
declare -A jobs=(["first run"]=$'0\n' )
Instead you are arguing in bad faith that "That's not a bash-caveat, but
a bash feature!" When strictly speaking your code is flawed, it doesn't
correctly handle indexed arrays with spaces in the key and doesn't
forbid them either.
>> This won't protect against all code injections, of course; only the
>> ones that contain a whitespace character.
>>
>
>
Re: simple prob?
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 failure to quote is a SECURITY
FEATURE?
Come *on*!
unicorn:~$ njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
unicorn:~$ njobs 'x[0$(date>&2)]'
Tue Jun 29 19:49:16 EDT 2021
All I had to do was remove the space. You're not even trying.
Your failure to quote is simply a failure. If you want to prevent
code injection attacks, you need to sanity-check the input.
There is no other way.
Re: simple prob?
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't quote "$1".
$1 should never be quoted -- it is an identifier, and as such
cannot contain a space. By quoting it, you are allowing inputs that
would otherwise be filtered out because they are not valid variable
names.
Since you only ever tested
the cases where $1 was a valid variable name
It is only designed to work with $1 being an optional, valid
variable name.
Anything else should fail. There are times when putting quotes around a
var will enable problems.
, you never ran into that particular result... until now.
I never ran into "invalid input" because I didn't program it to
accept anything other than a variable name there.
As you can see, the unquoted $1 underwent word splitting, so you're
effectively running printf -v 'x[0$(date' '>&2)]' '%s\n' "...".
Which is detected as "illegal input" and disallowed. If you don't
enable
some security errors, they can't be as easily introduced. I assert that you
should never put quotes around something that is supposed to be a
variable name
since valid variable names can not be word-split. Many of the items on your
website about bash cautions, are because bash disallows some sketchy
constructs.
That's not a bash-caveat, but a bash feature!
This won't protect against all code injections, of course; only the
ones that contain a whitespace character.
Nothing protect against "all" 'X' or "everything", especially when
talking
about security. Security is best handled as a layered approach with
different
layers protecting against different things. There's no such thing as a
'Security Magic Bullet'. Just because NOTHING protects against "ALL"
[anything] is
not a reason to take extreme action. In fact realization that NOTHING is
perfect
is one of the better defenses against over-reacting in response to
supposed security
flaws.
Re: simple prob?
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 tested
the cases where $1 was a valid variable name, you never ran into that
particular result... until now.
As you can see, the unquoted $1 underwent word splitting, so you're
effectively running printf -v 'x[0$(date' '>&2)]' '%s\n' "...".
This won't protect against all code injections, of course; only the
ones that contain a whitespace character.
Re: simple prob?
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 >&2)]'
Tue Jun 29 17:00:29 EDT 2021
That's not what I see in my version:
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
Perhaps some solutions provide more resistance to problems than
others.
FWIW, I would be using 'njobs' in a script where I'm giving it
the input.
No matter which one of these you choose, you still have to sanity-check
the input. Or else declare that you do not care if the user shoots their
own foot off
The user has no access to internal functions inside a script. Though I
do take many precautions against my future self(ves).
Re: bash on Tru64
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; > #endif > -#if defined (HAVE_PSELECT) > +#if defined (HAVE_PSELECT) || defined (HAVE_SELECT) > sigset_t set, oset; > #endif This change is already on the devel branch. https://git.savannah.gnu.org/cgit/bash.git/commit/lib/sh/input_avail.c?h=devel=2047e28 -- vq
bash on Tru64
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_avail.c, line 131: In this statement, "set" is not declared. (undeclared) sigprocmask (SIG_BLOCK, (sigset_t *)NULL, ); -^ cc: Error: input_avail.c, line 135: In this statement, "oset" is not declared. (undeclared) sigemptyset (); ^ make[1]: *** [Makefile:78: input_avail.o] Error 1 make[1]: Leaving directory '/usr/users/jay/s/bash-5.1.8/lib/sh' make: *** [Makefile:692: lib/sh/libsh.a] Error 1 I fixed with: 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; #endif -#if defined (HAVE_PSELECT) +#if defined (HAVE_PSELECT) || defined (HAVE_SELECT) sigset_t set, oset; #endif Seems like it might affect other systems? A few of these: rm -f man2html.o cc -c -DHAVE_CONFIG_H -DSHELL -I/usr/users/jay/s/bash-5.1.8 -I.. -g -Wno-parentheses -Wno-format-security man2html.c cc -DHAVE_CONFIG_H -DSHELL -I/usr/users/jay/s/bash-5.1.8 -I.. -g -Wno-parentheses -Wno-format-security man2html.o -o man2html ld: Invalid flag usage: Wno-parentheses, -Wx,-option must appear after -_SYSTYPE_SVR4 ld: Usage: ld [options] file [...] make[1]: *** [Makefile:80: man2html] Error 1 make[1]: Leaving di I think the flags are ok on the compiler, ignored, but error on the linker. They should be autoconfed? Eh, they probably are, but then compiler is linker. Remove them for linking? I removed a bunch of -W flags unconditionally, and it builds and runs. Thank you, - Jay
Re: simple prob?
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 not correct. You can still get code injections with
printf -v.
unicorn:~$ njobs2() { printf -v "$1" %s 42; }
unicorn:~$ njobs2 'x[0$(date >&2)]'
Tue Jun 29 17:00:29 EDT 2021
> Simpler -- don't use a variable:
>
> njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
You're adding a newline to the variable. That may not be what you want.
> So...hmmm...how is it that jobs picks up the right answer in what
> would seem to be a subshell? Special cased?
The subshell inherits the job list from its parent -- it just can't
*wait* for any of those jobs, since it isn't their parent. But it can
still count them.
Re: simple prob?
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
> > > unicorn:~$ echo "$walsh"
> > > 3
> > >
> > > Now you just need to add sanity-checking on the argument of njobs, to
> > > avoid whatever code injection the malicious caller wants to perform.
> >
> > I can't fathom the switch to eval there. Why not printf -v "$1" %s "$_n",
> > for example? It even rejects invalid identifiers.
>
> 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 >&2)]'
> Tue Jun 29 17:00:29 EDT 2021
>
> No matter which one of these you choose, you still have to sanity-check
> the input. Or else declare that you do not care if the user shoots their
> own foot off (which is a valid stance as long as your code is never used
> in a context where the user can elevate their privileges/capabilites).
>
I see. Thanks.
--
Kerin Millar
Re: simple prob?
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() { local j;read j< <(jobs|wc -l);
printf ${1:+-v $1} "%s\n" "$j"; }
About the only thing that doesn't work are variations on
jobs|wc-l|read n -- since if read is in current process jobs doesn't
pick up the children, but if jobs is in current process, then read
isn't, and 'n' is lost.
Of course I was focusing on -s/-u lastpipe to provide some variation
but that was the only variation that would seem to be guaranteed not
to work. Oi!
Now you just need to add sanity-checking on the argument of njobs, to
avoid whatever code injection the malicious caller wants to perform.
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?
And maybe consider adding "make sure $1 isn't _n" to the list of your
sanity checks, since the caller can't be permitted to use that particular
variable namhe.
Simpler -- don't use a variable:
njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
---
The use of the builtin expansion off of the parameter has the side
benefit of printing the answer to output if no var is given.
So...hmmm...how is it that jobs picks up the right answer in what
would seem to be a subshell? Special cased?
unicorn:~$ njobs _n
unicorn:~$ echo "$_n"
(At least it didn't go into an infinite loop!)
Re: simple prob?
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 addresses had permanent fatal errors - (reason: 550-Callout verification failed:) --- I had it backwardsoh well. I did try there first!
Re: simple prob?
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-checking on the argument of njobs, to
> > avoid whatever code injection the malicious caller wants to perform.
>
> I can't fathom the switch to eval there. Why not printf -v "$1" %s "$_n", for
> example? It even rejects invalid identifiers.
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 >&2)]'
Tue Jun 29 17:00:29 EDT 2021
No matter which one of these you choose, you still have to sanity-check
the input. Or else declare that you do not care if the user shoots their
own foot off (which is a valid stance as long as your code is never used
in a context where the user can elevate their privileges/capabilites).
Re: simple prob?
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|wc -l
> > 3
>
> OK.
>
> > Would like to pass a varname to njobs to store the answer in, like:
> > > njobs n
> > echo "$n"
> > 3
>
> "How do I pass a value back from a function to its caller, you know,
> like a function in any other programming language can do" is one of the
> holy grails of shell programming. There is no sane answer. You appear
> to be going down the "pass a variable name by reference" path, so:
>
> unicorn:~$ jobs | wc -l
> 3
> unicorn:~$ njobs() { local _n=$(jobs | wc -l); eval "$1=\$_n"; }
> unicorn:~$ njobs walsh
> unicorn:~$ echo "$walsh"
> 3
>
> Now you just need to add sanity-checking on the argument of njobs, to
> avoid whatever code injection the malicious caller wants to perform.
I can't fathom the switch to eval there. Why not printf -v "$1" %s "$_n", for
example? It even rejects invalid identifiers.
--
Kerin Millar
Re: simple prob?
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 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
> #magic puts val in $v
> printf {$1:+-v $1} "%s\n" "$v"
This is obviously broken, because {$1:+expand} isn't how bash works. Try
swapping the "{" and the "$"...
> }
>
> So I can run:
>
>> njobs n
> echo "$n"
> 3
>
> ---
> How can I put the output into '$v'
> *without* using a temporary file?
>
> This seems so basic, yet its eluding me.
> Could someone throw me a clue-stick?
> Tnx!
What's wrong with the obvious
v=$(jobs | wc -l)
> p.s. - a trivial util func producing jobs:
>
> resleep() { alias my="declare " int="my -i "
> int n=${1:-3} t=${2:-99}; echo "$n jobs @ ${t}s:"
> while ((0 < n--)); do sleep "$t" & done; }
>
>
>
>
>
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
OpenPGP_signature
Description: OpenPGP digital signature
Re: simple prob?
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 answer in, like:
> > njobs n
> echo "$n"
> 3
"How do I pass a value back from a function to its caller, you know,
like a function in any other programming language can do" is one of the
holy grails of shell programming. There is no sane answer. You appear
to be going down the "pass a variable name by reference" path, so:
unicorn:~$ jobs | wc -l
3
unicorn:~$ njobs() { local _n=$(jobs | wc -l); eval "$1=\$_n"; }
unicorn:~$ njobs walsh
unicorn:~$ echo "$walsh"
3
Now you just need to add sanity-checking on the argument of njobs, to
avoid whatever code injection the malicious caller wants to perform.
And maybe consider adding "make sure $1 isn't _n" to the list of your
sanity checks, since the caller can't be permitted to use that particular
variable name.
unicorn:~$ njobs _n
unicorn:~$ echo "$_n"
(At least it didn't go into an infinite loop!)
simple prob?
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
#magic puts val in $v
printf {$1:+-v $1} "%s\n" "$v"
}
So I can run:
njobs n
echo "$n"
3
---
How can I put the output into '$v'
*without* using a temporary file?
This seems so basic, yet its eluding me.
Could someone throw me a clue-stick?
Tnx!
p.s. - a trivial util func producing jobs:
resleep() { alias my="declare " int="my -i "
int n=${1:-3} t=${2:-99}; echo "$n jobs @ ${t}s:"
while ((0 < n--)); do sleep "$t" & done; }
Re: bash completion after a multiline string
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 readline being line-oriented and a little more application-agnostic than you think. Readline understands how to complete within partially-quoted strings, or unclosed quoted strings if you prefer, since that's something fairly common across all the applications that use it. Since it's line-oriented, it doesn't know about quotes on previous lines, nor whether or not previous lines should logically be considered part of the current line. If you combine these two things, you should be able to see why the word you're trying to complete is ` /tm'. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: shell-backward-kill-word needs to behave more like werase
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. >
Re: shell-backward-kill-word needs to behave more like werase
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 A9DA AEC1 "And now for something completely different."
