bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Document that here strings don't support brace expansion.


From: Martin D Kealey
Subject: Re: Document that here strings don't support brace expansion.
Date: Wed, 15 Mar 2023 16:31:25 +1100

I suggest avoiding enumerating exclusions (including removing any existing
ones), and adding an explanation that "expansions that can produce multiple
words are excluded".

On Wed, 15 Mar 2023, 15:52 Alex Bochannek, <alex@bochannek.com> wrote:

> Chet,
>
> Thank you for the thoughtful responses. My thoughts below got a bit
> long, so here is a summary:
>
> - The here-string documentation should either spell out that brace
>   expansion is not performed or simple only list the expansions that
>   are.
> - The same goes for the documentation for the shell-expand-line Readline
>   command.
> - A Readline command to expand braces is a nice to have, but not
>   essential.
>
>
> For the longer version, let's address the two issues separately, first
> to Dale's point.
>
> Chet Ramey <chet.ramey@case.edu> writes:
>
> > On 3/14/23 11:23 AM, Dale R. Worley wrote:
> >> Interesting ... I would recommend adding brace expansion to the list
> >> of
> >> things-not-done because I think it's a common cognitive error to include
> >> brace expansion as part of filename expansion -- it's one of those
> >> things you do on the command line to generate a list of the files you
> >> want.
> >
> > OK, let's assume that's true: that brace expansion and filename expansion
> > are linked in your mind. Some glob(3) implementations do include it as a
> > non-standard extension, in fact.
> >
> > If they're linked, why wouldn't saying filename generation isn't
> performed
> > be enough to imply that brace expansion isn't performed either?
> >
> > I mean, it's not a huge deal -- two words. What I want to avoid is the
> > expectation that not only does the documentation need to specify which
> > expansions are performed, but the ones that are not. How about assuming
> > that if it's not specified as being performed, it's not performed?
>
> I first learned about brace expansion when using Csh 30-ish years ago.
> Back then it was absolutely considered (and documented in the man page)
> as part of "Filename substitution."
>
> In Bash, the man page (and the info manual) says: "Brace expansion is a
> mechanism by which arbitrary strings may be generated. This mechanism is
> similar to pathname[filename] expansion, but the file names generated
> need not exist." It has been like this since 1.14.7 in May 1995 (the
> oldest version I have access to) and still is like this in 5.2 from
> September 2022 - these man pages have Chet's name on it, so Chet is the
> authority as to their intent. I think Dale has a fair point though that
> people tend to think of brace expansion as "adjacent to" (i.e., often
> used for) filename expansion and I would guess a construct like "mv
> foo{.,bak}" is probably one of the most commonly used cases of brace
> expansion. However, sequence expressions, while certainly also used to
> construct filenames, feel a bit more removed from globbing.
>
> Anyway, for the purposes of this issue (documentation of here-strings),
> I would like to suggest that all expansions that do take place need to
> be listed and all that do not are either enumerated or combined with a
> phrase like: "No other expansion is performed on WORD." Ultimately, the
> list of seven expansions is what the reader references as the
> authoritative list, which is why the absence of brace expansion in the
> here-string documentation is surprising.
>
> Now on to the Readline point.
>
> Chet Ramey <chet.ramey@case.edu> writes:
>
> > I assume that means you think there should be a bash-specific bindable
> > command that performs brace expansion on the current word?
>
> I think this would be a nice feature to have, especially in light of the
> existence of complete-into-braces. It's interesting that this only
> applies to existing files, so if there were an equivalent brace
> expansion Readline command, combining it with complete-into-braces would
> not result in an identity function. This may be an argument against
> using M-} as a default binding for this hypothetical new function
> because it would suggest a symmetry that is not there.
>
> >> The documentation for M-C-e says "Expand the line as the shell does.
> >> This performs alias and history expansion as well as all of the shell
> >> word expansions (*note Shell Expansions::)." Maybe that can be tightened
> >> up a bit as well to clarify what it does not do?
> >
> > Sure, it can list the word expansions it performs.
>
> That would be helpful. The shell-expand-line command is really useful
> and I don't think a lot of users understand what its limitations are.
>
> Thank you!
>
> --
> Alex.
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]