Re: Issue with -0 option for xargs in version 1.22.1

On Wed, Nov 07, 2018 at 12:57 PM, Tyson Williams said: > I am using BusyBox version 1.22.1. When I execute > > -- > echo hi | xargs -0 > -- > > the output I get is > >

Issue with -0 option for xargs in version 1.22.1

Hello, I am using BusyBox version 1.22.1. When I execute -- echo hi | xargs -0 -- the output I get is

Re: License concerns when embedding script in busybox binary

Kang-Che Sung wrote: >Since we are introducing the feature of embedding scripts into BusyBox, and >user may now include and build their custom scripts into the BusyBox binary, I >think there's one thing we forgot to address when this binary would be >distributed. That is: the license problem. I me

License concerns when embedding script in busybox binary

Since we are introducing the feature of embedding scripts into BusyBox, and user may now include and build their custom scripts into the BusyBox binary, I think there's one thing we forgot to address when this binary would be distributed. That is: the license problem. Specifically, I think the cur

Re: [RFC PATCH v2] Allow applets to be implemented as scripts

On Wed, Nov 7, 2018 at 9:54 PM Tito wrote: > > this embedded scripts patch looks like "featuritis" at its best to me. > It is adding complexity for solving what problem exactly: > avoiding to copy the scripts manually to the new system or to > the new firmware image? I see one advantage of embeddi

Re: [RFC PATCH v2] Allow applets to be implemented as scripts

On 07/11/18 08:42, Ron Yorston wrote: Kang-Che Sung wrote: Let no script applets individually configurable in menuconfig. Let users resolve the dependencies of whatever they put in applets_sh. My view is that if script applets are provided as part of BusyBox they should have all the feature

Re: [RFC PATCH 0/1] Allow applets to be implemented as scripts

On Wednesday, November 7, 2018, Ron Yorston wrote: > Kang-Che Sung wrote: >>You have already been needing 4 lines of config options for dependencies >>(CAT & SLEEP & ECHO & SH) of a 3-line script applet (nologin). > > nologin is actually an extreme case among the samples in applets_sh. > The other

Re: [RFC PATCH v2] Allow applets to be implemented as scripts

Kang-Che Sung wrote: >You have already been needing 4 lines of config options for dependencies >(CAT & SLEEP & ECHO & SH) of a 3-line script applet (nologin). nologin is actually an extreme case among the samples in applets_sh. The others only require sed, though each does have a TODO suggesting t

Re: [PATCH] powertop fix buffer overflow, removed unecessary strlen call

Hi , Please ignore this patch, as I realised that the strlen was correct looking at the if condition following the strlen Sorry for the inconvenience caused Get Outlook for Android From: haroon maqsood Sent: Wednesday, November 7, 2018 1:0

Re: [RFC PATCH v2] Allow applets to be implemented as scripts

On Wed, Nov 7, 2018 at 4:54 PM Ron Yorston wrote: > > Kang-Che Sung wrote: > >I think there is a potential for user to modify script applets heavily (for > >their particular application). Trying to track dependencies after user > >modification would be too much work for little benefit. > > Sure, u

Re: [RFC PATCH v2] Allow applets to be implemented as scripts

Kang-Che Sung wrote: >I think there is a potential for user to modify script applets heavily (for >their particular application). Trying to track dependencies after user >modification would be too much work for little benefit. Sure, users can modify script applets and break them. But that's nothi

Re: [RFC PATCH v2] Allow applets to be implemented as scripts

On Wed, Nov 7, 2018 at 3:42 PM Ron Yorston wrote: > > Kang-Che Sung wrote: > >Let no script applets individually configurable in menuconfig. Let users > >resolve the dependencies of whatever they put in applets_sh. > > My view is that if script applets are provided as part of BusyBox they > should

[PATCH] powertop fix buffer overflow, removed unecessary strlen call

Hi, PFA a small change to procps/powertop that removes a potential buffer overflow reported by gcc. in my opinion as dirent->d_name is allocated on the stack , we can avoid the strlen call, and make the char buf[] a bit bigger to accomodate the strings that are hardcoded i.e /proc/acpi/process/d->d