Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15736

Re: unquoted expansion not working (was Re: Not missing, but very hard to see)

Show key headers only | View raw

[Multipart message — attachments visible in raw view] - view raw

On 12/14/19 5:48 AM, L A Walsh wrote:
>> If on the other hand Chet decides that the man page's wording is not
>> accurate, then the issue about whether to quote punctuation characters
>> becomes irrelevant.  The generation of punctuation characters is an
>> unexpected consequence, and the answer is Don't Do That.
>>   
> -----
>    No -- you don't go backwards -- it could break existing scripts that
> use that

That's a ridiculous argument, essentially saying bash must retain
bug-level compatibility with every previous version of every behavior.

https://xkcd.com/1172/

But it's also beside the point, because I don't actually see anyone
making the argument you're opposing. The proposal is to update the man
page to declare the current behavior as "expected", and possibly include
a note "abusing brace expansion to produce characters other than ASCII
letters is fragile and results in non-intuitive behavior. Users are
advised to not do it".

The alternative, changing bash's behavior to make the output of my
strings which happen to resemble brace expansion, suddenly produce an
array of expanded characters, is "breaking my script what are you doing
even stop making bash behave differently from version to version why
don't you even comprehend backwards compatibility ARGHHHHHHHHHHHH".

See, I can play the "people do unexpected things, don't break backwards
compatibility" absurdity game too.

> for one, but two -- are you going to limit it only to every
> range of letters and numbers in unicode?  It seems allowing it to work
> generally would be easier than trying to only have it work on the multiple
> ranges of unicode -- which I'd point out is consistent with bash growing to
> be able to use unicode (when it used to not be so), and most features
> working with unicode.

So this is actually not an unreasonable suggestion, I guess. Although I
can't really imagine a practical use for it, whereas generally with
other "works with unicode data" features, I can.

>    May not happen overnight, but a fix to quote meta-chars and allow all
> characters, including, _eventually_ 'null' embedded in strings, since that
> does happen in the MS world and in C++ where counts instead of zstrings are
> more frequently found, but I won't be holding my breath for that result.

Wait what.

Are you actually serious? Because this looks like trolling.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread

Thread

Re: unquoted expansion not working (was Re: Not missing, but very hard to see) Eli Schwartz <eschwartz@archlinux.org> - 2019-12-15 13:46 -0500

csiph-web