Re: [PATCH] less: further tweaks to regular file detection
Applied, thanks!
On Fri, Jul 31, 2015 at 6:33 PM, Ron Yorston r...@pobox.com wrote:
Test explicitly for REOPEN flags: update_num_lines is called
unconditionally so (num_lines != NOT_REGULAR_FILE) is also true when
num_lines contains a valid number of lines.
The call to fstat doesn't need to be in #if ENABLE_FEATURE_LESS_FLAGS:
the whole function is already in such a test.
Signed-off-by: Ron Yorston r...@pobox.com
---
miscutils/less.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/miscutils/less.c b/miscutils/less.c
index be8d20e..7a441bf 100644
--- a/miscutils/less.c
+++ b/miscutils/less.c
@@ -615,11 +615,12 @@ static int safe_lineno(int fline)
static void update_num_lines(void)
{
int count, fd;
+ struct stat stbuf;
ssize_t len, i;
char buf[4096];
/* only do this for regular files */
- if (num_lines != NOT_REGULAR_FILE) {
+ if (num_lines == REOPEN_AND_COUNT || num_lines == REOPEN_STDIN) {
count = 0;
fd = open(/proc/self/fd/0, O_RDONLY);
if (fd 0 num_lines == REOPEN_AND_COUNT) {
@@ -631,17 +632,10 @@ static void update_num_lines(void)
num_lines = NOT_REGULAR_FILE;
return;
}
-#if ENABLE_FEATURE_LESS_FLAGS
- {
- struct stat stbuf;
- if (fstat(fd, stbuf) != 0
-|| !S_ISREG(stbuf.st_mode)
- ) {
- num_lines = NOT_REGULAR_FILE;
- goto do_close;
- }
+ if (fstat(fd, stbuf) != 0 || !S_ISREG(stbuf.st_mode)) {
+ num_lines = NOT_REGULAR_FILE;
+ goto do_close;
}
-#endif
while ((len = safe_read(fd, buf, sizeof(buf))) 0) {
for (i = 0; i len; ++i) {
if (buf[i] == '\n' ++count == MAXLINES)
--
2.4.3
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: command chpasswd on busybox 1.17.3
On Mon, Jul 20, 2015 at 6:02 PM, ANTOINE ROUQUETTE
antoine@gmail.com wrote:
Hi everyone,
My question is has followed :
when I use chpasswd command, the option -e allow me to supply password in
encrypted form. How do I know which encryption form I should use for this
command?
You can use any encryption. chpasswd will simply take your
(presumably encrypted) password and insert it into
/etc/{passwd,shadow}. It will not analyze it to see which encryption
was used.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH RESEND] mdev: fix sysfs traversal with CONFIG_SYSFS_DEPRECATED_V2=y
On Wed, Jul 15, 2015 at 11:10 PM, Gregory Fong gregory.0...@gmail.com wrote:
From: Simon Edlund si...@edlund.nl
When mdev -s traverses the /sys directory looking for dev files, it
starts with the block devices under /sys/block, and will find the dev
file through the symlink, and create a block device node. In the next
stage it will scan the /sys/class looking for char devices, and will
find mtdX/dev again, but this time the mknod will fail because there is
already a device node with that name.
By swapping recursive_action(/sys/class) and
recursive_action(/sys/block), now the same thing will happen
when the second scan is done.
Why this is better?
[gregory: added commit message to patch from BZ #6806]
Signed-off-by: Gregory Fong gregory.0...@gmail.com
---
util-linux/mdev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/util-linux/mdev.c b/util-linux/mdev.c
index ca4b915..4495b0a 100644
--- a/util-linux/mdev.c
+++ b/util-linux/mdev.c
@@ -1063,6 +1063,9 @@ int mdev_main(int argc UNUSED_PARAM, char **argv)
putenv((char*)ACTION=add);
+ recursive_action(/sys/class,
+ ACTION_RECURSE | ACTION_FOLLOWLINKS,
+ fileAction, dirAction, temp, 0);
/* ACTION_FOLLOWLINKS is needed since in newer kernels
* /sys/block/loop* (for example) are symlinks to dirs,
* not real directories.
@@ -1079,9 +1082,6 @@ int mdev_main(int argc UNUSED_PARAM, char **argv)
ACTION_RECURSE | ACTION_FOLLOWLINKS |
ACTION_QUIET,
fileAction, dirAction, temp, 0);
}
- recursive_action(/sys/class,
- ACTION_RECURSE | ACTION_FOLLOWLINKS,
- fileAction, dirAction, temp, 0);
} else {
char *fw;
char *seq;
--
1.9.1
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] uname: make OS name configurable
Applied, thanks!
On Sun, Jul 12, 2015 at 5:06 PM, Ron Yorston r...@frippery.org wrote:
A mailing list thread in September 2013 discussed changing the string
returned by the non-POSIX 'uname -o' option. Nothing ever came of this
because there was no agreement as to what the string should be.
Make the string configurable so that people can decide for themselves.
Signed-off-by: Ron Yorston r...@pobox.com
---
coreutils/Config.src | 8
coreutils/uname.c| 4 ++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/coreutils/Config.src b/coreutils/Config.src
index 1ec3a0a..3315623 100644
--- a/coreutils/Config.src
+++ b/coreutils/Config.src
@@ -636,6 +636,14 @@ config UNAME
help
uname is used to print system information.
+config UNAME_OSNAME
+ string Operating system name
+ default GNU/Linux
+ depends on UNAME
+ help
+ Sets the operating system name reported by uname -o. The
+ default is GNU/Linux.
+
config UNEXPAND
bool unexpand
default y
diff --git a/coreutils/uname.c b/coreutils/uname.c
index 1c6aa5f..fd677d2 100644
--- a/coreutils/uname.c
+++ b/coreutils/uname.c
@@ -74,7 +74,7 @@ typedef struct {
struct utsname name;
char processor[sizeof(((struct utsname*)NULL)-machine)];
char platform[sizeof(((struct utsname*)NULL)-machine)];
- char os[sizeof(GNU/Linux)];
+ char os[sizeof(CONFIG_UNAME_OSNAME)];
} uname_info_t;
static const char options[] ALIGN1 = snrvmpioa;
@@ -141,7 +141,7 @@ int uname_main(int argc UNUSED_PARAM, char **argv)
#endif
strcpy(uname_info.processor, unknown_str);
strcpy(uname_info.platform, unknown_str);
- strcpy(uname_info.os, GNU/Linux);
+ strcpy(uname_info.os, CONFIG_UNAME_OSNAME);
#if 0
/* Fedora does something like this */
strcpy(uname_info.processor, uname_info.name.machine);
--
2.4.3
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH RESEND] mdev: fix sysfs traversal with CONFIG_SYSFS_DEPRECATED_V2=y
Hmm. This is strikingly similar in purpose to the patch that I sent a couple months ago (mdev -s: don't mistake inter-device symlinks for separate devices; using a different approach; it wasn't clear to me whether just disabling symlink-traversal entirely was the right thing, but skipping the device symlinks did seem to be right even if it was too narrow in scope). I guess I'm one of the several people you mentioned in your follow-up patch :) On 2015-08-03 17:17, Gregory Fong wrote: On Mon, Aug 3, 2015 at 9:07 AM, Denys Vlasenko vda.li...@googlemail.com wrote: On Wed, Jul 15, 2015 at 11:10 PM, Gregory Fong gregory.0...@gmail.com wrote: From: Simon Edlund si...@edlund.nl When mdev -s traverses the /sys directory looking for dev files, it starts with the block devices under /sys/block, and will find the dev file through the symlink, and create a block device node. In the next stage it will scan the /sys/class looking for char devices, and will find mtdX/dev again, but this time the mknod will fail because there is already a device node with that name. By swapping recursive_action(/sys/class) and recursive_action(/sys/block), now the same thing will happen when the second scan is done. Why this is better? This is better because if you're using a newer kernel with both CONFIG_SYSFS_DEPRECATED=y (and CONFIG_SYSFS_DEPRECATED_V2=y to enable it), then where traversing /sys/block with the deprecated layout: - /sys/block/mtdblock0 is not a symlink, but an actual directory - /sys/block/mtdblock0/device is a symlink to mtd0 IOW, on deprecated sysfs: # ls -l /sys/block/mtdblock0 -r--r--r--1 root root 4096 Jan 1 00:00 alignment_offset lrwxrwxrwx1 root root 0 Jan 1 00:00 bdi - ../../devices/virtual/bdi/31:0 -r--r--r--1 root root 4096 Jan 1 00:00 capability -r--r--r--1 root root 4096 Jan 1 00:00 dev lrwxrwxrwx1 root root 0 Jan 1 00:00 device - ../../devices/platform/brcmnand.0/mtd/mtd0 -r--r--r--1 root root 4096 Jan 1 00:00 discard_alignment -r--r--r--1 root root 4096 Jan 1 00:00 ext_range drwxr-xr-x2 root root 0 Jan 1 00:00 holders -r--r--r--1 root root 4096 Jan 1 00:00 inflight drwxr-xr-x2 root root 0 Jan 1 00:00 power drwxr-xr-x3 root root 0 Jan 1 00:00 queue -r--r--r--1 root root 4096 Jan 1 00:00 range -r--r--r--1 root root 4096 Jan 1 00:00 removable -r--r--r--1 root root 4096 Jan 1 00:00 ro -r--r--r--1 root root 4096 Jan 1 00:00 size drwxr-xr-x2 root root 0 Jan 1 00:00 slaves -r--r--r--1 root root 4096 Jan 1 00:00 stat lrwxrwxrwx1 root root 0 Jan 1 00:00 subsystem - ../../block -rw-r--r--1 root root 4096 Jan 1 00:00 uevent On non-deprecated sysfs: # ls -l /sys/block/mtdblock0 lrwxrwxrwx1 root root 0 Jan 3 18:57 /sys/block/mtdblock0 - ../devices/platform/rdb/f03e2800.nand/mtd/mtd0/mtdblock0 Now, I hadn't really investigated the problem carefully enough until now. This patch simply solved a real problem for us when using CONFIG_SYSFS_DEPRECATED, and I figured that submitting it would be at least a good starting point for someone who actually understands this better to figure out a better fix. But let's see... since recursive_action is called with ACTION_FOLLOWLINKS, it will end up checking both /sys/block/mtdblock0/dev and /sys/block/mtdblock0/device/dev and creating block devices for both of those. That's not correct. So I think I now have a real fix here, which is to change the recursive_action call that will only be invoked if CONFIG_SYSFS_DEPRECATED=y. In that case, we _shouldn't_ need to follow symlinks because everything in the top level of /sys/block/ will be a real directory, and following them will result in the aforementioned problem. It was a bit surprising to me that this problem isn't also seen with /sys/class/block, since that has the same hierarchy where it could follow the link and get to /sys/class/block/mtdblock0/device/dev, but looking at recursive_action(), it appears that links are only followed where depth == 0, which would explain that. I'm stuck using the gmail interface right now and so can't copy and paste the new patch inline... will send to the list shortly. Best regards, Gregory [gregory: added commit message to patch from BZ #6806] Signed-off-by: Gregory Fong gregory.0...@gmail.com --- util-linux/mdev.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/util-linux/mdev.c b/util-linux/mdev.c index ca4b915..4495b0a 100644 --- a/util-linux/mdev.c +++ b/util-linux/mdev.c @@ -1063,6 +1063,9 @@ int mdev_main(int argc UNUSED_PARAM, char **argv)
Re: zcip, link-local ARP responses
On Tue, Jul 21, 2015 at 2:03 PM, dbextern db_ext...@gmx.de wrote: Hello! For our link local functionality I'm using udhcpc together with zcip out of busybox on a Blackfin BF-537 CPU without MMU. The base functionality is there. But when I connect two networks with stable IP addresses, and both networks had the same IP(s) in them, the conflict stays unresolved. My setup is one master PC or MAC and several embedded boards. What I would expect (following RFC3927 https://tools.ietf.org/html/rfc3927#page-10[https://3c.gmx.net/mail/client/dereferrer?redirectUrl=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc3927%23page-10]; chapter 2.x and 4) is that after a while the ARP messages will resolve the problem because the still running zcip sees ARP responses on it's own IP and reacts accordingly. What really happens is: * Windows only sends broadcast ARP requests as long as it never got an answer. After that there is only unicast. And the requested device answers with a unicast as well. * the MAC always sends broadcasts. And both embedded devices with the conflicting IP answer. But with a unicast ARP reply to the MAC. As I understand the specification (last paragraph in chapter 2.5) then all ARP messages between devices with link local addresses should be link layer broadcasts. Did I get that right? And if yes, why does zcip not follow that rule? zcip does use bcast for all packets it sends: # tcpdump -nliwlan0 -s0 -vv -e arp tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes zcip runs 02:49:51.078369 00:04:e2:64:23:c2 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 169.254.194.171 tell 0.0.0.0 02:49:52.391711 00:04:e2:64:23:c2 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 169.254.194.171 tell 0.0.0.0 02:49:54.254628 00:04:e2:64:23:c2 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 169.254.194.171 tell 0.0.0.0 02:49:55.305731 00:04:e2:64:23:c2 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 169.254.194.171 (00:04:e2:64:23:c2) tell 169.254.194.171 02:49:57.307788 00:04:e2:64:23:c2 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 169.254.194.171 (00:04:e2:64:23:c2) tell 169.254.194.171 02:49:59.309844 00:04:e2:64:23:c2 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 169.254.194.171 (00:04:e2:64:23:c2) tell 169.254.194.171 And a more general question: when I handle an ARP packet in zcip, how does the kernel know not to work on it as well? I don't know... ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: osuosl.org and Spamhaus PBL
On Wed, Jul 22, 2015 at 03:16:15PM +0200, Laurent Bercot wrote: X-Greylist: delayed 00:06:59 by SQLgrey-1.7.6 (For the record, I read the headers wrong, and it's osuosl.org that actually performs that greylisting. My apologies to Numericable, for once I accused them wrongly. Now to understand what that greylisting does for osuosl.org... if they're using PBL in the first place, and only accept SMTP connections from known ISP servers... oh well, some things are best left unexplained.) Greylisting (at least if passing results are cached) is a lot less hostile than outright blocking, but I share your sentiment and would strongly prefer that this list (and in general, all mail services used by multiple users, some of whom may not want this hostile blocking) not use the PBL. I've even had my (non-dynamic, business class) IP addresses blocked by it in the past and nearly had to pay ransom to get them delisted. Rich ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH RESEND] mdev: fix sysfs traversal with CONFIG_SYSFS_DEPRECATED_V2=y
On Mon, Aug 3, 2015 at 9:07 AM, Denys Vlasenko vda.li...@googlemail.com wrote: On Wed, Jul 15, 2015 at 11:10 PM, Gregory Fong gregory.0...@gmail.com wrote: From: Simon Edlund si...@edlund.nl When mdev -s traverses the /sys directory looking for dev files, it starts with the block devices under /sys/block, and will find the dev file through the symlink, and create a block device node. In the next stage it will scan the /sys/class looking for char devices, and will find mtdX/dev again, but this time the mknod will fail because there is already a device node with that name. By swapping recursive_action(/sys/class) and recursive_action(/sys/block), now the same thing will happen when the second scan is done. Why this is better? This is better because if you're using a newer kernel with both CONFIG_SYSFS_DEPRECATED=y (and CONFIG_SYSFS_DEPRECATED_V2=y to enable it), then where traversing /sys/block with the deprecated layout: - /sys/block/mtdblock0 is not a symlink, but an actual directory - /sys/block/mtdblock0/device is a symlink to mtd0 IOW, on deprecated sysfs: # ls -l /sys/block/mtdblock0 -r--r--r--1 root root 4096 Jan 1 00:00 alignment_offset lrwxrwxrwx1 root root 0 Jan 1 00:00 bdi - ../../devices/virtual/bdi/31:0 -r--r--r--1 root root 4096 Jan 1 00:00 capability -r--r--r--1 root root 4096 Jan 1 00:00 dev lrwxrwxrwx1 root root 0 Jan 1 00:00 device - ../../devices/platform/brcmnand.0/mtd/mtd0 -r--r--r--1 root root 4096 Jan 1 00:00 discard_alignment -r--r--r--1 root root 4096 Jan 1 00:00 ext_range drwxr-xr-x2 root root 0 Jan 1 00:00 holders -r--r--r--1 root root 4096 Jan 1 00:00 inflight drwxr-xr-x2 root root 0 Jan 1 00:00 power drwxr-xr-x3 root root 0 Jan 1 00:00 queue -r--r--r--1 root root 4096 Jan 1 00:00 range -r--r--r--1 root root 4096 Jan 1 00:00 removable -r--r--r--1 root root 4096 Jan 1 00:00 ro -r--r--r--1 root root 4096 Jan 1 00:00 size drwxr-xr-x2 root root 0 Jan 1 00:00 slaves -r--r--r--1 root root 4096 Jan 1 00:00 stat lrwxrwxrwx1 root root 0 Jan 1 00:00 subsystem - ../../block -rw-r--r--1 root root 4096 Jan 1 00:00 uevent On non-deprecated sysfs: # ls -l /sys/block/mtdblock0 lrwxrwxrwx1 root root 0 Jan 3 18:57 /sys/block/mtdblock0 - ../devices/platform/rdb/f03e2800.nand/mtd/mtd0/mtdblock0 Now, I hadn't really investigated the problem carefully enough until now. This patch simply solved a real problem for us when using CONFIG_SYSFS_DEPRECATED, and I figured that submitting it would be at least a good starting point for someone who actually understands this better to figure out a better fix. But let's see... since recursive_action is called with ACTION_FOLLOWLINKS, it will end up checking both /sys/block/mtdblock0/dev and /sys/block/mtdblock0/device/dev and creating block devices for both of those. That's not correct. So I think I now have a real fix here, which is to change the recursive_action call that will only be invoked if CONFIG_SYSFS_DEPRECATED=y. In that case, we _shouldn't_ need to follow symlinks because everything in the top level of /sys/block/ will be a real directory, and following them will result in the aforementioned problem. It was a bit surprising to me that this problem isn't also seen with /sys/class/block, since that has the same hierarchy where it could follow the link and get to /sys/class/block/mtdblock0/device/dev, but looking at recursive_action(), it appears that links are only followed where depth == 0, which would explain that. I'm stuck using the gmail interface right now and so can't copy and paste the new patch inline... will send to the list shortly. Best regards, Gregory [gregory: added commit message to patch from BZ #6806] Signed-off-by: Gregory Fong gregory.0...@gmail.com --- util-linux/mdev.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/util-linux/mdev.c b/util-linux/mdev.c index ca4b915..4495b0a 100644 --- a/util-linux/mdev.c +++ b/util-linux/mdev.c @@ -1063,6 +1063,9 @@ int mdev_main(int argc UNUSED_PARAM, char **argv) putenv((char*)ACTION=add); + recursive_action(/sys/class, + ACTION_RECURSE | ACTION_FOLLOWLINKS, + fileAction, dirAction, temp, 0); /* ACTION_FOLLOWLINKS is needed since in newer kernels * /sys/block/loop* (for example) are symlinks to dirs, * not real directories. @@ -1079,9 +1082,6 @@ int mdev_main(int argc UNUSED_PARAM, char **argv) ACTION_RECURSE | ACTION_FOLLOWLINKS | ACTION_QUIET,
[PATCH] mdev: don't follow deprecated sysfs /sys/block symlinks
/sys/block will only be scanned with CONFIG_SYSFS_DEPRECATED=y and
deprecated sysfs enabled (using CONFIG_SYSFS_DEPRECATED_V2=y or the
related kernel boot param). In that case, all of /sys/block/* will be
a real directory, so we don't need to follow symlinks. Additionally,
following symlinks causes a bug for mtd in this case, e.g. several
people have been seeing that /dev/mtd0 was getting created by this
traversal as a block device. Subsequent investigation revealed that
was caused by this pass following the /sys/block/mtdblock0/device
symlink and resulting in both
- /sys/block/mtdblock0/dev
- /sys/block/mtdblock0/device/dev
being used here, and the second results in that incorrect /dev/mtd0.
Change to not follow symlinks while traversing /sys/block to fix this.
Fixes BZ #6806.
Signed-off-by: Gregory Fong gregory.0...@gmail.com
Cc: Denys Vlasenko vda.li...@googlemail.com
Cc: Simon Edlund si...@edlund.nl
---
util-linux/mdev.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/util-linux/mdev.c b/util-linux/mdev.c
index ca4b915..af986a2 100644
--- a/util-linux/mdev.c
+++ b/util-linux/mdev.c
@@ -1063,22 +1063,27 @@ int mdev_main(int argc UNUSED_PARAM, char **argv)
putenv((char*)ACTION=add);
- /* ACTION_FOLLOWLINKS is needed since in newer kernels
-* /sys/block/loop* (for example) are symlinks to dirs,
-* not real directories.
-* (kernel's CONFIG_SYSFS_DEPRECATED makes them real dirs,
-* but we can't enforce that on users)
-*/
if (access(/sys/class/block, F_OK) != 0) {
/* Scan obsolete /sys/block only if /sys/class/block
* doesn't exist. Otherwise we'll have dupes.
* Also, do not complain if it doesn't exist.
* Some people configure kernel to have no blockdevs.
+*
+* Don't use ACTION_FOLLOWLINKS here. This will only be
+* run if CONFIG_SYSFS_DEPRECATED=y, in which case
+* everything at the top-level will be a real dir, and
+* following symlinks can result in the 'device'
+* symlink being followed and resulting in e.g. mtd0
+* being set up as a block dev instead of a char dev.
*/
recursive_action(/sys/block,
- ACTION_RECURSE | ACTION_FOLLOWLINKS |
ACTION_QUIET,
+ ACTION_RECURSE | ACTION_QUIET,
fileAction, dirAction, temp, 0);
}
+ /* ACTION_FOLLOWLINKS is needed since in newer kernels
+* /sys/class/block/loop* (for example) are symlinks to dirs,
+* not real directories.
+*/
recursive_action(/sys/class,
ACTION_RECURSE | ACTION_FOLLOWLINKS,
fileAction, dirAction, temp, 0);
--
1.9.1
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: osuosl.org and Spamhaus PBL
On 30 Jul 2015 05:41, Mike Frysinger wrote: the OSUOSL has kindly hosted busybox infrastructure for us for a long time now and that includes activing as admins for the mail server. they would prefer to keep admining these things since it's sitting on their network, and i have no problem deferring to them. not that i think what you describe is even an issue in the first place -- if you want to send e-mail, then don't use dynamic IPs. it's unfortunate that your ISP sucks, but that doesn't translate into us enabling a significant source of spam. ah, and the irony that e-mails to you get bounced by design and require some bs confirm app. forcing that on everyone else is pretty lame. -mike signature.asc Description: Digital signature ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH 4/5] ash: respect -p flag when command builtin is run with -v/-V
The command builtin should only check the default path, not $PATH,
when the -p flag is used along with -v/-V.
Based on commits 65ae84b (by Harald van Dijk) and 29ee27d (by Herbert
Xu) from git://git.kernel.org/pub/scm/utils/dash/dash.git).
function old new delta
commandcmd72 87 +15
describe_command 437 450 +13
typecmd 84 86 +2
--
(add/remove: 0/0 grow/shrink: 3/0 up/down: 30/0) Total: 30 bytes
Signed-off-by: Ron Yorston r...@pobox.com
---
shell/ash.c | 12
shell/ash_test/ash-misc/command.right | 1 +
shell/ash_test/ash-misc/command.tests | 1 +
3 files changed, 10 insertions(+), 4 deletions(-)
create mode 100644 shell/ash_test/ash-misc/command.right
create mode 100755 shell/ash_test/ash-misc/command.tests
diff --git a/shell/ash.c b/shell/ash.c
index ddcd28b..7ba9a7f 100644
--- a/shell/ash.c
+++ b/shell/ash.c
@@ -7812,14 +7812,15 @@ findkwd(const char *s)
* Locate and print what a word is...
*/
static int
-describe_command(char *command, int describe_command_verbose)
+describe_command(char *command, const char *path, int describe_command_verbose)
{
struct cmdentry entry;
struct tblentry *cmdp;
#if ENABLE_ASH_ALIAS
const struct alias *ap;
#endif
- const char *path = pathval();
+
+ path = path ? path : pathval();
if (describe_command_verbose) {
out1str(command);
@@ -7919,7 +7920,7 @@ typecmd(int argc UNUSED_PARAM, char **argv)
verbose = 0;
}
while (argv[i]) {
- err |= describe_command(argv[i++], verbose);
+ err |= describe_command(argv[i++], NULL, verbose);
}
return err;
}
@@ -7933,6 +7934,7 @@ commandcmd(int argc UNUSED_PARAM, char **argv
UNUSED_PARAM)
VERIFY_BRIEF = 1,
VERIFY_VERBOSE = 2,
} verify = 0;
+ const char *path = NULL;
while ((c = nextopt(pvV)) != '\0')
if (c == 'V')
@@ -7943,9 +7945,11 @@ commandcmd(int argc UNUSED_PARAM, char **argv
UNUSED_PARAM)
else if (c != 'p')
abort();
#endif
+ else
+ path = bb_default_path;
/* Mimic bash: just command -v doesn't complain, it's a nop */
if (verify (*argptr != NULL)) {
- return describe_command(*argptr, verify - VERIFY_BRIEF);
+ return describe_command(*argptr, path, verify - VERIFY_BRIEF);
}
return 0;
diff --git a/shell/ash_test/ash-misc/command.right
b/shell/ash_test/ash-misc/command.right
new file mode 100644
index 000..7f746d9
--- /dev/null
+++ b/shell/ash_test/ash-misc/command.right
@@ -0,0 +1 @@
+recho: not found
diff --git a/shell/ash_test/ash-misc/command.tests
b/shell/ash_test/ash-misc/command.tests
new file mode 100755
index 000..5d445af
--- /dev/null
+++ b/shell/ash_test/ash-misc/command.tests
@@ -0,0 +1 @@
+command -p -V recho
--
2.4.3
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[PATCH 3/5] ash: fix command -- crash
busybox sh -c 'command --' segfaults because parse_command_args
returns a pointer to a null pointer.
Based on commit 18071c7 from git://git.kernel.org/pub/scm/utils/dash/dash.git
by Gerrit Pape.
function old new delta
evalcommand 13681350 -18
--
(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-18) Total: -18 bytes
Signed-off-by: Ron Yorston r...@pobox.com
---
shell/ash.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/shell/ash.c b/shell/ash.c
index 7f3808b..ddcd28b 100644
--- a/shell/ash.c
+++ b/shell/ash.c
@@ -8885,8 +8885,8 @@ parse_command_args(char **argv, const char **path)
if (!c)
break;
if (c == '-' !*cp) {
- argv++;
- break;
+ if (!*++argv)
+ return 0;
}
do {
switch (c) {
--
2.4.3
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[PATCH 1/5] ash: allow newline after variable name in for loop
Newline is a valid delimiter between the variable name and `in`
keyword in for loops.
Based on commit 22e8fb4 from git://git.kernel.org/pub/scm/utils/dash/dash.git
by Herbert Xu.
function old new delta
parse_command 15681563 -5
--
(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-5) Total: -5 bytes
Signed-off-by: Ron Yorston r...@pobox.com
---
shell/ash.c | 4 ++--
shell/ash_test/ash-misc/for.right | 1 +
shell/ash_test/ash-misc/for.tests | 5 +
3 files changed, 8 insertions(+), 2 deletions(-)
create mode 100644 shell/ash_test/ash-misc/for.right
create mode 100755 shell/ash_test/ash-misc/for.tests
diff --git a/shell/ash.c b/shell/ash.c
index f6190c3..450a42f 100644
--- a/shell/ash.c
+++ b/shell/ash.c
@@ -10914,7 +10914,7 @@ parse_command(void)
n1 = stzalloc(sizeof(struct nfor));
n1-type = NFOR;
n1-nfor.var = wordtext;
- checkkwd = CHKKWD | CHKALIAS;
+ checkkwd = CHKNL | CHKKWD | CHKALIAS;
if (readtoken() == TIN) {
app = ap;
while (readtoken() == TWORD) {
@@ -10941,7 +10941,7 @@ parse_command(void)
* Newline or semicolon here is optional (but note
* that the original Bourne shell only allowed NL).
*/
- if (lasttoken != TNL lasttoken != TSEMI)
+ if (lasttoken != TSEMI)
tokpushback = 1;
}
checkkwd = CHKNL | CHKKWD | CHKALIAS;
diff --git a/shell/ash_test/ash-misc/for.right
b/shell/ash_test/ash-misc/for.right
new file mode 100644
index 000..d86bac9
--- /dev/null
+++ b/shell/ash_test/ash-misc/for.right
@@ -0,0 +1 @@
+OK
diff --git a/shell/ash_test/ash-misc/for.tests
b/shell/ash_test/ash-misc/for.tests
new file mode 100755
index 000..4889a9f
--- /dev/null
+++ b/shell/ash_test/ash-misc/for.tests
@@ -0,0 +1,5 @@
+for i
+in OK
+do
+ echo $i
+done
--
2.4.3
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[PATCH 0/5] Some more fixes to ash
This patch series harvests some more fixes from dash. These are all quite small: the overall effect is an additional 12 bytes of bloat. I've included tests where appropriate. Ron ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH 5/5] ash: fix error during recursive processing of here document
Save the value of the checkkwd flag to prevent it being clobbered
during recursion.
Based on commit ec2c84d from git://git.kernel.org/pub/scm/utils/dash/dash.git
by Herbert Xu.
function old new delta
readtoken190 203 +13
--
(add/remove: 0/0 grow/shrink: 1/0 up/down: 13/0) Total: 13 bytes
Signed-off-by: Ron Yorston r...@pobox.com
---
shell/ash.c | 5 +++--
shell/ash_test/ash-heredoc/heredoc2.right | 1 +
shell/ash_test/ash-heredoc/heredoc2.tests | 9 +
3 files changed, 13 insertions(+), 2 deletions(-)
create mode 100644 shell/ash_test/ash-heredoc/heredoc2.right
create mode 100755 shell/ash_test/ash-heredoc/heredoc2.tests
diff --git a/shell/ash.c b/shell/ash.c
index 7ba9a7f..db6fb8f 100644
--- a/shell/ash.c
+++ b/shell/ash.c
@@ -11896,6 +11896,7 @@ static int
readtoken(void)
{
int t;
+ int kwd = checkkwd;
#if DEBUG
smallint alreadyseen = tokpushback;
#endif
@@ -11909,7 +11910,7 @@ readtoken(void)
/*
* eat newlines
*/
- if (checkkwd CHKNL) {
+ if (kwd CHKNL) {
while (t == TNL) {
parseheredoc();
t = xxreadtoken();
@@ -11923,7 +11924,7 @@ readtoken(void)
/*
* check for keywords
*/
- if (checkkwd CHKKWD) {
+ if (kwd CHKKWD) {
const char *const *pp;
pp = findkwd(wordtext);
diff --git a/shell/ash_test/ash-heredoc/heredoc2.right
b/shell/ash_test/ash-heredoc/heredoc2.right
new file mode 100644
index 000..ce01362
--- /dev/null
+++ b/shell/ash_test/ash-heredoc/heredoc2.right
@@ -0,0 +1 @@
+hello
diff --git a/shell/ash_test/ash-heredoc/heredoc2.tests
b/shell/ash_test/ash-heredoc/heredoc2.tests
new file mode 100755
index 000..96c227c
--- /dev/null
+++ b/shell/ash_test/ash-heredoc/heredoc2.tests
@@ -0,0 +1,9 @@
+echo hello greeting
+cat EOF
+$(cat greeting)
+EOF
+{
+ echo $?
+ cat greeting
+} /dev/null
+rm greeting
--
2.4.3
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
