From vda.linux at googlemail.com Thu May 1 00:32:18 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 1 May 2008 09:32:18 +0200 Subject: PATCH: brctl show In-Reply-To: <20080430205146.GA17480@mx.loc> References: <20080405211044.GB31717@hedwig.net.cmu.edu> <200804060919.25024.vda.linux@googlemail.com> <20080430205146.GA17480@mx.loc> Message-ID: <200805010932.18660.vda.linux@googlemail.com> On Wednesday 30 April 2008 22:51, Bernhard Fischer wrote: > On Sun, Apr 06, 2008 at 09:19:24AM +0200, Denys Vlasenko wrote: > >On Saturday 05 April 2008 23:10, L. Gabriel Somlo wrote: > >> Hi, > >> > >> I need to be able to see the list of ports currently configured on a > >> bridge, so I took a shot at implementing 'brctl show'. Might follow up > >> with 'showmacs' later, but for now, let me know what you think, and > >> please apply... > > > >Applied, thanks. > > > >NB: "standard" brctl talks to kernel via /sys, not ioctls. > > No, it doesn't. > Either it would work without *any* ioctl or exclusively via sysfs ?) > I don't see how mixing sysfs and ioctl interfaces makes any sense at > all, please explain? I discovered a bug in "standard" brctl. It manifested only when you run it on 32/64 user/kernelspace system. The bug was directly caused by unimplemented ioctl conversion in kernel. Which was done on purpose - newer brctl (supposed to) use sysfs, so supporting this conversion is pointless. The bug was that in this case brctl was erroneously still using ioctls (which works on non 32/64-split system). I sent a fix to the maintainer. Thats how I learned that brctl uses mostly sysfs these days, and even contributing for it doing that a bit more. -- vda From vda.linux at googlemail.com Thu May 1 00:53:44 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 1 May 2008 09:53:44 +0200 Subject: [PATCH 2/2] start-stop-daemon - find processes better In-Reply-To: <200804301719.16679.roy@marples.name> References: <200804301218.05140.roy@marples.name> <1209569110.16926.43.camel@gentoo-jocke.transmode.se> <200804301719.16679.roy@marples.name> Message-ID: <200805010953.44393.vda.linux@googlemail.com> Hi, Hereby I am informing all interested parties that I am totally confused now. I am not using ssd and I need your help in making a decent documentation how it work (or supposed to) > > > But the intent of start-stop-daemon is to start and stop daemons. > > > s-s-d --stop --exec /usr/sbin/ntpd > > > I would that expect it to stop the currently running ntpd process > > > regardless of if the binary itself still exists or not. > > > > Don't think so, this is what --name is for. At least I think so. > > --name is for checking the process name, or argv[0], which is different from > how the daemon is started. > > > you stopping udhcpd or all instances of busybox daemons? > > > > You won't stop anything with your solution because /proc/xxx/exe > > contains the real file name. So > > s-s-d --stop --exec /bin/mysymlinkeddaemon > > will not match. > > Good point. > New patch attached which just checks cmdline instead of doing exe then > cmdline. > Also you should consider the case of scripts. If /usr/bin/foo is a python > script, and was started like > start-stop-daemon --start --exec /usr/bin/foo > then you could reasonably expect > start-stop-daemon --stop --exec /usr/bin/foo > to work. However it won't because the exe inode points at python and not the > script. Let's see what help says, and whether it matches reality (I deleted some obvious options): # start-stop-daemon --help Usage: start-stop-daemon [OPTIONS] [--start|--stop] ... [-- arguments...] Start and stop services Options: -S,--start Start -K,--stop Stop -a,--startas pathname Start process specified by pathname WRONG? it seems to just set argv[0]. It's not a pathname, it's just a "name" (arbitrary) -u,--user username|uid Stop this user's processes Clarification? Will e.g. "ssd -K -u roy" stop all roy's processes? -x,--exec executable Program to either start or check Waht does it mean "check"? "stop"? How executable is searched for for "stop" case? -n,--name process-name Stop processes with this name Is it equivalent to "killall name"? If not, what's the difference? -p,--pidfile pid-file Save or load pid using a pid-file -m,--make-pidfile Create the -p file and enter pid in it ?? How "save" is different from "create and enter pid in it"? Please help by proposing your own help text which is unambiguous. Be as verbose as needed. -- vda From WHarms at bfs.de Thu May 1 02:03:24 2008 From: WHarms at bfs.de (walter harms) Date: Thu, 01 May 2008 11:03:24 +0200 Subject: just another one of my rumblings In-Reply-To: <200804302202.26681.vapier@gentoo.org> References: <22064.1209178121@brightstareng.com> <200804252326.11857.vapier@gentoo.org> <200804260842.43353.vda.linux@googlemail.com> <200804302202.26681.vapier@gentoo.org> Message-ID: <4819875C.7020404@bfs.de> Mike Frysinger wrote: > On Saturday 26 April 2008, Denys Vlasenko wrote: >> On Saturday 26 April 2008 05:26, Mike Frysinger wrote: >>>> > [ -n "$var" ] is clear. [ "$var" ] is not. >>>> >>>> it's exactly analogous to "if (foo != 0)" vs. "if (foo)". >>>> >>>> it's all subjective. i'd probably have to look up "-n". :-) >>> i doubt it's the same. most people who understand shell coding know what >>> the -n test means. i would doubt that most people know what the default >>> behavior is if no operator is specified at all. unlike C coders who know >>> that "true" means "non-0". >> http://en.wikipedia.org/wiki/Color_of_the_bikeshed ? > > as i explained, it isnt just subjective, thus this does not apply. my > assertion is that every C coder knows that "if (foo)" and "if (foo != 0)" is > the same thing. shell coding is a much looser art form and a lot less people > know that [ "$foo" ] is the same thing as [ -n "$foo" ]. ive seen people > make [ "$foo" ] explicit, but do it wrong because they didnt really > understand what the implicit behavior was in the first place. and when > quizzed directly, many havent the foggiest. > > if the only people working on the shell code in question were you, myself, and > a few other people, then yes, [ "$foo" ] is fine because i'm assured we all > know these fugly little details in our head. but we arent the only ones > touching it. > -mike > It is stating the become philosophy of programming ... not everything that can be done should be done. In the long term the survival of the code will depend not only on it function but also on its clarity (therefore maintainability). i would always prefer (foo != 0) over (foo) since it will make my intentions clear and a forgotten "!" is easily visible. even in a busybox universe where thigh is good you need (easy) understand. and something else i found missing in the discussion is we are talking about *test code*. there is no production environment were i need to stuff everything into a few bits box. just my two cents, wh From roy at marples.name Thu May 1 04:09:52 2008 From: roy at marples.name (Roy Marples) Date: Thu, 1 May 2008 12:09:52 +0100 Subject: [PATCH 2/2] start-stop-daemon - find processes better In-Reply-To: <200805010953.44393.vda.linux@googlemail.com> References: <200804301218.05140.roy@marples.name> <200804301719.16679.roy@marples.name> <200805010953.44393.vda.linux@googlemail.com> Message-ID: <200805011209.53240.roy@marples.name> On Thursday 01 May 2008 08:53:44 Denys Vlasenko wrote: > Hereby I am informing all interested parties that > I am totally confused now. > > I am not using ssd and I need your help > in making a decent documentation how it work > (or supposed to) The Debian man page was never that clear either. I re-wrote it to match my interpretation. You can find an online version here. http://roy.marples.name/cgi-bin/man.cgi?8+start-stop-daemon > > Let's see what help says, and whether it matches reality > (I deleted some obvious options): > > # start-stop-daemon --help > Usage: start-stop-daemon [OPTIONS] [--start|--stop] ... [-- arguments...] > Start and stop services > Options: > -S,--start Start > -K,--stop Stop > -a,--startas pathname Start process specified by pathname > WRONG? it seems to just set argv[0]. > It's not a pathname, it's just a "name" (arbitrary) Correct. It's a crap option. Gentoo silently remaps it to --exec > -u,--user username|uid Stop this user's processes > Clarification? Will e.g. "ssd -K -u roy" stop > all roy's processes? Yes > -x,--exec executable Program to either start or check > Waht does it mean "check"? "stop"? > How executable is searched for for "stop" case? My view is that it searches for programs started as that. So if the user launches /usr/sbin/ntpd then ssd should check /proc/pid/cmdline to see if it was started as /usr/sbin/ntpd and then match. OpenRC extends this futher and also matches daemon arguments. Thus, this works start-stop-damon --start --exec /usr/sbin/daemon -- --hostname foo start-stop-damon --start --exec /usr/sbin/daemon -- --hostname bar start-stop-damon --stop --exec /usr/sbin/daemon -- --hostname foo the second daemon *should* still be running in my eyes. However, adding that will bloat ssd a little more, so may not be beneficial for busybox. > -n,--name process-name Stop processes with this name > Is it equivalent to "killall name"? > If not, what's the difference? Should be equivalent. This is a bad option to use as many daemon love to change their process name AND don't create a pidfile AND are scripts. Again, this is why we changed --exec to look at how it was started to solve this problem. > -p,--pidfile pid-file Save or load pid using a pid-file > -m,--make-pidfile Create the -p file and enter pid in it > ?? How "save" is different from "create and enter pid in it"? In normal ssd, -p only matters when stopping. It reads the specified file and just stops that pid. However, ssd can also background some daemons which don't by default. Or which don't create a pidifle by default. So the solution is to run the daemon in foreground mode in a forked process. We then store that pid in the pidfile. Example start-stop-daemon --start --exec /usr/sbin/daemon --pidfile /var/run/daemon.pid --make-pidfile -- --foreground --foreground is an option specific to daemon and not start-stop-daemon. Thanks Roy From Joakim.Tjernlund at transmode.se Thu May 1 04:39:16 2008 From: Joakim.Tjernlund at transmode.se (Joakim Tjernlund) Date: Thu, 1 May 2008 13:39:16 +0200 Subject: [PATCH 2/2] start-stop-daemon - find processes better In-Reply-To: <200804301719.16679.roy@marples.name> References: <200804301218.05140.roy@marples.name> <200804301527.11102.roy@marples.name> <1209569110.16926.43.camel@gentoo-jocke.transmode.se> <200804301719.16679.roy@marples.name> Message-ID: <010c01c8ab7f$fcc95b70$f65c1250$@Tjernlund@transmode.se> > -----Original Message----- > From: Roy Marples [mailto:roy at marples.name] > Sent: den 30 april 2008 18:19 > To: joakim.tjernlund at transmode.se > Cc: Denys Vlasenko; busybox at busybox.net > Subject: Re: [PATCH 2/2] start-stop-daemon - find processes better > > On Wednesday 30 April 2008 16:25:10 Joakim Tjernlund wrote: > > > But the intent of start-stop-daemon is to start and stop daemons. > > > s-s-d --stop --exec /usr/sbin/ntpd > > > I would that expect it to stop the currently running ntpd process > > > regardless of if the binary itself still exists or not. > > > > Don't think so, this is what --name is for. At least I think so. > > --name is for checking the process name, or argv[0], which is different from > how the daemon is started. > > > > > > > > It > > > > > wont work when cmdline i a symlink. Should you not use --name instead > > > > > to handle the deleted case? > > > > > > But this is good :) > > > Consider busybox - loads of things symlink into it, like udhcpd. So are > > > you stopping udhcpd or all instances of busybox daemons? > > > > You won't stop anything with your solution because /proc/xxx/exe > > contains the real file name. So > > s-s-d --stop --exec /bin/mysymlinkeddaemon > > will not match. > > Good point. > New patch attached which just checks cmdline instead of doing exe then > cmdline. > > function old new delta > start_stop_daemon_main 984 1006 +22 > .rodata 119312 119303 -9 > check 755 714 -41 > ------------------------------------------------------------------------------ > (add/remove: 0/0 grow/shrink: 1/2 up/down: 22/-50) Total: -28 bytes > > So that's now an overall code shrink :) > > Also you should consider the case of scripts. If /usr/bin/foo is a python > script, and was started like > start-stop-daemon --start --exec /usr/bin/foo > then you could reasonably expect > start-stop-daemon --stop --exec /usr/bin/foo > to work. However it won't because the exe inode points at python and not the > script. Roy, the above all makes sense and your patch looks good too. One minor thing, I don't think you need the + if (execname) + xstat(execname, &execstat); anymore or am I missing something? Jocke From roy at marples.name Thu May 1 05:06:36 2008 From: roy at marples.name (Roy Marples) Date: Thu, 1 May 2008 13:06:36 +0100 Subject: [PATCH 2/2] start-stop-daemon - find processes better Message-ID: <200805011306.37028.roy@marples.name> On Thursday 01 May 2008 12:39:16 you wrote: > Roy, the above all makes sense and your patch looks good too. One minor > thing, I don't think you need the > + if (execname) > + xstat(execname, &execstat); > anymore or am I missing something? Checking the existance of the binary to start? Sure, execv will catch it, but if using --background on a non existant binary, the parent will have already returned 0 which is bad. Thanks Roy From vda.linux at googlemail.com Thu May 1 06:18:40 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 1 May 2008 15:18:40 +0200 Subject: [PATCH 2/2] start-stop-daemon - find processes better In-Reply-To: <200805011209.53240.roy@marples.name> References: <200804301218.05140.roy@marples.name> <200805010953.44393.vda.linux@googlemail.com> <200805011209.53240.roy@marples.name> Message-ID: <200805011518.40943.vda.linux@googlemail.com> On Thursday 01 May 2008 13:09, Roy Marples wrote: > > Let's see what help says, and whether it matches reality > > (I deleted some obvious options): > > > > # start-stop-daemon --help > > Usage: start-stop-daemon [OPTIONS] [--start|--stop] ... [-- arguments...] > > Start and stop services > > Options: > > -S,--start Start > > -K,--stop Stop > > -a,--startas pathname Start process specified by pathname > > WRONG? it seems to just set argv[0]. > > It's not a pathname, it's just a "name" (arbitrary) > > Correct. It's a crap option. Gentoo silently remaps it to --exec Are you suggesting to drop it? This risks breaking things for existing users. > > -u,--user username|uid Stop this user's processes > > Clarification? Will e.g. "ssd -K -u roy" stop > > all roy's processes? > > Yes And what does it mean for --start case? ssd -S -u roy -x /usr/bin/sleep 1234 > > -x,--exec executable Program to either start or check > > Waht does it mean "check"? "stop"? > > How executable is searched for for "stop" case? > > My view is that it searches for programs started as that. > So if the user launches /usr/sbin/ntpd then ssd should check /proc/pid/cmdline > to see if it was started as /usr/sbin/ntpd and then match. And what to do if cmdline contains just "ntpd"? or "./ntpd"? Does that match? Do we need to check /proc/$PID/stat? /proc/$PID/exec? For more details, here is the comment from libbb/find_pid_by_name.c: /* In Linux we have three ways to determine "process name": 1. /proc/PID/stat has "...(name)...", among other things. It's so-called "comm" field. 2. /proc/PID/cmdline's first NUL-terminated string. It's argv[0] from exec syscall. 3. /proc/PID/exe symlink. Points to the running executable file. kernel threads: comm: thread name cmdline: empty exe: executable comm: first 15 chars of base name (if executable is a symlink, then first 15 chars of symlink name are used) cmdline: argv[0] from exec syscall exe: points to executable (resolves symlink, unlike comm) script (an executable with #!/path/to/interpreter): comm: first 15 chars of script's base name (symlinks are not resolved) cmdline: /path/to/interpreter (symlinks are not resolved) (script name is in argv[1], args are pushed into argv[2] etc) exe: points to interpreter's executable (symlinks are resolved) If FEATURE_PREFER_APPLETS=y (and more so if FEATURE_SH_STANDALONE=y), some commands started from busybox shell, xargs or find are started by execXXX("/proc/self/exe", applet_name, params....) and therefore comm field contains "exe". */ > OpenRC extends this futher and also matches daemon arguments. Thus, this works > > start-stop-damon --start --exec /usr/sbin/daemon -- --hostname foo > start-stop-damon --start --exec /usr/sbin/daemon -- --hostname bar > start-stop-damon --stop --exec /usr/sbin/daemon -- --hostname foo > the second daemon *should* still be running in my eyes. > However, adding that will bloat ssd a little more, so may not be beneficial > for busybox. > > > -n,--name process-name Stop processes with this name > > Is it equivalent to "killall name"? > > If not, what's the difference? > > Should be equivalent. > This is a bad option to use as many daemon love to change their process name Change process name? How? > AND don't create a pidfile AND are scripts. Again, this is why we > changed --exec to look at how it was started to solve this problem. How it is different from -x? > > -p,--pidfile pid-file Save or load pid using a pid-file > > -m,--make-pidfile Create the -p file and enter pid in it > > ?? How "save" is different from "create and enter pid in it"? > > In normal ssd, -p only matters when stopping. It reads the specified file and > just stops that pid. > However, ssd can also background some daemons which don't by default. Or which > don't create a pidifle by default. So the solution is to run the daemon in > foreground mode in a forked process. We then store that pid in the pidfile. > Example > > start-stop-daemon --start --exec /usr/sbin/daemon --pidfile /var/run/daemon.pid --make-pidfile -- --foreground > --foreground is an option specific to daemon and not start-stop-daemon. But --make-pidfile seems to be superfluous here... --start + --pidfile FILE imply pidfile creation. -- vda From roy at marples.name Thu May 1 06:38:19 2008 From: roy at marples.name (Roy Marples) Date: Thu, 1 May 2008 14:38:19 +0100 Subject: [PATCH 2/2] start-stop-daemon - find processes better In-Reply-To: <200805011518.40943.vda.linux@googlemail.com> References: <200804301218.05140.roy@marples.name> <200805011209.53240.roy@marples.name> <200805011518.40943.vda.linux@googlemail.com> Message-ID: <200805011438.19384.roy@marples.name> On Thursday 01 May 2008 14:18:40 Denys Vlasenko wrote: > > > -a,--startas pathname Start process specified by pathname > > > WRONG? it seems to just set argv[0]. > > > It's not a pathname, it's just a "name" (arbitrary) > > > > Correct. It's a crap option. Gentoo silently remaps it to --exec > > Are you suggesting to drop it? This risks breaking > things for existing users. No, I'm suggesting just to remap --startas to --exec > > > > -u,--user username|uid Stop this user's processes > > > Clarification? Will e.g. "ssd -K -u roy" stop > > > all roy's processes? > > > > Yes > > And what does it mean for --start case? > ssd -S -u roy -x /usr/bin/sleep 1234 If /usr/bin/sleep is currently running AND owned by roy then ssd should say it's already running, otherwise try and start it. Remember, ssd does processes matching for starting as well. > > > > -x,--exec executable Program to either start or check > > > Waht does it mean "check"? "stop"? > > > How executable is searched for for "stop" case? > > > > My view is that it searches for programs started as that. > > So if the user launches /usr/sbin/ntpd then ssd should check > > /proc/pid/cmdline to see if it was started as /usr/sbin/ntpd and then > > match. > > And what to do if cmdline contains just "ntpd"? or "./ntpd"? > Does that match? > Do we need to check /proc/$PID/stat? /proc/$PID/exec? That's the one hole really :) It doesn't match, but then I don't expect it too either. ssd is normally used in scripts, so the way it's started should match the way it's stopped. > > OpenRC extends this futher and also matches daemon arguments. Thus, this > > works > > > > start-stop-damon --start --exec /usr/sbin/daemon -- --hostname foo > > start-stop-damon --start --exec /usr/sbin/daemon -- --hostname bar > > start-stop-damon --stop --exec /usr/sbin/daemon -- --hostname foo > > the second daemon *should* still be running in my eyes. > > However, adding that will bloat ssd a little more, so may not be > > beneficial for busybox. > > > > > -n,--name process-name Stop processes with this name > > > Is it equivalent to "killall name"? > > > If not, what's the difference? > > > > Should be equivalent. > > This is a bad option to use as many daemon love to change their process > > name > > Change process name? How? Normally they just change their argv[0], but this depends on platform. The BSD's have a libc call. > > AND don't create a pidfile AND are scripts. Again, this is why we > > changed --exec to look at how it was started to solve this problem. > > How it is different from -x? -x is --exec, or did I miss something? > > > > -p,--pidfile pid-file Save or load pid using a pid-file > > > -m,--make-pidfile Create the -p file and enter pid in it > > > ?? How "save" is different from "create and enter pid in it"? > > > > In normal ssd, -p only matters when stopping. It reads the specified file > > and just stops that pid. > > However, ssd can also background some daemons which don't by default. Or > > which don't create a pidifle by default. So the solution is to run the > > daemon in foreground mode in a forked process. We then store that pid in > > the pidfile. Example > > > > start-stop-daemon --start --exec /usr/sbin/daemon --pidfile > > /var/run/daemon.pid --make-pidfile -- --foreground --foreground is an > > option specific to daemon and not start-stop-daemon. > > But --make-pidfile seems to be superfluous here... --start + --pidfile FILE > imply pidfile creation. Not so as --pidfile is used to check processes before the demon starts start-stop-daemon --start --exec /usr/bin/foo --pidfile /var/run/foo.pid Check that /usr/bin/foo is NOT running on the pidfile in /var/run/foo.pid. If not running, start foo, otherwise error. ssd should not stamp on pidfiles unless told. Thanks Roy From mikes at kuentos.guam.net Thu May 1 07:49:33 2008 From: mikes at kuentos.guam.net (Michael D. Setzer II) Date: Fri, 02 May 2008 00:49:33 +1000 Subject: Best use of mdev? Message-ID: <481A651D.20097.4311B0F@mikes.kuentos.guam.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was just contacted by a user that has 11 partitions on a large hard disk. My g4l project currently has the nods setup as being precreated in the /dev directory. It had massive number of these for both the hd and sd going all the way to sdp but only to the 9th option. I was manually able to create a script to create the additional nods, but then started looking at options to have it automaticly create the proper nods. I have found the mdev, and seem to have figured some of it out, but think there might be some additional things to make it work better. I booted from the g4l cd, and did the following manually. created the /etc/mdev.conf with these two lines. hd[a-z][0-9]* 0:3 660 sd[a-z][0-9]* 0:3 660 Run the commands to create the /dev mkdir /sys mount -t sysfs sysfs /sys mdev -s Below is the original contents of the /dev directory minus all the hd and sd files. Not sure which all of these can also be created with the mdev.conf file and which have to be manually created. Also, some of the directories were for raid systems that users had. Would the mdev create these? Unfortunately, I don't have all the hardware to test. The g4l is the root id, and that as how it runs. Thanks. drwxr-xr-x 2 g4l g4l 1024 Mar 1 2004 vc drwxr-xr-x 2 g4l g4l 1024 Jun 30 2004 pts crw-rw-rw- 1 g4l g4l 1, 5 Oct 10 2004 zero crw-rw---- 1 g4l 5 4, 6 Oct 10 2004 tty6 crw--w--w- 1 g4l 5 4, 0 Oct 10 2004 tty0 brw-rw---- 1 g4l 6 1, 1 Oct 10 2004 ram1 brw-rw---- 1 g4l 6 1, 0 Oct 10 2004 ram0 crw-rw-rw- 1 g4l g4l 1, 3 Oct 10 2004 null crw-r----- 1 g4l 9 1, 1 Oct 10 2004 mem crw-r----- 1 g4l 9 1, 2 Oct 10 2004 kmem brw-rw---- 1 g4l 6 2, 0 Oct 10 2004 fd0 crw-r--r-- 1 g4l g4l 1, 9 Apr 28 2005 urandom brw-r--r-- 1 g4l g4l 9, 0 Apr 28 2005 md0 brw-r--r-- 1 g4l g4l 9, 1 Apr 28 2005 md1 brw-r--r-- 1 g4l g4l 9, 2 Apr 28 2005 md2 brw-r--r-- 1 g4l g4l 9, 3 Apr 28 2005 md3 brw-r--r-- 1 g4l g4l 9, 4 Apr 28 2005 md4 brw-r--r-- 1 g4l g4l 9, 5 Apr 28 2005 md5 brw-r--r-- 1 g4l g4l 9, 6 Apr 28 2005 md6 brw-r--r-- 1 g4l g4l 9, 7 Apr 28 2005 md7 brw-r--r-- 1 g4l g4l 9, 8 Apr 28 2005 md8 brw-r--r-- 1 g4l g4l 9, 9 Apr 28 2005 md9 brw-r--r-- 1 g4l g4l 9, 10 Apr 28 2005 md10 brw-r--r-- 1 g4l g4l 9, 11 Apr 28 2005 md11 brw-r--r-- 1 g4l g4l 9, 12 Apr 28 2005 md12 brw-r--r-- 1 g4l g4l 9, 13 Apr 28 2005 md13 brw-r--r-- 1 g4l g4l 9, 14 Apr 28 2005 md14 brw-r--r-- 1 g4l g4l 9, 15 Apr 28 2005 md15 brw-r--r-- 1 g4l g4l 9, 16 Apr 28 2005 md16 brw-r--r-- 1 g4l g4l 9, 17 Apr 28 2005 md17 brw-r--r-- 1 g4l g4l 9, 18 Apr 28 2005 md18 brw-r--r-- 1 g4l g4l 9, 19 Apr 28 2005 md19 brw-r--r-- 1 g4l g4l 9, 20 Apr 28 2005 md20 brw-r--r-- 1 g4l g4l 9, 21 Apr 28 2005 md21 brw-r--r-- 1 g4l g4l 9, 22 Apr 28 2005 md22 brw-r--r-- 1 g4l g4l 9, 23 Apr 28 2005 md23 brw-r--r-- 1 g4l g4l 9, 24 Apr 28 2005 md24 brw-r--r-- 1 g4l g4l 9, 25 Apr 28 2005 md25 brw-r--r-- 1 g4l g4l 9, 26 Apr 28 2005 md26 brw-r--r-- 1 g4l g4l 9, 27 Apr 28 2005 md27 brw-r--r-- 1 g4l g4l 9, 28 Apr 28 2005 md28 brw-r--r-- 1 g4l g4l 9, 29 Apr 28 2005 md29 brw-r--r-- 1 g4l g4l 9, 30 Apr 28 2005 md30 brw-r--r-- 1 g4l g4l 9, 31 Apr 28 2005 md31 drwxr-xr-x 2 g4l g4l 4096 Jan 20 2006 cciss drwxr-xr-x 2 g4l g4l 4096 Jan 23 2006 ataraid drwxr-xr-x 2 g4l g4l 32768 Jan 23 2006 ida crw-r--r-- 1 g4l g4l 5, 0 Apr 28 02:36 tty lrwxrwxrwx 1 g4l g4l 4 Apr 29 10:09 ramdisk -> ram0 lrwxrwxrwx 1 g4l g4l 4 Apr 29 10:09 ram -> ram0 lrwxrwxrwx 1 g4l g4l 3 Apr 29 10:09 cdrom -> hdb crw-rw---- 1 g4l 5 4, 5 May 1 13:55 tty5 crw-rw---- 1 g4l 5 4, 4 May 1 13:55 tty4 crw-rw---- 1 g4l 5 4, 3 May 1 13:55 tty3 crw-rw---- 1 g4l 5 4, 2 May 1 13:55 tty2 crw------- 1 g4l g4l 5, 1 May 1 13:56 console crw------- 1 g4l g4l 4, 1 May 1 13:58 tty1 crw-r--r-- 1 g4l g4l 5, 2 May 1 14:04 ptmx +----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes at kuentos.guam.net mailto:msetzerii at gmail.com http://www.guam.net/home/mikes Guam - Where America's Day Begins +----------------------------------------------------------+ http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489) BOINC at HOME CREDITS SETI 5,269,727.070797 | EINSTEIN 1,573,038.609732 | ROSETTA 480,077.992597 -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 -- QDPGP 2.61c Comment: http://community.wow.net/grt/qdpgp.html iQA/AwUBSBlL3yzGQcr/2AKZEQJRowCgggJ9mQrAq88A6K7Xo/YvR5J1JQIAn0d/ X8gl8fcbYF7qH6qvxvGgj9H0 =xC7F -----END PGP SIGNATURE----- From cristian.ionescu-idbohrn at axis.com Thu May 1 09:11:06 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Thu, 1 May 2008 18:11:06 +0200 (CEST) Subject: [patch] testsuite/testing.sh: removes obvious bashisms Message-ID: <0805011333150.10843@somehost> I'm not sure I found all of them. Didn't test function 'mkchroot', but I can't see how my modifications would make it fail. I tested using bash, dash and ash as shells. You will notice this: testing() { + local ECHO='echo -e' + + [ -z "$($ECHO)" ] || ECHO='echo' + '-e' is non-posix and dash has that builtin. That is, if the standard shell is dash (ubuntu and derivatives, and RSN debian): # echo -e will output: -e and the tests will go wrong and all that... Maybe some 'echo' replacement like: ECHO='echo -e' [ -z "$($ECHO)" ] || ECHO='echo' in testsuite/runtest (and then propagated to all scripts in and below the testsuite directory) sould be a better way to do it. Thoughts? 'echo -n' may also cause problems. I read here: http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html ,---- | A string to be written to standard output. If the first operand is -n, or | if any of the operands contain a backslash ( '\' ) character, the results | are implementation-defined. | | [XSI] [Option Start] On XSI-conformant systems, if the first operand is | -n, it shall be treated as a string, not an option. `---- 'printf' instead of 'echo -e[n]' may be a safer way do do it, but... I noticed that even if I replaced 'echo -e[n]' with printf, I still run into problems :( For example testsuite/bunzip2.tests: echo -ne "\x02\x00\x6e\xd7\xac\xfd\x06\x00\x00\x00" No joy just replacing 'echo -ne' with 'printf', as dash builtin 'printf' does not support: \xHH byte with hexadecimal value HH (1 to 2 digits) as printf (GNU coreutils) 6.10. bash builtin printf (and even echo), on the other hand, seems to support that and more. But posix-printf should support octal sequences, so this: printf "\002\000\156\327\254\375\006\000\000\000" will work better (see 2nd attachment). Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: testing.sh.patch Type: text/x-diff Size: 1330 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080501/ee745138/attachment-0002.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: bunzip2.tests.patch Type: text/x-diff Size: 1458 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080501/ee745138/attachment-0003.patch From rep.dot.nop at gmail.com Fri May 2 00:28:44 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Fri, 2 May 2008 09:28:44 +0200 Subject: Best use of mdev? In-Reply-To: <481A651D.20097.4311B0F@mikes.kuentos.guam.net> References: <481A651D.20097.4311B0F@mikes.kuentos.guam.net> Message-ID: <20080502072844.GB14696@mx.loc> On Fri, May 02, 2008 at 12:49:33AM +1000, Michael D. Setzer II wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >I was just contacted by a user that has 11 partitions on a large hard disk. My >g4l project currently has the nods setup as being precreated in the /dev >directory. It had massive number of these for both the hd and sd going all >the way to sdp but only to the 9th option. I was manually able to create a >script to create the additional nods, but then started looking at options to >have it automaticly create the proper nods. I have found the mdev, and >seem to have figured some of it out, but think there might be some >additional things to make it work better. > >I booted from the g4l cd, and did the following manually. > >created the /etc/mdev.conf with these two lines. > >hd[a-z][0-9]* 0:3 660 >sd[a-z][0-9]* 0:3 660 > >Run the commands to create the /dev > >mkdir /sys >mount -t sysfs sysfs /sys >mdev -s > >Below is the original contents of the /dev directory minus all the hd and sd >files. Not sure which all of these can also be created with the mdev.conf file >and which have to be manually created. Also, some of the directories were >for raid systems that users had. Would the mdev create these? >Unfortunately, I don't have all the hardware to test. I usually only have /dev/null and /dev/console and create all the rest via mdev. $ egrep -v "(^#|^$)" box/root/etc/inittab ::sysinit:/bin/mount -t proc none /proc ::sysinit:/bin/mount -t sysfs none /sys ::sysinit:/bin/mount -t tmpfs -o size=64k,mode=0755 none /dev ::sysinit:/bin/mkdir /dev/pts ::sysinit:/bin/mount -t devpts devpts /dev/pts ::sysinit:/bin/echo /sbin/mdev > /proc/sys/kernel/hotplug ::sysinit:/sbin/mdev -s ::sysinit:/bin/mount -o remount,rw / ::sysinit:/bin/mount -a ::sysinit:/bin/hostname -F /etc/hostname ::sysinit:/etc/init.d/rcS HTH, From vda.linux at googlemail.com Fri May 2 01:43:05 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 2 May 2008 10:43:05 +0200 Subject: [PATCH 2/2] start-stop-daemon - find processes better In-Reply-To: <200805011438.19384.roy@marples.name> References: <200804301218.05140.roy@marples.name> <200805011518.40943.vda.linux@googlemail.com> <200805011438.19384.roy@marples.name> Message-ID: <200805021043.05959.vda.linux@googlemail.com> Hi Roy, Joakim. Joakim, please scroll down to the end and let me know what you thing about proposed ssd documentation. On Thursday 01 May 2008 15:38, Roy Marples wrote: > > > > It's not a pathname, it's just a "name" (arbitrary) > > > > > > Correct. It's a crap option. Gentoo silently remaps it to --exec > > > > Are you suggesting to drop it? This risks breaking > > things for existing users. > > No, I'm suggesting just to remap --startas to --exec Don't see why it cannot be used as intended - as an argv[0] override. > > > My view is that it searches for programs started as that. > > > So if the user launches /usr/sbin/ntpd then ssd should check > > > /proc/pid/cmdline to see if it was started as /usr/sbin/ntpd and then > > > match. > > > > And what to do if cmdline contains just "ntpd"? or "./ntpd"? > > Does that match? > > Do we need to check /proc/$PID/stat? /proc/$PID/exec? > > That's the one hole really :) > It doesn't match, but then I don't expect it too either. ssd is normally used > in scripts, so the way it's started should match the way it's stopped. I need this to be exactly spelled out. > > > > -n,--name process-name Stop processes with this name > > > AND don't create a pidfile AND are scripts. Again, this is why we > > > changed --exec to look at how it was started to solve this problem. > > > > How it is different from -x? > > -x is --exec, or did I miss something? I meant "how --exec is different for --name?" > > > In normal ssd, -p only matters when stopping. It reads the specified file > > > and just stops that pid. > > > However, ssd can also background some daemons which don't by default. Or > > > which don't create a pidifle by default. So the solution is to run the > > > daemon in foreground mode in a forked process. We then store that pid in > > > the pidfile. Example > > > > > > start-stop-daemon --start --exec /usr/sbin/daemon --pidfile > > > /var/run/daemon.pid --make-pidfile -- --foreground --foreground is an > > > option specific to daemon and not start-stop-daemon. > > > > But --make-pidfile seems to be superfluous here... --start + --pidfile FILE > > imply pidfile creation. Really? Must be documented. And if --make-pidfile indeed implies pidfile creation, then it makes no sense. Adding/removing --make-pidfile to command line chages nothing. > Not so as --pidfile is used to check processes before the demon starts > > start-stop-daemon --start --exec /usr/bin/foo --pidfile /var/run/foo.pid > > Check that /usr/bin/foo is NOT running on the pidfile in /var/run/foo.pid. > If not running, start foo, otherwise error. > ssd should not stamp on pidfiles unless told. Please review proposed documentation below. Please spell out how -n NAME and -x NAME are different in respect to stopping the processes. To reiterate: we nave 3 different ideas of "process name": In Linux we have three ways to determine "process name": 1. /proc/PID/stat has "...(name)...", among other things. It's so-called "comm" field. 2. /proc/PID/cmdline's first NUL-terminated string. It's argv[0] from exec syscall. 3. /proc/PID/exe symlink. Points to the running executable file. kernel threads: comm: thread name cmdline: empty exe: executable comm: first 15 chars of base name (if executable is a symlink, then first 15 chars of symlink name are used) cmdline: argv[0] from exec syscall exe: points to executable (resolves symlink, unlike comm) script (an executable with #!/path/to/interpreter): comm: first 15 chars of script's base name (symlinks are not resolved) cmdline: /path/to/interpreter (symlinks are not resolved) (script name is in argv[1], args are pushed into argv[2] etc) exe: points to interpreter's executable (symlinks are resolved) Which one(s) should be used by -n? -x? start-stop-daemon [OPTIONS] [--start|--stop] ... [-- arguments...] One (only) of these must be given: -S,--start Start -K,--stop Stop start-stop-daemon will first search for matching processes, stop them (by sending a signal). If --start is given, it will then start a new process. Stop options: -u,--user USERNAME|UID Stop this user's processes -n,--name PROCESS_NAME Stop processes with this name ?? -x,--exec EXECUTABLE Stop processes with this name ?? -p,--pidfile PID_FILE Stop processes with PID from this file -s,--signal SIG Signal to send (default TERM) Start options: -x,--exec EXECUTABLE Program to run (1st arg of execvp). Mandatory. -a,--startas NAME argv[0] (defults to EXECUTABLE) -b,--background Put process into background -N,--nicelevel N Add N to process's nice level -c,--chuid user[:[grp]] Change to specified user/group -m,--make-pidfile -p,--pidfile PID_FILE Write PID to the file (both -m and -p must be given!) Misc options: -o,--oknodo Exit status 0 if nothing done -q,--quiet Quiet -v,--verbose Verbose -- vda From vda.linux at googlemail.com Fri May 2 02:40:01 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 2 May 2008 11:40:01 +0200 Subject: [patch] testsuite/testing.sh: removes obvious bashisms In-Reply-To: <0805011333150.10843@somehost> References: <0805011333150.10843@somehost> Message-ID: <200805021140.01381.vda.linux@googlemail.com> On Thursday 01 May 2008 18:11, Cristian Ionescu-Idbohrn wrote: > I'm not sure I found all of them. Didn't test function 'mkchroot', but I > can't see how my modifications would make it fail. > > I tested using bash, dash and ash as shells. - FAILCOUNT=$[$FAILCOUNT+1] + FAILCOUNT=$(($FAILCOUNT + 1)) Ok - [ "${i:0:1}" == "/" ] || i=$(which $i) + first_char=${i#?} + first_char=${first_char%$first_char} + [ "$first_char" = / ] || i=$(which $i) Just use i=$(which $i) always. > You will notice this: > > testing() > { > + local ECHO='echo -e' > + > + [ -z "$($ECHO)" ] || ECHO='echo' > + > > '-e' is non-posix and dash has that builtin. That is, if the standard > shell is dash (ubuntu and derivatives, and RSN debian): > > # echo -e > > will output: > > -e > > and the tests will go wrong and all that... > > Maybe some 'echo' replacement like: > > ECHO='echo -e' > [ -z "$($ECHO)" ] || ECHO='echo' > > in testsuite/runtest (and then propagated to all scripts in and below the > testsuite directory) sould be a better way to do it. Thoughts? > > 'echo -n' may also cause problems. > > I read here: > > http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html > > ,---- > | A string to be written to standard output. If the first operand is -n, or > | if any of the operands contain a backslash ( '\' ) character, the results > | are implementation-defined. > | > | [XSI] [Option Start] On XSI-conformant systems, if the first operand is > | -n, it shall be treated as a string, not an option. > `---- > > 'printf' instead of 'echo -e[n]' may be a safer way do do it, but... > > I noticed that even if I replaced 'echo -e[n]' with printf, I still > run into problems :( For example testsuite/bunzip2.tests: > > echo -ne "\x02\x00\x6e\xd7\xac\xfd\x06\x00\x00\x00" > > No joy just replacing 'echo -ne' with 'printf', as dash builtin 'printf' > does not support: > > \xHH byte with hexadecimal value HH (1 to 2 digits) > > as printf (GNU coreutils) 6.10. bash builtin printf (and even echo), on > the other hand, seems to support that and more. But posix-printf should > support octal sequences, so this: > > printf "\002\000\156\327\254\375\006\000\000\000" > > will work better (see 2nd attachment). Scary mess. Either declare than we absolutely require echo -ne to work. Making it work without echo -ne will hurt readability too much. Or have "echo-n", "echo-ne" and "echo-e" helper programs written in C. 8] Thus bunzip2.tests.patch is NAKed. Sorry. In the end, I applied this patch: diff -d -urpN busybox.2/testsuite/testing.sh busybox.3/testsuite/testing.sh --- busybox.2/testsuite/testing.sh 2008-04-27 22:36:56.000000000 +0200 +++ busybox.3/testsuite/testing.sh 2008-05-02 11:34:30.000000000 +0200 @@ -79,7 +79,7 @@ testing() cmp expected actual >/dev/null 2>/dev/null if [ $? -ne 0 ] then - FAILCOUNT=$[$FAILCOUNT+1] + FAILCOUNT=$(($FAILCOUNT + 1)) echo "FAIL: $NAME" [ -n "$VERBOSE" ] && diff -u expected actual else @@ -107,7 +107,8 @@ mkchroot() shift for i in "$@" do - [ "${i:0:1}" == "/" ] || i=$(which $i) + #bashism: [ "${i:0:1}" == "/" ] || i=$(which $i) + i=$(which $i) # no-op for /bin/prog [ -f "$dest/$i" ] && continue if [ -e "$i" ] then -- vda From cristian.ionescu-idbohrn at axis.com Fri May 2 03:13:12 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Fri, 2 May 2008 12:13:12 +0200 (CEST) Subject: [patch] testsuite/testing.sh: removes obvious bashisms In-Reply-To: <200805021140.01381.vda.linux@googlemail.com> References: <0805011333150.10843@somehost> <200805021140.01381.vda.linux@googlemail.com> Message-ID: <0805021148050.10843@somehost> On Fri, 2 May 2008, Denys Vlasenko wrote: > Scary mess. :) > Either declare than we absolutely require echo -ne to work. Easy. Force the shebang lines to (in all scripts): #!/bin/bash and leave those who don't have bash installed do whatever they can. > Making it work without echo -ne will hurt readability too much. Realy? Why? Readability pain from using: # printf "foo\tbar" compared to: # echo -ne "foo\tbar" is minimal (if any), IMHO, make the scripts more maintainable accross various distributions and make more people happy :) > Or have "echo-n", "echo-ne" and "echo-e" helper programs written in C. 8] I have no problems with that, but I still think printf is easier and more flexible. Cheers, -- Cristian From vda.linux at googlemail.com Fri May 2 03:31:50 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 2 May 2008 12:31:50 +0200 Subject: [patch] testsuite/testing.sh: removes obvious bashisms In-Reply-To: <0805021148050.10843@somehost> References: <0805011333150.10843@somehost> <200805021140.01381.vda.linux@googlemail.com> <0805021148050.10843@somehost> Message-ID: <200805021231.50736.vda.linux@googlemail.com> On Friday 02 May 2008 12:13, Cristian Ionescu-Idbohrn wrote: > > Either declare than we absolutely require echo -ne to work. > > Easy. Force the shebang lines to (in all scripts): > > #!/bin/bash Is it a bashism? It's more like echo-ism... > > Or have "echo-n", "echo-ne" and "echo-e" helper programs written in C. 8] > > I have no problems with that, but I still think printf is easier and more > flexible. printf has more than just aestethic problems. All "new-style" tests use echo -ne (indirectly). If you change that to printf, you nned to audit them all for "%" format specifier. -- vda From rep.dot.nop at gmail.com Fri May 2 03:40:55 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Fri, 2 May 2008 12:40:55 +0200 Subject: Best use of mdev? In-Reply-To: <481B757B.25626.30614F8@mikes.kuentos.guam.net> References: <20080502072844.GB14696@mx.loc> <481B757B.25626.30614F8@mikes.kuentos.guam.net> Message-ID: <20080502104055.GB15508@mx.loc> On Fri, May 02, 2008 at 08:11:39PM +1000, Michael D. Setzer II wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On 2 May 2008 at 9:28, Bernhard Fischer wrote: > >Date sent: Fri, 2 May 2008 09:28:44 +0200 >From: Bernhard Fischer >To: "Michael D. Setzer II" >Copies to: busybox at busybox.net >Subject: Re: Best use of mdev? > >> On Fri, May 02, 2008 at 12:49:33AM +1000, Michael D. Setzer II wrote: >> >-----BEGIN PGP SIGNED MESSAGE----- >> >Hash: SHA1 >> > >> >I was just contacted by a user that has 11 partitions on a large hard disk. My >> >g4l project currently has the nods setup as being precreated in the /dev >> >directory. It had massive number of these for both the hd and sd going all >> >the way to sdp but only to the 9th option. I was manually able to create a >> >script to create the additional nods, but then started looking at options to >> >have it automaticly create the proper nods. I have found the mdev, and >> >seem to have figured some of it out, but think there might be some >> >additional things to make it work better. >> > >> >I booted from the g4l cd, and did the following manually. >> > >> >created the /etc/mdev.conf with these two lines. >> > >> >hd[a-z][0-9]* 0:3 660 >> >sd[a-z][0-9]* 0:3 660 >> > >> >Run the commands to create the /dev >> > >> >mkdir /sys >> >mount -t sysfs sysfs /sys >> >mdev -s >> > >> >Below is the original contents of the /dev directory minus all the hd and sd >> >files. Not sure which all of these can also be created with the mdev.conf file >> >and which have to be manually created. Also, some of the directories were >> >for raid systems that users had. Would the mdev create these? >> >Unfortunately, I don't have all the hardware to test. >> >> I usually only have /dev/null and /dev/console and create all the rest >> via mdev. >> $ egrep -v "(^#|^$)" box/root/etc/inittab >> ::sysinit:/bin/mount -t proc none /proc >> ::sysinit:/bin/mount -t sysfs none /sys >> ::sysinit:/bin/mount -t tmpfs -o size=64k,mode=0755 none /dev >> ::sysinit:/bin/mkdir /dev/pts >> ::sysinit:/bin/mount -t devpts devpts /dev/pts >> ::sysinit:/bin/echo /sbin/mdev > /proc/sys/kernel/hotplug >> ::sysinit:/sbin/mdev -s >> ::sysinit:/bin/mount -o remount,rw / >> ::sysinit:/bin/mount -a >> ::sysinit:/bin/hostname -F /etc/hostname >> ::sysinit:/etc/init.d/rcS >> > >Thanks for all the info. I did some test, and mdev -s seems to create all the >files that were in the /dev directory. The exception was the sub directories >and the symbolic links. Haven't tried with a clean dev on boot. Notice your >system has a way to create the pts, which I need for the telnetd to work. So, >was going to leave it there, but if I can have it created that would be better. > >The vc directory, and the others are for raid controllers that some users >had.Since I don't have a system with these raid systems, I don't know if >mdev could create those directories and nods. Not clear on the vc directory, >since it just has a 0 file. > >Additionally, you seem to do the things in inittab, whereas the g4l that I got >from the last author seems to have it all in the rcS file. > >One question that still stands is do I need to add something to the >mdev.config for md files. It seemed to create a single md file on a test. $ cat box/root/etc/mdev.* cat: box/root/etc/mdev.*: No such file or directory Note that i currently have $ grep SYSFS linux-2.6.25/.config CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_SYSFS=y From cristian.ionescu-idbohrn at axis.com Fri May 2 04:52:25 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Fri, 2 May 2008 13:52:25 +0200 (CEST) Subject: [patch] testsuite/testing.sh: removes obvious bashisms In-Reply-To: <200805021231.50736.vda.linux@googlemail.com> References: <0805011333150.10843@somehost> <200805021140.01381.vda.linux@googlemail.com> <0805021148050.10843@somehost> <200805021231.50736.vda.linux@googlemail.com> Message-ID: <0805021301110.10843@somehost> On Fri, 2 May 2008, Denys Vlasenko wrote: > On Friday 02 May 2008 12:13, Cristian Ionescu-Idbohrn wrote: > > > Either declare than we absolutely require echo -ne to work. > > > > Easy. Force the shebang lines to (in all scripts): > > > > #!/bin/bash > > Is it a bashism? But of course it is. The "good" thing would be we could then stop worrying about them :) > It's more like echo-ism... Really, what I wanted to underline is this: If we want those test scripts to all work with various default shells, than a good approach is to try to make them posix-complient. The two major examples I gave are 'echo' and 'printf'. echo usage in the test-scripts: - the '-e' options is _not_ posix - use of the '-e' option may lead to several tests failing if the default shell (dash on several distributions) does not support it - I think the '-n' option should also be avoided - I'm _not_ saying busybox echo should not support the '-e' and '-n' options - and this is what I base my statements on: http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html - the above document talks about "XSI-conformant systems" and says "The following character sequences shall be recognized on XSI-conformant systems"; '\xHH' is not one of them, but '\OOO' is; the question is: can we always assume XSI-conformancy of all default shells on all distributions? printf usage in the test-scripts: - printf should replace 'echo -ne', as according to this: http://www.opengroup.org/onlinepubs/009695399/utilities/printf.html it that's what it is intended for (among othe things) - escape sequences like '\xHH' are posix-complient, but '\OOO' are and should be used instead > > I have no problems with that, but I still think printf is easier and > > more flexible. Should have added "as a replacement for 'echo -ne'". > printf has more than just aestethic problems. Obviously you don't like printf :) > All "new-style" tests use echo -ne (indirectly). If you change that to > printf, you nned to audit them all for "%" format specifier. Hmm... Yes, some things might break in such cases, but it looks like 'echo -ne' leads to far more breakage on some distributions. Cheers, -- Cristian From cristian.ionescu-idbohrn at axis.com Fri May 2 05:11:48 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Fri, 2 May 2008 14:11:48 +0200 (CEST) Subject: [patch] testsuite/grep.tests: fixes 'grep (no newline at EOL)' test Message-ID: <0805021406560.10843@somehost> Both busybox and gnu grep output a new line character after the located string: # grep bug input even if there is no new line character after the 'bug' string in the input file. Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: grep.tests.patch Type: text/x-diff Size: 519 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080502/aca248ef/attachment.patch From natanael.copa at gmail.com Fri May 2 05:12:50 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Fri, 02 May 2008 14:12:50 +0200 Subject: the busybox-1.10.1-mdev.patch in fixes-1.10.1 break things Message-ID: <1209730370.5978.199.camel@nc.nor.wtbts.org> Attatched is a patch that fixes a bug introduced in the fixes-1.10.1/busybox-1.10.1-mdev.patch that make mdev -s fail on existing mdev.conf files. It should be applied after the busybox-1.10.1-mdev.patch. Below is a diff with --ignore-space-change option to show exactly what this patch does. Please put the attatched diff in the fixes-1.10.1 dir. btw... why was the mdev patch added there in firstplace? I thought fixes should only contain fixes and not new features. # diff -bu util-linux/mdev.c.patched util-linux/mdev.c --- util-linux/mdev.c.patched 2008-05-02 11:08:49 +0000 +++ util-linux/mdev.c 2008-05-02 11:45:30 +0000 @@ -161,14 +161,15 @@ if (ENABLE_FEATURE_MDEV_RENAME) { if (!next) break; + if (*next == '>') { val = next; next = next_field(val); - if (*val == '>') { -#if ENABLE_FEATURE_MDEV_RENAME_REGEXP + if (ENABLE_FEATURE_MDEV_RENAME_REGEXP) { /* substitute %1..9 with off[1..9], if any */ char *s, *p; unsigned i, n; - + val = next; + next = next_field(val); n = 0; s = val; while (*s && *s++ == '%') @@ -190,9 +191,9 @@ p++; s++; } -#else + } else { alias = xstrdup(val + 1); -#endif + } } } -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-1.10.1-mdev2.patch Type: text/x-patch Size: 1666 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080502/fd6560bd/attachment.bin From WHarms at bfs.de Fri May 2 05:16:24 2008 From: WHarms at bfs.de (walter harms) Date: Fri, 02 May 2008 14:16:24 +0200 Subject: [patch] testsuite/testing.sh: removes obvious bashisms In-Reply-To: <0805021301110.10843@somehost> References: <0805011333150.10843@somehost> <200805021140.01381.vda.linux@googlemail.com> <0805021148050.10843@somehost> <200805021231.50736.vda.linux@googlemail.com> <0805021301110.10843@somehost> Message-ID: <481B0618.4070403@bfs.de> Cristian Ionescu-Idbohrn wrote: t. > > The two major examples I gave are 'echo' and 'printf'. > > echo usage in the test-scripts: > > - the '-e' options is _not_ posix > - use of the '-e' option may lead to several tests failing if the > default shell (dash on several distributions) does not support it > - I think the '-n' option should also be avoided > - I'm _not_ saying busybox echo should not support the '-e' and '-n' > options > - and this is what I base my statements on: > http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html > - the above document talks about "XSI-conformant systems" and says > "The following character sequences shall be recognized on > XSI-conformant systems"; '\xHH' is not one of them, but '\OOO' is; the > question is: can we always assume XSI-conformancy of all default > shells on all distributions? > this is correct but be real this is a *testscript* you can simply add to the docu "we expect that echo support ". Making a script work with "posix only" is a nice exercise but that would miss the point of this testscript. Even if this script work with bash only i do not see any problem -- that you can not test it on any not-bash-supported system is a problem but not for the system -- since the (busybox-) code should work there if test on a other box. we have a lot of missing tests *that* is a problem. look at autoconf code if you want to work around bug that the different type of shell may have, not very pleasant reading. just my 2 cent, wh From vda.linux at googlemail.com Fri May 2 05:33:09 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 2 May 2008 14:33:09 +0200 Subject: [patch] testsuite/grep.tests: fixes 'grep (no newline at EOL)' test In-Reply-To: <0805021406560.10843@somehost> References: <0805021406560.10843@somehost> Message-ID: <200805021433.09975.vda.linux@googlemail.com> On Friday 02 May 2008 14:11, Cristian Ionescu-Idbohrn wrote: > Both busybox and gnu grep output a new line character after the located > string: > > ? # grep bug input > > even if there is no new line character after the 'bug' string in the input > file. I added this text as a comment in testsuite: # GNU grep (version?) outputs a new line character after the located string # even if there is no new line character in the input testing "grep (no newline at EOL)" "grep bug input" "bug\n" "bug" "" Which version of grep? Applied, thanks! -- vda From cristian.ionescu-idbohrn at axis.com Fri May 2 05:40:51 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Fri, 2 May 2008 14:40:51 +0200 (CEST) Subject: [patch] testsuite/grep.tests: fixes grep (no newline at EOL) test In-Reply-To: <200805021433.09975.vda.linux@googlemail.com> References: <0805021406560.10843@somehost> <200805021433.09975.vda.linux@googlemail.com> Message-ID: <0805021436500.10843@somehost> On Fri, 2 May 2008, Denys Vlasenko wrote: > I added this text as a comment in testsuite: > > # GNU grep (version?) outputs a new line character after the located string > # even if there is no new line character in the input > testing "grep (no newline at EOL)" "grep bug input" "bug\n" "bug" "" > > Which version of grep? grep (GNU grep) 2.5.1 GNU grep 2.5.3 Cheers, -- Cristian From vda.linux at googlemail.com Fri May 2 05:47:48 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 2 May 2008 14:47:48 +0200 Subject: the busybox-1.10.1-mdev.patch in fixes-1.10.1 break things In-Reply-To: <1209730370.5978.199.camel@nc.nor.wtbts.org> References: <1209730370.5978.199.camel@nc.nor.wtbts.org> Message-ID: <200805021447.48320.vda.linux@googlemail.com> On Friday 02 May 2008 14:12, Natanael Copa wrote: > Attatched is a patch that fixes a bug introduced in the > fixes-1.10.1/busybox-1.10.1-mdev.patch that make mdev -s fail on > existing mdev.conf files. > > It should be applied after the busybox-1.10.1-mdev.patch. > > Below is a diff with --ignore-space-change option to show exactly what > this patch does. > > Please put the attatched diff in the fixes-1.10.1 dir. Ok... can you test attached patch (atop busybox-1.10.1-mdev.patch)? > btw... why was the mdev patch added there in firstplace? I thought fixes > should only contain fixes and not new features. mdev had a serious bug - it was creating wrong type of device nodes. Also it didn't stop parsing config after first match. Other smaller problems too. I decided that it's too buggy to let people wait for 1.11. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 4.patch Type: text/x-diff Size: 771 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080502/132113d8/attachment.patch From vda.linux at googlemail.com Fri May 2 06:19:02 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 2 May 2008 15:19:02 +0200 Subject: [patch] testsuite/testing.sh: removes obvious bashisms In-Reply-To: <0805021301110.10843@somehost> References: <0805011333150.10843@somehost> <200805021231.50736.vda.linux@googlemail.com> <0805021301110.10843@somehost> Message-ID: <200805021519.02287.vda.linux@googlemail.com> On Friday 02 May 2008 13:52, Cristian Ionescu-Idbohrn wrote: > Really, what I wanted to underline is this: > > If we want those test scripts to all work with various default > shells, than a good approach is to try to make them posix-complient. I agree. > The two major examples I gave are 'echo' and 'printf'. > > echo usage in the test-scripts: > > - the '-e' options is _not_ posix > - use of the '-e' option may lead to several tests failing if the > default shell (dash on several distributions) does not support it > - I think the '-n' option should also be avoided > - I'm _not_ saying busybox echo should not support the '-e' and '-n' > options > - and this is what I base my statements on: > http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html > - the above document talks about "XSI-conformant systems" and says > "The following character sequences shall be recognized on > XSI-conformant systems"; '\xHH' is not one of them, but '\OOO' is; the > question is: can we always assume XSI-conformancy of all default > shells on all distributions? I understand this and agree that making it work on more systems is a good goal. > > printf usage in the test-scripts: > > - printf should replace 'echo -ne', as according to this: > http://www.opengroup.org/onlinepubs/009695399/utilities/printf.html > it that's what it is intended for (among othe things) > - escape sequences like '\xHH' are posix-complient, but '\OOO' are and > should be used instead > > > > I have no problems with that, but I still think printf is easier and > > > more flexible. > > Should have added "as a replacement for 'echo -ne'". > > > printf has more than just aestethic problems. > > Obviously you don't like printf :) I don't have any problems with it. I just know that new-style scripts can break if we switch to it, because their strings can contain "%". Therefore it cannot be used. > > All "new-style" tests use echo -ne (indirectly). If you change that to > > printf, you nned to audit them all for "%" format specifier. > > Hmm... Yes, some things might break in such cases, but it looks like > 'echo -ne' leads to far more breakage on some distributions. Therefore neither echo -ne nor printf is ok. I propose using helper binary. -- vda From cristian.ionescu-idbohrn at axis.com Fri May 2 06:36:47 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Fri, 2 May 2008 15:36:47 +0200 (CEST) Subject: [patch] testsuite/testing.sh: removes obvious bashisms In-Reply-To: <200805021519.02287.vda.linux@googlemail.com> References: <0805011333150.10843@somehost> <200805021231.50736.vda.linux@googlemail.com> <0805021301110.10843@somehost> <200805021519.02287.vda.linux@googlemail.com> Message-ID: <0805021528130.10843@somehost> On Fri, 2 May 2008, Denys Vlasenko wrote: > On Friday 02 May 2008 13:52, Cristian Ionescu-Idbohrn wrote: > > > > Obviously you don't like printf :) > > I don't have any problems with it. I just know that new-style scripts > can break if we switch to it, because their strings can contain "%". > > Therefore it cannot be used. Do we have control over those strings? Could you give an RL example? > Therefore neither echo -ne nor printf is ok. Hmm... Still, they can be used in many cases, as long as we control the strings. > I propose using helper binary. Well, I can't say I'm happy about it, but it might be needed. Still, I'd like to see some RL examples that show there is no other way. Cheers, -- Cristian From vda.linux at googlemail.com Fri May 2 06:39:41 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 2 May 2008 15:39:41 +0200 Subject: [patch] testsuite/testing.sh: removes obvious bashisms In-Reply-To: <0805021528130.10843@somehost> References: <0805011333150.10843@somehost> <200805021519.02287.vda.linux@googlemail.com> <0805021528130.10843@somehost> Message-ID: <200805021539.41231.vda.linux@googlemail.com> On Friday 02 May 2008 15:36, Cristian Ionescu-Idbohrn wrote: > On Fri, 2 May 2008, Denys Vlasenko wrote: > > > On Friday 02 May 2008 13:52, Cristian Ionescu-Idbohrn wrote: > > > > > > Obviously you don't like printf :) > > > > I don't have any problems with it. I just know that new-style scripts > > can break if we switch to it, because their strings can contain "%". > > > > Therefore it cannot be used. > > Do we have control over those strings? > Could you give an RL example? testsuite/pidof.tests #!/bin/sh # pidof tests. # Copyright 2005 by Bernhard Fischer # Licensed under GPL v2, see file LICENSE for details. # AUDIT: . testing.sh # testing "test name" "options" "expected result" "file input" "stdin" testing "pidof (exit with error)" \ "pidof veryunlikelyoccuringbinaryname ; echo \$?" "1\n" "" "" testing "pidof (exit with success)" "pidof pidof > /dev/null; echo \$?" \ "0\n" "" "" # We can get away with this because it says #!/bin/sh up top. testing "pidof this" "pidof pidof.tests | grep -o -w $$" "$$\n" "" "" optional FEATURE_PIDOF_SINGLE testing "pidof -s" "pidof -s init" "1\n" "" "" optional FEATURE_PIDOF_OMIT # This test fails now because process name matching logic has changed, # but new logic is not "wrong" either... see find_pid_by_name.c comments #testing "pidof -o %PPID" "pidof -o %PPID pidof.tests | grep -o -w $$" "" "" "" testing "pidof -o %PPID NOP" "pidof -o %PPID -s init" "1\n" "" "" testing "pidof -o init" "pidof -o 1 init | grep -o -w 1" "" "" "" exit $FAILCOUNT testsuite/uuencode.tests #!/bin/sh # unit test for uuencode to test functionality. # Copyright 2006 by Erik Hovland # Licensed under GPL v2, see file LICENSE for details. # AUDIT: Unit tests for uuencode . testing.sh # testing "test name" "options" "expected result" "file input" "stdin" # file input will be file called "input" # test can create a file "actual" instead of writing to stdout # Test setup of standard input saved_umask=$(umask) umask 0 testing "uuencode sets standard input mode correctly" \ "uuencode foo 2!F;W@@:G5M<&5D(&]V97(@=&AE(&QA>GD at 8G)O=VX@\n%9&]G+ at H\`\n\`\nend\n" \ "" "The fast grey fox jumped over the lazy brown dog.\n" testing "uuencode correct base64 encoding" "uuencode -m bb_uuenc_test.out" \ "begin-base64 644 bb_uuenc_test.out\nVGhlIGZhc3QgZ3JleSBmb3gganVtcGVkIG92ZXIgdGhlIGxhenkgYnJvd24g\nZG9nLgo=\n====\n" \ "" "The fast grey fox jumped over the lazy brown dog.\n" exit $FAILCOUNT > > > Therefore neither echo -ne nor printf is ok. > > Hmm... Still, they can be used in many cases, as long as we control the > strings. > > > I propose using helper binary. > > Well, I can't say I'm happy about it, but it might be needed. Still, I'd > like to see some RL examples that show there is no other way. > > > Cheers, > From dnlombar at ichips.intel.com Fri May 2 06:46:00 2008 From: dnlombar at ichips.intel.com (Lombard, David N) Date: Fri, 2 May 2008 06:46:00 -0700 Subject: Best use of mdev? In-Reply-To: <20080502072844.GB14696@mx.loc> References: <481A651D.20097.4311B0F@mikes.kuentos.guam.net> <20080502072844.GB14696@mx.loc> Message-ID: <20080502134600.GA15859@nlxdcldnl2.cl.intel.com> On Fri, May 02, 2008 at 09:28:44AM +0200, Bernhard Fischer wrote: > > I usually only have /dev/null and /dev/console and create all the rest > via mdev. I've switched over to the kernel's initrd utilities to avoid having to create devices, i.e., to build as non-root: { $SHELL linux-2.6.25/scripts/gen_initramfs_list.sh \ -u squash -g squash root echo "nod /dev/null 0600 0 0 c 1 3" echo "nod /dev/tty1 0600 0 0 c 4 1" echo "nod /dev/ttyS0 0600 0 0 c 4 64" echo "nod /dev/ttyS1 0600 0 0 c 4 65" } | linux-2.6.25/usr/gen_init_cpio - | gzip > initrd.img Earlier versions were less useful: $SHELL linux-2.6.18/scripts/gen_initramfs_list.sh \ -u $(id -u) -g $(id -g) root > initramfs_list echo "nod /dev/null 0600 0 0 c 1 3" >> initramfs_list echo "nod /dev/tty1 0600 0 0 c 4 1" >> initramfs_list echo "nod /dev/ttyS0 0600 0 0 c 4 64" >> initramfs_list echo "nod /dev/ttyS1 0600 0 0 c 4 65" >> initramfs_list linux-2.6.18/usr/gen_init_cpio initramfs_list | gzip > initrd.img -- David N. Lombard, Intel, Irvine, CA I do not speak for Intel Corporation; all comments are strictly my own. From cristian.ionescu-idbohrn at axis.com Fri May 2 07:26:46 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Fri, 2 May 2008 16:26:46 +0200 (CEST) Subject: [patch] testsuite/testing.sh: removes obvious bashisms In-Reply-To: <200805021539.41231.vda.linux@googlemail.com> References: <0805011333150.10843@somehost> <200805021519.02287.vda.linux@googlemail.com> <0805021528130.10843@somehost> <200805021539.41231.vda.linux@googlemail.com> Message-ID: <0805021546160.10843@somehost> On Fri, 2 May 2008, Denys Vlasenko wrote: > On Friday 02 May 2008 15:36, Cristian Ionescu-Idbohrn wrote: > > On Fri, 2 May 2008, Denys Vlasenko wrote: > > > > > On Friday 02 May 2008 13:52, Cristian Ionescu-Idbohrn wrote: > > > > > > > > Obviously you don't like printf :) > > > > > > I don't have any problems with it. I just know that new-style > > > scripts can break if we switch to it, because their strings can > > > contain "%". > > > > > > Therefore it cannot be used. > > > > Do we have control over those strings? > > Could you give an RL example? > > testsuite/pidof.tests Thanks. I was afraid but I didn't know why :) What about: -#testing "pidof -o %PPID" "pidof -o %PPID pidof.tests | grep -o -w $$" "" "" "" -testing "pidof -o %PPID NOP" "pidof -o %PPID -s init" "1\n" "" "" +#testing "pidof -o \045PPID" "pidof -o \045PPID pidof.tests | grep -o -w $$" "" "" "" +testing "pidof -o \045PPID NOP" "pidof -o \045PPID -s init" "1\n" "" "" Is it too quirky (there's already one escaped sequence in there)? > testsuite/uuencode.tests Same here: -"begin 644 bb_uuenc_test.out\nM5&AE(&9A2!F;W@@:G5M<&5D(&]V97(@=&AE(&QA>GD at 8G)O=VX@\n%9&]G+ at H\`\n\`\nend\n" \ +"begin 644 bb_uuenc_test.out\nM5&AE(&9A2!F;W@@:G5M<&5D(&]V97(@=&AE(&QA>GD at 8G)O=VX@\n\0459&]G+ at H\`\n\`\nend\n" \ Wouldn't that work with printf? There is also the problem when a real '\' is part of the string, and would need to be replaced by either '\\' or '\134'. And more :( What about some stray '$' in the wrong neighbourhood: ---8<--- #!/bin/dash -e foo=FOO bar=date echo "echo: var: expect a FOO here '$foo'" printf "printf: var: expect another FOO here '$foo'\n" echo "echo: expr: today's '$($bar)' weather" printf "printf: expr: today's '$($bar)' weather\n" exit 0 ---8<--- You need to watch for that too. Nirvana is still far away :) Anyway, as long as you have control over the input yo can get around. It's harder if you don't. Cheers, -- Cristian From cristian.ionescu-idbohrn at axis.com Fri May 2 07:29:40 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Fri, 2 May 2008 16:29:40 +0200 (CEST) Subject: use of 'testing' function from testsuite/testing.sh Message-ID: <0805021413310.10843@somehost> Documentation: # The "testing" function takes five arguments: # $1) Description to display when running command -# $2) Command line arguments to command +# $2) Command and command line arguments # $3) Expected result (on stdout) # $4) Data written to file "input" # $5) Data written to stdin +# At least one of $4 and $5 should not be empty, but if both are empty +# an input file name should be included in $2 (how do we validate that?). Tests not specifying $4 or $5 _and_ the input (file) in $2 (when $4 is non-empty) may not work at all. Some still do work due to a "feature/bug" in the 'testing' function, which always does this: echo -ne "$5" | eval "$2" regardless. This should be probably done only if both $4 and $5 are empty. If $4 is non-emty the magic word 'input' should be present in $2, but even if it's present, it could be placed in the wrong spot. And if $5 is empty, then only: eval "$2" should be executed (no echo). Are there cases where we want both stdin and input file(s)? Are there cases where we _don't_ want them both? If both $4 and $5 are non-empy, the magic word 'input' should be present in $2, double input should be assumed and the 'testing' function should execute: echo "$5" | eval "$2" Still, not totally reliable :( Cheers, -- Cristian From Joakim.Tjernlund at transmode.se Fri May 2 07:35:50 2008 From: Joakim.Tjernlund at transmode.se (Joakim Tjernlund) Date: Fri, 2 May 2008 16:35:50 +0200 Subject: [PATCH 2/2] start-stop-daemon - find processes better In-Reply-To: <200805021043.05959.vda.linux@googlemail.com> References: <200804301218.05140.roy@marples.name> <200805011518.40943.vda.linux@googlemail.com> <200805011438.19384.roy@marples.name> <200805021043.05959.vda.linux@googlemail.com> Message-ID: <003401c8ac61$d1b38ef0$751aacd0$@Tjernlund@transmode.se> > -----Original Message----- > From: Denys Vlasenko [mailto:vda.linux at googlemail.com] > Sent: den 2 maj 2008 10:43 > To: Roy Marples > Cc: joakim.tjernlund at transmode.se; busybox at busybox.net > Subject: Re: [PATCH 2/2] start-stop-daemon - find processes better > > Hi Roy, Joakim. > > Joakim, please scroll down to the end and let me know > what you thing about proposed ssd documentation. > > > On Thursday 01 May 2008 15:38, Roy Marples wrote: > > > > > It's not a pathname, it's just a "name" (arbitrary) > > > > > > > > Correct. It's a crap option. Gentoo silently remaps it to --exec > > > > > > Are you suggesting to drop it? This risks breaking > > > things for existing users. > > > > No, I'm suggesting just to remap --startas to --exec > > Don't see why it cannot be used as intended - as an argv[0] override. > > > > > My view is that it searches for programs started as that. > > > > So if the user launches /usr/sbin/ntpd then ssd should check > > > > /proc/pid/cmdline to see if it was started as /usr/sbin/ntpd and then > > > > match. > > > > > > And what to do if cmdline contains just "ntpd"? or "./ntpd"? > > > Does that match? > > > Do we need to check /proc/$PID/stat? /proc/$PID/exec? > > > > That's the one hole really :) > > It doesn't match, but then I don't expect it too either. ssd is normally used > > in scripts, so the way it's started should match the way it's stopped. yes it is a hole, but we could try rebuild the full path by merging the CWD and cmdline in this case. I don't think this is a big deal though. > > I need this to be exactly spelled out. > > > > > > -n,--name process-name Stop processes with this name > > > > AND don't create a pidfile AND are scripts. Again, this is why we > > > > changed --exec to look at how it was started to solve this problem. > > > > > > How it is different from -x? > > > > -x is --exec, or did I miss something? > > I meant "how --exec is different for --name?" > > > > > In normal ssd, -p only matters when stopping. It reads the specified file > > > > and just stops that pid. > > > > However, ssd can also background some daemons which don't by default. Or > > > > which don't create a pidifle by default. So the solution is to run the > > > > daemon in foreground mode in a forked process. We then store that pid in > > > > the pidfile. Example > > > > > > > > start-stop-daemon --start --exec /usr/sbin/daemon --pidfile > > > > /var/run/daemon.pid --make-pidfile -- --foreground --foreground is an > > > > option specific to daemon and not start-stop-daemon. > > > > > > But --make-pidfile seems to be superfluous here... --start + --pidfile FILE > > > imply pidfile creation. > > Really? Must be documented. And if --make-pidfile indeed implies > pidfile creation, then it makes no sense. Adding/removing > --make-pidfile to command line chages nothing. > > > Not so as --pidfile is used to check processes before the demon starts > > > > start-stop-daemon --start --exec /usr/bin/foo --pidfile /var/run/foo.pid > > > > Check that /usr/bin/foo is NOT running on the pidfile in /var/run/foo.pid. > > If not running, start foo, otherwise error. > > ssd should not stamp on pidfiles unless told. > > > Please review proposed documentation below. > > Please spell out how -n NAME and -x NAME are different in respect > to stopping the processes. To reiterate: we nave 3 different > ideas of "process name": > > In Linux we have three ways to determine "process name": > 1. /proc/PID/stat has "...(name)...", among other things. It's so-called "comm" field. > 2. /proc/PID/cmdline's first NUL-terminated string. It's argv[0] from exec syscall. > 3. /proc/PID/exe symlink. Points to the running executable file. > kernel threads: > comm: thread name > cmdline: empty > exe: > executable > comm: first 15 chars of base name > (if executable is a symlink, then first 15 chars of symlink name are used) > cmdline: argv[0] from exec syscall > exe: points to executable (resolves symlink, unlike comm) > script (an executable with #!/path/to/interpreter): > comm: first 15 chars of script's base name (symlinks are not resolved) > cmdline: /path/to/interpreter (symlinks are not resolved) > (script name is in argv[1], args are pushed into argv[2] etc) > exe: points to interpreter's executable (symlinks are resolved) > > Which one(s) should be used by -n? -x? I think we should use cmdline for all. The comm. field is too small to hold a bigger file name so it would be hard to match such a file. > > > > > start-stop-daemon [OPTIONS] [--start|--stop] ... [-- arguments...] > > One (only) of these must be given: > -S,--start Start > -K,--stop Stop > > start-stop-daemon will first search for matching processes, > stop them (by sending a signal). If --start is given, > it will then start a new process. Perhaps this could read start-stop-daemon will first search for matching processes. If --stop is given, then stop all matching processes(by sending a signal). If --start if given, start a new process unless a matching process was found. > Stop options: > -u,--user USERNAME|UID Stop this user's processes > -n,--name PROCESS_NAME Stop processes with this name ?? > -x,--exec EXECUTABLE Stop processes with this name ?? Perhaps -n,--name PROCESS_NAME Stop processes with matching basename(argv[0]) -x,--exec EXECUTABLE Stop processes with matching argv[0] > -p,--pidfile PID_FILE Stop processes with PID from this file > -s,--signal SIG Signal to send (default TERM) > > Start options: > -x,--exec EXECUTABLE Program to run (1st arg of execvp). Mandatory. > -a,--startas NAME argv[0] (defults to EXECUTABLE) > -b,--background Put process into background > -N,--nicelevel N Add N to process's nice level > -c,--chuid user[:[grp]] Change to specified user/group > -m,--make-pidfile -p,--pidfile PID_FILE > Write PID to the file > (both -m and -p must be given!) > Misc options: > -o,--oknodo Exit status 0 if nothing done > -q,--quiet Quiet > -v,--verbose Verbose > > > > -- > vda From natanael.copa at gmail.com Fri May 2 09:22:47 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Fri, 02 May 2008 18:22:47 +0200 Subject: the busybox-1.10.1-mdev.patch in fixes-1.10.1 break things In-Reply-To: <200805021447.48320.vda.linux@googlemail.com> References: <1209730370.5978.199.camel@nc.nor.wtbts.org> <200805021447.48320.vda.linux@googlemail.com> Message-ID: <1209745367.5978.203.camel@nc.nor.wtbts.org> On Fri, 2008-05-02 at 14:47 +0200, Denys Vlasenko wrote: > On Friday 02 May 2008 14:12, Natanael Copa wrote: > > Attatched is a patch that fixes a bug introduced in the > > fixes-1.10.1/busybox-1.10.1-mdev.patch that make mdev -s fail on > > existing mdev.conf files. > > > > It should be applied after the busybox-1.10.1-mdev.patch. > > > > Below is a diff with --ignore-space-change option to show exactly what > > this patch does. > > > > Please put the attatched diff in the fixes-1.10.1 dir. > > Ok... can you test attached patch (atop busybox-1.10.1-mdev.patch)? yup. works. i switched back to 1.9.2 last minute because i need to make a release of alpine (my busybox/uclibc based distro) today. But that was related to other things. > > btw... why was the mdev patch added there in firstplace? I thought fixes > > should only contain fixes and not new features. > > mdev had a serious bug - it was creating wrong type of device nodes. > Also it didn't stop parsing config after first match. > Other smaller problems too. > > I decided that it's too buggy to let people wait for 1.11. fair enough. Thanks! > -- > vda From cristian.ionescu-idbohrn at axis.com Fri May 2 09:25:32 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Fri, 2 May 2008 18:25:32 +0200 (CEST) Subject: [patch] testsuite/testing.sh: tidyups Message-ID: <0805021814430.10843@somehost> A previous 'optionflag' function seems to have been renamed to 'optional', but the documentation remained unchanged. Empty string variables can be set like this: SKIP= SKIP='' SKIP="" Better not mix them, so I just fixed another non-problem ;-) General idea seems to be that positional parameters should be quote protected. Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: testing.sh.2.patch Type: text/x-diff Size: 1601 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080502/201a4dfb/attachment-0001.patch From cristian.ionescu-idbohrn at axis.com Fri May 2 10:33:30 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Fri, 2 May 2008 19:33:30 +0200 (CEST) Subject: [patch] testsuite/cpio.tests: fixes half of it Message-ID: <0805021827070.10843@somehost> hexdump on my system (part of the bsdmainutils v6.1.10) does not support the '-R' option, so I need to use busybox hexdump with FEATURE_HEXDUMP_REVERSE enabled. I'm a bit unsure about proper usage of the 'optional' function, but used like I did seems to work. Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: cpio.tests.patch Type: text/x-diff Size: 892 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080502/17342e0f/attachment.patch From rep.dot.nop at gmail.com Fri May 2 13:21:53 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Fri, 2 May 2008 22:21:53 +0200 Subject: [patch] testsuite/cpio.tests: fixes half of it In-Reply-To: <0805021827070.10843@somehost> References: <0805021827070.10843@somehost> Message-ID: <20080502202153.GB9589@mx.loc> On Fri, May 02, 2008 at 07:33:30PM +0200, Cristian Ionescu-Idbohrn wrote: >hexdump on my system (part of the bsdmainutils v6.1.10) does not support >the '-R' option, so I need to use busybox hexdump with >FEATURE_HEXDUMP_REVERSE enabled. > >I'm a bit unsure about proper usage of the 'optional' function, but used >like I did seems to work. optional is ment to toggle test on or off, depending on whether a feature was set or not (see pidof.tests for the way i ment it to be used; It could be that it was extended or changed since then, i didn't look). To reset non-conditional tests, use 'optional ""' (IIRC). HTH, From vda.linux at googlemail.com Fri May 2 13:56:39 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 2 May 2008 22:56:39 +0200 Subject: [patch] testsuite/cpio.tests: fixes half of it In-Reply-To: <0805021827070.10843@somehost> References: <0805021827070.10843@somehost> Message-ID: <200805022256.39692.vda.linux@googlemail.com> On Friday 02 May 2008 19:33, Cristian Ionescu-Idbohrn wrote: > hexdump on my system (part of the bsdmainutils v6.1.10) does not support > the '-R' option, so I need to use busybox hexdump with > FEATURE_HEXDUMP_REVERSE enabled. # check if hexdump supports the '-R' option echo "x" | hexdump -R >/dev/null 2>&1 || optional FEATURE_HEXDUMP_REVERSE [ -z "$SKIP" ] || { echo "'hexdump -R' not available" >&2 exit 1 } "If hexdump -R fails, die with "'hexdump -R' not available". Else check FEATURE_HEXDUMP_REVERSE, and if it is not set, die with "'hexdump -R' not available". " I don't understand. If hexdump -R works, then FEATURE_HEXDUMP_REVERSE is set. optional FEATURE_HEXDUMP_REVERSE will always return SKIP="". IOW: this will work: hexdump -R /dev/null 2>&1 || { echo "'hexdump -R' is not available" >&2 exit 1 } Am I missing something? -- vda From cristian.ionescu-idbohrn at axis.com Fri May 2 14:14:18 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Fri, 2 May 2008 23:14:18 +0200 (CEST) Subject: [patch] testsuite/cpio.tests: fixes half of it In-Reply-To: <200805022256.39692.vda.linux@googlemail.com> References: <0805021827070.10843@somehost> <200805022256.39692.vda.linux@googlemail.com> Message-ID: <0805022312010.10843@somehost> On Fri, 2 May 2008, Denys Vlasenko wrote: > On Friday 02 May 2008 19:33, Cristian Ionescu-Idbohrn wrote: > > hexdump on my system (part of the bsdmainutils v6.1.10) does not support > > the '-R' option, so I need to use busybox hexdump with > > FEATURE_HEXDUMP_REVERSE enabled. > > # check if hexdump supports the '-R' option > echo "x" | hexdump -R >/dev/null 2>&1 || optional FEATURE_HEXDUMP_REVERSE > [ -z "$SKIP" ] || { > echo "'hexdump -R' not available" >&2 > exit 1 > } > > "If hexdump -R fails, die with "'hexdump -R' not available". > Else check FEATURE_HEXDUMP_REVERSE, and if it is not set, > die with "'hexdump -R' not available". " > > I don't understand. If hexdump -R works, then FEATURE_HEXDUMP_REVERSE > is set. optional FEATURE_HEXDUMP_REVERSE will always return SKIP="". > > IOW: this will work: > > hexdump -R /dev/null 2>&1 || { > echo "'hexdump -R' is not available" >&2 > exit 1 > } > > Am I missing something? No, that's better. Cheers, -- Cristian From vda.linux at googlemail.com Fri May 2 14:14:40 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 2 May 2008 23:14:40 +0200 Subject: use of 'testing' function from testsuite/testing.sh In-Reply-To: <0805021413310.10843@somehost> References: <0805021413310.10843@somehost> Message-ID: <200805022314.40228.vda.linux@googlemail.com> On Friday 02 May 2008 16:29, Cristian Ionescu-Idbohrn wrote: > Documentation: > > # The "testing" function takes five arguments: > # $1) Description to display when running command > -# $2) Command line arguments to command > +# $2) Command and command line arguments Command(s) to run. May have pipes, redirects, etc > # $3) Expected result (on stdout) > # $4) Data written to file "input" > # $5) Data written to stdin > +# At least one of $4 and $5 should not be empty, but if both are empty > +# an input file name should be included in $2 (how do we validate that?). "Sanity checking found bugs. More sanity checking found more bugs and now even more sanity checking finds bugs in sanity checking. What will be next?" Seriously. $4 and $5 _can_ be empty. Lots of commands don't use input. For example, mdev. "an input file name should be included in $2". What input file? Why it should be included? The applets we test are so diverse, they have wastly different behavior. For example, sleep applet takes no input. At all. There will be no "input file" in $2 for it. And lastly, we don't need sanity checking on sanity checking. > Tests not specifying $4 or $5 _and_ the input (file) in $2 (when $4 is > non-empty) may not work at all. Some still do work due to a > "feature/bug" in the 'testing' function, which always does this: > > echo -ne "$5" | eval "$2" > > regardless. This should be probably done only if both $4 and $5 are > empty. > > If $4 is non-emty the magic word 'input' should be present in $2, but even > if it's present, it could be placed in the wrong spot. And if $5 is > empty, then only: > > eval "$2" > > should be executed (no echo). What will happen if test *will* read stdin? > Are there cases where we want both stdin and input file(s)? Yes. grep etc. > Are there cases where we _don't_ want them both? Yes. There are. But "testing" doesn't need to bother! It should just feed the stding and create "input", and don't worry whether thing being tested uses it or not. > If both $4 and $5 are non-empy, the magic word 'input' should be present > in $2, double input should be assumed and the 'testing' function should > execute: > > echo "$5" | eval "$2" > > Still, not totally reliable :( I dont understand. _What_ is not reliable? -- vda From vda.linux at googlemail.com Fri May 2 14:45:58 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 2 May 2008 23:45:58 +0200 Subject: [patch] testsuite/testing.sh: removes obvious bashisms In-Reply-To: <0805021546160.10843@somehost> References: <0805011333150.10843@somehost> <200805021539.41231.vda.linux@googlemail.com> <0805021546160.10843@somehost> Message-ID: <200805022345.58278.vda.linux@googlemail.com> On Friday 02 May 2008 16:26, Cristian Ionescu-Idbohrn wrote: > > > > I don't have any problems with it. I just know that new-style > > > Could you give an RL example? > > > > testsuite/pidof.tests > > Thanks. I was afraid but I didn't know why :) What about: > > -#testing "pidof -o %PPID" "pidof -o %PPID pidof.tests | grep -o -w $$" "" "" "" > -testing "pidof -o %PPID NOP" "pidof -o %PPID -s init" "1\n" "" "" > +#testing "pidof -o \045PPID" "pidof -o \045PPID pidof.tests | grep -o -w $$" "" "" "" > +testing "pidof -o \045PPID NOP" "pidof -o \045PPID -s init" "1\n" "" "" > > Is it too quirky (there's already one escaped sequence in there)? You are proposing that starting from now test writers should _also_ worry about having accidental %format string in their strings escaped. > > testsuite/uuencode.tests > > Same here: > > -"begin 644 bb_uuenc_test.out\nM5&AE(&9A2!F;W@@:G5M<&5D(&]V97(@=&AE(&QA>GD at 8G)O=VX@\n%9&]G+ at H\`\n\`\nend\n" \ > +"begin 644 bb_uuenc_test.out\nM5&AE(&9A2!F;W@@:G5M<&5D(&]V97(@=&AE(&QA>GD at 8G)O=VX@\n\0459&]G+ at H\`\n\`\nend\n" \ > > Wouldn't that work with printf? Technically, yes. But I'd rather use this: export FAILCOUNT=0 export SKIP= +# Helper for helpers. Oh my... +test x"$ECHO" = x"" && { + export ECHO="echo" + test x"`echo -ne`" = x"" || { + # Compile and use a replacement 'echo' which understands -e -n + ECHO="$PWD/echo-ne" + test -x "$ECHO" || { + gcc -Os -o "$ECHO" ../scripts/echo.c || exit 1 + } + } +} + # Helper functions optional() Please check current svn - is it ok now? -- vda From cristian.ionescu-idbohrn at axis.com Fri May 2 15:12:44 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sat, 3 May 2008 00:12:44 +0200 (CEST) Subject: use of 'testing' function from testsuite/testing.sh In-Reply-To: <200805022314.40228.vda.linux@googlemail.com> References: <0805021413310.10843@somehost> <200805022314.40228.vda.linux@googlemail.com> Message-ID: <0805022324170.10843@somehost> On Fri, 2 May 2008, Denys Vlasenko wrote: > On Friday 02 May 2008 16:29, Cristian Ionescu-Idbohrn wrote: > > Documentation: > > > > # The "testing" function takes five arguments: > > # $1) Description to display when running command > > -# $2) Command line arguments to command > > +# $2) Command and command line arguments > > Command(s) to run. May have pipes, redirects, etc That's fine. But "Command line arguments to command" is a little bit confusing. > > # $3) Expected result (on stdout) > > # $4) Data written to file "input" > > # $5) Data written to stdin > > +# At least one of $4 and $5 should not be empty, but if both are empty > > +# an input file name should be included in $2 (how do we validate that?). > > "Sanity checking found bugs. More sanity checking found more bugs > and now even more sanity checking finds bugs in sanity checking. > > What will be next?" You tell me. > Seriously. $4 and $5 _can_ be empty. Lots of commands don't use input. > For example, mdev. Yes, I figured that out. I'm not complaining, but I still think it's a bit confusing and may thus be one reason why writing tests might not so attractive. > "an input file name should be included in $2". What input file? > Why it should be included? The applets we test are so diverse, > they have wastly different behavior. For example, sleep > applet takes no input. At all. There will be no "input file" > in $2 for it. Yes, I do see that writing flexible tools is not easy. I'm not complainig. I'm just stating unattractiveness has side effects, like not enough tests to cover all areas. And, by the way, attached is a POC test for hexdump. > And lastly, we don't need sanity checking on sanity checking. If you say so. But, I agree, it may get too complex. > > Tests not specifying $4 or $5 _and_ the input (file) in $2 (when $4 is > > non-empty) may not work at all. Some still do work due to a > > "feature/bug" in the 'testing' function, which always does this: > > > > echo -ne "$5" | eval "$2" > > > > regardless. This should be probably done only if both $4 and $5 are > > empty. > > > > If $4 is non-emty the magic word 'input' should be present in $2, but even > > if it's present, it could be placed in the wrong spot. And if $5 is > > empty, then only: > > > > eval "$2" > > > > should be executed (no echo). > > What will happen if test *will* read stdin? Yes. Loose end. > > Are there cases where we want both stdin and input file(s)? > > Yes. grep etc. > > > Are there cases where we _don't_ want them both? > > Yes. There are. But "testing" doesn't need to bother! Those questions were a bit rhethorical. > It should just feed the stding and create "input", > and don't worry whether thing being tested uses it or not. How do you then test whether thing being tested _shouldn't_ use it? > > If both $4 and $5 are non-empy, the magic word 'input' should be present > > in $2, double input should be assumed and the 'testing' function should > > execute: > > > > echo "$5" | eval "$2" > > > > Still, not totally reliable :( > > I dont understand. _What_ is not reliable? Bad wording, maybe. Confusion, maybe. Still, finding reliable ways to write tests isn't easy att all. Cheers, -- Cristian -------------- next part -------------- _app=hexdump tmpf=$(mktemp /tmp/${0##*/}.XXXXXXXXXX) || { echo "E: can't create temp file" >&2 exit 1 } exec 5>$tmpf cleanup() { rm -fr $tmpf $host_hxd $bb_hxd $orig } trap 'cleanup' EXIT _bbwd=$(pwd) while [ "$_bbwd" ] && [ ! -x $_bbwd/busybox ]; do _bbwd=${_bbwd%/*} done [ "$_bbwd" ] || { echo "E: can't busybox executable" >&2 exit 1 } echo "PATH=$PATH" >&5 which -a hexdump >&5 hxd_path= IFS_old="$IFS" IFS=: for _d in $PATH; do [ -x $_d/$_app ] || continue [ $_d != $_bbwd ] || continue hxd_path=$_d/$_app break done IFS="$IFS_old" echo "I: found this:" >&5 echo " $hxd_path" >&5 echo " $_bbwd/busybox" >&5 host_hxd=$tmpf.host > $host_hxd && chmod 600 $host_hxd cat $0 | bzip2 -c | $hxd_path -Cv >>$host_hxd 2>>$tmpf bb_hxd=$tmpf.bb > $bb_hxd && chmod 600 $bb_hxd cat $0 | bzip2 -c | $_bbwd/busybox $_app -Cv >>$bb_hxd 2>>$tmpf cmp $host_hxd $bb_hxd 2>>$tmpf orig=$tmpf.orig > $orig && chmod 600 $orig $_bbwd/busybox $_app -R $bb_hxd | bunzip2 -c >>$orig cmp $0 $orig 2>>$tmpf From vda.linux at googlemail.com Fri May 2 16:20:31 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 3 May 2008 01:20:31 +0200 Subject: use of 'testing' function from testsuite/testing.sh In-Reply-To: <0805022324170.10843@somehost> References: <0805021413310.10843@somehost> <200805022314.40228.vda.linux@googlemail.com> <0805022324170.10843@somehost> Message-ID: <200805030120.31317.vda.linux@googlemail.com> On Saturday 03 May 2008 00:12, Cristian Ionescu-Idbohrn wrote: > > It should just feed the stding and create "input", > > and don't worry whether thing being tested uses it or not. > > How do you then test whether thing being tested _shouldn't_ use it? "echo FOO | { thing being tested; read foo; }; echo $foo" If $foo is not set to FOO, thing ate FOO. Bad thing, bad. -- vda From paul at mad-scientist.us Fri May 2 16:27:11 2008 From: paul at mad-scientist.us (Paul Smith) Date: Fri, 02 May 2008 19:27:11 -0400 Subject: use of 'testing' function from testsuite/testing.sh In-Reply-To: <200805030120.31317.vda.linux@googlemail.com> References: <0805021413310.10843@somehost> <200805022314.40228.vda.linux@googlemail.com> <0805022324170.10843@somehost> <200805030120.31317.vda.linux@googlemail.com> Message-ID: <1209770831.18375.8.camel@homebase.localnet> On Sat, 2008-05-03 at 01:20 +0200, Denys Vlasenko wrote: > "echo FOO | { thing being tested; read foo; }; echo $foo" > > If $foo is not set to FOO, thing ate FOO. Bad thing, bad. This won't work in most POSIX shells. In most shells, every part of a pipeline is invoked in a subshell, which means $foo won't be set. ksh has a special feature where the final command in a pipeline is run in the parent shell; it would work there. But, not in bash/dash/ash/etc. Plus, if the thing DID eat FOO, then the read will never return and your test will hang. From paul at mad-scientist.us Fri May 2 16:29:27 2008 From: paul at mad-scientist.us (Paul Smith) Date: Fri, 02 May 2008 19:29:27 -0400 Subject: use of 'testing' function from testsuite/testing.sh In-Reply-To: <1209770831.18375.8.camel@homebase.localnet> References: <0805021413310.10843@somehost> <200805022314.40228.vda.linux@googlemail.com> <0805022324170.10843@somehost> <200805030120.31317.vda.linux@googlemail.com> <1209770831.18375.8.camel@homebase.localnet> Message-ID: <1209770967.18375.11.camel@homebase.localnet> On Fri, 2008-05-02 at 19:27 -0400, Paul Smith wrote: > Plus, if the thing DID eat FOO, then the read will never return and > your test will hang. Oops, that was stupid. Of course that's not right. The first point stands though. You can rewrite it like this and I think it will work: echo FOO | { some command; read foo; echo $foo; } If that prints FOO you're OK; otherwise "some command" used it up. From paul at mad-scientist.us Fri May 2 16:39:46 2008 From: paul at mad-scientist.us (Paul Smith) Date: Fri, 02 May 2008 19:39:46 -0400 Subject: use of 'testing' function from testsuite/testing.sh In-Reply-To: <1209770967.18375.11.camel@homebase.localnet> References: <0805021413310.10843@somehost> <200805022314.40228.vda.linux@googlemail.com> <0805022324170.10843@somehost> <200805030120.31317.vda.linux@googlemail.com> <1209770831.18375.8.camel@homebase.localnet> <1209770967.18375.11.camel@homebase.localnet> Message-ID: <1209771586.18375.17.camel@homebase.localnet> On Fri, 2008-05-02 at 19:29 -0400, Paul Smith wrote: > echo FOO | { some command; read foo; echo $foo; } > > If that prints FOO you're OK; otherwise "some command" used it up. Sorry for all the mail. The big problem with this is you lose the exit code for "some command". Maybe this instead? echo FOO 2>/dev/null | { some command && read foo; } \ || echo "Failed!" The "read" operation will fail if it can't read anything, which means that if either "some command" OR the read fails, the pipeline will fail. From vda.linux at googlemail.com Fri May 2 23:49:18 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 3 May 2008 08:49:18 +0200 Subject: use of 'testing' function from testsuite/testing.sh In-Reply-To: <1209771586.18375.17.camel@homebase.localnet> References: <0805021413310.10843@somehost> <1209770967.18375.11.camel@homebase.localnet> <1209771586.18375.17.camel@homebase.localnet> Message-ID: <200805030849.18417.vda.linux@googlemail.com> On Saturday 03 May 2008 01:39, Paul Smith wrote: > On Fri, 2008-05-02 at 19:29 -0400, Paul Smith wrote: > > echo FOO | { some command; read foo; echo $foo; } > > > > If that prints FOO you're OK; otherwise "some command" used it up. > > Sorry for all the mail. > > The big problem with this is you lose the exit code for "some command". > Maybe this instead? > > echo FOO 2>/dev/null | { some command && read foo; } \ > || echo "Failed!" Or just echo exit code: bash-3.2# echo FOO | { sleep 1; echo $?; read foo; echo $foo; } 0 FOO bash-3.2# echo FOO | { cat >/dev/null; echo $?; read foo; echo $foo; } 0 bash-3.2# -- vda From martinb at zeelandnet.nl Sat May 3 14:32:35 2008 From: martinb at zeelandnet.nl (Martinb_ARM_NOMMU_KISSDVD) Date: Sat, 3 May 2008 23:32:35 +0200 Subject: tar xzf does not work anymore on my arm system In-Reply-To: <200804251950.51927.vda.linux@googlemail.com> Message-ID: I did telnet to the box on port 2323 (telnet with the old lash shell) I did start strace and paste some console message when i did start the 2e telnet (on port 23 with latest hush) (its possible/likely my strace is buggy) /paste console /hdd # strace -f -o strace.log -p 68 Process 68 attached - interrupt to quit PANIC: setbpt for syscall 190 on 68??? Process 79 attached Process 68 detached Process 79 detached /end paste console i did paste the strace.log (its small) /hdd # cat strace.log 68 select(10, [4 5 6 7 8 9], NULL, NULL, NULL) = 1 (in [7]) 68 accept(7, 0, NULL) = 3 68 rt_sigprocmask(SIG_BLOCK, [HUP ALRM CHLD], [], 8) = 0 68 vfork() = 79 68 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 68 close(3) = 0 68 select(10, [4 5 6 7 8 9], NULL, NULL, NULL) = ? ERESTARTNOHAND (To be restarted) 68 --- SIGCHLD (Child exited) @ 0 (0) --- 68 wait4(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 0], WNOHANG, NULL) = 79 68 wait4(-1, 0x1573c58, WNOHANG, NULL) = 0 68 sigreturn() = ? (mask now []) 68 select(10, [4 5 6 7 8 9], NULL, NULL, NULL If i just attach to the inetd and exit (without a sleep and ) i get /hdd # cat strace3.log 68 select(10, [4 5 6 7 8 9], NULL, NULL, NULL) = 1 (in [7]) 68 accept(7, 0, NULL) = 3 68 rt_sigprocmask(SIG_BLOCK, [HUP ALRM CHLD], [], 8) = 0 68 vfork() = 87 68 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 68 close(3) = 0 68 select(10, [4 5 6 7 8 9], NULL, NULL, NULL My config is attached > -----Oorspronkelijk bericht----- > Van: Denys Vlasenko [mailto:vda.linux at googlemail.com] > Verzonden: vrijdag 25 april 2008 19:51 > Aan: Martinb_ARM_NOMMU_KISSDVD > CC: busybox at busybox.net > Onderwerp: Re: tar xzf does not work anymore on my arm system > > > On Wednesday 23 April 2008 23:22, Martinb_ARM_NOMMU_KISSDVD wrote: > > sorry, here some more info how to reproduce > > > > I have a nommu arm system > > I do use inetd and I did switch from lash to hush > > > > services look like this > > > > telnet 23/tcp # telnet > > telnet2 2323/tcp # test telnet > > > > inetd.conf looks like this: > > > > http stream tcp nowait root /hdd/stage2/bin/httpd httpd -h > > /hdd/stage2/htmlroot > > ftp stream tcp nowait root /bin/ftpd ftpd -b -H -w > > kml stream tcp nowait root /hdd/stage2/bin/httpd httpd -h > > /hdd/stage2/htmlroot > > telnet stream tcp nowait root /sbin/telnetd telnetd -l /bin/hush > > httpfsck stream tcp nowait root /systempart/httpd httpd -h > /systempart > > telnet2 stream tcp nowait root /sbin/telnetd telnetd -l > /hdd/test/lash > > > > the lash is a old version > > hush is the latest version > > > > if I connect to the 2e telnet (on port 2323) I get a telnetprompt > > if I execute a command (like ls) and while its running press > > telnet still runs > > > > if I connect to the first telnet (on port 23) i also get a telnetprompt > > if I execute a command (like ls) and while its running press > > telnet just exit and if I connect again I don?t see any old > running process > > > > so I do telnet to 2323 > > type "ls" > > press and I just exit the command and go back to > (telnet)prompt > > > > if i telnet to 23 > > type "ls" > > press telnet just ends > > > > I set up a similar environment and it doesn't fail for me as you describe. > Perhaps the difference is in our .config files. Please send me yours. > > Also, it will be interesting to see the result of > > strace -f -o strace.log -p > > Start inetd first, then strace, then telnet into the box, run "sleep 10" > and Ctrl-C it - telnetd will die as you describe (correct behavior > is "only sleep dies, telnetd does not"). Then stop (Ctrl-C) strace > and post the resulting strace.log > -- > vda -------------- next part -------------- A non-text attachment was scrubbed... Name: .config.bz2 Type: application/octet-stream Size: 4318 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080503/51bba9df/attachment.obj From cristian.ionescu-idbohrn at axis.com Sun May 4 02:18:40 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 4 May 2008 11:18:40 +0200 (CEST) Subject: [patch] testsuite/cpio.tests: removes the SKIP line Message-ID: <0805041113230.10843@somehost> Not needed as next is exit. Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: cpio.tests.patch Type: text/x-diff Size: 502 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080504/a88185ff/attachment.patch From cristian.ionescu-idbohrn at axis.com Sun May 4 02:28:52 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 4 May 2008 11:28:52 +0200 (CEST) Subject: [patch] zip tests Message-ID: <0805041122380.10843@somehost> Moves common parts of the tests to compressfuncts.sh (new). Adds a new test: zcat.tests. Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: ziptests.patch Type: text/x-diff Size: 4235 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080504/c8fb0578/attachment.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: compressfuncs.sh Type: application/x-sh Size: 995 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080504/c8fb0578/attachment.sh -------------- next part -------------- #!/bin/sh -e app=zcat bb_app="busybox $app" ext=gz wdir=testdir . compressfuncs.sh rm -rf $wdir mkdir -p $wdir ( cd $wdir || { echo "cannot cd $wdir!"; exit 1; } expected="HELLO\nok\n" prep check "$app: dont delete src" "$bb_app t2.gz; test -f t2.gz && echo ok" ) rm -rf $wdir From vapier at gentoo.org Sun May 4 04:22:20 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 4 May 2008 07:22:20 -0400 Subject: Best use of mdev? In-Reply-To: <20080502072844.GB14696@mx.loc> References: <481A651D.20097.4311B0F@mikes.kuentos.guam.net> <20080502072844.GB14696@mx.loc> Message-ID: <200805040722.21562.vapier@gentoo.org> On Friday 02 May 2008, Bernhard Fischer wrote: > On Fri, May 02, 2008 at 12:49:33AM +1000, Michael D. Setzer II wrote: > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > >I was just contacted by a user that has 11 partitions on a large hard > > disk. My g4l project currently has the nods setup as being precreated in > > the /dev directory. It had massive number of these for both the hd and sd > > going all the way to sdp but only to the 9th option. I was manually able > > to create a script to create the additional nods, but then started > > looking at options to have it automaticly create the proper nods. I have > > found the mdev, and seem to have figured some of it out, but think there > > might be some additional things to make it work better. > > > >I booted from the g4l cd, and did the following manually. > > > >created the /etc/mdev.conf with these two lines. > > > >hd[a-z][0-9]* 0:3 660 > >sd[a-z][0-9]* 0:3 660 > > > >Run the commands to create the /dev > > > >mkdir /sys > >mount -t sysfs sysfs /sys > >mdev -s > > > >Below is the original contents of the /dev directory minus all the hd and > > sd files. Not sure which all of these can also be created with the > > mdev.conf file and which have to be manually created. Also, some of the > > directories were for raid systems that users had. Would the mdev create > > these? > >Unfortunately, I don't have all the hardware to test. > > I usually only have /dev/null and /dev/console and create all the rest > via mdev. /dev/console is required to be on the root device before userspace is even executed. after that, if you code things safely, you literally need no other nodes (mdev will create console and null for you). however, people often create /dev/null ahead of time so they can redirect into it with impudence. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080504/a526b530/attachment-0001.pgp From vapier at gentoo.org Sun May 4 04:27:24 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 4 May 2008 07:27:24 -0400 Subject: [patch] testsuite/cpio.tests: removes the SKIP line In-Reply-To: <0805041113230.10843@somehost> References: <0805041113230.10843@somehost> Message-ID: <200805040727.25030.vapier@gentoo.org> On Sunday 04 May 2008, Cristian Ionescu-Idbohrn wrote: > -#!/bin/sh > +#!/bin/sh -e better to add 'set -e' at the top i think ... otherwise this gets ignored if people do `/bin/sh cpio.tests`. may seem odd, but consider the common scenario of test Makefiles executing $(CONFIG_SHELL) on things instead of assuming files are +x. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080504/8a842408/attachment.pgp From cristian.ionescu-idbohrn at axis.com Sun May 4 05:23:55 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 4 May 2008 14:23:55 +0200 (CEST) Subject: [patch] shell/ash.c: mimics dash WRT 'set [+|-]o' Message-ID: <0805041330110.10843@somehost> It also replicates reality in some error messages, like: # ./busybox ash -c 'set -q' ash: set: line 1: illegal option -q # ./busybox ash -c 'set +q' ash: set: line 1: illegal option +q Currently shows always '-q' regardless. Current behaviour (same output for -o as for +o): # ./busybox ash -c "set -o" Current option settings errexit off noglob off ignoreeof off interactive off monitor off noexec off stdin off xtrace off verbose off noclobber off allexport off notify off nounset off vi off # ./busybox ash -c "set +o" Current option settings errexit off noglob off ignoreeof off interactive off monitor off noexec off stdin off xtrace off verbose off noclobber off allexport off notify off nounset off vi off The attached patch makes ash produce this: # ./busybox ash -c 'set -fmb;set -o' errexit off noglob on ignoreeof off interactive off monitor on noexec off stdin off xtrace off verbose off noclobber off allexport off notify on nounset off vi off # ./busybox ash -c 'set -fmb;set +o' set +o errexit set -o noglob set +o ignoreeof set +o interactive set -o monitor set +o noexec set +o stdin set +o xtrace set +o verbose set +o noclobber set +o allexport set -o notify set +o nounset set +o vi similar to both dash and bash. Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: ash.c.+o.5.patch Type: text/x-diff Size: 1430 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080504/8183bd84/attachment.patch From bluecolour.sz at gmail.com Sun May 4 19:49:32 2008 From: bluecolour.sz at gmail.com (cheesiong) Date: Mon, 5 May 2008 10:49:32 +0800 Subject: busybox httpd cgi cgi-bin Message-ID: <8ab1d9170805041949o29e08910n7c36a4b165f43aef@mail.gmail.com> hi busybox friends, i am trying to have a feel on how cgi is woking on busybox. but i still have problem while after i have several try, would anyone please teach me or give me a pointer so to make it running? thank you. i have busybox compiled on i686 system running fedora 8 in vmware on winxp. i put busybox source in /home/keo/busybox and compile statically with only httpd. ( i tried a defconfig, but i hope a simplest compile will isolate problem). then i mkdir www for webroot and cgi-bin within www. then i launch with ./busybox httpd -h www -c $PWD/www/httpd.conf i copy 2 files from internet. www/form-post.html and cgi-bin/test-post but when i submit in the form-post.html which pass to test-post i get 404 Not Found The requested URL was not found regards,-keo ----------------------------------- CGI Test

Text field

Radio button

1

2

3

Some text

 

 

 

-------------------------------------- #!/bin/sh echo "Content-type: text/html" echo "" echo "Sample CGI Output" echo "" echo "
"
echo "Environment variables"
echo ""
env
echo ""
echo "========================================================="
echo ""
echo "Form variables :"
echo ""
read QUERY_STRING
eval $(echo "$QUERY_STRING"|awk -F'&' '{for(i=1;i<=NF;i++){print $i}}')
tmp=`httpd -d $Text_Field`
echo "Text_Field=$tmp"
tmp=`httpd -d $Radio_Button`
echo "Radio_Button=$tmp"
tmp=`httpd -d $Text_Area`
echo "Text_Area=$tmp"
echo "
" echo "" [root at fedora8 busybox]# pwd /home/keo/busybox [root at fedora8 busybox]# file busybox busybox: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, stripped [root at fedora8 busybox]# ./busybox BusyBox v1.10.1 (2008-05-05 10:35:41 HKT) multi-call binary Copyright (C) 1998-2007 Erik Andersen, Rob Landley, Denys Vlasenko and others. Licensed under GPLv2. See source distribution for full notice. Usage: busybox [function] [arguments]... 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! Currently defined functions: httpd -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080505/322723c9/attachment.htm From cristian.ionescu-idbohrn at axis.com Mon May 5 00:41:16 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Mon, 5 May 2008 09:41:16 +0200 (CEST) Subject: [patch] testsuite/cpio.tests: removes the SKIP line In-Reply-To: <200805040727.25030.vapier@gentoo.org> References: <0805041113230.10843@somehost> <200805040727.25030.vapier@gentoo.org> Message-ID: <0805050940380.25506@somehost> On Sun, 4 May 2008, Mike Frysinger wrote: > On Sunday 04 May 2008, Cristian Ionescu-Idbohrn wrote: > > -#!/bin/sh > > +#!/bin/sh -e > > better to add 'set -e' at the top i think ... otherwise this gets ignored if > people do `/bin/sh cpio.tests`. may seem odd, but consider the common > scenario of test Makefiles executing $(CONFIG_SHELL) on things instead of > assuming files are +x. Good idea. Cheers, -- Cristian From ladi1 at rocketmail.com Mon May 5 01:21:02 2008 From: ladi1 at rocketmail.com (L a d i) Date: Mon, 5 May 2008 01:21:02 -0700 (PDT) Subject: SUDO package Message-ID: <501824.80336.qm@web50304.mail.re2.yahoo.com> Greeting everyone, First of all i'm pretty new to busybox so please forgive my ignorance. I would like to have the "sudo" included in the busybox. I did some search and found out that there is this patch at http://bugs.busybox.net/view.php?id=511. However i'm not sure how to include it to the busybox. I'll really appreciate any help. Thanks in advance Ladio ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080505/ff2d5b35/attachment.htm From WHarms at bfs.de Mon May 5 03:06:35 2008 From: WHarms at bfs.de (walter harms) Date: Mon, 05 May 2008 12:06:35 +0200 Subject: SUDO package In-Reply-To: <501824.80336.qm@web50304.mail.re2.yahoo.com> References: <501824.80336.qm@web50304.mail.re2.yahoo.com> Message-ID: <481EDC2B.3040807@bfs.de> so far i know there is such thing like sudo, since you only have one binary. you can emulate sudo by finetuning via busybox.conf. re, wh L a d i wrote: > Greeting everyone, > > First of all i'm pretty new to busybox so please forgive my ignorance. I would like to have the "sudo" included in the busybox. I did some search and found out that there is this patch at http://bugs.busybox.net/view.php?id=511. However i'm not sure how to include it to the busybox. > I'll really appreciate any help. > > Thanks in advance > Ladio > > > From cristian.ionescu-idbohrn at axis.com Mon May 5 07:32:41 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Mon, 5 May 2008 16:32:41 +0200 (CEST) Subject: [patch] miscutils/last.c: old sin :) Message-ID: <0805051631310.7149@somehost> Index: miscutils/last.c =================================================================== --- miscutils/last.c (revision 21370) +++ miscutils/last.c (working copy) @@ -49,7 +49,7 @@ ut.ut_type = SHUTDOWN_TIME; else if (strncmp(ut.ut_user, "reboot", 6) == 0) ut.ut_type = BOOT_TIME; - else if (strncmp(ut.ut_user, "runlevel", 7) == 0) + else if (strncmp(ut.ut_user, "runlevel", 8) == 0) ut.ut_type = RUN_LVL; } else { if (ut.ut_name[0] == '\0' || strcmp(ut.ut_name, "LOGIN") == 0) { Cheers, -- Cristian From rep.dot.nop at gmail.com Mon May 5 07:45:40 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Mon, 5 May 2008 16:45:40 +0200 Subject: [patch] miscutils/last.c: old sin :) In-Reply-To: <0805051631310.7149@somehost> References: <0805051631310.7149@somehost> Message-ID: <20080505144540.GA2776@mx.loc> Applied as 21932. Thanks! From ladi1 at rocketmail.com Mon May 5 22:48:46 2008 From: ladi1 at rocketmail.com (L a d i) Date: Mon, 5 May 2008 22:48:46 -0700 (PDT) Subject: SUDO package Message-ID: <407114.9613.qm@web50307.mail.re2.yahoo.com> Thanks a bunch Walter, Somehow the sudo doesn't show when you list all the commands in the busybox package (like su for example). That is why i had the feeling it is not there. I'm going to play around with the busybox.conf and see if i can manage to get it running. Thanks a lot, Ladio ----- Original Message ---- From: walter harms To: L a d i Cc: busybox at busybox.net Sent: Monday, May 5, 2008 6:06:35 PM Subject: Re: SUDO package so far i know there is such thing like sudo, since you only have one binary. you can emulate sudo by finetuning via busybox.conf. re, wh L a d i wrote: > Greeting everyone, > > First of all i'm pretty new to busybox so please forgive my ignorance. I would like to have the "sudo" included in the busybox. I did some search and found out that there is this patch at http://bugs.busybox.net/view.php?id=511. However i'm not sure how to include it to the busybox. > I'll really appreciate any help. > > Thanks in advance > Ladio > > > ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080505/4a5dcd1c/attachment.htm From jacob_tiju at yahoo.com Mon May 5 23:32:29 2008 From: jacob_tiju at yahoo.com (Tiju Jacob) Date: Tue, 6 May 2008 12:02:29 +0530 (IST) Subject: Unable to login to the shell Message-ID: <118887.26612.qm@web94109.mail.in2.yahoo.com> Hi all, I am using buildroot for an arm board. The issue I am facing is that I am not able to get the shell prompt. It keeps on respawning the getty when I try to login. I dont have bash in my build. Any other issue leading to this? What is the name of your serial? Mine is ttySAC0. Could this cause an issue anywhere on busybox? I have modified the inittab with ttySAC0::respawn:/sbin/getty -L ttySAC0 115200 vt100 Should I make changes anywhere else? Thanks in advance. Tiju From Chandigarh to Chennai - find friends all over India. Go to http://in.promos.yahoo.com/groups/citygroups/ From jacob_tiju at yahoo.com Mon May 5 23:34:56 2008 From: jacob_tiju at yahoo.com (Tiju Jacob) Date: Tue, 6 May 2008 12:04:56 +0530 (IST) Subject: Unable to login to the shell Message-ID: <696386.57073.qm@web94101.mail.in2.yahoo.com> Hi all, I am using buildroot for an arm board. The issue I am facing is that I am not able to get the shell prompt. It keeps on respawning the getty when I try to login. I dont have bash in my build. Any other issue leading to this? The name of my serial is ttySAC0. Could this cause an issue anywhere on busybox? I have modified the inittab with ttySAC0::respawn:/sbin/getty -L ttySAC0 115200 vt100 Should I make changes anywhere else? Thanks in advance. Tiju From Chandigarh to Chennai - find friends all over India. Go to http://in.promos.yahoo.com/groups/citygroups/ From vda.linux at googlemail.com Tue May 6 05:07:22 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 6 May 2008 14:07:22 +0200 Subject: [patch] testsuite/cpio.tests: removes the SKIP line In-Reply-To: <0805041113230.10843@somehost> References: <0805041113230.10843@somehost> Message-ID: <200805061407.22829.vda.linux@googlemail.com> On Sunday 04 May 2008 11:18, Cristian Ionescu-Idbohrn wrote: > Not needed as next is exit. -#!/bin/sh +#!/bin/sh -e Why? - SKIP=1 exit 1 } Applied, thanks. -- vda From vda.linux at googlemail.com Tue May 6 05:21:24 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 6 May 2008 14:21:24 +0200 Subject: [patch] zip tests In-Reply-To: <0805041122380.10843@somehost> References: <0805041122380.10843@somehost> Message-ID: <200805061421.24610.vda.linux@googlemail.com> On Sunday 04 May 2008 11:28, Cristian Ionescu-Idbohrn wrote: > Moves common parts of the tests to compressfuncts.sh (new). Cannot take it as a whole: [ "$ECHO" ] || . testing.sh I was told that nothing says that . operator shall search current directory first. If you mean it, use ". ./file" explicitly. local xtrace xtrace=$(set -o | sed -rne 's/xtrace[[:space:]]+([^[:space:]]+)/\1/p') [ "$xtrace" = off ] || set +x eval "$2" >t_actual 2>&1 || { echo "$1: FAIL (eval)" } [ "$xtrace" = off ] || set -x if $ECHO -ne "$expected" | cmp - t_actual; then echo "$1: PASS" else echo "$1: FAIL" fi I have no idea what this xtrace thing can be. Why is it needed? Can you explain it in the comment? +wdir=testdir -cd testdir || { echo "cannot cd testdir!"; exit 1; } +cd $wdir || { echo "cannot cd $wdir!"; exit 1; } Why is this useful? -prep; check "$unpack: doesnt exist" "${bb}$unpack z t1.$ext; echo \$?; cat t1" +prep +check "$unpack: doesnt exist" "set +e;$bb_app z t1.$ext; echo \$?; cat t1" The part which splits "command; command" into several lines is ok. Do you want to resend it as separate patch? (If these changes were sent as a few patches instead of all-in-one, I would already applied that one) > Adds a new test: zcat.tests. Depends on compressfuncts.sh. Let's deal with that one first. -- vda From vda.linux at googlemail.com Tue May 6 05:42:58 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 6 May 2008 14:42:58 +0200 Subject: busybox httpd cgi cgi-bin In-Reply-To: <8ab1d9170805041949o29e08910n7c36a4b165f43aef@mail.gmail.com> References: <8ab1d9170805041949o29e08910n7c36a4b165f43aef@mail.gmail.com> Message-ID: <200805061442.58369.vda.linux@googlemail.com> On Monday 05 May 2008 04:49, cheesiong wrote: > i copy 2 files from internet. www/form-post.html and cgi-bin/test-post > but when i submit in the form-post.html which pass to test-post i get > > 404 Not Found > > The requested URL was not found run it under strace: strace -f -o httpd.log ./busybox httpd -vvv -h www -c $PWD/www/httpd.conf and see what file it is trying to open. Also try the example from http://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/networking/httpd_post_upload.txt (click "view" link on that page) -- vda From cristian.ionescu-idbohrn at axis.com Tue May 6 06:45:23 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Tue, 6 May 2008 15:45:23 +0200 (CEST) Subject: [patch] testsuite/cpio.tests: removes the SKIP line In-Reply-To: <200805061407.22829.vda.linux@googlemail.com> References: <0805041113230.10843@somehost> <200805061407.22829.vda.linux@googlemail.com> Message-ID: <0805061538500.10380@somehost> On Tue, 6 May 2008, Denys Vlasenko wrote: > On Sunday 04 May 2008 11:18, Cristian Ionescu-Idbohrn wrote: > > Not needed as next is exit. > > -#!/bin/sh > +#!/bin/sh -e Or, better (as Mike Frysinger suggested) #!/bin/sh + +set -e > Why? Why not? Unhandled errors will abort the rest of the script: -e errexit If not interactive, exit immediately if any untested command fails. The exit status of a com- mand is considered to be explicitly tested if the command is used to control an if, elif, while, or until; or if the command is the left hand operand of an ``&&'' or ``||'' operator. but I believe you already know that. Scripts, and especially test scripts, should handle all possible errors. Cheers, -- Cristian From tsong at fiberhome.com.cn Tue May 6 08:19:33 2008 From: tsong at fiberhome.com.cn (=?GB2312?B?y87Mzg==?=) Date: Tue, 6 May 2008 23:19:33 +0800 Subject: how to use telnetd of busybox Message-ID: i use busybox-1.3.2 for my board and i want to run telnetd in buysbox on the target(192.168.81.100), in start with command:$telnetd -d telnet Trying 192.168.81.100... Connected to 192.168.81.100 (192.168.81.100). Escape character is '^]'. Connection closed by foreign host. -- ----------------------------------------------------- fiberhome,wuhan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080506/e47d1cd7/attachment.htm From vda.linux at googlemail.com Tue May 6 08:29:58 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 6 May 2008 17:29:58 +0200 Subject: [patch] shell/ash.c: mimics dash WRT 'set [+|-]o' In-Reply-To: <0805041330110.10843@somehost> References: <0805041330110.10843@somehost> Message-ID: <200805061729.58220.vda.linux@googlemail.com> On Sunday 04 May 2008 14:23, Cristian Ionescu-Idbohrn wrote: > It also replicates reality in some error messages, like: > Applied, thanks -- vda From vda.linux at googlemail.com Tue May 6 08:35:10 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 6 May 2008 17:35:10 +0200 Subject: how to use telnetd of busybox In-Reply-To: References: Message-ID: <200805061735.10766.vda.linux@googlemail.com> On Tuesday 06 May 2008 17:19, ?? wrote: > i use busybox-1.3.2 for my board > and i want to run telnetd in buysbox > on the target(192.168.81.100), in start with command:$telnetd -d What? I barely understand your bug decription. > telnet > Trying 192.168.81.100... > Connected to 192.168.81.100 (192.168.81.100). > Escape character is '^]'. > Connection closed by foreign host. "telnetd -d" is not a valid command: