On Wed, Nov 11, 2009 at 4:09 PM, Johns Daniel <[email protected]> wrote:
>> this wording applies only to the initial start up of a shell, not to the
>> continued execution of other commands.
>>
>> i.e. when you run `sh`, that shell will check stdin and reset to blocking
>> reads if need be. it does not apply to a shell that runs `foo` and thus has
>> the non blocking bit changed in mid execution.
>
> What does it say about the state of the shell when a new command is started?
It says nothing about it.
> I don't know; I am asking to find out. All I know is that no Linux
> shell I know of, except the current BusyBox shells, have this
> behavior.
Are you deliberately ignoring my point that the problem
was still happening when shell was *running a script*?
nonblock_set
vi file.txt <-- KABOOM
> Even the old BusyBox shells had "standard" behavior.
>
> Try this program on bash and in BusyBox ash:
>
> #include <unistd.h>
> #include <fcntl.h>
> int main()
> {
> fcntl(0, F_SETFL, fcntl(0, F_GETFL) | O_NONBLOCK);
> return 0;
> }
>
> Works fine in bash. In BusyBox ash, the shells exits when I press the
> up arrow (for command history) after running this program! I don't
> think you can convince me that this is correct behavior!
Can't reproduce it, neither on current git nor 1.15.2:
sh-4.0# ./nonblock_set
sh-4.0# ./nonblock_show
O_NONBLOCK is off
sh-4.0# ./busybox ash
~/srcdevel/bbox/fix/busybox-1.15.2 # ./nonblock_set
~/srcdevel/bbox/fix/busybox-1.15.2 # ./nonblock_show
O_NONBLOCK is on
~/srcdevel/bbox/fix/busybox-1.15.2 # <up/down works, no crashes>
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
