'tr' character class support?

[Sam Kuper]

Dear all,

I'm not an OpenWRT dev, just a lurker on the mailing list & a sometime
user of OpenWRT.  (Thank you to all the devs & maintainers of OpenWRT &
packages, btw.)  So, my view might not count for much, but ...


On Fri, Jul 10, 2020 at 09:36:03PM -0400, Eric Luehrsen wrote:
> I did a comparison, which gave about a 500 byte increase [..] I'd say
> that difference is acceptable [..]
>
> Unless there is an overwhelming size cost, basic POSIX binaries should
> be provided "POSIX'ly correct" by default. [..]

On Sat, Jul 11, 2020 at 11:26:23AM -0700, Jordan Geoghegan wrote:
> On 2020-07-11 06:08, Magnus Kroken wrote:
>> [..] Making tr compliant when it's there anyway and has this small
>> cost is good. [..]
>
> [..] I agree about having to make certain sacrifices in order to
> remain usable on smaller devices, the only reason I brought it up was
> due to the dangerous way in which 'tr' was configured to ignore
> character classes and treat all characters literally, rather than at
> least printing an error. I'm glad to see you've decided to re-enable
> tr POSIX stuff. Thanks :)


... I agree with Eric, Magnus & Jordan: POSIX-compliance is *definitely*
worth implementing when the size cost is negligible, as it is in this
case.

It will reduce the risk of bugs in cases where:

- OpenWRT devs or package maintainers, e.g. new ones, might assume
  POSIX-compliant `tr` behaviour (& might forget to test for
  non-compliance); or

- third-party package authors do likewise.

Such bugs could end up having subtle & insidious effects, hard to
diagnose.

So, I would be grateful if the OpenWRT devs would make the suggested
change to the default Busybox compilation option.

(I say this as someone who owns one or two 4/32 devices, so please don't
think I'm not conscious of size constraints.)


> I'm not sure if there's any interest in making use of tr+classes for
> base system scripts, but I'd be happy to go through and start cleaning
> stuff up if there is interest.
> 
> Attached please find a patch for
> "package/network/services/hostapd/files/hostapd.sh" [..]

I also agree with Jordan's suggestion to fix OpenWRT base system scripts
so that they would use `tr` classes instead of attempting to work around
the current POSIX non-compliance by using literal ranges.  This way,
users - especially users who change locales - will be less likely to
experience bugs.

We're not in the pre-Unicode, pre-globalisation era anymore.  OpenWRT is
used internationally & no user should be penalised for switching locales
or performing other innocent actions that could trigger bugs with the
current scripts.

So, I would also be glad if Jordan's suggestion (& patch) could be
accepted.

Thank you for hearing me out, & thanks again for developing/maintaining
OpenWRT!

Sam

-- 
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?

()  ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\  file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.