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

[Alex Bochannek]

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.