Fair. I'm not saying anyone has to change it, but I will call out what I think is a design flaw. But this is going to turn into some philosophical discussion as to whether it should have been done this way from the start. That I don't know, and hold no responsibility for, as I'm not a bash dev, I'm an exploit dev. Maybe an asshole too.
On Fri, Nov 19, 2021 at 9:05 AM Kerin Millar <k...@plushkava.net> wrote: > (Copying the list back in ...) > > On Fri, 19 Nov 2021 07:19:29 -0500 > Marshall Whittaker <marshallwhitta...@gmail.com> wrote: > > > Though I do disagree with you, this is the only message in this thread > that > > even makes sense. > > Firstly, rm * is a valid - albeit unsafe - simple command, and one that is > easily rectified. Secondly, the manner in which * expands is in accordance > with the documented behaviour. Thirdly, the manner in which simple commands > are processed is in accordance with the documented behaviour. In the event > that you can falsify the second and/or third of these assertions, then - > and only then - will you have discovered a bug in bash. > > As far as I can tell, your contention is that the default mode of pathname > expansion should be changed in order to paper over the first point. Very > well. Let's consider what would happen if, say, GLOBIGNORE=".*:-*" were to > be a default. > > * bash would violate POSIX [1] > * bash would be incompatible with other shells on this point > * existing scripts would change their behaviour and/or break (note: file > names beginning with a dash are perfectly legal) > * the behavioural change would not conclusively address the issue > > What do I mean by not addressing the issue? Fundamentally, the issue is > one of passing unsanitised input to an program, with the input taking the > form of an argument vector. Programs are free to act upon their arguments > in whatever way they see fit. While it may be common for argument beginning > with a dash to denote an option, this is by no means a cast-iron rule. If > the words produced by the expansion of a glob be arbitrary in nature, it is > your responsibility to understand how to convey them safely to a given > program. In many cases, assuming that responsibility turns out not to be > overly hard. The point is that it is beyond the purview of the shell. > > [1] > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13 > > -- > Kerin Millar >
