Re: [PATCH] switch_root: remove /init check

Linus Heckemann 於 2024年4月23日 星期二寫道： > > I don't really see the existence of /init being so critical for > this check given that we check below that it's a ramfs or tmpfs, which > seems to me to be enough that people won't be destroying filesystems > they cared a great deal about. > The

Re: [PATCH] switch_root: remove /init check

Linus Heckemann 於 2024年4月19日 星期五寫道： > We were having some difficulty switching out of our custom initramfs > into the final filesystem, with the error "message '/init' is not a > regular file". We were confused as to why it was looking for `/init` > -- we didn't have `/init`, neither in our

Re: [PATCH v2] bloat-o-meter: line wrapped at 75 columns instead of 80

Jones Syue 薛懷宗 於 2024年3月11日 星期一寫道： > This patch replaces the 78 "-" prints with 75 "-". And replace the 80 > columns summary line with 77 columns. ("%s" is considered as two chars > and should be filled with whitespace " ", so 77 = 75 + 2) > > Consider this scenario: a patch contains the output

Re: [PATCH] seedrng: fix getrandom() detection for non-glibc libc

Just my two cents... On Wednesday, April 19, 2023, Raphaël Mélotte wrote: > +# Not all libc versions have getrandom, so check for it. > +HAVE_GETRANDOM := $(shell printf '#include \n#include \nint main(void){char buf[256];\ngetrandom(buf,sizeof(buf),GRND_NONBLOCK);}' >bb_libtest.c; $(CC)

Re: sha256sum Illegal instruction on musl amd64

On Fri, Mar 31, 2023 at 12:34 AM wrote: > > shaNI = ((ebx >> 28) & 2) - 1; /* bit 29 -> 1 or -1 */ > > Seems a lot more complicated than intel's approach: > > shaNI = ((ebx >> 29) & 1); > The `shaNI` variable is not a boolean, but has three possible values: 0 (undetermined), 1 (SHA instructions

Re: [PATCH] find: implement -nouser, -nogroup

On Sunday, January 29, 2023, David Leonard < d+busy...@adaptive-enterprises.com> wrote: > > Resending patch for 'find -nouser', 'find -nogroup'. Refreshed bloatcheck > > Subject: [PATCH] find: implement -nouser, -nogroup > > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html > >

Re: [PATCH v2 2/9] loop:refactor: extract subfunction get_next_free_loop()

On Mon, Nov 21, 2022 at 9:19 AM Xiaoming Ni wrote: > static int get_next_free_loop(char *dev, size_t dev_size, int id) > { > int loopdevno = get_free_loop(); > if (loopdevno >= 0) { > snprintf(dev, dev_size, LOOP_FORMAT, loopdevno); > return 1;

Re: [PATCH v2 6/9] loop:refactor: Use a structure to reduce parameters

On Mon, Nov 21, 2022 at 9:31 AM Xiaoming Ni wrote: > > Also, it is unclear why there is the need to clone the loopinfo buffer. > > > > > /* Old kernel, does not support LO_FLAGS_AUTOCLEAR? */ > > > /* (this code path is not tested) */ > > > -

Re: [PATCH v2 9/9] loop: Add LOOP_CONFIGURE ioctl

On Friday, November 18, 2022, Xiaoming Ni wrote: > LOOP_CONFIGURE is added to Linux 5.8 > > This allows userspace to completely setup a loop device with a single > ioctl, removing the in-between state where the device can be partially > configured - eg the loop device has a backing file

Re: [PATCH v2 6/9] loop:refactor: Use a structure to reduce parameters

On Friday, November 18, 2022, Xiaoming Ni wrote: > Step 6 of micro-refactoring the set_loop(): > Use structs to avoid transferring a large number of parameters > in set_loop_configure() and set_loop_info() > > function old new

Re: [PATCH v2 2/9] loop:refactor: extract subfunction get_next_free_loop()

On Friday, November 18, 2022, Xiaoming Ni wrote: > Step 2 of micro-refactoring the set_loop function () > Extract subfunction get_next_free_loop() from set_loop() > > Also fix miss free(try) when stat(try) and mknod fail > > function old new

Re: [PATCH 9/9] loop: Add LOOP_CONFIGURE ioctl

On Fri, Nov 18, 2022 at 9:04 AM Xiaoming Ni wrote: > > LOOP_CONFIGURE is added to Linux 5.8 > > This allows userspace to completely setup a loop device with a single > ioctl, removing the in-between state where the device can be partially > configured - eg the loop device has a backing file

Re: [PATCH] buildsys: resurrect PLATFORM_LINUX and depend on it for linux-specific applets

On Sat, Nov 5, 2022 at 12:55 AM Michael Tokarev wrote: > diff --git a/Makefile b/Makefile > index 503475fe9..ad780c261 100644 > --- a/Makefile > +++ b/Makefile > @@ -361,9 +361,16 @@ scripts/basic/%: scripts_basic ; > > # This target generates Kbuild's and Config.in's from *.c files > PHONY +=

Re: [PATCH v4] shell: exchange Dijkstra $(( )) evaluator..

On Wednesday, September 7, 2022, Steffen Nurpmeso wrote: > Kang-Che Sung wrote in > : > |On Wednesday, September 7, 2022, Steffen Nurpmeso > |wrote: > ... > |>|> + if(su_64( i > U32_MAX || ) i >= UZ_MAX / 2 || > ... > |>|I have to admit that t

Re: [PATCH v4] shell: exchange Dijkstra $(( )) evaluator..

On Wednesday, September 7, 2022, Steffen Nurpmeso wrote: > |> + /* Overflow check: since arithmetic expressions are rarely \ > |> long enough > |> + * to come near this limit, xxx laxe & fuzzy, not exact; max \ > |> U32_MAX! */ > |> + if(su_64( i > U32_MAX || ) i >= UZ_MAX /

Re: [PATCH] ntpd: make NTP client Y2036-ready

On Monday, May 9, 2022, Miroslav Lichvar wrote: > The 32-bit integer part of the NTP timestamp overflows in year 2036, > which starts the second NTP era. > > Modify the timestamp conversion to shift values between 1900-1970 (in > the first era) to the second era to enable the client to

Re: [PATCH v4] tree: new applet

Hi Roger, May I suggest you add an option to draw the tree lines using ASCII characters only, and make the Unicode support optional at build time? I just feel uncomfortable when I see source code containing embedded UTF-8 characters and the strings have no ASCII alternative. The DOS tree

Re: [PATCH 2/2] less: replace most uses of NORMAL escape with UNHIGHLIGHT

On Friday, April 15, 2022, FriendlyNeighborhoodShane < shane.880088.s...@gmail.com> wrote: > Fixes conflict when -R's color escape codes are mixed together with > highlights. Better complement to HIGHLIGHT. What's the difference between the NORMAL escape and the UNHIGHLIGHT escape? Is there a

Re: grep: add option for better usability in pipelines

On Thu, Feb 17, 2022 at 3:27 PM Ulrich Eckhardt wrote: > > > > Why do we need to implement a workaround in grep while you can > > do this in shell to ignore the exit code of grep? > > > > { grep issue > `grep -p ...` rather replaces `grep ... || test $? = 1`. The advantage > is that it is

Re: grep: add option for better usability in pipelines

On Thu, Feb 17, 2022 at 12:50 PM Michael Conrad wrote: > > On 2/16/22 19:32, Kang-Che Sung wrote: > > > >> Now, for an example where it makes a difference. Consider a Bash script > >> like this: > >> > >># enable automatic error handling >

Re: grep: add option for better usability in pipelines

On Thu, Feb 17, 2022 at 8:01 AM Ulrich Eckhardt wrote: > > I've implemented a `-p` flag for grep, which disables a behaviour that > the exit status is used (abused?) to signal whether any match > occurred. The behaviour is POSIX. > Now, for an example where it makes a difference. Consider a

Re: Patch to add support for RFC2324 (HTCPCP)

On Mon, Nov 29, 2021 at 5:16 AM Peter Willis wrote: > > Hi busybox devs, It's been a long time! About 17 years since my last > submission :-) > > I was just trying to make some coffee with busybox, and I noticed it doesn't > support RFC 2324 (Hyper Text Coffee Pot Control Protocol). Attached is

Re: [PATCH] ed: add support for -p command-line option as mandated by POSIX

On Sunday, November 21, 2021, Harald van Dijk wrote: > On 21/11/2021 07:12, Kang-Che Sung wrote: >> >> On Sunday, November 21, 2021, David Laight mailto:david.lai...@aculab.com>> wrote: >> > >> > You shouldn't need the strdup(). >> > I th

Re: [PATCH] ed: add support for -p command-line option as mandated by POSIX

On Sunday, November 21, 2021, David Laight wrote: > From: soe...@soeren-tempel.net >> Sent: 20 November 2021 17:17 >> >> The POSIX.1-2008 specification of ed(1) mandates two command-line >> options: -p (for specifying a prompt string) and -s (to suppress writing >> of byte counts). This commit

Re: lzip support in busybox?

On Wed, Aug 25, 2021 at 1:32 AM Jacob Burkholder wrote: > > In 2012 a patch was submitted to the list about lzip support in busybox, > there was not much discussion about it. I've been using the patch for some > years and keep porting it to new versions of busybox, just now 1.33.1. I use > a

Re: [PATCH] ash: add built-in $ASH_VERSION variable

On Thu, Mar 11, 2021 at 2:55 PM Ariadne Conill wrote: > > This is helpful for detecting if the shell is busybox ash or not, > which is necessary for enabling ash-specific features in /etc/profile > and Alpine's default $ENV. > > https://gitlab.alpinelinux.org/alpine/aports/-/issues/12398 outlines

Re: [PATCH] wget: new option FEATURE_WGET_FTP to enable/disable FTP

On Monday, January 18, 2021, Sergey Ponomarev wrote: > Introduce a separate option FTPS_SUPPORTED instead of not obvious ENABLE_FEATURE_WGET_HTTPS. > I juat wonder... If you are bothered to add FTP configure option, how about making FTPS separate from HTTPS as well?

Re: [PATCH v2 1/2] modutils: check ELF header before calling finit_module()

On Mon, Jan 4, 2021 at 6:32 PM Qu Wenruo wrote: > > On 2021/1/4 下午6:01, Kang-Che Sung wrote: > > On Sun, Jan 3, 2021 at 12:11 PM Qu Wenruo wrote: > >> > >> finit_module() and init_module() system calls have clear specification > >> to only accept val

Re: [PATCH v2 1/2] modutils: check ELF header before calling finit_module()

On Sun, Jan 3, 2021 at 12:11 PM Qu Wenruo wrote: > > finit_module() and init_module() system calls have clear specification > to only accept valid ELF image. > > Although we try finit_module() on compressed modules to let the kernel > determine if it's an ELF image, but it's not ideal, especially

Re: [PATCH] shrink last_char_is function even more

On Monday, July 20, 2020, Tito wrote: > > > On 7/20/20 9:22 AM, Laurent Bercot wrote: >>> The param should be marked with the nonnull attribute, just like the >>> libc string functions. Then the compiler will warn you if you try to >>> pass NULL (may need higher optimization, warning levels, or

Re: [PATCH] libbb/last_char_is: rewrite for smaller and faster code

On Saturday, July 4, 2020, Harald van Dijk wrote: > > This is really the same problem as with standard library functions such as strchr(). The function should have a return type of char* if its argument has type char*. The function should have a return type of const char* if its argument has type

Re: [PATCH] libbb/last_char_is: rewrite for smaller and faster code

On Friday, July 3, 2020, Jody Bruchon wrote: > > > On July 2, 2020 11:29:06 AM EDT, Kang-Che Sung wrote: >>On Thursday, July 2, 2020, Jody Bruchon wrote: >>> /* Find out if the last character of a string matches the one given >>*/ >>> -char* FAST

Re: [PATCH] libbb/last_char_is: rewrite for smaller and faster code

On Thursday, July 2, 2020, Jody Bruchon wrote: > /* Find out if the last character of a string matches the one given */ > -char* FAST_FUNC last_char_is(const char *s, int c) > +char* FAST_FUNC last_char_is(char *s, char c) Why are you removing the const qualifier, and how would that reduce the

Re: Invalid tar magic when streaming download

On Fri, Dec 6, 2019 at 10:06 AM Jeffrey Fetterman wrote: > > Ah. I don't think this mailing list is for me. Thank you for your time. > What are you expecting anyway? 1. It is normal for a tar program to reject a tarball with multiple layers of gzip. Some tar implementations allows recurse

Re: Invalid tar magic when streaming download

On Friday, December 6, 2019, Eli Schwartz wrote: > libarchive bsdtar works, which I guess means that libarchive permits you > to wrap a tarball in *two* layers of gzip compression, then extract the > contents. Personally, I would claim this is a buggy design goal, because > you'd have to be nuts

[RFC] gzip: Default compress level changeable at build time.

s is how I proposed letting the user change the compression level when GZIP_LEVELS is turned off, when discussing about gzip default compression level. This patch is a proof of concept of that. <http://lists.busybox.net/pipermail/busybox/2019-September/087442.html> Signed-off-by: Kang-Che Sun

[PATCH] bc: Add 'U' suffix in UINT_MAX preprocessor check

Without the 'U' unsigned suffix, gcc will throw a "integer constant is so large that it is unsigned" warning. --- miscutils/bc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/miscutils/bc.c b/miscutils/bc.c index e492f0f50..92721d18f 100644 --- a/miscutils/bc.c +++

Re: Patches to make GNU gzip and BusyBox gzip produce identical compression results

Well, it seems that Denys merged the changes before I have the time to respond to comments, but anyway: I actually disliked the argument about "de-facto standard" on compression levels. I think scripts should not depend on the default compression level, and should instead specify it explicitly.

Re: Patches to make GNU gzip and BusyBox gzip produce identical compression results

> From 12d30559486502feec4e2821b3ab45ae6139e7aa Mon Sep 17 00:00:00 2001 > From: Daniel Edgecumbe > Date: Mon, 2 Sep 2019 22:09:15 +0100 > Subject: [PATCH 3/3] gzip: set default compression level to 6 when > CONFIG_FEATURE_GZIP_LEVELS=n > > With this change, GNU gzip -n and BusyBox gzip now

Re: switch_root: zap the last directory for the mount point of new-root

On Friday, August 2, 2019, 阿保 純一 wrote: >> Speaking of, since we are now overmounting the root before zapping the >> initramfs, I wonder if we can remove one check about whether the new root >> is a mount point (this saves code size; mount() would fail with EINVAL in >> that case). > At least, I

Re: switch_root: zap the last directory for the mount point of new-root

On Friday, July 19, 2019, Kang-Che Sung wrote: > > There's side benefit for this patch: In case that overmount fails, we can have > a rootfs kept intact (instead of almost destroyed). > Correction. It's just a side effect, not a "benefit" worth talking about. Speakin

Re: switch_root: zap the last directory for the mount point of new-root

On Fri, Jul 19, 2019 at 3:27 PM 阿保 純一 wrote: > > As the author said in the comment of util-linux/switch_root.c, current > implementation leaves the mount point of new root-file-system without rmdir(). > As long as I experimented on a linux kernel, current process of "/" still > points old

Re: [PATCH 1/2] wget: add -o flag

On Wednesday, December 26, 2018, Martin Lewis wrote: > [...] > @@ -147,6 +148,7 @@ > //usage: "\n -T SEC Network read timeout is SEC seconds" > //usage: ) > //usage: "\n -O FILE Save to FILE ('-' for stdout)" > +//usage: "\n -o FILE

Re: [PATCH] Tweaks to build process for embedded scripts

On Monday, November 19, 2018, Ron Yorston wrote: > Kang-Che Sung wrote: >>Script stripping should be optional, for at least two reasons: >>1. It's beyond the scope of the script embedding feature, and it would better >>be implemented and maintained as a separate tool. >

Re: [PATCH] Tweaks to build process for embedded scripts

On Mon, Nov 19, 2018 at 5:43 PM Ron Yorston wrote: > > Denys Vlasenko wrote: > >On Sun, Nov 18, 2018 at 10:06 AM Ron Yorston wrote: > >> - Strip leading comments and blank lines from embedded scripts before > >> compressing them. Removing all comments would be nice but is hard. > > > >Well,

Re: [PATCH 1/3] Support both custom scripts and scripted applets

On Sat, Nov 17, 2018 at 6:56 AM Denys Vlasenko wrote: > I basically agree. > > How about this? - embed/ applets can have configuration. > If it exists, then they are visible in "make menuconfig" > and can be selected or deselected. > But if config is _absent_, they are included unconditionally. >

Re: [PATCH] Add a 'busybox --list name' option to display script content Re: License concerns when embedding script in busybox binary

On Sat, Nov 10, 2018 at 2:10 AM Ron Yorston wrote: > > Add an option to allow the content of embedded scripts to be > displayed. > > It's disabled by default. When enabled: > > function old new delta > run_applet_and_exit

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

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

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 cas

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

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 pro

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

Can we do this instead: Let no script applets individually configurable in menuconfig. Let users resolve the dependencies of whatever they put in applets_sh. If user needs to temporarily not embed a particular applet in that folder, then we can provide a "DISABLE" file that specifies which

Re: [PATCH 1/1] wget: make --no-check-certificate option appear in usage

On Sat, Jun 9, 2018 at 1:46 AM, James Byrne wrote: > The line for this option was missing the 'usage:' prefix, meaning that > it was ignored. > > Signed-off-by: James Byrne > --- Well, actually wget in BusyBox does not yet check for certificates, so adding the help text would be redundant and

Re: [PATCH] wget: don't silently ignore certificate validation

On Fri, May 25, 2018 at 12:50 AM, Jakub Jirutka wrote: > Internal TLS code (FEATURE_WGET_HTTPS) does not implement validation > of the server's certificate. It is documented in the code, but not > even mentioned in the --help message, so users typically don't know > about this

Re: [PATCH] wget: don't silently ignore certificate validation

On Sun, May 27, 2018 at 1:34 AM, Denys Vlasenko wrote: > wget should work for common use cases. > Such as downloading sources of kernels, gcc and such. > From build scripts, not only by hand. > Without having to modify said scripts. > Your patch breaks that. > NAK. > > I

Re: [PATCH 1/2] udhcpc6: carry along length of packet when parsing it.

David Decotigny 於 2018年5月24日 週四 23:38 寫道： > This is to avoid parsing garbage past packet's actual end. > > Also const-ize params to a few functions. > > Signed-off-by: David Decotigny > I wonder if parsing such "garbage" has security implications. >

Re: [BUG] 'case' does not match double-quoted backslash

On Tue, Feb 13, 2018 at 10:34 AM, Martijn Dekker <mart...@inlv.org> wrote: > Op 13-02-18 om 03:09 schreef Kang-Che Sung: >> Just wondering, why using "\z" and not "\\z" ? >> The former doesn't seem to be a valid syntax. > > It is val

Re: [BUG] 'case' does not match double-quoted backslash

On Tue, Feb 13, 2018 at 5:36 AM, Martijn Dekker wrote: > The following outputs BUG in ash: > > case "\z" in > "\z" ) echo ok ;; > * ) echo BUG ;; > esac > > Apparently `case` has trouble matching the "\z" pattern due to the > backslash within the double quotes. Quoting it

Re: [PATCH] ash: make bash_source command search current directory after PATH

I really want to argue that there is a quite simple workaround to get the bash 'source' behavior you need: Just append ":." to the PATH environment variable before you run the "." command. Or this: source () { PATH="$PATH:." . "$@" } Was there any difficulty of doing it?

Re: [PATCH] ash: make bash_source command search current directory after PATH

On Mon, Jan 29, 2018 at 2:51 AM, Bernd Petrovitsch wrote: > On Fri, 2018-01-26 at 15:15 +0100, Denys Vlasenko wrote: >> On Fri, Jan 26, 2018 at 9:34 AM, Paul Otto wrote: > [...] >> > According to the BASH documentation, the source command should: >> >

Re: [PATCH] ash: make bash_source command search current directory after PATH

2018年1月28日 上午5:05，"Paul Otto" 寫道： Thanks for taking care of this, Denys. It didn't wind up the way I'd hoped, but at least it is predictable both ways now. I will see if there is a way to get Alpine Linux to build with that config option set, to resolve the regression introduced

Re: [PATCH 0/2] Add -R to less applet (bug #5546)

Hi Denys Vlasenko, I think I found a typo in the recent commit 8528d3d4f8240ab4715f671aa819fe034f0fc285 > @@ -106,7 +122,7 @@ > > //usage:#define less_trivial_usage > //usage: "[-E" IF_FEATURE_LESS_REGEXP("I")IF_FEATURE_LESS_FLAGS("Mm") > -//usage: "N" IF_FEATURE_LESS_TRUNCATE("S") "h~]

Re: [PATCH 4/4] chrt: don't rely on exact values of SCHED_* defines

On Sun, Jan 14, 2018 at 5:30 AM, Povilas Kanapickas wrote: > --- a/util-linux/chrt.c > +++ b/util-linux/chrt.c > @@ -36,17 +36,20 @@ > #include > #include "libbb.h" > > -static const struct { > - int policy; > - char name[sizeof("SCHED_OTHER")]; > -} policies[] =

Re: ash.c history loading and ENABLE_FEATURE_EDITING_SAVEHISTORY

2017年12月24日 09:17，"Ceriel Jacobs" 寫道： There is no need to remember what was just typed. There is a need to use commands that were typed a long time (years) ago. Disasters often happen a long time after the backup (script/system) was made. The point is that you don't

Re: ash.c history loading and ENABLE_FEATURE_EDITING_SAVEHISTORY

2017-12-24 07:55，"Ceriel Jacobs" 寫道： It seems that BusyBox v1.27.2 doesn't load history from a history file when ENABLE_FEATURE_EDITING_SAVEHISTORY is not set. I think that the corresponding source code logic is here:

Re: [PATCH] ash: fix a crash on arm when building with clang.

On Thu, Dec 21, 2017 at 5:32 AM, Yunlian Jiang wrote: > > When I run > busybox ash on an arm device with busybox built with clang 6. > I got a segmentation fault > in the macro > #define INIT_S() do { \ > (*(struct lineedit_statics**)_ptr_to_statics) = xzalloc(sizeof(S)); \ >

Re: Ash glob symlink regression when using libc glob

On Tue, Oct 31, 2017 at 8:48 PM, Lauri Kasanen wrote: > > So it was fixed after 2.26 and no released glibc contains the fix. How > about either editing the description to say glibc >= 2.27 only, or even > checking that compile-time? I would like to have both. And probably give a

Re: [PATCH 4/7] xfuncs: Handle missing non-POSIX termios constants

On Sun, Oct 8, 2017 at 10:34 PM, Ralf Friedl wrote: > > Because the way the line is now is one line with 8 values. Changing that to > use ifdefs for each value would change that one line to 3*8+2=26 lines, that > makes the code much harder to read and maintain. And there

Re: [PATCH 7/7] libbb.h: Handle missing HOST_NAME_MAX; ensure MAXFOOLEN agrees with FOO_MAX

2017年10月8日 18:59，"James Clarke" 寫道： That's not actually true (any more); util-linux/fdisk_osf.c, whilst Linux-specific, does use MAXPATHLEN, and networking/traceroute.c uses MAXHOSTNAMELEN. These could be changed to use {PATH,HOST_NAME}_MAX, but it's highly likely that a

Re: [PATCH 4/7] xfuncs: Handle missing non-POSIX termios constants

2017年10月8日 18:50，"James Clarke" <jrt...@jrtc27.com>寫道： On 8 Oct 2017, at 02:34, Kang-Che Sung <explore...@gmail.com> wrote: > On Sun, Oct 8, 2017 at 1:53 AM, James Clarke <jrt...@jrtc27.com> wrote: >> diff --git a/libbb/xfuncs.c b/libbb/xfuncs.c >> index

Re: [PATCH 7/7] libbb.h: Handle missing HOST_NAME_MAX; ensure MAXFOOLEN agrees with FOO_MAX

On Sun, Oct 8, 2017 at 1:53 AM, James Clarke wrote: > Signed-off-by: James Clarke > --- > include/libbb.h | 19 ++- > 1 file changed, 18 insertions(+), 1 deletion(-) > > diff --git a/include/libbb.h b/include/libbb.h > index

Re: [PATCH 4/7] xfuncs: Handle missing non-POSIX termios constants

On Sun, Oct 8, 2017 at 1:53 AM, James Clarke wrote: > diff --git a/libbb/xfuncs.c b/libbb/xfuncs.c > index 9cbfb2836..95dac656a 100644 > --- a/libbb/xfuncs.c > +++ b/libbb/xfuncs.c > @@ -22,6 +22,16 @@ > */ > #include "libbb.h" > > +#ifndef IMAXBEL > +# define IMAXBEL 0 >

Re: Cannot download busybox with busybox

On Tue, Aug 29, 2017 at 7:58 PM, Denys Vlasenko wrote: > I'll cc this to bbox mailing list to humiliate this guy. > > On Tue, Aug 29, 2017 at 1:21 PM, wrote: I'm trying to update busybox binary on busybox-based system. When i am trying to

[PATCH] ps: Allow ps config options if minips is enabled

Follow-up of commit ab77e81a8527fa11a4f9392d97c2da037d6f4f98 "klibc-utils: new applets: resume, nuke, minips" Also put FEATURE_PS_UNUSUAL_SYSTEMS to under FEATURE_PS_TIME in the menu. Signed-off-by: Kang-Che Sung <explore...@gmail.com> --- procps/ps.c | 16 1

Re: [PATCH] ash/hush: implement -d DELIM option for `read`

On Mon, Aug 7, 2017 at 6:18 PM, Johannes Schindelin wrote: > The POSIX standard only requires the `read` builtin to handle `-r`: > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/read.html > > However, Bash introduced the option `-d ` to override IFS for >

Re: BusyBox top buffered and the cached memory

On Tue, Aug 1, 2017 at 3:44 PM, Klaaßen, Fynn (LAWO) wrote: > > I guess, there is a trivial bug when using busybox top: > > BusyBox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) multi-call binary: > > Mem: 3278296K used, 1236784K free, 0K shrd, 35373432K buff, 140001458828604K >

Re: [PATCH] libbb: remove vdprintf

On Sat, Jul 29, 2017 at 9:48 PM, Ron Yorston wrote: > -#if defined(__GLIBC__) && __GLIBC__ < 2 > -int vdprintf(int d, const char *format, va_list ap); > -#endif __GLIBC__ is NOT defined in glibc before version 2. So this macro check actually means a libc which claims to be

Re: [PATCH] ash: support platforms that don't have '%m' printf specifier

On Fri, Jul 28, 2017 at 12:58 AM, Jody Bruchon wrote: > IMO the whole issue is that %m is non-standard despite having moderate de > facto acceptance in many libc implementations. I think BusyBox should comply > with the standards instead of having a compile-time hack and

Re: [PATCH] ash: support platforms that don't have '%m' printf specifier

On Thu, Jul 27, 2017 at 8:53 PM, Ron Yorston wrote: > The '%m' conversion specifier prints an error message based on the > current value of 'errno'. It is available in the GNU C library, > Cygwin (since 2012), uClibc and musl. > > It is not available in various BSDs, BSD-derived

Re: [PATCH] ash: avoid GLIBC'ism %m

AM, Jody Bruchon <j...@jodybruchon.com> wrote: >>> > On 2017-07-18 9:15 PM, Kang-Che Sung wrote: >>> >> >>> >> On Wed, Jul 19, 2017 at 2:11 AM, Markus Gothe <nietzs...@lysator.liu.se> >>> >> wrote: >>> >>

Re: [PATCH v3 0/2] Avoid GLIBC'ism "%m"

On Tue, Jul 25, 2017 at 9:56 PM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > > As pointed out by Kang-Che Sung and verified by Jody Bruchon, the "%m" > format placeholder is really not in any open standard. > > Also: contrary to Denys' assumpti

Re: [PATCH] ash: avoid GLIBC'ism %m

On Sun, Jul 23, 2017 at 10:03 AM, Kang-Che Sung <explore...@gmail.com> wrote: > > How about wrapping the printf("%m") uses within the __GNU_LIBRARY__ macro? > It seems that %m support has been there from the beginning of glibc. Correction. It's since glibc 1.06. I've lo

Re: [PATCH] ash: avoid GLIBC'ism %m

On Sun, Jul 23, 2017 at 4:33 AM, Michael Conrad wrote: > On 7/22/2017 2:56 PM, Johannes Schindelin wrote: >> >> No, not every libc. I would not have spent the time and effort to develop >> the patch, contribute it, rework it and contribute a second iteration if >> it was

Re: About the approximate applet sizes in menuconfig

On Thu, Jul 20, 2017 at 8:22 PM, walter harms <wha...@bfs.de> wrote: > > > Am 20.07.2017 12:17, schrieb Denys Vlasenko: >> On Wed, Jul 19, 2017 at 6:38 PM, Kang-Che Sung <explore...@gmail.com> wrote: >>> (https://git.busybox.net/busybox/commit/?id=4eed

About the approximate applet sizes in menuconfig

(https://git.busybox.net/busybox/commit/?id=4eed2c6c5092ed95b8ee6d994106c54a9fc6ed3e) I don't like this. I don't like these size info to be put on the titles of config options. A few reasons: * It can give a false impression that the size of the final busybox binary is the size of these applets

Re: [PATCH] ash: avoid GLIBC'ism %m

On Wed, Jul 19, 2017 at 2:11 AM, Markus Gothe wrote: > Actually last time I checked ‘%m’ is POSIX contrary to glibc’s deprecated > '%a’. > However, I agree that it should not be used since at least uClibc can be > built without support for it. How come %m is POSIX

Re: [PATCH] ash: avoid GLIBC'ism %m

I wonder if there's a better solution to this. BusyBox has bb_perror_msg() and like. Maybe using these API's are better? On Mon, Jul 17, 2017 at 4:08 AM, Johannes Schindelin wrote: > GLIBC's printf() family supports the extension where the placeholder %m > is

[PATCH] make_single_applets: fix ": $((fail++))" expansion error

$((fail++)) is not a required expression in POSIX, and in "dash" it could produce an error like this: ./make_single_applets.sh: 61: arithmetic expression: expecting primary: "fail++" Replace this with something portable: fail=$((fail+1)) would work. Signed-off-by: Ka

[PATCH] cat: allow compiling out -n and -b

When these options were introduced in d88f94a5df3a2edb8ba56fab5c13674b452f87ab it provides no config options to compile them out. Now provide one. Introduce config FEATURE_CATN. Signed-off-by: Kang-Che Sung <explore...@gmail.com> --- coreutils/cat.

Re: Need Help with BusyBox Configuration

On Tue, Jul 11, 2017 at 7:42 PM, Siddharth Muralee wrote: > Hey there, > I am relatively new to busybox and I am trying to compile a 32bit Linux > kernel of 2.6.32 and I am not able to compile busybox for 32bit. > Currently Busybox binary is of > busybox: ELF 64-bit

Re: [PATCH 1/1] makedevs: set path size to match linux

On Thu, Jul 6, 2017 at 8:04 AM, Denys Vlasenko <vda.li...@googlemail.com> wrote: > On Tue, Jun 27, 2017 at 3:20 PM, Kang-Che Sung <explore...@gmail.com> wrote: >> Hello. Can I suggest another way? >> How about modifying the `line` buffer so it can be used directl

Re: [PATCH 1/1] makedevs: set path size to match linux

On Tue, Jun 27, 2017 at 3:53 PM, walter harms wrote: > > Am 27.06.2017 05:31, schrieb Baruch Siach: >> >> On Mon, Jun 26, 2017 at 08:45:42PM -0500, Matthew Weber wrote: >>> On Mon, Jun 26, 2017 at 7:36 PM, Emmanuel Deloget wrote: On Mon, Jun 26, 2017 at 11:23

Re: ash buildin "read" interrupted on SIGCHLD

On Thu, Jun 1, 2017 at 5:36 PM, Guido Classen wrote: > I was curious how to catch SIGCHLD using trap and what behavior we should > expect. Could you also provide a test for trap in conjunction with SIGCHLD. I was about to ask the same question, until I realize that the

Re: tree

On Wed, May 3, 2017 at 6:00 AM, Jethro Tull wrote: > why tree is not in busybox? Short answer: Because no one has been implementing it in Busybox yet. ___ busybox mailing list busybox@busybox.net

Re: [PATCH 3/3] ash: exec: -a option for setting zeroth arg

Back in January 2017, a person named Patrick Pief has suggested a similar patch to add "exec -a" support: http://lists.busybox.net/pipermail/busybox/2017-January/085146.html Is your patch same as his or is there any difference? ___ busybox mailing list

Re: A good scripting language for busybox?

On Fri, Mar 17, 2017 at 11:20 PM, Pavel Aronsky wrote: > Apologies for maybe a wild or off-topic question. > After dealing with quite a few products with busybox and its ash shell used > as the primary scripting language, I'd like to ask you, busybox experts: > what are

Re: [RFC 1/2] Add hidden option FEATURE_HAVE_SEAMLESS_COMPRESSION

On Tue, Mar 14, 2017 at 1:42 AM, Denys Vlasenko wrote: > Sorry about the delay. > > This change make future entries in config affect the past. > In menuconfig, this makes items in module submenu affect > items in archival submenu. This does not feel right. My intention

Re: kill builtin in ash might behave like killall

On 03/03/2017 01:01 PM, Emmanuel Deloget wrote: > > Hello, > > I'm using BB 1.26.2 with an heavily modified LEDE where I added > procps-ng and sysvinit. Given that setup, I'm using /usr/bin/kill from > props-ng and killall5 from sysvinit, meaning that I have the following > configuration: > > #

Fwd: Busybox fails to build on my Pentium 133MHz

(Resent the mail in order to CC to the mailing list) On 26 February 2017 23:40:49 CET, "Gunner C. Hooper" wrote: >I built static busybox on a Pentium III to run on my Pentium 133MHz >with >64MB of RAM. It runs perfectly on the Pentium III, but when I try to >run

  1   2   >