warning: label 'out1' defined but not used
I'm seeing this warning: shell/ash.c: In function 'subevalvar': shell/ash.c:7280:2: warning: label 'out1' defined but not used [-Wunused-label] 7280 | out1: | ^~~~ It appears this patch: diff --git a/shell/ash.c b/shell/ash.c index d1ca3451d..8c9a590d1 100644 --- a/shell/ash.c +++ b/shell/ash.c @@ -7277,7 +7277,9 @@ subevalvar(char *start, char *str, int strloc, out: amount = loc - expdest; STADJUST(amount, expdest); +#if BASH_PATTERN_SUBST out1: +#endif /* Remove any recorded regions beyond start of variable */ removerecordregions(startloc); gets rid of it. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: after latest update I see this...
On Sun, 25 Oct 2020, Denys Vlasenko wrote: > > Try now, should be fixed. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
after latest update I see this...
coreutils/od.c: In function 'odoffset': coreutils/od.c:138:20: error: invalid use of incomplete typedef 'FS' 138 | dumper->fshead->nextfu->fmt[TYPE_OFFSET] |^~ coreutils/od.c:139:23: error: invalid use of incomplete typedef 'FS' 139 | = dumper->fshead->nextfs->nextfu->fmt[TYPE_OFFSET] | ^~ CC networking/route.o make[1]: *** [scripts/Makefile.build:197: coreutils/od.o] Error 1 Here, debian unstable, `gcc -v': Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.0-15' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-10-mPxEea/gcc-10-10.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-mPxEea/gcc-10-10.2.0/debian/tmp-gcn/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.0 (Debian 10.2.0-15) Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Some issues in examples/udhcp/simple.script
On Thu, 5 Sep 2019, Rolf Eike Beer wrote: > > Busybox ash: > > # command ip > -sh: command: not found > # ip a > 1: lo: mtu 65536 qdisc noqueue qlen 1000 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 You're probably missing: CONFIG_ASH_CMDCMD=y in your .config. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: sed in-place write unsafe (was: Power-fail safe writes)
On Wed, 3 Apr 2019, Denys Vlasenko wrote: > On Wed, Apr 3, 2019 at 12:07 PM Cristian Ionescu-Idbohrn > wrote: > > > > Denys, > > > > On Tue, 2 Apr 2019, Sebastian Brand wrote: > > > > > > I recently had problems when updating a configuration file using sed > > > with in-place edit option (-i), shortly followed by a power fail, > > > which has the end result of an empty configuration file and a system > > > that won't boot. > > > The reason behind this is me relying on sed and sed in-place editing > > > not using a power-fail safe write pattern (copy, edit copy, > > > synchronize copy, rename, synchronize folder). > > > > I'd be interested in your comment about this patch, which fsyncs the > > created temporary file and the directory (after rename) before it's > > done. Any chance it can end up in upstream busybox in this form or > > another? > > Attempts to fix such problems via fsync'ing in generic utilities > usually don't work out long term - this causes performance regressions > when someone wants e.g. to process 6 files. True. > Trying to convince thousands of userspace developers > that they are not careful enough with fsync'ing is futile: > a lot of them will still be not careful enough. Also true. > ext4 developers were eventually convinced to change fs code > so that the usual "write new file + rename over old one" > is reliable wrt power failure: rename implies fsync, > and rename either succeeds completely, or does not > happen at all. Yes. > I take it, your filesystem is not doing that? Ubifs. Appears upstream does not seem interested of fixing it, yet. > I propose, for modification of config files, > to use a wrapper script around sed, > which directs sed result into a new file, > then sync's new file, then renames it over old file, > then sync's the directory. Your comments are appreciated. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
sed in-place write unsafe (was: Power-fail safe writes)
Denys, On Tue, 2 Apr 2019, Sebastian Brand wrote: > > I recently had problems when updating a configuration file using sed > with in-place edit option (-i), shortly followed by a power fail, > which has the end result of an empty configuration file and a system > that won't boot. > The reason behind this is me relying on sed and sed in-place editing > not using a power-fail safe write pattern (copy, edit copy, > synchronize copy, rename, synchronize folder). I'd be interested in your comment about this patch, which fsyncs the created temporary file and the directory (after rename) before it's done. Any chance it can end up in upstream busybox in this form or another? Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Power-fail safe writes
On Tue, 2 Apr 2019, Denys Vlasenko wrote: > On Tue, Apr 2, 2019 at 11:55 AM Cristian Ionescu-Idbohrn > wrote: > > > > On Tue, 2 Apr 2019, Sebastian Brand wrote: > > > > > > I recently had problems when updating a configuration file using sed > > > with in-place edit option (-i), shortly followed by a power fail, > > > which has the end result of an empty configuration file and a system > > > that won't boot. > > > The reason behind this is me relying on sed and sed in-place editing > > > not using a power-fail safe write pattern (copy, edit copy, > > > synchronize copy, rename, synchronize folder). > > > I have locally written a feature to enable "safe write" for sed, but > > > since this is a problem for many flash filesystems there might be > > > more people interested in this? (Perhaps especially people using > > > Busybox for embedded systems?) And this is probably not only > > > relevant for sed? > > > > > > There is also a part 2 that arises when trying to "manually" do a > > > safe write: since the fsync applet uses the O_NOATIME flag it is > > > impossible for user1:group1 to synchronize a directory owned by > > > user2:group1 (you get an "Operation not permitted" error from > > > fsync). Is this intended? (Using gnu sync [8.26] and synchronizing > > > on a specific folder works for the same situation.) > > > > GNU sync command is doing this on a file: > > > > , > > | openat(AT_FDCWD, "/tmp/foo/bar", O_RDONLY|O_NONBLOCK) = 3 > > | fcntl(3, F_GETFL) = 0x8800 (flags > > O_RDONLY|O_NONBLOCK|O_LARGEFILE) > > | fcntl(3, F_SETFL, O_RDONLY|O_LARGEFILE) = 0 > > | fsync(3)= 0 > > | close(3)= 0 > > ` > > > > and this on a directory: > > > > , > > | openat(AT_FDCWD, "/tmp/foo", O_RDONLY|O_NONBLOCK) = 3 > > | fcntl(3, F_GETFL) = 0x8800 (flags > > O_RDONLY|O_NONBLOCK|O_LARGEFILE) > > | fcntl(3, F_SETFL, O_RDONLY|O_LARGEFILE) = 0 > > | fsync(3)= 0 > > | close(3)= 0 > > ` > > > > Note, no O_NOATIME. > > > > namei.c:/* O_NOATIME can only be set by the owner or superuser */ > > ^ > > namei.c:if (flag & O_NOATIME && !inode_owner_or_capable(inode)) > > namei.c-return -EPERM; > > > I removed NOATIME in git just now. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Power-fail safe writes
On Tue, 2 Apr 2019, Sebastian Brand wrote: > > I recently had problems when updating a configuration file using sed > with in-place edit option (-i), shortly followed by a power fail, > which has the end result of an empty configuration file and a system > that won't boot. > The reason behind this is me relying on sed and sed in-place editing > not using a power-fail safe write pattern (copy, edit copy, > synchronize copy, rename, synchronize folder). > I have locally written a feature to enable "safe write" for sed, but > since this is a problem for many flash filesystems there might be > more people interested in this? (Perhaps especially people using > Busybox for embedded systems?) And this is probably not only > relevant for sed? > > There is also a part 2 that arises when trying to "manually" do a > safe write: since the fsync applet uses the O_NOATIME flag it is > impossible for user1:group1 to synchronize a directory owned by > user2:group1 (you get an "Operation not permitted" error from > fsync). Is this intended? (Using gnu sync [8.26] and synchronizing > on a specific folder works for the same situation.) GNU sync command is doing this on a file: , | openat(AT_FDCWD, "/tmp/foo/bar", O_RDONLY|O_NONBLOCK) = 3 | fcntl(3, F_GETFL) = 0x8800 (flags O_RDONLY|O_NONBLOCK|O_LARGEFILE) | fcntl(3, F_SETFL, O_RDONLY|O_LARGEFILE) = 0 | fsync(3)= 0 | close(3)= 0 ` and this on a directory: , | openat(AT_FDCWD, "/tmp/foo", O_RDONLY|O_NONBLOCK) = 3 | fcntl(3, F_GETFL) = 0x8800 (flags O_RDONLY|O_NONBLOCK|O_LARGEFILE) | fcntl(3, F_SETFL, O_RDONLY|O_LARGEFILE) = 0 | fsync(3)= 0 | close(3)= 0 ` Note, no O_NOATIME. namei.c:/* O_NOATIME can only be set by the owner or superuser */ ^ namei.c:if (flag & O_NOATIME && !inode_owner_or_capable(inode)) namei.c-return -EPERM; Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash builtin function `read' called without arguments...
On Mon, 11 Feb 2019, Denys Vlasenko wrote: > On Sat, Feb 9, 2019 at 5:10 PM Cristian Ionescu-Idbohrn > wrote: > > > > On Sat, 9 Feb 2019, Denys Vlasenko wrote: > > > On Wed, Jan 30, 2019 at 2:09 PM Cristian Ionescu-Idbohrn > > > wrote: > > > > ...sets implicit variable REPLY, even though ASH_BASH_COMPAT is not > > > > set. > > > > > > > > That was introduced in 2010-01-12 with commit > > > > 045f4ad92c07434625e168bc8c37aa0e89f6e58e. The comment is still > > > > present in the code: > > > > > > > > + /* $IFS splitting. NOT done if we run "read" > > > > +* without variable names (bash compat). > > > > +* Thus, "read" and "read REPLY" are not the same. > > > > +*/ > > > > > > > > Still, this is a bashism and should be tested with IF_ASH_BASH_COMPAT. > > > > > > > > Dash does not support that: > > > > > > > > $ read > > > > dash: 1: read: arg count > > > > > > > > and The Open Group Base Specifications Issue 6 does not document that > > > > behaviour. > > > > > > > > Yes, I suspect the "feature" may be already abused. > > > > > > > > What do you think? > > > > > > Correctly testing for ASH_BASH_COMPAT *and* HUSH_BASH_COMPAT > > > is tricky. I can think on of disabling "bashism" behavior > > > in case both options are off. > > > But is it worth the trouble? > > > > IMO, yes. There might be other opinions. RFC. Let's wait. > > > > In my case (at work), I have to watch and prevent people from doing > > unportable things. For me, that's a burden. > > ash.c readcmd(): > params.argv = argptr; > > hush.c builtin_read(c): > params.argv = argv; > > We can add a "params.argv[0] == NULL" test after these lines, > emit error message if it is and bash compat is off. That sounds like a good idea. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash builtin function `read' called without arguments...
On Sat, 9 Feb 2019, Denys Vlasenko wrote: > On Wed, Jan 30, 2019 at 2:09 PM Cristian Ionescu-Idbohrn > wrote: > > ...sets implicit variable REPLY, even though ASH_BASH_COMPAT is not > > set. > > > > That was introduced in 2010-01-12 with commit > > 045f4ad92c07434625e168bc8c37aa0e89f6e58e. The comment is still > > present in the code: > > > > + /* $IFS splitting. NOT done if we run "read" > > +* without variable names (bash compat). > > +* Thus, "read" and "read REPLY" are not the same. > > +*/ > > > > Still, this is a bashism and should be tested with IF_ASH_BASH_COMPAT. > > > > Dash does not support that: > > > > $ read > > dash: 1: read: arg count > > > > and The Open Group Base Specifications Issue 6 does not document that > > behaviour. > > > > Yes, I suspect the "feature" may be already abused. > > > > What do you think? > > Correctly testing for ASH_BASH_COMPAT *and* HUSH_BASH_COMPAT > is tricky. I can think on of disabling "bashism" behavior > in case both options are off. > But is it worth the trouble? IMO, yes. There might be other opinions. RFC. Let's wait. In my case (at work), I have to watch and prevent people from doing unportable things. For me, that's a burden. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
ash builtin function `read' called without arguments...
...sets implicit variable REPLY, even though ASH_BASH_COMPAT is not set. That was introduced in 2010-01-12 with commit 045f4ad92c07434625e168bc8c37aa0e89f6e58e. The comment is still present in the code: + /* $IFS splitting. NOT done if we run "read" +* without variable names (bash compat). +* Thus, "read" and "read REPLY" are not the same. +*/ Still, this is a bashism and should be tested with IF_ASH_BASH_COMPAT. Dash does not support that: $ read dash: 1: read: arg count and The Open Group Base Specifications Issue 6 does not document that behaviour. Yes, I suspect the "feature" may be already abused. What do you think? Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: printf can't handle the '+' char in front of an integer
On Fri, 19 Oct 2018, Bernhard Reutner-Fischer wrote: > > right. Also "%d" ' 42' was moaning about the leading whitespace. > 3db4e7f84cf795de8559ea0d96eaa491999ccf24 > Thanks for mentioning! Thanks. -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
printf can't handle the '+' char in front of an integer
The documentation on this page: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html (search for 'ISO/IEC 646:1991') shows this example: printf "%d\n" 3 +3 -3 \'3 \"+3 "'-3" busybox ash can't handle the '+3' argument (tested with v1.30.0.git, v1.27.2 and v1.22.1): $ printf "%d\n" +3 ash: invalid number '+3' 0 dash v0.5.10.2 can: $ printf "%d\n" +3 3 Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
warnings with latest master
This is with: $ gcc --version gcc (Debian 8.2.0-6) 8.2.0 shell/ash.c: In function 'wait_block_or_sig': shell/ash.c:4216:35: warning: passing argument 3 to restrict-qualified parameter aliases with argument 2 [-Wrestrict] sigprocmask(SIG_SETMASK, , ); shell/hush.c: In function 'wait_for_child_or_signal': shell/hush.c:11429:37: warning: passing argument 3 to restrict-qualified parameter aliases with argument 2 [-Wrestrict] sigprocmask(SIG_SETMASK, , ); networking/inetd.c: In function 'block_CHLD_HUP_ALRM': networking/inetd.c:491:2: warning: passing argument 3 to restrict-qualified parameter aliases with argument 2 [-Wrestrict] sigprocmask(SIG_BLOCK, m, m); /* old sigmask is stored in m */ procps/powertop.c: In function 'read_cstate_counts': procps/powertop.c:181:20: warning: '%s' directive writing up to 255 bytes into a region of size 171 [-Wformat-overflow=] sprintf(buf, "%s/%s/power", "/proc/acpi/processor", d->d_name); ^~ procps/powertop.c:181:3: note: 'sprintf' output between 28 and 283 bytes into a destination of size 192 sprintf(buf, "%s/%s/power", "/proc/acpi/processor", d->d_name); util-linux/mdev.c: In function 'fileAction': util-linux/mdev.c:834:25: warning: passing argument 2 to restrict-qualified parameter aliases with argument 1 [-Wrestrict] res = readlink(subsys, subsys, sizeof(subsys)-1); libbb/lineedit.c: In function 'read_line_input': libbb/lineedit.c:2422:43: warning: passing argument 3 to restrict-qualified parameter aliases with argument 2 [-Wrestrict] sigaction(SIGWINCH, _handler, _handler); Thoughts? Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
build failure if CONFIG_FLOAT_DURATION is not set
# CONFIG_FLOAT_DURATION is not set CC libbb/duration.o libbb/duration.c: In function 'parse_duration_str': libbb/duration.c:76:26: error: 'argv' undeclared (first use in this function) return xatou_range_sfx(*argv, 0, UINT_MAX, duration_suffixes); ^~~~ libbb/duration.c:76:26: note: each undeclared identifier is reported only once for each function it appears in libbb/duration.c:74:47: warning: unused parameter 'str' [-Wunused-parameter] duration_t FAST_FUNC parse_duration_str(char *str) ~~^~~ libbb/duration.c:77:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ make[1]: *** [scripts/Makefile.build:198: libbb/duration.o] Error 1 make: *** [Makefile:743: libbb] Error 2 Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
I keep seing this...
Since a while back, with: $ gcc --version gcc (Debian 7.2.0-12) 7.2.1 20171025 procps/powertop.c: In function 'read_cstate_counts': procps/powertop.c:181:20: warning: '%s' directive writing up to 255 bytes into a region of size 171 [-Wformat-overflow=] sprintf(buf, "%s/%s/power", "/proc/acpi/processor", d->d_name); ^~ procps/powertop.c:181:3: note: 'sprintf' output between 28 and 283 bytes into a destination of size 192 sprintf(buf, "%s/%s/power", "/proc/acpi/processor", d->d_name); Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: tr: trying to find the right incantation of a character class...
On Tue, 29 Aug 2017, Olivier Brunel wrote: > On Tue, 29 Aug 2017 19:23:39 +0200 (CEST) > Cristian Ionescu-Idbohrn <cristian.ionescu-idbo...@axis.com> wrote: > > > ...to do this: > > > > $ echo 'hello world-1' | tr -d '[ -]' > > > > that is, remove all SPACES (0x20) and dashes (0x2D) in input? I get > > echo 'hello world-1' | tr -d -- ' -' > > > mixed results with both various versions of busybox but also with the > > coreutils `tr' and the characters order placed in the character class. > > > > `man 7 regex' is telling us: > > SETs in tr(1) aren't actually regex, so this doesn't apply. As shown > above, simply list the characters you wanna delete. > > `man tr` tells us: > > SETs are specified as strings of characters. Most > represent themselves. Thanks a lot for putting me on the right track ;) Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
tr: trying to find the right incantation of a character class...
...to do this: $ echo 'hello world-1' | tr -d '[ -]' that is, remove all SPACES (0x20) and dashes (0x2D) in input? I get mixed results with both various versions of busybox but also with the coreutils `tr' and the characters order placed in the character class. `man 7 regex' is telling us: To include a literal '-', make it the first or last character, or the second end-point of a range. To use a literal '-' as the first endpoint of a range, enclose it in "[." and ".]" to make it a collating element (see below). To use a literal '-' as the first endpoint of a range, enclose it in "[." and ".]" to make it a collating element (see below). With the exception of these and some combinations using '[' (see next paragraphs), all other special characters, including '\', lose their special significance within a bracket expression. and so on. So, I could list a few unintuitive character classes that would produce unintuitive results, with both coreutils `tr' and busybox `tr'. What is the correct incantation that would always work as expected? Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
warning: this 'if' clause does not guard...
coreutils/factor.c: In function 'factor_main': coreutils/factor.c:204:5: warning: this 'if' clause does not guard... [-Wmisleading-indentation] if (*end != '\0'); ^~ coreutils/factor.c:205:6: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if' *end++ = '\0'; Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
recipe for target 'libbb/securetty.o' failed
On current master:
libbb/securetty.c:9:15: error: redefinition of 'is_tty_secure'
int FAST_FUNC is_tty_secure(const char *short_tty)
^
In file included from libbb/securetty.c:7:0:
include/libbb.h:1487:26: note: previous definition of 'is_tty_secure' was here
static ALWAYS_INLINE int is_tty_secure(const char *short_tty UNUSED_PARAM) {
return 1; }
^
CC libbb/str_tolower.o
scripts/Makefile.build:197: recipe for target 'libbb/securetty.o' failed
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] unzip: avoid warning on unused variable org
archival/unzip.c: In function 'read_next_cdf':
archival/unzip.c:271:8: warning: variable 'org' set but
not used [-Wunused-but-set-variable]
off_t org;
^~~
Signed-off-by: Cristian Ionescu-Idbohrn <cristian.ionescu-idbo...@axis.com>
---
archival/unzip.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/archival/unzip.c b/archival/unzip.c
index f1726439d..856abce36 100644
--- a/archival/unzip.c
+++ b/archival/unzip.c
@@ -268,13 +268,13 @@ static uint32_t find_cdf_offset(void)
static uint32_t read_next_cdf(uint32_t cdf_offset, cdf_header_t *cdf_ptr)
{
- off_t org;
+ /* off_t org; */
uint32_t magic;
if (cdf_offset == BAD_CDF_OFFSET)
return cdf_offset;
- org = xlseek(zip_fd, 0, SEEK_CUR);
+ /* org = xlseek(zip_fd, 0, SEEK_CUR); */
dbg("Reading CDF at 0x%x", (unsigned)cdf_offset);
xlseek(zip_fd, cdf_offset, SEEK_SET);
xread(zip_fd, , 4);
--
2.11.0
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] appletlib: avoid warning on unused function ingroup
libbb/appletlib.c:558:12: warning: 'ingroup' defined but
not used [-Wunused-function]
static int ingroup(uid_t u, gid_t g)
^~~
That function is used only if FEATURE_SUID_CONFIG is also enabled.
Signed-off-by: Cristian Ionescu-Idbohrn <cristian.ionescu-idbo...@axis.com>
---
libbb/appletlib.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libbb/appletlib.c b/libbb/appletlib.c
index ee8b4ec14..805cd3ae6 100644
--- a/libbb/appletlib.c
+++ b/libbb/appletlib.c
@@ -554,6 +554,7 @@ static inline void parse_config_file(void)
# if ENABLE_FEATURE_SUID && NUM_APPLETS > 0
+# if ENABLE_FEATURE_SUID_CONFIG
/* check if u is member of group g */
static int ingroup(uid_t u, gid_t g)
{
@@ -568,6 +569,7 @@ static int ingroup(uid_t u, gid_t g)
}
return 0;
}
+# endif
static void check_suid(int applet_no)
{
--
2.11.0
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: Shell script silently exits. Why?
On Tue, 29 Nov 2016, Pavel A wrote: > > Is it possible to test for active option within ash script? > My version of ash does not seem to recognize "test -o" or [ -o errexit ] To test on errexit you'd do something like: case $- in *e*) echo errexit set ;; *) echo errexit not set ;; esac The $- thing: Special Parameters - (Hyphen.) Expands to the current option flags (the single-letter option names concatenated into a string) as specified on invocation, by the set builtin command, or implicitly by the shell. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: # CONFIG_BUSYBOX is not set: breakage on master
On Mon, 29 Aug 2016, Denys Vlasenko wrote: > > Yes, it is intended too. Alright. > Propose a change to the help text of this option which would > make it clearer. Well, something along these lines: "Disabling this will remove the banner and applet list text when running the busybox command without options or with options '--help', '--list[-full]'. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
playing around with allyesconfig on current master
At commit d3d7f085ebf2898b62d4bb75566122c65be96454. First CONFIG_SELINUX=y, and then: Package libselinux was not found in the pkg-config search path. Perhaps you should add the directory containing `libselinux.pc' to the PKG_CONFIG_PATH environment variable No package 'libselinux' found Package libsepol was not found in the pkg-config search path. Perhaps you should add the directory containing `libsepol.pc' to the PKG_CONFIG_PATH environment variable No package 'libsepol' found Easy to avoid that with '# CONFIG_SELINUX is not set'. Seems `pkg-config --exists --print-errors' is already run. Then why not show the messages but generate .config with "# CONFIG_SELINUX is not set'? Next. allyesconfig sets the default shell CONFIG_HUSH=y and: shell/hush.c:1334:13: error: 'close_all_FILE_list' defined but not used [-Werror=unused-function] static void close_all_FILE_list(void) Alright, let's change to ash. `make menuconfig' -> Shells. But ash is not on the list. Something to do with "Depends on: !NOMMU"? Yes. Deselect Busybox Settings -> Build Options -> Force NOMMU build. Ash is now a visible option. Make it the default shell too. In file included from util-linux/fdisk.c:641:0: util-linux/fdisk_osf.c: In function 'bsd_select': util-linux/fdisk_osf.c:364:6: error: implicit declaration of function 'partname' [-Werror=implicit-function-declaration] partname(disk_device, t+1, 0)); ^~~~ util-linux/fdisk.c: At top level: util-linux/fdisk.c:2062:1: error: conflicting types for 'partname' partname(const char *dev, int pno, int lth) ^~~~ In file included from util-linux/fdisk.c:641:0: util-linux/fdisk_osf.c:364:6: note: previous implicit declaration of 'partname' was here partname(disk_device, t+1, 0)); ^~~~ Let's disable "Support BSD disklabels". In file included from util-linux/fdisk.c:680:0: util-linux/fdisk_sgi.c: In function 'sgi_list_table': util-linux/fdisk_sgi.c:329:25: error: implicit declaration of function 'partnam' [-Werror=implicit-function-declaration] /* device */partname(disk_device, kpi, w+3), ^~~~ util-linux/fdisk.c: At top level: util-linux/fdisk.c:2062:1: error: conflicting types for 'partname' partname(const char *dev, int pno, int lth) ^~~~ In file included from util-linux/fdisk.c:680:0: util-linux/fdisk_sgi.c:329:25: note: previous implicit declaration of 'partname' was here /* device */partname(disk_device, kpi, w+3), Let's disable "Support SGI disklabels" too. In file included from util-linux/fdisk.c:698:0: util-linux/fdisk_sun.c: In function 'sun_list_table': util-linux/fdisk_sun.c:661:5: error: implicit declaration of function 'partname' [-Werror=implicit-function-declaration] partname(disk_device, i+1, w), /* device */ ^~~~ util-linux/fdisk.c: At top level: util-linux/fdisk.c:2062:1: error: conflicting types for 'partname' partname(const char *dev, int pno, int lth) ^~~~ In file included from util-linux/fdisk.c:698:0: util-linux/fdisk_sun.c:661:5: note: previous implicit declaration of 'partname' was here partname(disk_device, i+1, w), /* device */ Disable "Support SUN disklabels". gcc: error: cannot specify -static with -fsanitize=address Note: if build needs additional libraries, put them in CONFIG_EXTRA_LDLIBS. Example: CONFIG_EXTRA_LDLIBS="pthread dl tirpc audit pam" Makefile:717: recipe for target 'busybox_unstripped' failed Disable Busybox Settings -> Build Options -> Build BusyBox as a static binary (no shared libs). Finally, it builds and runs. I'm not making any suggestions, but the HUSH and the STATIC may be real bugs. "Support (odd) disklabels" disabled per default may also simplify for many/most of the user base. Default CONFIG_NOMMU=y, I have no idea how common that is today. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: # CONFIG_BUSYBOX is not set: breakage on master
On Sat, 27 Aug 2016, Denys Vlasenko wrote: > > This thing is meant for people who are in real squeeze and don't want > any more functionality than they absolutely must have. > > If they configured 20 applets they need and they prepare their filesystem > so that the /bin/foo -> /bin/busybox links are created by means > other than busybox --install, they don't need the code which says this: > > BusyBox is copyrighted by many authors between 1998-2015. > Licensed under GPLv2. See source distribution for detailed > copyright notices. > > Usage: busybox [function [arguments]...] >or: busybox --list[-full] >or: busybox --install [-s] [DIR] >or: function [arguments]... > > BusyBox is a multi-call binary that combines many common Unix > utilities into a single executable. Most people will create a > link to busybox for each function they wish to use and BusyBox > will act like whatever it was invoked as. > > It's just useless bloat for them. Now they can switch it off. Got it, thanks. But it's not only that text that's removed. The "Currently defined functions:" list is also gone, as well as the one-applet-per-line list. I do understand those might be considered bloat too, but that was not intuitive for me. > OTOH, you do want that code to be present. Thus, please turn > CONFIG_BUSYBOX=y. Yes, we can ;) Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: # CONFIG_BUSYBOX is not set: breakage on master
On Sat, 27 Aug 2016, Michael Conrad wrote: > On 8/27/2016 2:18 AM, Cristian Ionescu-Idbohrn wrote: > > On Sat, 27 Aug 2016, Denys Vlasenko wrote: > > > config BUSYBOX > > > bool "Include busybox applet" > > > default y > > > help > > >The busybox applet provides general help regarding busybox and > > >allows the included applets to be listed. It's also required > > >if applet links are to be installed at runtime. > > > > > >If you can live without these features disabling this will save > > >some space. > > And this is also expected: > > > > $ ./busybox > > busybox: applet not found > > > > when executed immediately after build? And this too? > > > > $ ./busybox --help > > -help: applet not found > > > > $ ./busybox --list > > -list: applet not found > > Yes, adding or removing those behaviors is precisely the purpose of > the CONFIG_BUSYBOX setting. Is it? I didn't realize that and I still don't :( > Maybe you should explain your situation and what you expected? > because a person reading your subject line would assume you are > trying to say "I compiled busybox without the CONFIG_BUSYBOX flag, > and now I'm surprised that it did what it said it would do"... Alright. My bad. I'll go back and read the ML... So, I went back and re-read the "Make busybox an applet" threads where "turn off help and list of applets" is mentioned. On Tue, 31 May 2016, Ron Yorston wrote: | | This doesn't make busybox an applet, it just makes it possible to turn | off help and list of applets. | | I'm not really interested in that: I wanted busybox to be an actual | applet to avoid having to treat it as a special case in standalone | shell mode. | | If busybox is a real applet there's no need for FEATURE_SHARED_BUSYBOX | because FEATURE_INDIVIDUAL will make a busybox binary along with those | for all the other applets. And my understandig now is that if CONFIG_BUSYBOX=y, the '--help', '--list' and '--list-full' options are removed, and at the same time adds about 900 bytes to the binary. I may be thick, but what I still don't understand is what benefits does that bring? Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: # CONFIG_BUSYBOX is not set: breakage on master
On Sat, 27 Aug 2016, Denys Vlasenko wrote: > On Fri, Aug 26, 2016 at 11:33 PM, Cristian Ionescu-Idbohrn > <cristian.ionescu-idbo...@axis.com> wrote: > > $ ./busybox > > busybox: applet not found > > > > $ gcc --version > > gcc (Debian 6.2.0-1) 6.2.0 20160822 > > > > That's debian unstable. > > > > Everything since commit 877dedb seems broken. > > It's not a bug, it's a feature Really? > config BUSYBOX > bool "Include busybox applet" > default y > help > The busybox applet provides general help regarding busybox and > allows the included applets to be listed. It's also required > if applet links are to be installed at runtime. > > If you can live without these features disabling this will save > some space. And this is also expected: $ ./busybox busybox: applet not found when executed immediately after build? And this too? $ ./busybox --help -help: applet not found $ ./busybox --list -list: applet not found Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
# CONFIG_BUSYBOX is not set: breakage on master
$ ./busybox busybox: applet not found $ gcc --version gcc (Debian 6.2.0-1) 6.2.0 20160822 That's debian unstable. Everything since commit 877dedb seems broken. fails on master, commit e4caf1d with: # CONFIG_BUSYBOX is not set ok with: CONFIG_BUSYBOX=y Problem seems to have been introduced on master with commit 8e95068: Include busybox applet (BUSYBOX) [Y/n/?] (NEW) ok with: CONFIG_BUSYBOX=y fails with: # CONFIG_BUSYBOX is not set $ ./busybox busybox: applet not found Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Bug in ash alias handing ?
On Sat, 25 Jun 2016, Walter Harms wrote: > On Fri, 24 Jun 2016, Walter Harms wrote: > >Try: > > >alias idt='grep -o -E "\\\$Id:[^$]+."' > > great. works for me ! > > you changed roles of ' and " , ok. Yes. Do not expand anything when setting the alias. Expand when executing. > But why the \\\ double escape for $ but not in the [^$] ? When executing, the '\\' expands to '\' and '\$' to '$'. Thus, at execution time, you get '\$' which is what you want. Class '[^$]' is special. No escaping needed. Regexp:s. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Bug in ash alias handing ?
On Fri, 24 Jun 2016, Walter Harms wrote: > > i tried to make this little gem grep -o -E '\$Id:[^\$]+.' into an alias > for ash in the latest busybox version. > > alias idt="grep -o -E '\$Id:[^\$]+.'" > > but the result was always a non working alias > I tried various escapes but nothing worked. > > does someone has a solution ? Try: alias idt='grep -o -E "\\\$Id:[^$]+."' Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] common_bufsiz: ignore generated files
On Sun, 24 Apr 2016, Denys Vlasenko wrote: > > I added /common_bufsiz.h* (there can be more generated files > matching that pattern). Let me know if it doesn't do the trick I just happen to use `git-sh-prompt' (which comes with the debian git package (/usr/lib/git-core/git-sh-prompt)) to reveals such things instantly. $ git status will tell, but that's fine for now. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] common_bufsiz: ignore generated files
Signed-off-by: Cristian Ionescu-Idbohrn <cristian.ionescu-idbo...@axis.com> --- include/.gitignore | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/.gitignore b/include/.gitignore index 9d9b6c4..e512886 100644 --- a/include/.gitignore +++ b/include/.gitignore @@ -5,6 +5,8 @@ /autoconf.h /bbconfigopts_bz2.h /bbconfigopts.h +/common_bufsiz.h +/common_bufsiz.h.method /NUM_APPLETS.h /usage_compressed.h /usage.h -- 2.8.1 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
two new generated files to be ignored?
$ git status On branch master Your branch is up-to-date with 'origin/master'. Untracked files: (use "git add ..." to include in what will be committed) include/common_bufsiz.h include/common_bufsiz.h.method nothing added to commit but untracked files present (use "git add" to track) Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: busybox sed, 'r' command
On Thu, 24 Mar 2016, Ron Yorston wrote: > > and specifically about 'r': > >If rfile does not exist or cannot be read, it shall be treated as if >it were an empty file, causing no error condition. My observation, looking at the strace from GNU sed, is it attempts to open a file with no/empty name and fails, but ignores the error. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: *FLAWED* Re: busybox sed, 'r' command
On Wed, 23 Mar 2016, Ralf Friedl wrote:
>
> On the other hand, I don't know why busybox sed needs exactly one space
> between command and filename. GNU sed works with zero or more spaces.
Good points, everyone. Thanks. Still...
# Note, the input file /tmp/bar lacks the on the last line
# simplified
GNU sed ignores open failure on not specified/not existing file:
$ strace sed 'r' /tmp/bar
open("/tmp/bar", O_RDONLY|O_LARGEFILE) = 3
read(3, "foo\nbar\nbaz", 4096) = 11
write(1, "foo\n", 4foo
)= 4
open("", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
write(1, "bar\n", 4bar
)= 4
open("", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
read(3, "", 4096) = 0
write(1, "baz\n", 4baz
)= 4
open("", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
read(3, "", 4096) = 0
close(3)= 0
busybox sed reports an error:
$ strace busybox sed 'r' /tmp/bar
write(2, "sed: empty filename\n", 20sed: empty filename
) = 20
Arguably, this may look like a bug in GNU sed, or intentional
behaviour?
# Let's do a more reasonable test.
$ sed -n '1,$p' /tmp/bar | cat -E
foo$
bar$
baz
^
Note the missing char on the last line.
$ busybox sed -n '1,$p' /tmp/bar | cat -E
foo$
bar$
baz$
^
There's a char on the last line.
Which is at fault here? I would say both (with reservations).
But obviously, non-determinism.
$ f=/tmp/bar && cat $f && [ -z "$(tail -c1 $f)" ] || echo
and:
$ f=/tmp/bar && cat $f && tail -c1 $f | read __ || echo
work, but they look more convoluted to me.
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: busybox sed, 'r' command
On Wed, 23 Mar 2016, Ron Yorston wrote: > > Since the 'r' command requires a space before the filename it will need > to be quoted. Some of your examples have quotes and some don't so you > aren't always comparing the same thing. Right. Still. The different behaviour confused me. > "sed r -" is an 'r' command with no filename while the "sed 'r -'" is an > 'r' command with a filename of '-'. It appears that GNU sed and BusyBox > sed handle an 'r' command with no filename differently. Yes. That seems to be it. Question is if busybox sed should mimic GNU sed behaviour or not. The current GNU sed behaviour might be seen upon as a bug. But it's been like that for ages. Maybe it's a bug upstream wants to keep for historical reasons? > Also note that printf doesn't issue a newline at the end of the string. > This can affect the results. Yes, that was intentional. A file that lacks a at the end of the last line, passing through: $ sed r enforces proper line termination on last line. I know there's other cludge that can achieve the same thing. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
busybox sed, 'r' command
sed (GNU sed) 4.2.2 can do this: $ printf 'foo bar baz' | sed r - foo bar baz or, after storing the text in a file: $ printf 'foo bar baz' >/tmp/bar $ sed r /tmp/bar foo bar baz But busybox sed can't: $ printf 'foo bar baz' | busybox sed r - sed: empty filename $ busybox sed r /tmp/bar sed: empty filename $ printf '' | busybox sed 'r /tmp/bar' $ busybox sed 'r /tmp/bar' The 'r' command is documented by GNU sed as a GNU extension. Still, busybox sed documents the 'r' command as supported: r [address]r file Read contents of file and append after the contents of the pattern space. Exactly one space must be put between r and the filename. Am I misinterpreting the documentation? Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Remove a compilation warning
On Fri, 1 Jan 2016, Rich Felker wrote: > On Fri, Jan 01, 2016 at 02:44:25PM -0500, Jody Bruchon wrote: > > How about putting the left side in parentheses to silence the > > warning instead of turning the warning off completely? > > My point was that the parentheses make the code less readable, not > more readable, and that nobody would reasonably mistake the operator > precedence in this case or in any case reported by > -Wlogical-not-parentheses. It's a bogus warning. Whatever. Pick your fight. Upstream isn't me ;) Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] Remove a compilation warning
Reported by gcc (Debian 5.3.1-4) 5.3.1 20151219
shell/ash.c: In function 'evaltree':
shell/ash.c:8432:19: warning: logical not is only applied to the left hand side
of comparison [-Wlogical-not-parentheses]
if (!exitstatus == is_or)
^
Signed-off-by: Cristian Ionescu-Idbohrn <cristian.ionescu-idbo...@axis.com>
---
shell/ash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/shell/ash.c b/shell/ash.c
index e7a867f..daec975 100644
--- a/shell/ash.c
+++ b/shell/ash.c
@@ -8429,7 +8429,7 @@ evaltree(union node *n, int flags)
n->nbinary.ch1,
(flags | ((is_or >> 1) - 1)) & EV_TESTED
);
- if (!exitstatus == is_or)
+ if ((!exitstatus) == is_or)
break;
if (!evalskip) {
n = n->nbinary.ch2;
--
2.6.4
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: Help needed in disabling busybox configuration for linux hardening requirement.
On Fri, 9 Oct 2015, purushi1 . wrote: > > We want to disable CONFIG_BRCTL, CONFIG_FEATURE_BRCTL_FANCY, > CONFIG_FEATURE_BRCTL_SHOW options in Busybox configuration. Those configuration knobs are used in networking/brctl.c only. > But if we disable these options in busybox configuration. Then we > are getting compilation error in busybox. Would maybe help if you show us the "compilation error". Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: bump: ash variable substitution, quote slash
On Wed, 23 Sep 2015, Bastian Bittorf wrote:
>
> trying to replace a slash in a variable using
> substitution I stumbled over this old thread:
> http://lists.busybox.net/pipermail/busybox/2010-September/073290.html
>
> so basically this does not work (no matter how I escape)
> var='a/c'; echo ${varb}
That looks like a bashism (not portable). Is it this:
${parameter/pattern/string}
you're trying to use? In that case, this:
v=a/c && echo ${v/\//b}
should work for you.
> (should output 'abc')
But you can do that in a portable way too:
v=a/c && echo ${v%%/*}b${v#*/}
(exchange the 1st '/' char in variable v for char 'b')
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: -ash: changed behaviour of local vars / v1.22.1 - v1.23.2
On Thu, 16 Apr 2015, Eugene Rudoy wrote: @Denys: your commit-message states bash does that. bash indeed does so for the test-case from your commit, but doesn't do so for Bastians example (tested with bash 4.1 4.3). I believe if the variable should be unset should depend on its (variables) scope. Even if bash does that, it isn't necessary the right thing to do. I have lots of scripts relying on former behaviour (inherit initial local variable value from the calling scope). The current behaviour is a regression, AFAICT. `dash' does not behave like `bash' either. I guess I'll have to carry a local patch reverting that commit :( Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
nc_bloaty in persistent server mode seems broken
I run it under gdb, something like this:
$ nc -vv -k -p 1234
(yes, the -l option isn't needed, var cnt_l is set to 2).
Then I start a client:
$ echo foo | nc -w1 localhost 1234
I see the server shows the 'foo'. I try to send another one:
$ echo bar | nc -w1 localhost 1234
But that fails, and I notice the server got stuck. ^C it, and:
(gdb) bt full
#0 0x77b11f03 in __select_nocancel ()
at ../sysdeps/unix/syscall-template.S:81
No locals.
#1 0x00402b25 in readwrite () at networking/nc_bloaty.c:626
wretry = 8200
rr = optimized out
zp = 0x0
np = 0x608124
rzleft = 0
rnleft = 0
netretry = 2
fds_open = 1
ding1 = {fds_bits = {1, 0 repeats 15 times}}
ding2 = {fds_bits = {1, 0 repeats 15 times}}
#2 0x0040316a in nc_main (argc=optimized out,
argv=0x7fffe568)
at networking/nc_bloaty.c:914
str_p = 0x7fffe914 1234
str_s = 0x0
str_i = 0x7fffe8f4 busybox_unstripped
str_o = 0x77de9f0c _dl_fixup+508 \017\037@
themdotted = optimized out
proggie = 0x0
x = optimized out
cnt_l = 2
o_lport = optimized out
#3 0x004019f4 in run_applet_no_and_exit (applet_no=0,
argv=argv@entry=0x7fffe540) at libbb/appletlib.c:772
argc = 5
#4 0x00401a1b in run_applet_and_exit (name=0x7fffe907
nc,
argv=argv@entry=0x7fffe540) at libbb/appletlib.c:779
applet = optimized out
#5 0x00401b86 in busybox_main (argv=0x7fffe540)
at libbb/appletlib.c:731
No locals.
#6 run_applet_and_exit (name=optimized out,
argv=argv@entry=0x7fffe538)
at libbb/appletlib.c:781
applet = optimized out
#7 0x00401c11 in main (argc=optimized out,
argv=0x7fffe538)
at libbb/appletlib.c:836
No locals.
.config is:
CONFIG_HAVE_DOT_CONFIG=y
CONFIG_PLATFORM_LINUX=y
CONFIG_FEATURE_BUFFERS_USE_MALLOC=y
CONFIG_SHOW_USAGE=y
CONFIG_FEATURE_VERBOSE_USAGE=y
CONFIG_FEATURE_COMPRESS_USAGE=y
CONFIG_SUBST_WCHAR=0
CONFIG_LAST_SUPPORTED_WCHAR=0
CONFIG_LONG_OPTS=y
CONFIG_PID_FILE_PATH=
CONFIG_BUSYBOX_EXEC_PATH=/proc/self/exe
CONFIG_CROSS_COMPILER_PREFIX=
CONFIG_SYSROOT=
CONFIG_EXTRA_CFLAGS=-g3
CONFIG_EXTRA_LDFLAGS=
CONFIG_EXTRA_LDLIBS=
CONFIG_NO_DEBUG_LIB=y
CONFIG_INSTALL_APPLET_SYMLINKS=y
CONFIG_PREFIX=./_install
CONFIG_PASSWORD_MINLEN=6
CONFIG_MD5_SMALL=1
CONFIG_SHA3_SMALL=1
CONFIG_FEATURE_EDITING_MAX_LEN=0
CONFIG_FEATURE_EDITING_HISTORY=0
CONFIG_FEATURE_COPYBUF_KB=4
CONFIG_GZIP_FAST=0
CONFIG_DEFAULT_SETFONT_DIR=
CONFIG_FEATURE_VI_MAX_LEN=0
CONFIG_FEATURE_VI_UNDO_QUEUE_MAX=0
CONFIG_TELINIT_PATH=
CONFIG_FEATURE_KILL_DELAY=0
CONFIG_INIT_TERMINAL_TYPE=
CONFIG_LAST_ID=0
CONFIG_FIRST_SYSTEM_ID=0
CONFIG_LAST_SYSTEM_ID=0
CONFIG_FEATURE_DEFAULT_PASSWD_ALGO=
CONFIG_DEFAULT_MODULES_DIR=
CONFIG_DEFAULT_DEPMOD_FILE=
CONFIG_FEATURE_CROND_DIR=
CONFIG_FEATURE_LESS_MAXLINES=0
CONFIG_FEATURE_BEEP_FREQ=0
CONFIG_FEATURE_BEEP_LENGTH_MS=0
CONFIG_NC=y
CONFIG_NC_SERVER=y
CONFIG_NC_EXTRA=y
CONFIG_NC_110_COMPAT=y
CONFIG_IFUPDOWN_IFSTATE_PATH=
CONFIG_PSCAN=y
CONFIG_DHCPD_LEASES_FILE=
CONFIG_UDHCP_DEBUG=0
CONFIG_UDHCPC_DEFAULT_SCRIPT=
CONFIG_UDHCPC_SLACK_FOR_BUGGY_SERVERS=0
CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS=
CONFIG_FEATURE_MIME_CHARSET=
CONFIG_SV_DEFAULT_SERVICE_DIR=
CONFIG_FEATURE_SH_IS_NONE=y
CONFIG_FEATURE_BASH_IS_NONE=y
CONFIG_FEATURE_SYSLOGD_READ_BUFFER_SIZE=0
CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=0
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: 1.22.1: been hit by the zcat bug
On Tue, 21 Oct 2014, Cristian Ionescu-Idbohrn wrote: On Tue, 21 Oct 2014, Mike Frysinger wrote: On 21 Oct 2014 20:26, Cristian Ionescu-Idbohrn wrote: On Tue, 21 Oct 2014, Mike Frysinger wrote: On 21 Oct 2014 20:02, Cristian Ionescu-Idbohrn wrote: Nothing needs to be fixed. What I'm merryly suggesting is adding the appropriate _existing_ patch(es) to http://busybox.net/downloads/fixes-1.22.1/. There may be a general intrest in that. yes, but the branches aren't just let's cherry pick everything. I didn't suggest that. I recall saying appropriate. they tend to be for specific bugs that users have noticed. hence i'm asking, what bugs are you seeing in the current release that you want fixed *in the branch* ? so far, you've shown one case, and only (small) commit is needed for that. if you have no other use cases that are impacted, we'll just ignore the rest and move on. Whatever. You decide. I can do my own patching. ffs, i don't know why all this pointless dancing. i guess the answer is you only have the one use case, so only that one patch needs to be cherry picked. you aren't hitting any other issues, so there's no need to waste time backporting other commits. -mike Please go ahead with whatever you think fit. Thanks for downloads/fixes-1.22.1/busybox-1.22.1-zcat-no-ext.patch. Unfortunately, commit 28dd64a0e1a9cffcde7799f2849b66c0e16bb9cc alone didn't make it fly :( /bin/tar tvf foo.tar tar: no gzip magic I ended up applying these commits: From 28dd64a0e1a9cffcde7799f2849b66c0e16bb9cc From: Denys Vlasenko vda.li...@googlemail.com Date: Fri, 10 Jan 2014 14:06:57 +0100 Subject: libarchive: open_zipped() does not need to check extensions for e.g. gzip From 7c47b560a8fc97956dd8132bd7f1863d83c19866 From: Denys Vlasenko vda.li...@googlemail.com Date: Fri, 10 Jan 2014 14:06:57 +0100 Subject: libarchive: open_zipped() does not need to check From 0f592d7fb94c5887528d0ee24020c2225ab71c28 From: Denys Vlasenko vda.li...@googlemail.com Date: Fri, 10 Jan 2014 18:02:38 +0100 Subject: tar: tighten up pax header validity check From b664f740d90880560ce46b11f766625341342e80 From: Denys Vlasenko vda.li...@googlemail.com Date: Mon, 27 Jan 2014 13:02:18 +0100 Subject: libbb: open_zipped() should not fail on non-compressed files From 640ce3de07807133796bccd0bdfa146bbfc788c7 From: Denys Vlasenko vda.li...@googlemail.com Date: Sun, 2 Feb 2014 02:06:38 +0100 Subject: zcat: complain if input is not compressed From 640ce3de07807133796bccd0bdfa146bbfc788c7 From: Denys Vlasenko vda.li...@googlemail.com Date: Sun, 2 Feb 2014 02:06:38 +0100 Subject: zcat: complain if input is not compressed Thank you Denys for the patches. I left out: 2108a6f0b56633fba1e70af406da147c02b11765 81071e6872eeb9e47b938d5d6fd82056aaebdd2e a9dc7c2f59dc5e92870d2d46316ea5c1f14740e3 as they deal with unlzma and lzop, which I don't use. If you can think of a better solution I'm all ears ;) Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: 1.22.1: been hit by the zcat bug
On Tue, 21 Oct 2014, Mike Frysinger wrote: On 20 Oct 2014 20:54, Cristian Ionescu-Idbohrn wrote: That deserves a patch in http://busybox.net/downloads/fixes-1.22.1/, IMO. At least, commits: 7c47b560a8fc97956dd8132bd7f1863d83c19866 b664f740d90880560ce46b11f766625341342e80 640ce3de07807133796bccd0bdfa146bbfc788c7 may be relevantat. what exactly are you calling the zcat bug ? seems to me only the first one should be backported. `busybox zcat foo` failing when foo is not compressed matches standard `zcat` behavior. -mike Well, but it fails (but returns exit status success) even if the file is compressed (ex. gzipped) but the fipped file extension isn't .gz. It will procuce an exact copy of the original. This is a .tar.gz file: -rw-r--r--1 root root 2736 Oct 21 16:32 foo.tar.bar # zcat foo.tar.bar foo.tar;echo $? 0 -rw-r--r--1 root root 2736 Oct 21 16:37 foo.tar -rw-r--r--1 root root 2736 Oct 21 16:32 foo.tar.bar Attemting to extract the archive will fail instead, with appropriate exit status. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: 1.22.1: been hit by the zcat bug
On Tue, 21 Oct 2014, Cristian Ionescu-Idbohrn wrote: On Tue, 21 Oct 2014, Mike Frysinger wrote: On 20 Oct 2014 20:54, Cristian Ionescu-Idbohrn wrote: That deserves a patch in http://busybox.net/downloads/fixes-1.22.1/, IMO. At least, commits: 7c47b560a8fc97956dd8132bd7f1863d83c19866 b664f740d90880560ce46b11f766625341342e80 640ce3de07807133796bccd0bdfa146bbfc788c7 may be relevantat. what exactly are you calling the zcat bug ? seems to me only the first one should be backported. `busybox zcat foo` failing when foo is not compressed matches standard `zcat` behavior. -mike Well, but it fails (but returns exit status success) even if the file is compressed (ex. gzipped) but the fipped file extension isn't .gz. It will procuce an exact copy of the original. This is a .tar.gz file: -rw-r--r--1 root root 2736 Oct 21 16:32 foo.tar.bar # zcat foo.tar.bar foo.tar;echo $? 0 -rw-r--r--1 root root 2736 Oct 21 16:37 foo.tar -rw-r--r--1 root root 2736 Oct 21 16:32 foo.tar.bar Attemting to extract the archive will fail instead, with appropriate exit status. If I do: # ln -s foo.tar.bar foo.tar.gz # zcat foo.tar.gz foo.tar;echo $? 0 -rw-r--r--1 root root 40960 Oct 21 17:37 foo.tar -rw-r--r--1 root root 2736 Oct 21 17:36 foo.tar.bar lrwxrwxrwx1 root root11 Oct 21 17:37 foo.tar.gz - foo.tar.bar I get what I expect. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: 1.22.1: been hit by the zcat bug
On Tue, 21 Oct 2014, Mike Frysinger wrote: On 21 Oct 2014 18:41, Cristian Ionescu-Idbohrn wrote: On Tue, 21 Oct 2014, Mike Frysinger wrote: On 20 Oct 2014 20:54, Cristian Ionescu-Idbohrn wrote: That deserves a patch in http://busybox.net/downloads/fixes-1.22.1/, IMO. At least, commits: 7c47b560a8fc97956dd8132bd7f1863d83c19866 b664f740d90880560ce46b11f766625341342e80 640ce3de07807133796bccd0bdfa146bbfc788c7 may be relevantat. what exactly are you calling the zcat bug ? seems to me only the first one should be backported. `busybox zcat foo` failing when foo is not compressed matches standard `zcat` behavior. -mike Well, but it fails (but returns exit status success) even if the file is compressed (ex. gzipped) but the fipped file extension isn't .gz. It will procuce an exact copy of the original. yes, but that bug is only fixed by the first commit in your list: 7c47b560a8fc97956dd8132bd7f1863d83c19866 Ok, if you say so. But if I look at: $ git log --unified --reverse 1_22_1..master -- archival I get the impression commit 7c47b560a8fc97956dd8132bd7f1863d83c19866, by itself, isn't enough. At least b664f740d90880560ce46b11f766625341342e80 [libbb: open_zipped() should not fail on non-compressed files] and 640ce3de07807133796bccd0bdfa146bbfc788c7 [zcat: complain if input is not compressed] are also related. the others have no impact on that, hence my question as to what exactly are you looking to get fixed ? Nothing needs to be fixed. What I'm merryly suggesting is adding the appropriate _existing_ patch(es) to http://busybox.net/downloads/fixes-1.22.1/. There may be a general intrest in that. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: 1.22.1: been hit by the zcat bug
On Tue, 21 Oct 2014, Mike Frysinger wrote: On 21 Oct 2014 20:02, Cristian Ionescu-Idbohrn wrote: Nothing needs to be fixed. What I'm merryly suggesting is adding the appropriate _existing_ patch(es) to http://busybox.net/downloads/fixes-1.22.1/. There may be a general intrest in that. yes, but the branches aren't just let's cherry pick everything. I didn't suggest that. I recall saying appropriate. they tend to be for specific bugs that users have noticed. hence i'm asking, what bugs are you seeing in the current release that you want fixed *in the branch* ? so far, you've shown one case, and only (small) commit is needed for that. if you have no other use cases that are impacted, we'll just ignore the rest and move on. Whatever. You decide. I can do my own patching. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: 1.22.1: been hit by the zcat bug
On Tue, 21 Oct 2014, Mike Frysinger wrote: On 21 Oct 2014 20:26, Cristian Ionescu-Idbohrn wrote: On Tue, 21 Oct 2014, Mike Frysinger wrote: On 21 Oct 2014 20:02, Cristian Ionescu-Idbohrn wrote: Nothing needs to be fixed. What I'm merryly suggesting is adding the appropriate _existing_ patch(es) to http://busybox.net/downloads/fixes-1.22.1/. There may be a general intrest in that. yes, but the branches aren't just let's cherry pick everything. I didn't suggest that. I recall saying appropriate. they tend to be for specific bugs that users have noticed. hence i'm asking, what bugs are you seeing in the current release that you want fixed *in the branch* ? so far, you've shown one case, and only (small) commit is needed for that. if you have no other use cases that are impacted, we'll just ignore the rest and move on. Whatever. You decide. I can do my own patching. ffs, i don't know why all this pointless dancing. i guess the answer is you only have the one use case, so only that one patch needs to be cherry picked. you aren't hitting any other issues, so there's no need to waste time backporting other commits. -mike Please go ahead with whatever you think fit. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
1.22.1: been hit by the zcat bug
That deserves a patch in http://busybox.net/downloads/fixes-1.22.1/, IMO. At least, commits: 7c47b560a8fc97956dd8132bd7f1863d83c19866 b664f740d90880560ce46b11f766625341342e80 640ce3de07807133796bccd0bdfa146bbfc788c7 may be relevantat. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Reg: Busybox mount fails to mount ntfs file system
Please don't top post and quote properly or don't quote at all. On Fri, 12 Sep 2014, Indira Valmiki wrote: On Fri, Sep 12, 2014 at 10:36 PM, Cristian Ionescu-Idbohrn cristian.ionescu-idbo...@axis.commailto:cristian.ionescu-idbo...@axis.com wrote: On Fri, 12 Sep 2014, Indira Valmiki wrote: I am using debian wheezy. Kernel version - 3.4.74. busybox version - 1.21.1 I am trying to mount a NTFS filesystem USB by using following command. mount -t ntfs-3g /dev/sda1 mount location But i'm getting below error, mount: mounting /dev/sda1 on /var/local/devices/ntfs failed: No such device Are you intentionally running busybox mount? Please show output from: # mount --help I suspect it's util-linux mount, and that's a different beast ;) It is busybox mount which mount - /bin/mount and ls -l /bin/mount gives me /bin/mount - busybox So odd. To my knowledge, fully updated standard debian wheezy comes with: Kernel version - 3.2.60-1+deb7u1 busybox version - 1.20.2 util-linux version - 2.20.1-5.3 So your system is obviously heavily modified. Is that intentional? Standard debian uses busybox mount at the system installation stage only, AFAIK. You must have built busybox 1.21.1, from source. What does: $ grep MOUNT .config show? Then you have the ntfs-3g package version 1:2012.1.15AR.5-2.1. Did you install the binary package or did you build ntfs-3g yourself? When installing the package you're asked: Configuring ntfs-3g --- NTFS-3G can be installed with the set-user-id bit set, so that it will run with superuser privileges. This allows unprivileged users to mount NTFS volumes. Enabling this feature may be a security risk, so it is disabled by default. If in doubt, you should leave it disabled. Should NTFS-3G be installed setuid root? ^^ What did you answer to that question? Are you user 'root' whan you're executing mount? The package comes with: /sbin/mount.ntfs-3g - /bin/ntfs-3g Is procfs mounted on your system? Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Reg: Busybox mount fails to mount ntfs file system
On Fri, 12 Sep 2014, Indira Valmiki wrote: I am using debian wheezy. Kernel version - 3.4.74. busybox version - 1.21.1 I am trying to mount a NTFS filesystem USB by using following command. mount -t ntfs-3g /dev/sda1 mount location But i'm getting below error, mount: mounting /dev/sda1 on /var/local/devices/ntfs failed: No such device Are you intentionally running busybox mount? Please show output from: # mount --help I suspect it's util-linux mount, and that's a different beast ;) Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: /proc/pid/cmdline and udhcpcd
On Wed, 26 Mar 2014, Ralf Friedl wrote: Matt Whitlock wrote: On Tuesday, 25 March 2014, at 10:52 pm, Cristian Ionescu-Idbohrn wrote: I find out that using that option: -x hostname:foo ^ shows up in /proc/pid/cmdline as: -x hostname foo ^ /proc/pid/cmdline reflects any changes that the process has made to its argv array. My guess is also that udhcpcd does something like strchr(hostname, ':') = '\0'; I was suspecting something like that, but had difficulties to locate where in the code that is being done. Denys, Is it possible to restrain from modifying the arguments for the command line? The problem is that the process watcher used here is dependant on having the original/unmodified /proc/pid/cmdline. If the watched process dies, the cmdline is used to respawn it. Respawning it with an erroneous command line creates a respawn loop. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: /proc/pid/cmdline and udhcpcd
On Wed, 26 Mar 2014, Matt Whitlock wrote: On Wednesday, 26 March 2014, at 12:46 pm, Cristian Ionescu-Idbohrn wrote: Is it possible to restrain from modifying the arguments for the command line? The problem is that the process watcher used here is dependant on having the original/unmodified /proc/pid/cmdline. If the watched process dies, the cmdline is used to respawn it. Respawning it with an erroneous command line creates a respawn loop. Couldn't you use the 'init' applet from Busybox to achieve process watching and respawning? Short answer, no, can't do that. There's another one there, already. But really, this is not an `init' question, as I see it. It's about keeping the original/unmodified program arguments in /proc/pid/cmdline. I know of no other program doing such sort of thing, although I think I understand the reason behind this particular way of handling the '-x' option argument in udhcpc. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: /proc/pid/cmdline and udhcpcd
On Wed, 26 Mar 2014, Matt Whitlock wrote: On Wednesday, 26 March 2014, at 1:19 pm, Cristian Ionescu-Idbohrn wrote: But really, this is not an `init' question, as I see it. It's about keeping the original/unmodified program arguments in /proc/pid/cmdline. I know of no other program doing such sort of thing, although I think I understand the reason behind this particular way of handling the '-x' option argument in udhcpc. Tons of programs modify their argv arrays. Alright, you know better. Anything that uses strtok to split arguments at delimiters will do it. Yes, there's still much to learn. Do you happen to know of some popular examples? One should never assume that /proc/pid/cmdline will contain the command line as it was originally used to execute the process. Do you happen to know of some reliable reference text stating that? Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: /proc/pid/cmdline and udhcpcd
On Wed, 26 Mar 2014, Denys Vlasenko wrote: On Wed, Mar 26, 2014 at 12:46 PM, Cristian Ionescu-Idbohrn cristian.ionescu-idbo...@axis.com wrote: My guess is also that udhcpcd does something like strchr(hostname, ':') = '\0'; I was suspecting something like that, but had difficulties to locate where in the code that is being done. Denys, Is it possible to restrain from modifying the arguments for the command line? The problem is that the process watcher used here is dependant on having the original/unmodified /proc/pid/cmdline. If the watched process dies, the cmdline is used to respawn it. Respawning it with an erroneous command line creates a respawn loop. busybox can be fixed, yes. Great. But how that respawn tool going to work with other programs? As I've written in a previous message, I know nothing of such other programs, but I'd be intrested to learn more. There is no convention in Unix that you can't modify argv[]. Sad, because if there was, there would have been something to refer to. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: /proc/pid/cmdline and udhcpcd
A big thanks to all of you guys. I now feel enlightened :) On Wed, 26 Mar 2014, Laurent Bercot wrote: Just off the top of my head: Now that you write it down: sshd (from openssh) I realize I knew about this one, all along. avahi-daemon dovecot and even among the good guys: readproctitle runsvdir Well, let's hope busybox will be next on the good guys list ;) Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: /proc/pid/cmdline and udhcpcd
On Wed, 26 Mar 2014, Michael Conrad wrote: All mysql utilities overwrite passwords in cmdline as a security measure. http://dev.mysql.com/doc/refman/5.1/en/password-security-user.html Well, I recently learned there's some effort put in the linux kernel to help with that sort of thing. See: Documentation/filesystems/proc.txt (at the bottom) in a kernel source tree (I'm looking at 3.13) , | Configuring procfs | -- | | 4.1 Mount options | - | | The following mount options are supported: | | hidepid=Set /proc/pid/ access mode. | gid=Set the group authorized to learn processes information. ` Hope that helps. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
/proc/pid/cmdline and udhcpcd
Trying to move from: udhcpc -H foo to: udhcpc -x hostname:foo following the advice: udhcpc: option -h NAME is deprecated, use -x hostname:NAME This is BusyBox v1.20.2. I find out that using that option: -x hostname:foo ^ shows up in /proc/pid/cmdline as: -x hostname foo ^ and that screws up a few things around here :( Now I wonder what's going on. What should I put the blame on? A simple test shows that shouldn't happen. Run the attached script with: /path/to/cmdline2.sh -x hostname:foo and you'll see what I mean. The output from the script looks exactly like I'd expect it to. What's changing the /proc/pid/cmdline in the busybox udhcpcd case? Looking around in the process table I see other daemons showing correct option arguments: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 104:105 ^ Where should I seek enlightment? Cheers, -- Cristian cmdline2.sh Description: Bourne shell script ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFC: 3 shells (ash, dash, bash), 3 different behaviours
On Thu, 20 Mar 2014, Cristian Ionescu-Idbohrn wrote: On Thu, 20 Mar 2014, Denys Vlasenko wrote: Did you find a real-world script which does depend on previous value of local variable? Please show it. Alright. See attached. Run it with: $ dash /path/to/foo.sh $ bash /path/to/foo.sh $ /path/to/busybox ash /path/to/foo.sh I probabably owe an explanation for the script example attached to the previous message. Variable 'foo' contains the output from a dbus-send command. Function `f' is supposed to return the 'fps' of an mjpeg video stream with a 1920x1080 resolution. Running the script under dash does that for me and so did busybox ash, until recently. What I now have to do is to identify all scripts that do things like: IFS=:$IFS and replace the marked part with verbatim spacetabnewline. And that will keep me busy for a while, with the uncertainty that I didn't locate all such places. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFC: 3 shells (ash, dash, bash), 3 different behaviours
On Thu, 20 Mar 2014, Denys Vlasenko wrote: On Wed, Mar 19, 2014 at 6:47 PM, Cristian Ionescu-Idbohrn cristian.ionescu-idbo...@axis.com wrote: On Mon, 17 Mar 2014, Cristian Ionescu-Idbohrn wrote: I just had a look att commit 109ee5d33694a03cda3424b4846584250832ba8e. IMO, to imitate bash behaviour isn't the right thing to do. It's a bug. It is also the most widely used shell in Linux. That does not imply bug-free. Imitate dash behaviour instead. Why? Bash user base is much larger than dash, and likely to remain to be, unless dash developers stop being stubborn and implement at least, say, command-line editing. Right now, they seem to enjoy torturing their users. Not a good attitude. That's a biased optinion, IMO. I can now confirm the commit breaks several scripts based on these assumptions: 1. all script variables are global... 2. ...unless declared local 3. a `local' declaration inherits the upper scope variable value About (3): Says who? Common sense? 4. `local' modifications of the variable value are thrown away upon `return' from the function I consider the bash behaviour buggy. Considering that sane usage of local is to make sure that locally-used variables don't trash global variables' values, both behaviors are okay in practice. In practice, it won't make too much a difference. * knowlegeable bash users would assume a `local' declared variable would `unset' unset variable, and they will reset it * dash users will assume a `local' declared variable is inherited * both win Several distributions (besides debian) adopted, for several reasons, dash as the system shell. Using shell script code from such distributions and running it under busybox ash will break. Did you find a real-world script which does depend on previous value of local variable? Please show it. Alright. See attached. Run it with: $ dash /path/to/foo.sh $ bash /path/to/foo.sh $ /path/to/busybox ash /path/to/foo.sh Cheers, -- Cristian foo.sh Description: Bourne shell script ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFC: 3 shells (ash, dash, bash), 3 different behaviours
On Mon, 17 Mar 2014, Cristian Ionescu-Idbohrn wrote: I just had a look att commit 109ee5d33694a03cda3424b4846584250832ba8e. IMO, to imitate bash behaviour isn't the right thing to do. It's a bug. Imitate dash behaviour instead. Refer to the test shell/ash_test/ash-misc/local1.tests. Upon entering function `f', `local a' makes a copy of the variable with the same name in the upper scope. `local a' should not implicitly `unset a'. Let the user decide what to do with variable 'a' (modify, unset, whatever). I can now confirm the commit breaks several scripts based on these assumptions: 1. all script variables are global... 2. ...unless declared local 3. a `local' declaration inherits the upper scope variable value 4. `local' modifications of the variable value are thrown away upon `return' from the function I consider the bash behaviour buggy. Busybox ash is derived from dash. Holding to dash compatibility is, IMO, TRT to do. Several distributions (besides debian) adopted, for several reasons, dash as the system shell. Using shell script code from such distributions and running it under busybox ash will break. The least probable damage can be achived by keeping the dash like behaviour. Scripts specially written for bash assume `local' variables are emptied and will set new variable values. Non-bash scripts won't. Denys, Please revert that commit. IMO, that's the best of both worlds. I recommed reading this paragraph (`man 1 bash') too: BUGS Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ntpd config file support
On Tue, 18 Mar 2014, Bryan Evenson wrote: How about a set of ntpd menuconfig options to build the command line? We could configure the default ntpd settings at build time, it wouldn't add anything to the size of the final ntpd binary. How about using a resource file the initscript would source: ---[ rc-file ]--- NTPD_OPT1='-f foo' NTPD_OPT2='-b bar' NTPD_OPT3= - ---[ initscript ]--- #!/bin/sh . /path/to/rc-file ... command line to start ntpd $NTPD_OPT1 $NTPD_OPT2 $NTPD_OPT3 ... Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ntpd config file support
On Tue, 18 Mar 2014, Laszlo Papp wrote: I would really appreciate more respect here towards end users. No one is forcing anything. You're barking at the wrong tree, Laszlo. The end users have raised their opinion how they would like to see your software behaving. Who's the end user here? The end user may want to be able to configure. The distribution may want to provide the means. It is not the right tone to tell that their opinion is a shit storm. In fact, as an end user it feels quite scary to hear, I must confess. Boy, oh boy. Incredible how much effort went into this thread. But it should be ok. It's hopefully part of the process. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFC: 3 shells (ash, dash, bash), 3 different behaviours
On Sun, 16 Mar 2014, Cristian Ionescu-Idbohrn wrote: WRT script line the error is associated to, it seems dash is doing the best jobb (14: parameter not set, printed when trying to print IFS, immediately after unsetting it). ash reports the error on the line function f is called. That seems to be the only difference between dash and ash. bash reports 2 errors line 11: IFS: unbound variable and line 14: IFS: unbound variable. I just had a look att commit 109ee5d33694a03cda3424b4846584250832ba8e. IMO, to imitate bash behaviour isn't the right thing to do. It's a bug. Imitate dash behaviour instead. Refer to the test shell/ash_test/ash-misc/local1.tests. Upon entering function `f', `local a' makes a copy of the variable with the same name in the upper scope. `local a' should not implicitly `unset a'. Let the user decide what to do with variable 'a' (modify, unset, whatever). What do people think? Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFC: 3 shells (ash, dash, bash), 3 different behaviours
On Fri, 14 Mar 2014, ibid...@gmail.com wrote: On Fri, Mar 14, 2014 at 12:24:51AM +0100, Cristian Ionescu-Idbohrn wrote: On Thu, 13 Mar 2014, Cristian Ionescu-Idbohrn wrote: It's explained here: http://pubs.opengroup.org/onlinepubs/009695399/utilities/sh.html IFS (Input Field Separators.) A string treated as a list of characters that shall be used for field splitting and to split lines into words with the read command. See Field Splitting. If IFS is not set, the shell shall behave as if the value of IFS were space, tab, and newline. Implementations may ignore the value of IFS in the environment at the time sh is invoked, treating IFS as if it were not set. What bothers me is the last phrase: Reading this again: Implementations may ignore the value of IFS in the environment at the time sh is invoked, treating IFS as if it were not set. My mother tongue isn't english, but what I make of it is that the shell may ignore an environment IFS set outside a shell(script)?. Thoughts? Correct. If you use either of these: export IFS= -_; sh #or ./script.sh ... IFS= -_ sh the shell is _permitted_ (but not required) to ignore the value of IFS. The reverse sequence, sh $ IFS= -_ cannot be ignored, however. So the shell could unconditionally unset IFS on start. Right. Then the only unexpected behaviour ash, bash and dash show is that after activelly unsetting IFS, the shell produces the error: IFS: parameter not set when attemting to access the IFS value, although word splitting will internally still work, as the shell will fall back on an: IFS=spacetabnewline I guess I'm ok with that. (see even attached improved example script). Cheers, -- Cristian IFS-and-busybox-ash.example.sh Description: Bourne shell script ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
RFC: 3 shells (ash, dash, bash), 3 different behaviours
It's explained here:
http://pubs.opengroup.org/onlinepubs/009695399/utilities/sh.html
IFS
(Input Field Separators.) A string treated as a list of
characters that shall be used for field splitting and to split
lines into words with the read command. See Field Splitting.
If IFS is not set, the shell shall behave as if the value of
IFS were space, tab, and newline.
Implementations may ignore the value of IFS in the environment
at the time sh is invoked, treating IFS as if it were not set.
What bothers me is the last phrase:
Implementations may ignore the value of IFS in the environment
at the time sh is invoked, treating IFS as if it were not set.
My expectation is the shell _should_ show the way it would behave,
should IFS be used after unset. That's clearly not the case :(
Consider the attached example and run with:
$ {busybox ash,bash,dash} /path/to/IFS-and-busybox-ash.example.sh
IFS is a special (not ordinary) variable. What I'd intuively expect
is:
local IFS
would be an upper scope copy, or if unset:
IFS=spacetabnewline
I'm confused :(
Cheers,
--
Cristian
IFS-and-busybox-ash.example.sh
Description: Bourne shell script
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: RFC: 3 shells (ash, dash, bash), 3 different behaviours
On Thu, 13 Mar 2014, Cristian Ionescu-Idbohrn wrote:
Date: Thu, 13 Mar 2014 21:00:32 +0100
From: Cristian Ionescu-Idbohrn c...@axis.com
Reply-To: busybox@busybox.net busybox@busybox.net
To: busybox@busybox.net busybox@busybox.net
Subject: RFC: 3 shells (ash, dash, bash), 3 different behaviours
It's explained here:
http://pubs.opengroup.org/onlinepubs/009695399/utilities/sh.html
IFS
(Input Field Separators.) A string treated as a list of
characters that shall be used for field splitting and to split
lines into words with the read command. See Field Splitting.
If IFS is not set, the shell shall behave as if the value of
IFS were space, tab, and newline.
Implementations may ignore the value of IFS in the environment
at the time sh is invoked, treating IFS as if it were not set.
What bothers me is the last phrase:
Reading this again:
Implementations may ignore the value of IFS in the environment
at the time sh is invoked, treating IFS as if it were not set.
My mother tongue isn't english, but what I make of it is that the
shell may ignore an environment IFS set outside a shell(script)?.
Thoughts?
My expectation is the shell _should_ show the way it would behave,
should IFS be used after unset. That's clearly not the case :(
Consider the attached example and run with:
$ {busybox ash,bash,dash} /path/to/IFS-and-busybox-ash.example.sh
IFS is a special (not ordinary) variable. What I'd intuively expect
is:
local IFS
would be an upper scope copy, or if unset:
IFS=spacetabnewline
I'm confused :(
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: udhcpc: dont use BPF filter, users report problems (bugs 4598, 6746), commit e4785ca653d0e219926692c229673b2c1b8d6ac4
On Thu, 6 Feb 2014, Denys Vlasenko wrote: On Wed, Feb 5, 2014 at 9:51 PM, Mike Frysinger vap...@gentoo.org wrote: On Wednesday, February 05, 2014 16:41:15 Cristian Ionescu-Idbohrn wrote: On Wed, 5 Feb 2014, Denys Vlasenko wrote: On Tue, Feb 4, 2014 at 8:48 PM, Cristian Ionescu-Idbohrn cristian.ionescu-idbo...@axis.com wrote: The backside of this, IIRC, is that udhcpc will eat up huge chunks of CPU parsing uninteresting packets, on heavy loaded networks. udhcpc does not listen to the network after it established a lease. As I said, it's not the wait to get a lease that is a problem but the high CPU load (parsing packets). what is using the high CPU load ? not udhcpc, but the kernel itself ? what kernel are you using exactly ? what arch ? udhcpc uses raw socket to receive *all IPv4 packets* when it waits for initial DHCP server responses. Therefore, it can get potentially lots and lots of unrelated packets, and needs to check and discard each of them. Yes. Thanks for that explanation. I am not convinced this is a problem in practice. Well, it is. At least for the company that pays me. I want to avoid fixing a non-existing problem. We fixed it once with BPF filter, creating a real problem: for some people, presence of that filter broke udhcpc. (For me it worked). Yes. Some people that, supposedly, may run kernels with BPF filter disabled, or some such, I guess. What I can reveal (which is also public knowledge to anyone motivated to look for) is that the linux kernels date back to (at least) 2.6.x and the archs are arm, cris and mips, 100-400 Mhz. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: udhcpc: dont use BPF filter, users report problems (bugs 4598, 6746), commit e4785ca653d0e219926692c229673b2c1b8d6ac4
On Wed, 5 Feb 2014, Denys Vlasenko wrote: On Tue, Feb 4, 2014 at 8:48 PM, Cristian Ionescu-Idbohrn cristian.ionescu-idbo...@axis.com wrote: The backside of this, IIRC, is that udhcpc will eat up huge chunks of CPU parsing uninteresting packets, on heavy loaded networks. udhcpc does not listen to the network after it established a lease. As I said, it's not the wait to get a lease that is a problem but the high CPU load (parsing packets). Yes. But imagine the usecase where you get a power outage and a farm of embedded systems fight to get a lease. Also, every time a lease renew occurs CPU gets wasted parsing uninteresting packets. It just sleeps, usually for hours, waiting for 1/2 of the lease time to expire. No network sockets are open during that time: # ls -l /proc/1412/fd total 0 lr-x-- 1 root root 64 Feb 5 15:08 0 - /dev/null l-wx-- 1 root root 64 Feb 5 15:08 1 - pipe:[16588] l-wx-- 1 root root 64 Feb 5 15:08 2 - pipe:[16588] lr-x-- 1 root root 64 Feb 5 15:08 3 - pipe:[22350] l-wx-- 1 root root 64 Feb 5 15:08 4 - pipe:[22350] fds 1 and 2 are stdout/err (in my case, directed to a logger), fds 3 and 4 is the internal signal pipe. Yes. I understand that. Still, would you accept a patch that makes the BPF filter an option? Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
udhcpc: don't use BPF filter, users report problems (bugs 4598, 6746), commit e4785ca653d0e219926692c229673b2c1b8d6ac4
The backside of this, IIRC, is that udhcpc will eat up huge chunks of CPU parsing uninteresting packets, on heavy loaded networks. Bug #6746 names FRITZ!Box 7570 router (mipsel) and some unnamed kernel version that Apparently my kernel does not support this filter feature. Maybe a better alternative would be to either enable the filter kernel feature (witch will not only benefit busybox, but the whole system) or to make the BPF filtering a configurable busybox feature. That way noone would need to patch the udhcpc source. See also the kernel source: Documentation/networking/filter.txt Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: udhcpc: dont use BPF filter, users report problems (bugs 4598, 6746), commit e4785ca653d0e219926692c229673b2c1b8d6ac4
On Tue, 4 Feb 2014, Cristian Ionescu-Idbohrn wrote: The backside of this, IIRC, is that udhcpc will eat up huge chunks of CPU parsing uninteresting packets, on heavy loaded networks. Bug #6746 names FRITZ!Box 7570 router (mipsel) and some unnamed kernel version that Apparently my kernel does not support this filter feature. Maybe a better alternative would be to either enable the filter kernel feature (witch will not only benefit busybox, but the whole ^ that's supposed to spell 'which, instead system) or to make the BPF filtering a configurable busybox feature. That way noone would need to patch the udhcpc source. See also the kernel source: Documentation/networking/filter.txt Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Remove BUG_const_mismatch, locally defined but not used.
On Mon, 3 Feb 2014, Denys Vlasenko wrote:
This check is useful. I would like to retain it. How about moving it
to global scope?
#define CATV_OPT_e (10)
#define CATV_OPT_t (11)
#define CATV_OPT_v (12)
struct BUG_const_mismatch {
char BUG_const_mismatch[
CATV_OPT_e == VISIBLE_ENDLINE CATV_OPT_t ==
VISIBLE_SHOW_TABS
? 1 : -1
];
};
int catv_main(...)...
That'll work too.
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] Remove 'BUG_const_mismatch', locally defined but not used.
coreutils/catv.c:32:15: warning: typedef 'BUG_const_mismatch' locally defined but not used [-Wunused-local-typedefs] typedef char BUG_const_mismatch[ ^ Signed-off-by: Cristian Ionescu-Idbohrn cristian.ionescu-idbo...@axis.com --- coreutils/catv.c | 4 1 file changed, 4 deletions(-) diff --git a/coreutils/catv.c b/coreutils/catv.c index e3499c5..3846aea 100644 --- a/coreutils/catv.c +++ b/coreutils/catv.c @@ -29,10 +29,6 @@ int catv_main(int argc UNUSED_PARAM, char **argv) #define CATV_OPT_e (10) #define CATV_OPT_t (11) #define CATV_OPT_v (12) - typedef char BUG_const_mismatch[ - CATV_OPT_e == VISIBLE_ENDLINE CATV_OPT_t == VISIBLE_SHOW_TABS - ? 1 : -1 - ]; opts = getopt32(argv, etv); argv += optind; -- 1.9.rc1 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCHv2] Adjust help/usage texts for tail.
Signed-off-by: Cristian Ionescu-Idbohrn cristian.ionescu-idbo...@axis.com --- coreutils/Config.src | 3 ++- coreutils/tail.c | 8 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/coreutils/Config.src b/coreutils/Config.src index 0c44c4b..04bc250 100644 --- a/coreutils/Config.src +++ b/coreutils/Config.src @@ -633,12 +633,13 @@ config FEATURE_FANCY_TAIL default y depends on TAIL help - The options (-q, -s, and -v) are provided by GNU tail, but + The options (-q, -s, -v and -F) are provided by GNU tail, but are not specific in the SUSv3 standard. -q Never output headers giving file names -s SEC Wait SEC seconds between reads with -f -v Always output headers giving file names + -F Same as -f, but keep retrying config TEE bool tee diff --git a/coreutils/tail.c b/coreutils/tail.c index eab502b..f27ffe2 100644 --- a/coreutils/tail.c +++ b/coreutils/tail.c @@ -32,16 +32,14 @@ //usage: Print last 10 lines of each FILE (or stdin) to stdout.\n //usage: With more than one FILE, precede each with a filename header.\n //usage: \n -f Print data as file grows -//usage: IF_FEATURE_FANCY_TAIL( -//usage: \n -s SECONDS Wait SECONDS between reads with -f -//usage: ) +//usage: \n -c [+]N[kbm]Print last N bytes //usage: \n -n N[kbm] Print last N lines //usage: \n -n +N[kbm] Start on Nth line and print the rest //usage: IF_FEATURE_FANCY_TAIL( -//usage: \n -c [+]N[kbm]Print last N bytes //usage: \n -q Never print headers +//usage: \n -s SECONDS Wait SECONDS between reads with -f //usage: \n -v Always print headers +//usage: \n -F Same as -f, but keep retrying //usage: \n //usage: \nN may be suffixed by k (x1024), b (x512), or m (x1024^2). //usage: ) -- 1.8.5.2 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: coreutils/chown.c
On Thu, 9 Jan 2014, Cristian Ionescu-Idbohrn wrote: Yes. I did miss something after all :( Nevertheless, are the POSIX options LHP intended to be default (as usage suggests) or DESKTOP dependent? Answer to self (after staring at the code a little longer): * yes, the 'HLP' options are (arguably) DESKTOP dependent, in which case the attached patch idea 1 bb-chown-options-HLP-are-DESKTOP-dependent.patch should do the necessary cleanup * alternatively, attached patch idea 2 bb-chown-options-HLP-not-DESKTOP-dependent.patch which make the 'HLP' options DESKTOP independent Cheers, -- Cristiandiff --git a/busybox/coreutils/chown.c b/busybox/coreutils/chown.c index bb166d8..5310441 100644 --- a/busybox/coreutils/chown.c +++ b/busybox/coreutils/chown.c @@ -11,18 +11,18 @@ /* http://www.opengroup.org/onlinepubs/007904975/utilities/chown.html */ //usage:#define chown_trivial_usage -//usage: [-RhLHPIF_DESKTOP(cvf)]... OWNER[.|:[GROUP]] FILE... +//usage: [-RhIF_DESKTOP(vcfLHP)]... OWNER[.|:[GROUP]] FILE... //usage:#define chown_full_usage \n\n //usage: Change the owner and/or group of each FILE to OWNER and/or GROUP\n //usage: \n -R Recurse //usage: \n -h Affect symlinks instead of symlink targets -//usage: \n -L Traverse all symlinks to directories -//usage: \n -H Traverse symlinks on command line only -//usage: \n -P Don't traverse symlinks (default) //usage: IF_DESKTOP( -//usage: \n -c List changed files //usage: \n -v List all files +//usage: \n -c List changed files //usage: \n -f Hide errors +//usage: \n -L Traverse all symlinks to directories +//usage: \n -H Traverse symlinks on command line only +//usage: \n -P Don't traverse symlinks (default) //usage: ) //usage: //usage:#define chown_example_usage diff --git a/busybox/coreutils/chown.c b/busybox/coreutils/chown.c index bb166d8..4e9ab37 100644 --- a/busybox/coreutils/chown.c +++ b/busybox/coreutils/chown.c @@ -11,19 +11,19 @@ /* http://www.opengroup.org/onlinepubs/007904975/utilities/chown.html */ //usage:#define chown_trivial_usage -//usage: [-RhLHPIF_DESKTOP(cvf)]... OWNER[.|:[GROUP]] FILE... +//usage: [-RhIF_DESKTOP(vcf)LHP]... OWNER[.|:[GROUP]] FILE... //usage:#define chown_full_usage \n\n //usage: Change the owner and/or group of each FILE to OWNER and/or GROUP\n //usage: \n -R Recurse //usage: \n -h Affect symlinks instead of symlink targets -//usage: \n -L Traverse all symlinks to directories -//usage: \n -H Traverse symlinks on command line only -//usage: \n -P Don't traverse symlinks (default) //usage: IF_DESKTOP( -//usage: \n -c List changed files //usage: \n -v List all files +//usage: \n -c List changed files //usage: \n -f Hide errors //usage: ) +//usage: \n -L Traverse all symlinks to directories +//usage: \n -H Traverse symlinks on command line only +//usage: \n -P Don't traverse symlinks (default) //usage: //usage:#define chown_example_usage //usage: $ ls -l /tmp/foo\n @@ -40,7 +40,7 @@ /* This is a NOEXEC applet. Be very careful! */ -#define OPT_STR (Rh IF_DESKTOP(vcfLHP)) +#define OPT_STR (Rh IF_DESKTOP(vcf) LHP) #define BIT_RECURSE 1 #define OPT_RECURSE (opt 1) #define OPT_NODEREF (opt 2) @@ -56,10 +56,10 @@ * The last option specified shall determine the behavior of the utility. */ /* -L */ #define BIT_TRAVERSE 0x20 -#define OPT_TRAVERSE (IF_DESKTOP(opt BIT_TRAVERSE) IF_NOT_DESKTOP(0)) +#define OPT_TRAVERSE (opt BIT_TRAVERSE) /* -H or -L */ #define BIT_TRAVERSE_TOP (0x20|0x40) -#define OPT_TRAVERSE_TOP (IF_DESKTOP(opt BIT_TRAVERSE_TOP) IF_NOT_DESKTOP(0)) +#define OPT_TRAVERSE_TOP (opt BIT_TRAVERSE_TOP) #if ENABLE_FEATURE_CHOWN_LONG_OPTIONS static const char chown_longopts[] ALIGN1 = ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] Adjust help/usage texts for tail.c
Signed-off-by: Cristian Ionescu-Idbohrn cristian.ionescu-idbo...@axis.com --- coreutils/Config.src | 3 ++- coreutils/tail.c | 8 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/coreutils/Config.src b/coreutils/Config.src index 0c44c4b..04bc250 100644 --- a/coreutils/Config.src +++ b/coreutils/Config.src @@ -633,12 +633,13 @@ config FEATURE_FANCY_TAIL default y depends on TAIL help - The options (-q, -s, and -v) are provided by GNU tail, but + The options (-q, -s, -v and -F) are provided by GNU tail, but are not specific in the SUSv3 standard. -q Never output headers giving file names -s SEC Wait SEC seconds between reads with -f -v Always output headers giving file names + -F same as -f, but keep retrying config TEE bool tee diff --git a/coreutils/tail.c b/coreutils/tail.c index eab502b..f27ffe2 100644 --- a/coreutils/tail.c +++ b/coreutils/tail.c @@ -32,15 +32,14 @@ //usage: Print last 10 lines of each FILE (or stdin) to stdout.\n //usage: With more than one FILE, precede each with a filename header.\n //usage: \n -f Print data as file grows -//usage: IF_FEATURE_FANCY_TAIL( -//usage: \n -s SECONDS Wait SECONDS between reads with -f -//usage: ) +//usage: \n -c [+]N[kbm]Print last N bytes //usage: \n -n N[kbm] Print last N lines //usage: \n -n +N[kbm] Start on Nth line and print the rest //usage: IF_FEATURE_FANCY_TAIL( -//usage: \n -c [+]N[kbm]Print last N bytes //usage: \n -q Never print headers +//usage: \n -s SECONDS Wait SECONDS between reads with -f //usage: \n -v Always print headers +//usage: \n -F same as -f, but keep retrying //usage: \n //usage: \nN may be suffixed by k (x1024), b (x512), or m (x1024^2). //usage: ) @@ -124,6 +123,7 @@ int tail_main(int argc, char **argv) IF_FEATURE_FANCY_TAIL(opt_complementary = s+:Ff;) opt = getopt32(argv, fc:n: IF_FEATURE_FANCY_TAIL(qs:vF), str_c, str_n IF_FEATURE_FANCY_TAIL(,sleep_period)); + bb_error_msg(/cii/opt=%o, opt); #define FOLLOW (opt 0x1) #define COUNT_BYTES (opt 0x2) //if (opt 0x1) // -f -- 1.8.5.2 Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
coreutils/chown.c
The code suggests this patch: From e68af87e1e38911bb3dd653ad36701f81dbbdc3f Mon Sep 17 00:00:00 2001 From: Cristian Ionescu-Idbohrn cristian.ionescu-idbo...@axis.com Date: Wed, 8 Jan 2014 17:40:25 +0100 Subject: [PATCH] Make usage and code agree with each other. Signed-off-by: Cristian Ionescu-Idbohrn cristian.ionescu-idbo...@axis.com --- coreutils/chown.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/coreutils/chown.c b/coreutils/chown.c index 1a91276..c87433c 100644 --- a/coreutils/chown.c +++ b/coreutils/chown.c @@ -40,7 +40,7 @@ /* This is a NOEXEC applet. Be very careful! */ -#define OPT_STR (Rh IF_DESKTOP(vcfLHP)) +#define OPT_STR (RhLHP IF_DESKTOP(vcf)) #define BIT_RECURSE 1 #define OPT_RECURSE (opt 1) #define OPT_NODEREF (opt 2) -- 1.8.5.2 is the intended behaviour, unless I'm missing something. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Correct exit codes for invalid tar archives
On Wed, 20 Nov 2013, Denys Vlasenko wrote:
Your patch makes tar die on read 512 bytes at once, without
considering the possibility that it was a perfectly valid gzipped tarball
which become shorter than 512 bytes after gzipping.
The code before patch is:
i = full_read(archive_handle-src_fd, tar, 512);
if (i == 0) {
xfunc_error_retval = 0;
bb_error_msg_and_die(short read);
}
if (i != 512) {
IF_FEATURE_TAR_AUTODETECT(goto autodetect;)
NOTE THIS
bb_error_msg_and_die(short read);
}
You make it impossible to reach that line.
Of course you're right. Got it now.
In fact I think you are right, zero-sized file is likely
a result of error somewhere (a failed download or tarball creation)
and it's better to refuse to process such tarball. I fixed it in git.
Sounds good. `tar' with the latest patches works for us. Thanks.
Did some more tests. Files of /dev/zero and /dev/urandom bytes;
sizes 1, 2, 3, 511, 512, 513, 1023, 1034, 1025 bytes.
I use GNU tar 1.26. Found one discrepancy, though
$ bb-tar tf ../data/1023.zero-bytes;echo $?
tar: invalid tar magic
1
$ gnu-tar tf ../data/1023.zero-bytes;echo $?
tar: A lone zero block at 1
0
I'm not sure busybox-tar needs to care about that one, but you decide.
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Correct exit codes for invalid tar archives
On Tue, 19 Nov 2013, Denys Vlasenko wrote:
On Fri, Nov 15, 2013 at 3:30 PM, Cristian Ionescu-Idbohrn
cristian.ionescu-idbo...@axis.com wrote:
This is what my work collegue proposes. Works for us.
Acceptable hack Denys?
Signed-off-by: Magnus Rolf magnus.r...@axis.com
---
busybox/archival/libarchive/get_header_tar.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/busybox/archival/libarchive/get_header_tar.c
b/busybox/archival/libarchive/get_header_tar.c
index b168653..54ddb19 100644
--- a/busybox/archival/libarchive/get_header_tar.c
+++ b/busybox/archival/libarchive/get_header_tar.c
@@ -190,17 +190,14 @@ char FAST_FUNC get_header_tar(archive_handle_t
*archive_handle)
/* to prevent misdetection of bz2 sig */
*(aliased_uint32_t*)tar = 0;
i = full_read(archive_handle-src_fd, tar, 512);
- /* If GNU tar sees EOF in above read, it says:
-* tar: A lone zero block at N, where N = kilobyte
-* where EOF was met (not EOF block, actual EOF!),
-* and exits with EXIT_SUCCESS.
-* We will mimic exit(EXIT_SUCCESS), although we will not mimic
-* the message and we don't check whether we indeed
-* saw zero block directly before this. */
- if (i == 0) {
- xfunc_error_retval = 0;
+ /* Since v1.19, GNU tar exits with code 2 when supplied an archive
smaller
+* than 512 bytes in reading mode (-x, -t).
+* Previous tar versions silently ignored it, exiting with code 0.
+*/
+ if (i 512) {
+ xfunc_error_retval = 2;
short_read:
- bb_error_msg_and_die(short read);
+ bb_error_msg_and_die(This does not look like a tar
archive);
}
There are valid gzipped tarballs smaller than 512 bytes.
Yes, but, as I wrote, my understanding of the patch above is that it
only test the tar-ball (after possible decompression). IOW, the 512
magic number has nothing to do with gzipped tar-balls. Am I wrong?
Your 1st example tries to unpack 0-byte file. In uncompressed case,
such file can be interpreted as valid empty tarball with truncated
EOF blocks.
Won't argue with that, as my tar-fu is very limited.
The example when we misinterpret empty file as valid *tgz* file
is a bug. I'm applying attached patch to fix that case.
True. Still (after applying this patch) if I do:
$ tar cf foo.tar foo
with a zero-bytes foo and hexdump the result (the uncompressed case),
I see a filename (foo), permissions, a date (maybe), owner and group,
and not a 'valid empty tarball with truncated EOF blocks'. In such
a case, GNU-tar shows:
/bin/tar: This does not look like a tar archive
/bin/tar: Exiting with failure status due to previous errors
E: failed ($?=2) to check tarball '../foo'
gzip: stdin: unexpected end of file
/bin/tar: Child returned status 1
/bin/tar: Error is not recoverable: exiting now
E: failed ($?=2) to decompress and check tarbal '../foo'
where as bb-tar shows:
tar: short read
tar: invalid magic
tar: short read
E: failed ($?=1) to decompress and check tarbal '../foo'
(see my simple script, earlier in this thread; tar {tf|tzf} is
actually sufficient to demonstrate the point).
What about some tests under testsuite/tar to validate the proper
behaviour? I'm willing to contribute such patch(es) if noone else
beats me to it.
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: tar xf: failure/success
On Wed, 13 Nov 2013, Cristian Ionescu-Idbohrn wrote: Sometime between 1_19_4 and 1_20_2 tar extract changed behaviour. Invalid archive file (since 1_20_2) is successfuly ($?=0) expanded, although: tar: invalid magic tar: short read show up on stderr. I should have probably mentioned that gnu-tar behaviour is to return exit status failure in both cases. Running the test-script in the previous message (where bb-tar is replaced with gnu-tar) displays: $ ./tar_test.sh tar: This does not look like a tar archive tar: Exiting with failure status due to previous errors E: failed ($?=2) to extract tarball '../foo' gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now E: failed ($?=2) to decompress and extract tarbal '../foo' Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
tar xf: failure/success
Sometime between 1_19_4 and 1_20_2 tar extract changed behaviour.
Invalid archive file (since 1_20_2) is successfuly ($?=0) expanded,
although:
tar: invalid magic
tar: short read
show up on stderr.
Test script:
---8---
#!/bin/sh
set -eu
whine() {
echo $* 2
}
tb=../foo
$tb || {
whine E: failed (\$?=$?) to truncate '$tb'
exit 1
}
./busybox xvf $tb || whine E: failed (\$?=$?) to extract tarball '$tb'
./busybox xvzf $tb ||
whine E: failed (\$?=$?) to decompress and extract tarbal '$tb'
---8---
$ ../tar_test.sh on 1_19_4:
tar: short read
tar: short read
E: failed ($?=1) to decompress and extract tarbal '../foo'
$ ../tar_test.sh on 1_20_2:
tar: short read
tar: invalid magic
tar: short read
Wouldn't it be reasonable if tar exited with status failure on both
invalid magic and short read?
.config:
---8---
CONFIG_HAVE_DOT_CONFIG=y
CONFIG_PLATFORM_LINUX=y
CONFIG_FEATURE_BUFFERS_USE_MALLOC=y
CONFIG_SHOW_USAGE=y
CONFIG_FEATURE_VERBOSE_USAGE=y
CONFIG_FEATURE_COMPRESS_USAGE=y
CONFIG_SUBST_WCHAR=0
CONFIG_LAST_SUPPORTED_WCHAR=0
CONFIG_PID_FILE_PATH=
CONFIG_BUSYBOX_EXEC_PATH=/proc/self/exe
CONFIG_CROSS_COMPILER_PREFIX=
CONFIG_SYSROOT=
CONFIG_EXTRA_CFLAGS=
CONFIG_EXTRA_LDFLAGS=
CONFIG_EXTRA_LDLIBS=
CONFIG_DEBUG=y
CONFIG_DEBUG_PESSIMIZE=y
CONFIG_NO_DEBUG_LIB=y
CONFIG_INSTALL_APPLET_SYMLINKS=y
CONFIG_PREFIX=./_install
CONFIG_PASSWORD_MINLEN=6
CONFIG_MD5_SMALL=1
CONFIG_SHA3_SMALL=1
CONFIG_FEATURE_EDITING_MAX_LEN=0
CONFIG_FEATURE_EDITING_HISTORY=0
CONFIG_FEATURE_COPYBUF_KB=4
CONFIG_FEATURE_SEAMLESS_XZ=y
CONFIG_FEATURE_SEAMLESS_LZMA=y
CONFIG_FEATURE_SEAMLESS_BZ2=y
CONFIG_FEATURE_SEAMLESS_GZ=y
CONFIG_FEATURE_SEAMLESS_Z=y
CONFIG_GZIP_FAST=0
CONFIG_TAR=y
CONFIG_FEATURE_TAR_CREATE=y
CONFIG_FEATURE_TAR_AUTODETECT=y
CONFIG_FEATURE_TAR_FROM=y
CONFIG_FEATURE_TAR_OLDGNU_COMPATIBILITY=y
CONFIG_FEATURE_TAR_OLDSUN_COMPATIBILITY=y
CONFIG_FEATURE_TAR_GNU_EXTENSIONS=y
CONFIG_FEATURE_TAR_UNAME_GNAME=y
CONFIG_FEATURE_TAR_NOPRESERVE_TIME=y
CONFIG_DEFAULT_SETFONT_DIR=
CONFIG_FEATURE_VI_MAX_LEN=0
CONFIG_TELINIT_PATH=
CONFIG_FEATURE_KILL_DELAY=0
CONFIG_INIT_TERMINAL_TYPE=
CONFIG_FIRST_SYSTEM_ID=0
CONFIG_LAST_SYSTEM_ID=0
CONFIG_FEATURE_DEFAULT_PASSWD_ALGO=
CONFIG_DEFAULT_MODULES_DIR=
CONFIG_DEFAULT_DEPMOD_FILE=
CONFIG_FEATURE_LESS_MAXLINES=0
CONFIG_FEATURE_BEEP_FREQ=0
CONFIG_FEATURE_BEEP_LENGTH_MS=0
CONFIG_FEATURE_CROND_DIR=
CONFIG_IFUPDOWN_IFSTATE_PATH=
CONFIG_DHCPD_LEASES_FILE=
CONFIG_UDHCP_DEBUG=0
CONFIG_UDHCPC_DEFAULT_SCRIPT=
CONFIG_UDHCPC_SLACK_FOR_BUGGY_SERVERS=0
CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS=
CONFIG_FEATURE_MIME_CHARSET=
CONFIG_SV_DEFAULT_SERVICE_DIR=
CONFIG_FEATURE_SH_IS_NONE=y
CONFIG_FEATURE_BASH_IS_NONE=y
CONFIG_FEATURE_SYSLOGD_READ_BUFFER_SIZE=0
CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=0
---8---
Thoughts?
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: Information needed - ash
On Thu, 24 Oct 2013, Denys Vlasenko wrote:
On Wed, Oct 23, 2013 at 6:53 PM, Pravesh Raja Jindal
pravesh.jin...@gmail.com wrote:
I am using ash as a part of BusyBox system and want to know if ash
supports any rc file for running scripts at the shell start up to set
up environment variables, etc just like we have .bashrc for bash
shell.
Yes, it does.
Come on... Give the guy more of your arm ;)
13107-/*
13108: * Read /etc/profile or .profile.
13109- */
13110-static void
13111-read_profile(const char *name)
--
13223- const char *hp;
13224-
13225- state = 1;
13226: read_profile(/etc/profile);
13227- state1:
13228- state = 2;
13229- hp = lookupvar(HOME);
13230- if (hp) {
13231: hp = concat_path_file(hp, .profile);
13232- read_profile(hp);
13233- free((char*)hp);
13234- }
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: Ash internal 'read' command and pipes
On Wed, 9 Oct 2013, Xabier Oneca -- xOneca wrote:
I am new here, in the list.
I wonder if 'read' can read from pipes, because the following should
print 'testing' but instead 'got' remains undefined...
$ echo testing | read got
$ echo $got
In your example, variable $got exists only in a subshell.
Are these examples enough to explain why?
$ { echo main shell 2; echo testing; } | { read got; echo subshell: $got
2; }; { echo main shell 2; echo $got; }
This should as you expect it to.
$ read got -EOF
$(echo testing)
EOF
$ echo $got
testing
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: remote syslog
On Wed, 27 Feb 2013, Jonh Wendell wrote: so, what would be more appropriate? 1) do the same logic as we do with local log: apply the filter before sending messages to servers; 2) leave it as it is (sending ALL messages to remote servers) 3) make it configurable (as a command line switch or configure option?), letting the user to choose between 1) and 2). 3) seems to be the obvious choice, doesn't it? Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] mount, cifs bug in 1.20.2 Kernel 3.3.7
Let me bump this patch one more time Denys, now that you seem being back into busybox maintainership ;) On Tue, 30 Oct 2012, Martin Santesson wrote: On Fri, 26 Oct 2012, Nuno Lucas wrote: Hello, On Wed, Oct 24, 2012 at 10:27 AM, bb...@gmx.de wrote: Hi, I have the following problem: -Busybox 1.20.2 (Buildroot 2012.08) -Target Kernel: 3.4.7 on Target: mount -t cifs //server/share /destination -o username=xxx,password=xxx result (terminal): mount: mounting //server/share /destination failed: Invalid argument result(dmesg): CIFS VFS: Connecting to DFS root not implemented yet when i use kernel 3.3.7 everything is fine. Same problem with kernel 3.4.15 and 3.6.3. When I use buildroot cifs-utils (mount.cifs) instead of busybox mount everything is fine. I got this problem some time ago, too. Someone in kernel land decided that the option unc=\\machine\share is now mandatory since 3.4. It seems to ignore the Unix-style share passed as parameter and only care about the unc option (which must have the windows style '\\'s). I didn't thought much about it (it's a regression in the kernel, but it's too late in the game now), and that's how I worked around it. Regards, ~Nuno Lucas Hi, I also ran into this problem. I wrote a patch which supplies the unc option the kernel. Tested with Linux kernel 2.6.35, 3.2 (prior to mandatory unc option) and 3.4. Please have a look at my patch and let me know if it needs to be revised. Regards, Martin From fa16a76caebf1dfda1db81f0885e101624ac1462 Mon Sep 17 00:00:00 2001 From: Martin Santesson marti...@axis.com Date: Fri, 26 Oct 2012 09:40:04 +0200 Subject: [PATCH] mount: add unc option to CIFS mount (needed for Linux 3.4+) unc option for CIFS mount is mandatory after CIFS option parsing was rewritten in Linux 3.4 Signed-off-by: Martin Santesson marti...@axis.com --- busybox/util-linux/mount.c | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/busybox/util-linux/mount.c b/busybox/util-linux/mount.c index 0f213bb..d990ebc 100644 --- a/busybox/util-linux/mount.c +++ b/busybox/util-linux/mount.c @@ -1638,7 +1638,7 @@ static int singlemount(struct mntent *mp, intignore_busy) int len; char c; len_and_sockaddr *lsa; - char *hostname, *dotted, *ip; + char *hostname, *dotted, *ip, *share, *unc; hostname = mp-mnt_fsname + 2; len = strcspn(hostname, /\\); @@ -1646,6 +1646,15 @@ static int singlemount(struct mntent *mp, intignore_busy) goto report_error; c = hostname[len]; hostname[len] = '\0'; + + share = hostname + len + 1; + if (share[0] == '\0') + goto report_error; + // Insert unc=\\hostname\share option into options + unc = xasprintf(unc=%s\\%s, hostname, share); + parse_mount_options(unc, filteropts); + if (ENABLE_FEATURE_CLEAN_UP) free(unc); + lsa = host2sockaddr(hostname, 0); hostname[len] = c; if (!lsa) Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] mount, cifs bug in 1.20.2 Kernel 3.3.7
Denys? On Mon, 12 Nov 2012, Martin Santesson wrote: On 10/30/2012 03:53 PM, Martin Santesson wrote: Hi, I also ran into this problem. I wrote a patch which supplies the unc option the kernel. Tested with Linux kernel 2.6.35, 3.2 (prior to mandatory unc option) and 3.4. Please have a look at my patch and let me know if it needs to be revised. Regards, Martin From fa16a76caebf1dfda1db81f0885e101624ac1462 Mon Sep 17 00:00:00 2001 From: Martin Santessonmarti...@axis.com Date: Fri, 26 Oct 2012 09:40:04 +0200 Subject: [PATCH] mount: add unc option to CIFS mount (needed for Linux 3.4+) unc option for CIFS mount is mandatory after CIFS option parsing was rewritten in Linux 3.4 Signed-off-by: Martin Santessonmarti...@axis.com --- busybox/util-linux/mount.c | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/busybox/util-linux/mount.c b/busybox/util-linux/mount.c index 0f213bb..d990ebc 100644 --- a/busybox/util-linux/mount.c +++ b/busybox/util-linux/mount.c @@ -1638,7 +1638,7 @@ static int singlemount(struct mntent *mp, int ignore_busy) int len; char c; len_and_sockaddr *lsa; - char *hostname, *dotted, *ip; + char *hostname, *dotted, *ip, *share, *unc; hostname = mp-mnt_fsname + 2; len = strcspn(hostname, /\\); @@ -1646,6 +1646,15 @@ static int singlemount(struct mntent *mp, int ignore_busy) goto report_error; c = hostname[len]; hostname[len] = '\0'; + + share = hostname + len + 1; + if (share[0] == '\0') + goto report_error; + // Insert unc=\\hostname\share option into options + unc = xasprintf(unc=%s\\%s, hostname, share); + parse_mount_options(unc,filteropts); + if (ENABLE_FEATURE_CLEAN_UP) free(unc); + lsa = host2sockaddr(hostname, 0); hostname[len] = c; if (!lsa) Any other feedback on this patch? Any chanse of applying this? Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Is there a detailed manual for busyboxs ash?
On Mon, 25 Jun 2012, Walter Dnes wrote: On Mon, Jun 25, 2012 at 09:04:38PM +0200, Alexander Kriegisch wrote or read this: http://linux.die.net/man/1/dash Thanks. I now have the automount+autounmount script working under busybox ash. Turns out I only had one bash-specific feature in the original script. I'll test it on my home machine for a few days and then release it. I's intended for the Gentoo mailing list. Would it be of interest to the busybox list or any wiki it may have? Debian has something called /usr/bin/checkbashisms in a package called 'devscripts'. It's an almost selfcontained perl script. It does what it says it would. I do use it regulary. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [BUG] vi misbehaves on pasted text
On Mon, 11 Jun 2012, Denys Vlasenko wrote:
I checked what ncurses uses, and it seems that vi can be made to do
the same with these two write1() calls in vi_main():
// Save cursor, use alternate screen buffer, clear screen
write1(\033[?1049h);
while (1) {
edit_file(argv[optind]); /* param might be NULL */
if (++optind = argc)
break;
}
// Use normal screen buffer, restore cursor
write1(\033[?1049l);
I think we can risk using it.
Shouldn't these be also nuked?
./configs/TEST_nommu_defconfig:344:CONFIG_FEATURE_VI_OPTIMIZE_CURSOR=y
./configs/TEST_noprintf_defconfig:349:# CONFIG_FEATURE_VI_OPTIMIZE_CURSOR is
not set
./configs/TEST_rh9_defconfig:361:CONFIG_FEATURE_VI_OPTIMIZE_CURSOR=y
./configs/android2_defconfig:366:# CONFIG_FEATURE_VI_OPTIMIZE_CURSOR is not set
./configs/android_defconfig:389:CONFIG_FEATURE_VI_OPTIMIZE_CURSOR=y
./configs/android_ndk_defconfig:374:CONFIG_FEATURE_VI_OPTIMIZE_CURSOR=y
./configs/cygwin_defconfig:366:CONFIG_FEATURE_VI_OPTIMIZE_CURSOR=y
./configs/freebsd_defconfig:370:CONFIG_FEATURE_VI_OPTIMIZE_CURSOR=y
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: `netstat -ntp` odd 'Program name' presentation
On Sat, 21 Apr 2012, Cristian Ionescu-Idbohrn wrote:
The 'Program name' part is fetched from /proc/pid/cmdline, then mangled
before presentation. Mangling is done in netstat.c, function 'dir_act'.
The function assumes cmdline is a file path and extracts the basename.
Obviously that assumption is not always correct. It's not unusual a
cmdline looks like this:
sshd: foo@pts/48
or like this:
sshd: foo [priv]
Function 'bb_basename' uses strrchr everything up to and including the
last occurrence och character '/'. The result is (see first example
above):
PID/Program name
12345/48
or (second example):
PID/Program name
12345/sshd: foo [priv]
Neither is desirable.
I'd like to propose a different way to do that:
1. strip everything after and including the first whitespace character
2. maybe remove even odd ':' character at the end of the string
3. call bb_basename after that
Output would then look like:
PID/Program name
12345/sshd
which is what one would expect.
Thoughts?
Would this fit in somewhere?
[PATCH] Mangle 'Program name' to show the right thing.
Signed-off-by: Cristian Ionescu-Idbohrn cristian.ionescu-idbo...@axis.com
---
networking/netstat.c |8
1 file changed, 8 insertions(+)
diff --git a/networking/netstat.c b/networking/netstat.c
index 9c23957..31131cd 100644
--- a/networking/netstat.c
+++ b/networking/netstat.c
@@ -288,6 +288,14 @@ static int FAST_FUNC dir_act(const char *fileName,
if (n 0)
return FALSE;
cmdline_buf[n] = '\0';
+ {
+ char *cp = strchr(cmdline_buf, ' ');
+ if (cp)
+ *cp = '\0';
+ cp = strrchr(cmdline_buf, ':');
+ if (cp)
+ *cp = '\0';
+ }
/* go through all files in /proc/PID/fd and check whether they are
sockets */
strcpy(proc_pid_fname + len - (sizeof(cmdline)-1), fd);
--
1.7.10
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: `netstat -ntp` odd 'Program name' presentation
On Sun, 22 Apr 2012, Ralf Friedl wrote: I agree that sshd: foo@pts/48 should not be truncated to 48, which net-tools-1.60 netstat unfortunately does. Right. I'm open to any other suggestion that make 'Program name' useful. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
`netstat -ntp` odd 'Program name' presentation
The 'Program name' part is fetched from /proc/pid/cmdline, then mangled before presentation. Mangling is done in netstat.c, function 'dir_act'. The function assumes cmdline is a file path and extracts the basename. Obviously that assumption is not always correct. It's not unusual a cmdline looks like this: sshd: foo@pts/48 or like this: sshd: foo [priv] Function 'bb_basename' uses strrchr everything up to and including the last occurrence och character '/'. The result is (see first example above): PID/Program name 12345/48 or (second example): PID/Program name 12345/sshd: foo [priv] Neither is desirable. I'd like to propose a different way to do that: 1. strip everything after and including the first whitespace character 2. maybe remove even odd ':' character at the end of the string 3. call bb_basename after that Output would then look like: PID/Program name 12345/sshd which is what one would expect. Thoughts? Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] klogd: Handle facility too when reading from /proc/kmsg
On Sat, 21 Jan 2012, Denys Vlasenko wrote: On Friday 20 January 2012 23:03, Cristian Ionescu-Idbohrn wrote: On Fri, 20 Jan 2012, Denys Vlasenko wrote: On Tue, Dec 27, 2011 at 2:46 PM, Karol Lewandowski k.lewando...@samsung.com wrote: Support userspace applications like udev and systemd logging directly to kernel's log buffer. I hate systemd. Control your feelings. Hate is low. This is not the proper place/time. I don't understand why I need to support its idiotic design decisions. Feelings aside, because it's here and catched enough attention and it isn't about you. Sorry, I am not ready to accept whatever is forced down my throat. Now, that's a better argument ;) The problem is that systemd was sold as a better replacement of init (and it indeed has some valuable ideas in that area), but it infiltrates other areas of userspace whcih have absolutely nothing to do with init and service monitoring job. And that one even better. Here are helper programs systemd installs on Fedora machine: $ ls -l /lib/systemd/systemd* [...] and it does use many of them! Tell me, what can possibly systemd-localed have with better init and servce monitoring tool? Or systemd-reply-password? Or systemd-fsck? Etc... Replacements for existing init-scripts on desktops? I can't see any reason why busybox should support any of that, either. If systemd needs more than replacing /sbin/init, they're free to fork busybox and/or maintain an invasive patch that hooks those nice features into busybox. It seems that the fact that systemd was accepted into a few Linux distributions is used by systemd people as a backdoor to supplant many other packages, without consent or even knowledge of the people affected. Indeed, that seems to be the stategy. World domination ;) And it is not an accident. These people do it on purpose. They build a platform. I have no problem with anyone building something. I have a problem when someone forces this something on me. Pitty you feel that way. A NAK (and ignoring further requests) should be sufficient. Any lobbying going on in the background? So, how about me playing by these rules? I don't like ifup, so I'll remove it from busybox. And, btw, I don't like init, I think runsvdir is better. Get ready to say goodbye to init too. And, btw, getty will be gone too: use stty + login. I have many more of this in store. Would you like this? Don't forget, it was not _me_ that asked for that sort of thing. It was the OP, Karol Lewandowski k.lewando...@samsung.com. Found [1] another interesting proposal authored by the same man, that kindof supports the world domination theory ;) Solution seems rather simple - configure bash with --wihout-bash-malloc to use system/glibc-provided malloc. But, seriously... Just forget the whole episode, if you can. You're doing good work with busybox. Thanks. [1] http://bugs.debian.org/613803 Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] klogd: Handle facility too when reading from /proc/kmsg
On Fri, 20 Jan 2012, Denys Vlasenko wrote: On Tue, Dec 27, 2011 at 2:46 PM, Karol Lewandowski k.lewando...@samsung.com wrote: Support userspace applications like udev and systemd logging directly to kernel's log buffer. I hate systemd. Control your feelings. Hate is low. This is not the proper place/time. I don't understand why I need to support its idiotic design decisions. Feelings aside, because it's here and catched enough attention and it isn't about you. It's about users. Trying to accomodate/enlighten them might make the difference, or not. There may be problems in doing that. What are those problems? Try open our eyes. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: sed issue
On Fri, 13 Jan 2012, Bernd Petrovitsch wrote:
On Fre, 2012-01-13 at 10:28 +0100, Natanael Copa wrote:
[...]
When building xen it fails with a sed expression. Building with
GNU sed works.
What busybox version was that?
$ busybox sed -n
's,^\#define[[:space:]]\{1\,\}BOOT_TRAMPOLINE[[:space:]]\{1\,\},,p'
sed: bad regex
'^\#define[[:space:]]\{1\,\}BOOT_TRAMPOLINE[[:space:]]\{1\,\}':
Invalid content of \{\}
The line looks over-quoted as it is in single quotes and IMHO the
following was actually intended (or do I just miss a quoting level):
's,^#define[[:space:]]{1,}BOOT_TRAMPOLINE[[:space:]]{1,},,p'
I have not investigated if the sed line could be rewritten in a
standards compliant way or if its a bug in busybox sed.
{1,} is equivalent to +, so
's/^#define[[:space:]]+BOOT_TRAMPOLINE[[:space:]]+//p'
That's extended regex, so a '-r' is required.
should be equivalent (and since we have no path names, we can use /).
Or a more neutral delimiter, like '|'. And I don't think you want to
use character class '[:space:]'. What you're should use is
'[:blank:]'. A more robust regex:
$ busybox sed -rne \
's|^[[:blank:]]*#[[:blank:]]*define[[:blank:]]+BOOT_TRAMPOLINE[[:blank:]]+||p'
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: sed issue
On Fri, 13 Jan 2012, Natanael Copa wrote:
On Fri, Jan 13, 2012 at 12:16 PM, Cristian Ionescu-Idbohrn
cristian.ionescu-idbo...@axis.com wrote:
What busybox version was that?
busybox v1.19.3
awk is more readable...
awk '$1 == #define $2 == BOOT_TRAMPOLINE {print $3}'
Matter of taste, but it's a bigger hammer :)
I think I'll got with as little intrusive patch as possible for xen
upstream.
Right. Still, question remains: what's wrong with:
$ busybox sed -n
's,^\#define[[:space:]]\{1\,\}BOOT_TRAMPOLINE[[:space:]]\{1\,\},,p'
sed: bad regex
'^\#define[[:space:]]\{1\,\}BOOT_TRAMPOLINE[[:space:]]\{1\,\}':
Invalid content of \{\}
Should work with busybox too. Even if ',' is used as separator, it's IMO
corectly escaped in range '\{1\,\}'. Thoughts?
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: sed issue
On Fri, 13 Jan 2012, Natanael Copa wrote:
happens with both.
$ bash -c busybox sed -n
's,^\#define[[:space:]]\{1\,\}BOOT_TRAMPOLINE[[:space:]]\{1\,\},,p'
sed: bad regex '^\#define[[:space:]]\{1\,\}BOOT_TRAMPOLINE[[:space:]]\{1\,\}':
Invalid content of \{\}
Now, wait a second. I don't se that. busybox master top-dir:
$ bash -c ./busybox sed -ne \
's,^[[:blank:]]*\#[[:blank:]]*define[[:blank:]]\{1\,\}BB_DIR_USR_SBIN[[:blank:]]\{1\,\},,p'
\
include/applets.h
BB_DIR_SBIN
$ sed -ne \
's,^[[:blank:]]*\#[[:blank:]]*define[[:blank:]]\{1\,\}BB_DIR_USR_SBIN[[:blank:]]\{1\,\},,p'
\
include/applets.h
BB_DIR_SBIN
$ ./busybox sed -ne \
's,^[[:blank:]]*\#[[:blank:]]*define[[:blank:]]\{1\,\}BB_DIR_USR_SBIN[[:blank:]]\{1\,\},,p'
\
include/applets.h
BB_DIR_SBIN
How does that '#define BOOT_TRAMPOLINE ...' look like in original?
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: sed issue
On Sat, 14 Jan 2012, Cristian Ionescu-Idbohrn wrote:
On Fri, 13 Jan 2012, Natanael Copa wrote:
happens with both.
$ bash -c busybox sed -n
's,^\#define[[:space:]]\{1\,\}BOOT_TRAMPOLINE[[:space:]]\{1\,\},,p'
sed: bad regex
'^\#define[[:space:]]\{1\,\}BOOT_TRAMPOLINE[[:space:]]\{1\,\}':
Invalid content of \{\}
Now, wait a second. I don't se that. busybox master top-dir:
$ bash -c ./busybox sed -ne \
's,^[[:blank:]]*\#[[:blank:]]*define[[:blank:]]\{1\,\}BB_DIR_USR_SBIN[[:blank:]]\{1\,\},,p'
\
include/applets.h
BB_DIR_SBIN
$ sed -ne \
's,^[[:blank:]]*\#[[:blank:]]*define[[:blank:]]\{1\,\}BB_DIR_USR_SBIN[[:blank:]]\{1\,\},,p'
\
include/applets.h
BB_DIR_SBIN
$ ./busybox sed -ne \
's,^[[:blank:]]*\#[[:blank:]]*define[[:blank:]]\{1\,\}BB_DIR_USR_SBIN[[:blank:]]\{1\,\},,p'
\
include/applets.h
BB_DIR_SBIN
How does that '#define BOOT_TRAMPOLINE ...' look like in original?
On Sat, 14 Jan 2012, Alexander Kriegisch wrote:
How does that '#define BOOT_TRAMPOLINE ...' look like in original?
I had googled it up earlier and used it in my previous posting. Check it out.
Right.
Now, the original sed regex works with all:
GNU sed version 4.2.1
busybox v1.20.0.git, sed
bash version 4.2.20 around busybox sed above
Would seem to be a bug both in your bash and busybox v1.19.3.
What's your command line shell/bash shell version?
I stongly suspect some king of escaping bug in your login shell.
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: busybox 1.19.3 cp bug w.r.t device files?
On Wed, 21 Dec 2011, Denys Vlasenko wrote: On Wed, Dec 21, 2011 at 2:38 PM, Joakim Tjernlund joakim.tjernl...@transmode.se wrote: Denys Vlasenko vda.li...@googlemail.com wrote on 2011/12/21 13:08:30: On Wed, Dec 21, 2011 at 12:31 PM, Joakim Tjernlund joakim.tjernl...@transmode.se wrote: Recently installed bb 1.19.3 (gentoo) on our ppc target. Today I discovered that cp vmlinux /dev/mtdblock5 dosn't work. The device file is removed and a new plain file is created instead. Feels like a bb bug, comments? config FEATURE_NON_POSIX_CP bool Non-POSIX, but safer, copying to special nodes default y help With this option, cp file symlink will delete symlink and create a regular file. This does not conform to POSIX, but prevents a symlink attack. Similarly, cp file device will not send file's data to the device. (To do that, use cat file device) Not 100% sure how to read this. I have CONFIG_FEATURE_NON_POSIX_CP=y already. Should I change to CONFIG_FEATURE_NON_POSIX_CP=n? Yes. (however, I personally think it's better to use cat, not cp, for the operation you are trying to perform) 'dd' (with optimal bs) can be yet another alternative. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
