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=("$@")
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
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
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
I was also confused by the same statement.
On 2021-06-24 10:20 Chet Ramey 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 double quotes
>
Hello,
I just tried your commit of Tue Jun 15. I tested all the relevant patterns that
came to mind, and they all behave as agreed.
I'll let you know if I find something unexpected but I'm satisfied with this
solution.
Thanks for your work.
NP
On 2021-06-15 10:19 Chet Ramey wrote:
> > Or rather,
> > to never generate . or .. as a pathname component via globbing.
>
> I don't think it's useful -- and it's certainly incompatible -- to make
> an explicit pattern like `.?' ignore `..'.
I think it would be most useful. A better design.
Of
On 2021-06-15 09:43 Chet Ramey wrote:
> I can see how this would be more intuitive. Let's try it. I'll put support
> in the next devel branch push.
Thanks!
> I'm leaning towards a general statement about how dotglob affects the set
> of filenames that are tested against the extended patterns,
Hello,
> Personally, I'd just want an option to always make . and .. hidden from
> globs. [...]
If such option existed, I would certainly use it.
As I already said, I can't imagine why anyone would ever want a pattern to
match `.' or `..' (unless the entire path component is literal).
But even
In my previous message, I wrote:
> Yes, it all depends on the "universal set" from which the matches of the inner
> `pattern-list' are subtracted.
> But in the current implementation, the inner matches are subtracted from:
> - all files, if dotglob is set
> - all except dot files, if dotglob is
Thanks again for the info. Now I understand why `.' and `..' are handled
separately, and I can imagine the complexity.
> The "matched explicitly" refers to the previous sentence, which talks about
> the `.' at the start of a filename or path component needing to be matched
> explicitly by a
Thank you for your effort in understanding my problem.
> The actual change, captured in the `devel' branch that tracks bash
> development, happened sometime in 2011.
I see.
> How would you improve the wording? What do you think is most important to
> cover?
Here is the full paragraph for
Hello,
> This is behavior that changed more than ten years ago.
I thought it changed in this commit:
https://git.savannah.gnu.org/cgit/bash.git/commit/?id=ac50fbac377e32b98d2de396f016ea81e8ee9961
2014-02-26 -> 7.2 years ago
But yes, I know it's old stuff and I was not implying a regression, just
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname output: Linux columbus 4.4.246-gentoo #2 SMP Thu Dec 31 17:31:16 -00 2020
i686 AMD Athlon(tm) XP 2800+ AuthenticAMD
14 matches
Mail list logo
