[BusyBox 0001302]: busybox prefers internal applets even if !STANDALONE_SHELL

bugs at busybox.net bugs at busybox.net
Sat Apr 7 07:47:37 UTC 2007


A NOTE has been added to this issue. 
====================================================================== 
http://busybox.net/bugs/view.php?id=1302 
====================================================================== 
Reported By:                Michael Tokarev
Assigned To:                BusyBox
====================================================================== 
Project:                    BusyBox
Issue ID:                   1302
Category:                   Other
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
====================================================================== 
Date Submitted:             04-05-2007 00:55 PDT
Last Modified:              04-07-2007 00:47 PDT
====================================================================== 
Summary:                    busybox prefers internal applets even if
!STANDALONE_SHELL
Description: 
Since about 1.4.0, busybox prefers internal applets even if not configured
to do so.  This results in not-so-fun stuff like:

$ busybox ash
$ chmod --reference=x y
chmod: unrecognized option `--reference=x'
BusyBox v1.4.1 (2007-02-14 14:22:15 MSK) multi-call binary

No help available.

$ /bin/chmod --reference=x y
$ (this one works)

I looked into sources, and see that usage of tryexec() in shell/ash.c is
quite messed up (up to 1.4.2) - it has been partially
rewritten/reorganized.  And I don't quite understand what it supposed to
work like in the first place.

Speaking of this 'prefer internal applets' thing, I wonder if we can do
two things.

First, how about searching the executable normally, and stat()'ing the
found file to see if it's our executable - if yes, we can safely fork()
our own process, and not execute anything.  And IF not found in $PATH, try
to search our applet list.  I.e., something in the middle of
STANDALONE_SHELL and !STANDALONE_SHELL.

And second, how about marking whenever a given applet is "safe" in the
applet list, and not in ash?  So that other shells (by the way, why there
are so many of them??) will benefit.  Note that the list in ash.c is far
from complete - there are many more "safe" applets than that.
====================================================================== 

---------------------------------------------------------------------- 
 vda - 04-05-07 14:10  
---------------------------------------------------------------------- 
So it fixed in 1.4.2, yet you still created bug record in the database.
Why? The purpose of the database is to track UNFIXED problems.

Discussions are best directed to mailing list, not bugzilla. Please
continue there. 

---------------------------------------------------------------------- 
 Michael Tokarev - 04-05-07 23:07  
---------------------------------------------------------------------- 
It's far from fixed, at least as I see here.

$ ./busybox sh
$ chmod
BusyBox v1.4.2 (2007-04-04 23:23:24 MSD) multi-call binary

No help available.

$ fgrep STANDALONE_SHELL .config
# CONFIG_FEATURE_SH_STANDALONE_SHELL is not set
$ /bin/chmod 
/bin/chmod: missing operand
Try `/bin/chmod --help' for more information.
$ _

All the notes in original bugreport applies to 1.4.* up to and including
1.4.2. 

---------------------------------------------------------------------- 
 Michael Tokarev - 04-05-07 23:10  
---------------------------------------------------------------------- 
Ok, I stand corrected.  In 1.5.0, the code in question has been rewritten,
and it now looks more sanely, and the logic seems correct.  Building 1.5.0
right now... 

---------------------------------------------------------------------- 
 vda - 04-06-07 18:19  
---------------------------------------------------------------------- 
"chmod: missing operand" output is from COREUTILS CHMOD! You do get
external chmod executed! busyboxed one looks different:

bash-3.2# ./busybox chmod
BusyBox v1.5.0.svn (2007-03-18 15:44:41 CET) multi-call binary

Usage: chmod [-Rcvf] MODE[,MODE]... FILE...

Each MODE is one or more of the letters ugoa, one of the
symbols +-= and one or more of the letters rwxst

Options:
        -R      Changes files and directories recursively
        -c      List changed files
        -v      List all files
        -f      Hide errors

bash-3.2# /bin/chmod
/bin/chmod: missing operand
Try `/usr/bin/chmod --help' for more information.

bash-3.2# /bin/chmod --version
chmod (GNU coreutils) 6.8

 

---------------------------------------------------------------------- 
 Michael Tokarev - 04-07-07 00:47  
---------------------------------------------------------------------- 
Now I wonder.  If it's worth the effort to submit or discuss busybox bugs
in the first place.  Denis, please...  You either actually read the bugs,
or just ignore them (and better tell others your position).  In the latter
case it will be much more easily to fix bugs locally and be done with them,
without wasting your and my time.

This bugreport shows two your notes, and both - I assume - due to you not
reading what has been written.

In first note, you claim the bug has been fixed - it indeed is, but not in
version against which I filed the bugreport (1.4).  Yes, it was my fault
that I didn't look at 1.5 in the first place (now I did, and it seems to
be working; but my original questions/suggestions (you mentioned it's
better to discuss such things on the mailinglist) are "orphaned").  I
didn't say it's fixed, I demonstrated a newly discovered bug, and nowhere
I said it's fixed, yet you closed the bug because "I said it's fixed".

In second your note, you just didn't read what I wrote.  That "missing
operand" is indeed from coreutils - when I explicitly call it with a full
pathname (/bin/chmod), to show how DIFFERENT its behaviour is from
built-in chmod, which prints "busybox v1.4.2 etc" (and don't have help
text).

Wrt this very bugreport - i think it's ok to close it finally, because 1.5
works as intended (again: original bugreport was against 1.4, and it is
still present in 1.4.2).

But speaking of usefulness of submitting bugs in the first place - now I
have quite some doubts about this.  And this fact bothers me somewhat.

Thanks. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
04-05-07 00:55  Michael TokarevNew Issue                                    
04-05-07 00:55  Michael TokarevStatus                   new => assigned     
04-05-07 00:55  Michael TokarevAssigned To               => BusyBox         
04-05-07 14:10  vda            Note Added: 0002298                          
04-05-07 14:10  vda            Status                   assigned => closed  
04-05-07 14:10  vda            Resolution               open => fixed       
04-05-07 23:07  Michael TokarevStatus                   closed => feedback  
04-05-07 23:07  Michael TokarevResolution               fixed => reopened   
04-05-07 23:07  Michael TokarevNote Added: 0002300                          
04-05-07 23:10  Michael TokarevNote Added: 0002301                          
04-06-07 18:18  vda            Note Added: 0002302                          
04-06-07 18:19  vda            Note Edited: 0002302                         
04-06-07 18:19  vda            Note Edited: 0002302                         
04-07-07 00:47  Michael TokarevNote Added: 0002303                          
======================================================================




More information about the busybox-cvs mailing list