On Thu, Jun 24, 2021 at 5:20 PM Chet Ramey wrote:
> On 6/24/21 4:09 AM, Ilkka Virta wrote:
>
> > But 3.4 Shell Parameters is a bit confusing: "Word splitting is not
> > performed, with the exception of "$@" as explained below."
>
> This means that "$@" expands to multiple words, even though doubl
On 2021-06-26 01:05, Robert Elz wrote:
> | If Chet feels that a change is needed here, I would remove the "with
> | the exception of" clause entirely. Just say "Word splitting is not
> | performed."
>
> My suspicion (I'm guessing) is that exception is to cover
>
> x=("$@")
`name=[
On 2021-06-25 12:11, Greg Wooledge wrote:
> > | A variable may be assigned to by a statement of the form
> > | name=[value]
> > | [...]
> > | Word splitting is not performed, with the exception of "$@" as
> > | explained below.
>
> This isn't the full sentence in the current man page. In the b
i vote for script style api'ing readline
On Fri, Jun 25, 2021, 20:38 Chet Ramey wrote:
> On 6/25/21 10:53 AM, Pedro Gimeno wrote:
> > Bash Version: 4.4
> > Patch Level: 12
> > Release Status: release
> >
> > Tested also in the last version from this unofficial mirror:
> > https://github.com/bmin
On 6/25/21 10:53 AM, Pedro Gimeno wrote:
Bash Version: 4.4
Patch Level: 12
Release Status: release
Tested also in the last version from this unofficial mirror:
https://github.com/bminor/bash so I guess it's still a problem.
Tab auto-completion removes quotes from variables even when it should
Date:Fri, 25 Jun 2021 12:11:33 -0400
From:Greg Wooledge
Message-ID:
| That matches the behavior that I saw (and pasted on this mailing list the
| other day). (Which by the way is *not* the same as "$*" unless IFS happens
| to be unset or to begin with a space.
Bash Version: 4.4
Patch Level: 12
Release Status: release
Tested also in the last version from this unofficial mirror:
https://github.com/bminor/bash so I guess it's still a problem.
Tab auto-completion removes quotes from variables even when it shouldn't.
Test case:
$ mkdir 'a b'
$ touch 'a b
On Fri, Jun 25, 2021 at 03:15:25PM +0200, Nora Platiel wrote:
> But at least it is documented, and that part of the doc is clear to me.
> The part of the doc that I'm complaining about is this one:
>
> | A variable may be assigned to by a statement of the form
> | name=[value]
> | [...]
> | Wo
Date:Thu, 24 Jun 2021 21:03:22 -0400
From:Greg Wooledge
Message-ID:
| Bash is ALL about these special cases. If you don't like it, don't write
| code that uses it. In any sensible programming language, var="$@"
| would have been an error. In bash, it's not.
On 2021-06-25 7:36, Oğuz wrote:
> > To me, "$@" expanding to multiple words would mean that:
> >
> > $ var="$@" foo
> >
> > for $# > 0, behaves the same as:
> >
> > $ var="$1" "${@:2}" foo
>
> But it wouldn't make any sense. `foo' would be subjected to alias
> substitution even though it isn't kno
On 2021-06-24 21:03, Greg Wooledge wrote:
> "$@" expands like "$1 "$2" ... when used in most contexts. For example,
Yes, that is clear to me.
> The assignment-ness of the command overrides everything else. It
> completely changes how the "$@" expansion occurs. Now, instead of
> expanding like
11 matches
Mail list logo