Given what is currently the problem, I suppose "val & 1<<7 || 31 < val < 127" is not enough of an indicator. Generally and including possible cases of Unicode, I'd assume that the locale tells a program which encoding is used and thus which codepoints are valid "text".

Isn't there already a library/mechanism which simply answers the question whether a codepoint is text? How do programs like `ls` (at least my version of it) do it? (partly rhetoric question, if I get around to it I will check it myself)

(concerning their presentation by a shell)

Before I look at this, I'll note your incorrect assumption: filenames are arbitrary byte strings that do not include '/' or NUL. There are no other semantics, textual or otherwise, associated with them.

Rationale: Some sources of text which are reproduced by bash's output can not be assumed well-formed or safe.

Notably, filenames may contain non-textual (and thus, semantically invalid, as filenames are supposed to be textual) characters which must not be printed back to the terminal as-is.

If there is no way to infer the set of textually valid characters with certainty (e.g. from $TERM), a conservative guess must be made as to which are non-textual characters (with other semantics than text, such as terminal control) and the latter must be escaped.

See for example the behaviour of some implementations of `ls` or `file` and compare that to bash:

$ touch 'ph+'$'\256''nom+'$'\277''ne'
$ ls
'ph+'$'\256''nom+'$'\277''ne'
$ file ph*
ph+\256nom+\277ne:  empty
$ echo ph*
ph+nom+ne

where in bash's output the invalid charaacters \256 and \277 are printed as-is and can affect the terminal (e.g. alacritty).