Re: shell wildcard expansion (un)safety

[Max Nikulin <manikulin () gmail com>]

On 06/11/2024 11:12, Solar Designer wrote:
> The only not-too-unreasonable change I can
> think of is wildcard expansion prefixing filenames with "./", maybe only
> those that start with "-" and maybe not when used with builtin "echo".

Even this technique might have consequences unexpected by script
authors, see

<https://mywiki.wooledge.org/BashPitfalls#pf42>:
> Bash Pitfalls: 42. for file in ./* ; do if [[ $file != *.* ]]

> In the case of a pattern like *.* however, problems can arise because it
> matches a string of the form ./filename. In a simple case, you can just
> use the glob directly to generate the desired matches. If however a
> separate pattern-matching step is required (e.g. the results have been
> preprocessed and stored in an array, and need to be filtered), it could
> be solved by taking the prefix into account in the pattern:
> [[ $file != ./*.* ]], or by stripping the pattern from the match.

> # Bash
> shopt -s nullglob
> for path in ./*; do
>     [[ ${path##*/} != *.* ]] && rm "$path"
> done
>
> # Or even better
> for file in *; do
>     [[ $file != *.* ]] && rm "./$file"
> done
>
> # Or better still
> for file in *.*; do
>     rm "./$file"
> done

The original issue is #3 in this list:
<https://mywiki.wooledge.org/BashPitfalls#pf3>
"Filenames with leading dashes"
It is discussed in the pitfall #2 and some
<https://mywiki.wooledge.org/BashFAQ>
entries.

I am not trying to dispute that expanding leading dash to "./-" by 
default may be an improvement. However there should be a way to disable 
it in specific cases.

P.S. More and more tools are getting support of CLI options to format
output as JSON when it necessary to parse it by another program.