Summary 0000242: ash: read -t broken
this also implements -n and -s options to read. (they're configured
together because most of their code is in common, and separating them
seemed silly.
If we exec /proc/self/exe and only fall back to /bin/busybox if /proc isn't
there, then we have a reasonable chance of having the standalone shell work
even if busybox isn't installed in /bin on the system in question.
Still won't work in a chroot environment, but it's an improvement.
CONFIG_FEATURE_COMMAND_EDITING was defined *and*
CONFIG_FEATURE_COMMAND_TAB_COMPLETION was undefined.
Vladimir N. Oleynik writes:
Its declare always, also if CONFIG_FEATURE_COMMAND_TAB_COMPLETION
undefined.
Patch to CVS version attached.
--w
vodz
On Wed Aug 18, 2004 at 06:52:57PM +0800, Matt Johnston wrote:
> I've come across some strange-seeming behaviour when running programs
> under Busybox (1.0.0-rc3) ash. If the child process sets stdin to be
> non-blocking and then exits, the parent ash will also exit. A quick strace
> shows that a subsequent read() from stdin returns EAGAIN (as would be
> expected):
Thanks!
Patch attached.
--w
vodz
With job control enabled, ash fails to tcsetpgrp back to initialpgrp
upon exit. exitshell() should call setjobctl(0) to do this.
Context: I am using a lightweight menu system (replimenu[.sf.net]) on my
console, which invokes "/bin/sh -i -c /bin/login", where /bin/sh and
/bin/login are busybox applets. /bin/sh is ash, with
CONFIG_ASH_JOB_CONTROL=y as the sole suboption. The shell of the user
concerned (nobody) is also /bin/sh (ash). When the user /bin/sh exits
(and thereby login and its parent sh), replimenu receives EIO when it
tries to read from the terminal.
The updated patch adds a config option to explicitely enable 64 bit
arithmetic.
Also it removes the arith prototype from libbb.h as it is not used
outside of ash.
Bastian
this patch has been slightly modified by Erik for cleanliness.
This is a bulk spelling fix patch against busybox-1.00-pre10.
If anyone gets a corrupted copy (and cares), let me know and
I will make alternate arrangements.
Erik - please apply.
Authors - please check that I didn't corrupt any meaning.
Package importers - see if any of these changes should be
passed to the upstream authors.
I glossed over lots of sloppy capitalizations, missing apostrophes,
mixed American/British spellings, and German-style compound words.
What is "pretect redefined for test" in cmdedit.c?
Good luck on the 1.00 release!
- Larry
Just upgraded from 0.6 to 1.00-pre8
Dot command handling handled args correctly (same as bash) in 0.60,
but failed in 1.00:
I fixed this by reverting the dotcmd function back to previous 0.60
instantiation,
please consider using the older version.
Thanks
Peter
have checked in. Vladimir writes:
Your patch have many problem.
1. You always added + time(). This cannot reset RANDOM=value for debuging
with
replay sequential.
2. Hmm. I examine bash 2.04 source. This pseudorandom generator use low bits
of
counter value. You use high bits. This make bad pseudorandom values after
have
0-value. For example, if + time() do remove, your generator always return 0
after
first generate 0.
3. Memory leak per call. Use ash-unlike unecessary bb_strdup function.
4. Unsupport show last $RANDOM value for "set" and "export" command.
5. Bloat code. Busybox-unlike patch - added unstandart feature as default
hardcode.
Last patch attached.
Erik, why you apply Paul patch with have 5-th point problem? :(
Last patch have ash change xwrite() to fresh libbb/bb_full_write interfase
(haved loop after EINTR).
--w
vodz
Here's a follow-up replacement to the patch I sent earlier, this adjusts some
of the semantics of the dynamic variable setting. Namely, dynamic vars can hook
a set handler (which RANDOM uses to adjust the seed). They'll only lose their
dynamic status if they're unset.
I've used the same approach that bash does to come up with the random number,
mostly just for consistency.
For example:
$ echo $RANDOM
13759
$ echo $RANDOM
20057
$ echo $RANDOM
1502
$ export RANDOM=42
$ echo $RANDOM
24179
$ echo $RANDOM
2046
$ unset RANDOM
$ echo $RANDOM
$ export RANDOM=42
$ echo $RANDOM
42
$
Richard,
>I have a problem, which I can reproduce now. I am using pre7 version of
>busybox, and the tab completion works fine. I mean, with an empty command
>line I press the TAB twice, and ash shows me the available commands. But
>when i process the profile file below, as
> $ . /etc/profile
>then it stops working, and the double-tab lists the directories available
>from the cwd, and not the commands. Has someone else meet this problem
>before, or am i doing something wrong?
>
>This is my '/etc/profile':
>- ---
># System profile
>
>PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
>export PATH
>trap ":" INT QUIT TERM
>
>export PS1="\h \w # "
Thanks. Patch attached.
--w
vodz
- synced with dash 0.4.21
- better handle trap "cmds..." SIGINT (strange, i make bad hack for ash
and cmdedit, but this work only with this...)
- may be haven`t problem with Ctrl-D
The construct certain vintages of GCC (the one I have trouble
with is 3.2.3) have trouble with looks like the following:
static struct st a;
static struct st *p = &a;
struct st { int foo; };
static void init(void) { a.foo = 0; }
The problem disappears if we move the struct declaration up to
let the compiler know the shape of the struct before the first
definition uses it, like this:
struct st { int foo; }; /* this has been moved up */
static struct st a;
static struct st *p = &a;
static void init(void) { a.foo = 0; }
"If the shell is compiled with -DJOBS, this is all fine -- find wasn't
stopped (it was killed), so it correctly uses WTERMSIG instead of WSTOPSIG.
However, if the shell _isn't_ compiled with -DJOBS (which it isn't in d-i),
only WSTOPSIG is used, which extracts the high byte instead of the low
byte from the status code. Since the status code is 13 (SIGPIPE), "st"
suddenly gets the value 0, which is equivalent to SIGEXIT. Thus, ash prints
out "EXIT" on find's exit."
unless it had #!/bin/sh in the first line
"It correctly locates the script, tries to execute it via execve which
fails. After that it tries to hand it over to /bin/sh which fails too,
since ash
- neither provides the absolute pathname to /bin/sh
- nor tries to lookup the script via PATH if called as "sh script"
"
