AW: 'tr' character class support?

[Jordan Geoghegan]

On 2020-07-11 06:08, Magnus Kroken wrote:
> Hi
>
> On 11.07.2020 09:18, Thomas Endt wrote:
>>> --- Config-defaults.in.orig     Fri Jul 10 21:03:57 2020
>>> +++ Config-defaults.in  Fri Jul 10 21:03:22 2020
>>> @@ -837,7 +837,7 @@
>>>           default y
>>>    config BUSYBOX_DEFAULT_FEATURE_TR_CLASSES
>>>           bool
>>> -       default n
>>> +       default y
>>>    config BUSYBOX_DEFAULT_FEATURE_TR_EQUIV
>>>           bool
>>>           default n
>>
>> What impact on busybox package size does this have?
>>
>
> I did a comparison, which gave about a 500 byte increase to the 
> compressed package:
>
> r13779+11-9362ea1661
>
> Default config:
> -rw-r--r-- 1 openwrt openwrt 208372 Jul 11 13:54 
> bin/packages/mips_24kc/base/busybox_1.31.1-1_mips_24kc.ipk
>
> With CONFIG_BUSYBOX_CONFIG_FEATURE_TR_CLASSES=y
> -rw-r--r-- 1 openwrt openwrt 208868 Jul 11 14:06 
> bin/packages/mips_24kc/base/busybox_1.31.1-1_mips_24kc.ipk
>
> With CONFIG_BUSYBOX_CONFIG_FEATURE_TR_CLASSES=y and 
> CONFIG_BUSYBOX_CONFIG_FEATURE_TR_EQUIV=y
> -rw-r--r-- 1 openwrt openwrt 208895 Jul 11 14:08 
> bin/packages/mips_24kc/base/busybox_1.31.1-1_mips_24kc.ipk
>
> For the record, a POSIX compliant tr requires both 
> CONFIG_BUSYBOX_CONFIG_FEATURE_TR_CLASSES=y and 
> CONFIG_BUSYBOX_CONFIG_FEATURE_TR_EQUIV=y.
>
> I'd say that difference is acceptable, but for similar issues in the 
> future there remains the question of how desirable POSIX compliance is 
> in OpenWrt, and what sacrifices are reasonable to achieve it. Is there 
> a decision, goalr or mindset on this? I'm not a 4/32 fanatic and 
> accept that minimum requirements will increase over time, but I still 
> value the flexibility of OpenWrt (such as the ability to run on 
> relatively small devices). Making tr compliant when it's there anyway 
> and has this small cost is good. OTOH, a proper POSIX system requires 
> e.g. a working C compiler, which I think is an absurd minimum to set 
> for OpenWrt given how useful and flexible it is in its current state.
>
> Regards,
> Magnus Kroken

Hi Magnus,

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'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"


Regards,

Jordan Geoghegan





-------------- next part --------------
A non-text attachment was scrubbed...
Name: hostapd.sh.patch
Type: text/x-patch
Size: 580 bytes
Desc: not available
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20200711/6aa7c0c8/attachment.bin>