BusyBox Bug and Patch Tracking
BusyBox
Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ View Advanced ] [ Issue History ] [ Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0001302 [BusyBox] Other minor always 04-05-07 00:55 06-16-07 16:24
Reporter Michael Tokarev View Status public  
Assigned To BusyBox
Priority normal Resolution fixed  
Status closed   Product Version 1.4.x
Summary 0001302: 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.
Additional Information
Attached Files

- Relationships

- Notes
(0002298)
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.
 
(0002300)
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.
 
(0002301)
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...
 
(0002302)
vda
04-06-07 18:18
edited on: 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
 
(0002303)
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.
 
(0002304)
vda
04-07-07 02:19

 > In second your note, you just didn't read what I wrote.

Yes, my bad. I apologize.
 

- Issue History
Date Modified Username Field Change
04-05-07 00:55 Michael Tokarev New Issue
04-05-07 00:55 Michael Tokarev Status new => assigned
04-05-07 00:55 Michael Tokarev Assigned 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 Tokarev Status closed => feedback
04-05-07 23:07 Michael Tokarev Resolution fixed => reopened
04-05-07 23:07 Michael Tokarev Note Added: 0002300
04-05-07 23:10 Michael Tokarev Note 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 Tokarev Note Added: 0002303
04-07-07 02:19 vda Note Added: 0002304
06-16-07 16:24 vda Status feedback => closed
06-16-07 16:24 vda Resolution reopened => fixed

Copyright © 2000 - 2006 Mantis Group
Powered by Mantis Bugtracker