rmyorston / busybox-w32

WIN32 native port of BusyBox.

Status

Things may work for you, or may not. Things may never work because of huge differences between Linux and Windows. Or things may work in future, if you report the problem on GitHub or GitLab. If you don't have an account on one of those or you'd prefer to communicate privately you can email [email protected].

Additional information is available from the BusyBox for Windows web page. In particular:

• There are downloads of precompiled binaries for i686, x86_64 and aarch64.
• Release notes for the current and previous releases are available.

Building

You need a MinGW toolchain and a POSIX environment. I cross-compile on Linux. On Fedora the following should pull in everything required:

dnf install gcc make ncurses-devel perl-Pod-Html

dnf install mingw64-gcc (for a 64-bit build)

dnf install mingw32-gcc (for a 32-bit build)

On Microsoft Windows you can install w64devkit. Get the -i686 variant for a 32-bit build. Unzip the file and run w64devkit/w64devkit.exe.

On either Linux or Windows the commands make mingw64_defconfig or make mingw32_defconfig will pick up the default configuration. You can then customize your build with make menuconfig or by editing .config, if you know what you're doing.

Then just make.

See the Building busybox-w32 web page for additional information.

Hints

• Use forward slashes in paths: Windows doesn't mind and the shell will be happier.
• Windows paths are different from Unix (more detail):
  • Absolute paths: c:/path or //host/share/path
  • Relative to current directory of other drive: c:path
  • Relative to current root (drive or share): /path
  • Relative to current directory of current root (drive or share): path
• Handling of users, groups and permissions is totally bogus. The system only admits to knowing about the current user and employs various heuristics to synthesise uid, gid and permission values.
• Some crufty old Windows code (Windows XP, cmd.exe) doesn't like forward slashes in environment variables. The -X shell option prevents busybox-w32 from changing backslashes to forward slashes. If Windows programs don't run from the shell it's worth trying it.
• If you want to install 32-bit BusyBox in a system directory on a 64-bit version of Windows you should put it in C:\Windows\SysWOW64, not C:\Windows\System32 as you might expect. On 64-bit systems the latter is for 64-bit binaries.
• The system tries to detect the best way to handle the terminal being used. If this doesn't work you can try setting the environment variable BB_TERMINAL_MODE=1 to force the use of literal ANSI escapes or BB_TERMINAL_MODE=0 to emulate them using the Windows console API.
• busybox-w32 prefers built-in applets to external programs when running commands. This preference can be overridden by setting the environment variable BB_OVERRIDE_APPLETS to a space-separated list of applet names. Thus, to use an external make in preference to the built-in applet set BB_OVERRIDE_APPLETS="make".
• It's possible to obtain pseudo-random numbers using if=/dev/urandom as the input file to dd. The same emulation of /dev/urandom is used internally by the shred utility and to support https in wget. Serious users of random numbers may, of course, wish to make alternative arrangements.

busybox-w32's Issues

'schtasks' exits with an error when called from a script on Windows Server 2003 R2

When a shell script executed by busybox (latest binary build) calls the OS tool schtasks.exe, the tool fails with an error:

#!/bin/sh
schtasks.exe

> busybox.exe sh test.sh
ERROR: Class not registered

Same script when executed via:

GNU bash, version 3.1.23(6)-release (i686-pc-msys)
Copyright (C) 2005 Free Software Foundation, Inc.

> sh.exe -c test.sh

TaskName                             Next Run Time            Status         
==================================== ======================== ===============
[...]

It appears to be working fine when run under Windows 7 (SP1 x64).

Access violation

The local statement is causing an access violation in the ls instruction:

echo "Begin"
local locvar
echo "Local set"
ls
echo "Ls done" ; Will die before reaching this statement

However, if I define a global with the same name as the local var, the script doesn't crash:

echo "Begin"
locvar=""
local locvar
echo "Local set"
ls
echo "Ls done" ; Will work perfectly

According to OllyDbg, the crash is caused by a null-pointer exception in module msvcrt function strlen in the forked shell executing the ls instruction. I am attempting now to determine where is that precise call to strlen.

Note that I've tried this in the latest binary, not in the latest Git version, as my Cygwin setup apparently is broken and it's missing some headers (which indeed exist, but the make tool complains anyway)

Inclusion of ln applete and implemented as junctions

It's a bit of work, but implementing ln as an applet but in the underlying implementation using NTFS junctions for the implementation.
See https://msdn.microsoft.com/en-us/library/windows/desktop/aa365006%28v=vs.85%29.aspx for more info.
The reason I would prefer this meathod is that the CygWin kludge for ln is specific to CygWin and has no use inside of Windows, and as for MinGW, if I remember right, it copies the file rather then use the native junction option to maintain usability with older windows filesystems.

stderr redirection truncates output

#!/bin/sh

readonly logfile=test.log
rm -f "${logfile}"
echo '1' >> "${logfile}"
net start "(not_here)" 2>> "${logfile}"
echo '2' >> "${logfile}"

Notice the missing 1 line at the top of test.log, when run with either:
BusyBox v1.24.0-FRP-7-g316ecf2 (2015-05-27 15:40:02 BST) multi-call binary.
BusyBox v1.24.0-TIG-1784-gdb98881 (2015-04-22 21:47:46 BST) multi-call binary.

The service name is invalid.

More help is available by typing NET HELPMSG 2185.

2

test.log is correct when run with:
GNU bash, version 3.1.23(6)-release (i686-pc-msys)

1
The service name is invalid.

More help is available by typing NET HELPMSG 2185.

2

Redirection to stderr seems to truncate test.log.

FR: supporting mingw-w64 (Was: fix compiling in debian wheezy)

diff --git a/include/libbb.h b/include/libbb.h
index 5012209..a204b6c 100644
--- a/include/libbb.h
+++ b/include/libbb.h
@@ -160,6 +160,7 @@ int klogctl(int type, char *b, int len);

 /* Can't use ENABLE_PLATFORM_MINGW32 because it's also called by host compiler */
 #if ENABLE_PLATFORM_MINGW32
+# define __USE_MINGW_ANSI_STDIO
 # include "mingw.h"
 #endif

diff --git a/include/mingw.h b/include/mingw.h
index fdcd7f7..20da679 100644
--- a/include/mingw.h
+++ b/include/mingw.h
@@ -268,10 +268,12 @@ int mingw_fstat(int fd, struct stat *buf);
 /*
  * sys/time.h
  */
+#if 0
 struct timespec {
        time_t tv_sec;
        long int tv_nsec;
 };
+#endif
 struct itimerval {
        struct timeval it_value, it_interval;
 };

adding modeless editor

Hello! I'm trying to add ue as a modeless editor besides vi and I followed the instructions given in the main busybox page to include it, but somehow it didn't work. How can I share it to troubleshoot it? Thanks in advance,

`ls .` outputs `: applet not found` on Windows XP

First, thanks for maintaining this, super useful and I wish more people knew about it. We've been using this in Julia, to a very limited extent so far, but we'll likely expand our uses of it soon when we stop bundling msys. I might want to help with mingw-w64 compatibility at some point (the mingw32 toolchains are either not available or very outdated in most distributions), the patches floating around the tracker here don't all apply/work on current master but hopefully it's fixable.

So I checked all the downloads you have on FTP, things are working fine on Windows 7, but some time between TIG-1618-g0e0b5e9 and TIG-1627-gd143657, something changed that caused a regression in functionality on Windows XP, where running ls . returns : applet not found. I got a cross-compile build to work on Ubuntu 14.04 using i586-mingw32msvc-gcc, so maybe I'll try bisecting if I get some time to narrow it down further.

It's completely understandable if you don't care about supporting XP, it's EOL and people shouldn't be using it any more, but a fair number of people still are for whatever reason. If this is an expected change then we can close this, but in case it's an unexpected problem I figured I'd report it.

wildcards broken

e.g.:

> busybox.exe grep nircmd.exe *.bat
grep: *.bat: Invalid argument

the older v1.19.1 build by pclouds worked fine

Building with "i686-w64-mingw32" works, but building with "x86_64-w64-mingw32" doesn't

Make output after issuing make mingw32_defconfig and make menuconfig with cross-compiler prefix set to x86_64-w64-mingw32-.

  SPLIT   include/autoconf.h -> include/config/*
  GEN     include/bbconfigopts.h
  HOSTCC  applets/usage
  GEN     include/usage_compressed.h
  HOSTCC  applets/applet_tables
  GEN     include/applet_tables.h
  CC      applets/applets.o
In file included from include/libbb.h:163:0,
                 from include/busybox.h:8,
                 from applets/applets.c:9:
include/mingw.h:11:13: error: conflicting types for ‘pid_t’
/usr/lib/gcc/x86_64-w64-mingw32/4.6/../../../../x86_64-w64-mingw32/include/sys/types.h:68:16: note: previous declaration of ‘pid_t’ was here
include/mingw.h:123:0: warning: "fseeko" redefined [enabled by default]
/usr/lib/gcc/x86_64-w64-mingw32/4.6/../../../../x86_64-w64-mingw32/include/stdio.h:416:0: note: this is the location of the previous definition
In file included from include/libbb.h:163:0,
                 from include/busybox.h:8,
                 from applets/applets.c:9:
include/mingw.h:242:0: warning: "lseek" redefined [enabled by default]
/usr/lib/gcc/x86_64-w64-mingw32/4.6/../../../../x86_64-w64-mingw32/include/io.h:336:0: note: this is the location of the previous definition
include/mingw.h:243:0: warning: "stat" redefined [enabled by default]
/usr/lib/gcc/x86_64-w64-mingw32/4.6/../../../../x86_64-w64-mingw32/include/sys/stat.h:258:0: note: this is the location of the previous definition
include/mingw.h:247:0: warning: "fstat" redefined [enabled by default]
/usr/lib/gcc/x86_64-w64-mingw32/4.6/../../../../x86_64-w64-mingw32/include/sys/stat.h:259:0: note: this is the location of the previous definition
include/mingw.h:249:0: warning: "_stati64" redefined [enabled by default]
/usr/lib/gcc/x86_64-w64-mingw32/4.6/../../../../x86_64-w64-mingw32/include/_mingw_stat64.h:14:0: note: this is the location of the previous definition
include/mingw.h:243:14: warning: ‘struct _stati64’ declared inside parameter list [enabled by default]
include/mingw.h:243:14: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
include/mingw.h:243:14: warning: ‘struct _stati64’ declared inside parameter list [enabled by default]
include/mingw.h:243:14: warning: ‘struct _stati64’ declared inside parameter list [enabled by default]
include/mingw.h:243:14: warning: ‘struct _stati64’ declared inside parameter list [enabled by default]
include/mingw.h:243:14: warning: ‘struct _stati64’ declared inside parameter list [enabled by default]
include/mingw.h:243:14: warning: ‘struct _stati64’ declared inside parameter list [enabled by default]
make[1]: *** [applets/applets.o] Error 1
make: *** [applets_dir] Error 2

Attempted build is on Debian Wheezy, with the following packages installed:

apt-get install \
libncurses5-dev libncursesw5-dev \
mingw-w64-i686-dev g++-mingw-w64-i686 gcc-mingw-w64-i686 binutils-mingw-w64-i686 \
mingw-w64-x86-64-dev g++-mingw-w64-x86-64 gcc-mingw-w64-x86-64 binutils-mingw-w64-x86-64 \
gcc-mingw-w64-base \
g++-4.6 libstdc++6-4.6-dev libtinfo-dev

Variable substring matching pattern not recognized

This script is meant to extract the filename part from a pathspec in a portable way. It's expected to display file.ext twice, but it displays the whole input string instead when run with BusyBox:

#!/bin/sh
test='/dir/file.ext'
echo "${test##*[/|\\]}"
test='\dir\file.ext'
echo "${test##*[/|\\]}"

BusyBox v1.24.0-TIG-1784-gdb98881 (2015-04-22 21:47:46 BST) multi-call binary:

/dir/file.ext
\dir\file.ext

3.1.23(6)-release:

file.ext
file.ext

It's an upstream issue, in case it isn't an intentional omission. The pattern matching rules are described here.

quotation issue (Was: broken sed)

busybox-w32 sed don't work here:

# sed -n "s/^[^#]*ENC.*([^,]*, *\([^,]*\)\(,.*\)*).*/\1_encoder/p" ./libavcodec/allcodecs.c
#

allcodecs.c is here:
http://git.libav.org/?p=libav.git;a=blob_plain;f=libavcodec/allcodecs.c;hb=HEAD

new applet: pr

this is a very simple stub for making libav configure happy.

diff --git a/coreutils/Config.src b/coreutils/Config.src
index 81be719..0a2cce5 100644
--- a/coreutils/Config.src
+++ b/coreutils/Config.src
@@ -430,6 +430,12 @@ config OD
    help
      od is used to dump binary files in octal and other formats.

+config PR
+   bool "pr"
+   default y
+   help
+     pr is used to format text files before print.
+
 config PRINTENV
    bool "printenv"
    default y
diff --git a/coreutils/Kbuild.src b/coreutils/Kbuild.src
index d6453f0..7be6f3b 100644
--- a/coreutils/Kbuild.src
+++ b/coreutils/Kbuild.src
@@ -50,6 +50,7 @@ lib-$(CONFIG_MV)        += mv.o
 lib-$(CONFIG_NICE)      += nice.o
 lib-$(CONFIG_NOHUP)     += nohup.o
 lib-$(CONFIG_OD)        += od.o
+lib-$(CONFIG_PR)  += pr.o
 lib-$(CONFIG_PRINTENV)  += printenv.o
 lib-$(CONFIG_PRINTF)    += printf.o
 lib-$(CONFIG_ASH_BUILTIN_PRINTF) += printf.o
diff --git a/include/applets.src.h b/include/applets.src.h
index 597b1c9..96989f3 100644
--- a/include/applets.src.h
+++ b/include/applets.src.h
@@ -280,6 +280,7 @@ IF_PIPE_PROGRESS(APPLET(pipe_progress, BB_DIR_BIN, BB_SUID_DROP))
 IF_PIVOT_ROOT(APPLET(pivot_root, BB_DIR_SBIN, BB_SUID_DROP))
 IF_PKILL(APPLET_ODDNAME(pkill, pgrep, BB_DIR_USR_BIN, BB_SUID_DROP, pkill))
 IF_POPMAILDIR(APPLET(popmaildir, BB_DIR_USR_SBIN, BB_SUID_DROP))
+IF_PR(APPLET(pr, BB_DIR_USR_BIN, BB_SUID_DROP))
 IF_PRINTENV(APPLET_NOFORK(printenv, printenv, BB_DIR_BIN, BB_SUID_DROP, printenv))
 IF_PRINTF(APPLET_NOFORK(printf, printf, BB_DIR_USR_BIN, BB_SUID_DROP, printf))
 IF_PS(APPLET(ps, BB_DIR_BIN, BB_SUID_DROP))
--- a/coreutils/pr.c    2012-09-20 10:46:43 +0800
+++ b/coreutils/pr.c    2012-09-20 10:38:46 +0800
@@ -0,0 +1,42 @@
+/* vi: set sw=4 ts=4: */
+/*
+ * pr - format text files for printing
+ *
+ * Copyright (C) 2006 by Rob Sullivan, with ideas from code by Walter Harms
+ *
+ * Licensed under GPLv2 or later, see file LICENSE in this source tree.
+ */
+
+//usage:#define pr_trivial_usage
+//usage:       "[FILES...]\n"
+//usage:#define pr_full_usage "\n\n"
+//usage:       "pr FILE (or stdin) to stdout\n"
+
+#include "libbb.h"
+
+int pr_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE;
+int pr_main(int argc UNUSED_PARAM, char **argv)
+{
+   int bytes_read;
+   int exit_code = EXIT_SUCCESS;
+
+   ++argv; --argc; // not processing self(argv[0])
+   while (argc && (argv[0][0] == '-' || argv[0][0] == '+'))
+       --argc, ++argv;
+
+   do {
+       int fd = open_or_warn_stdin(*argv ? *argv : bb_msg_standard_input);
+
+       if (fd < 0) {
+           exit_code = EXIT_FAILURE;
+           continue;
+       }
+       while ((bytes_read = safe_read(fd, bb_common_bufsiz1, sizeof(bb_common_bufsiz1))) > 0) {
+           puts(bb_common_bufsiz1);
+       }
+       close(fd);
+
+   } while (*argv && *++argv);
+
+   fflush_stdout_and_exit(exit_code);
+}

use "[ -e ~/xxx ]", error: "sh: and: unknown operand, "

sh/ash/bash have the same problem.

Problem when executing busybox applets via link

If execute busybox.exe without any argument then we will see short help saying:

...  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.

So I make some link, e.g. diff.exe.
All is OK when starting applet with it's full name diff.exe
But if I type just name diff (without exe ext) then I see following message:

diff.exe: applet not found

Could you fix it?

Can not identify directory?

on XP(same problem on linux):

ls: wide char friendly

so it won't mess up wide chars.

diff --git a/coreutils/ls.c b/coreutils/ls.c
index 4fe291d..a37db85 100644
--- a/coreutils/ls.c
+++ b/coreutils/ls.c
@@ -473,14 +473,15 @@ static unsigned print_name(const char *name)
    uni_stat_t uni_stat;

    // TODO: quote tab as \t, etc, if -Q
-   name = printable_string(&uni_stat, name);
+   if (ENABLE_UNICODE_SUPPORT)
+       name = printable_string(&uni_stat, name);

    if (!(option_mask32 & OPT_Q)) {
        fputs(name, stdout);
-       return uni_stat.unicode_width;
+       return unicode_strwidth(name);
    }

-   len = 2 + uni_stat.unicode_width;
+   len = 2 + unicode_strwidth(name);
    putchar('"');
    while (*name) {
        if (*name == '"' || *name == '\\') {

bash unable to reference "${PROGRAMFILES(X86)}"

I'm not sure if this is an escaping issue, but I'm unable to check this string in the inherited environment from windows.
I keep getting:

C:\P\foo.bash: line 45: syntax error: bad substitution

right now the offending line looks like:

for PF in "${PROGRAMFILES}" "${PROGRAMFILES(X86)}" ; do
log_trace "${PF}"
done

jobs / fg / bg ?

I just noticed that although I can put jobs in the background, e.g.

$ sleep 10 && echo hi & # works as expected

..the commands for managing those background jobs seem missing:

~ $ jobs
ash: jobs: not found
~ $ fg
ash: fg: not found
~ $ bg
ash: bg: not found

calling an alias from function in ash

I'm seeing that aliases don't (seem) to work when calling from a function in ash.

# There is a newline in that string after $PWD.
alias Apushd='POPD_STACK_DIRS="$PWD
${POPD_STACK_DIRS}"; echo "${POPD_STACK_DIRS}" | xargs ; cd'

pushd() {
    export POPD_STACK_DIRS="$PWD
${POPD_STACK_DIRS}"
    echo "${POPD_STACK_DIRS}" | xargs
    cd "${1}"
}

# This is all one line.
alias popd='LINE=`echo "\${POPD_STACK_DIRS}" | sed -ne '1p'`;[ "$LINE" != "" ] && cd $LINE;POPD_STACK_DIRS=`echo "\${POPD_STACK_DIRS}" | sed -e '1d'`;echo "${POPD_STACK_DIRS}" | xargs'

what I have noticed is that I can call the function from another ash function - ie:

log_pushd() {
    log_trace "PUSHD \"${1}\""
    pushd "$1"
}

log_popd() {
    _lRet=$(popd "$1")
    log_trace "POPD \"${_lRet}\""
}

but switching to use the alias form gives me the error:

C:\P\blah\pp-build.sh: C:/P/blah/post-build.sh: line 47: pushd: not found

Is this an issue with Ash, or by design with ash?

MSVC++ Runtime Error with bb and openssl

I have encountered a rather strange issue with a busybox-w32 running on Windows XP when attempting to run the openssl.exe program from the installer provided on their binary distribution page here: https://www.openssl.org/related/binaries.html .

This issue is not present on my busybox-w32 build repeating the same steps on my Vista box: only XP. I have built busybox-w32 from git commit 3fd3465 in a fairly simple setup, and am happy to paste my .config if it will help (for reference, the current rmyorston-supplied binaries from http://intgat.tigress.co.uk/rmy/busybox/index.html break in the same way.) My compile environment is mingw on an Ubuntu-server 13.04 64-bit using i686-w64-mingw32-gcc as my compiler. Since it's not listed, I have no clue how the upstream binaries are built; both exhibit the same symptoms.

Note that I can run openssl.exe from a cmd.exe prompt fine, as it does from Cygwin's bash shell. Under Windows XP specifically, busybox-w32 appears to work fine except when I call that same openssl.exe from the above installation. For reference, an openssl executable from the OpenVPN installer (build using the mingw cross-compiler instead of MSVC++) works fine when called from busybox-w32.

When reproducing the issue, the following error is shown in a graphical message box:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: D:\Apps\OpenSSL-Win32\bin\openssl.exe
R6034
An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information.

While the MSVC++RT error message is apparently coming from openssl, there has to be something busybox is doing to cause it since this application works fine everywhere else I can think to run it from, including a variety of cygwin shells.

Reproduction steps:

1. Need to be using Windows XP.
2. Build busybox
3. Install the "OpenSSL Lite" (I'm using 1.0.1e, latest version)
4. OpenSSL Lite will require the Visual C++ 2008 Redistributable linked from their page if not already present.
5. Open a Windows command prompt & start bb: busybox.exe sh
6. Call the openssl program: D:/InstallPath/OpenSSL-Win32/bin/openssl.exe version

The expected result is of course the version from openssl, not the MSVC++ runtime error.

Let me know if any further info is useful for debugging.

Failed to run python, xp

winansi: skip DECTCEM (\e[?{numbers}[lh])

this will skip showing "1049l" when exiting busybox vi.

diff --git a/win32/winansi.c b/win32/winansi.c
index c923bde..9fc1206 100644
--- a/win32/winansi.c
+++ b/win32/winansi.c
@@ -294,6 +294,12 @@ static const char *set_attr(const char *str)
    case 'K':
        erase_in_line();
        break;
+   case '?': /* DECTCEM */
+       ++str; /* ? */
+       while (*str >= '0' && *str <= '9') /* numbers */
+           ++str;
+       func = str; /*++str; *//* l/h: load/save cursor position */
+       break;
    default:
        /* Unsupported code */
        break;

reduce Windows .exe size by a few kilobytes

Try adding -fno-ident to CFLAGS.

By default annoying C compiler ID string is built in each object
file and they will be linked into the final executable without
deduplication. This option will drop them all. (some may still
appear from compiler's objects)

[question] What's the relation to pclouds/busybox-w32 ?

This repo is a fork of pclouds/busybox-w32 but ahead of it by 90 commits (as of now), yet both seems active. Also, the readme at pclouds/busybox-w32 points to this (rmyorston/busybox-w32) repo..

So what's going on?

diff: non binary safe

You may try to diff -U8 bdf2hex.vs05.cpp bdf2hex.cpp and your git version goes strange ( http://roy.dnsd.me/rmyorston-diff.txt ), while pclouds version works.

http://roy.dnsd.me/bdf2hex.vs05.cpp
http://roy.dnsd.me/bdf2hex.cpp

vi: first line is broken

~/Desktop $ cat .jscreenfix.licence
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>JADS Licence Information</comment>
<entry key="paymentIsRefundable">true</entry>
<entry key="licenceProductName">JScreenFix</entry>
<entry key="licenceId">b241681b-d9ca-4978-b21f-df24323425d4</entry>
<entry key="hash">b6358a9567fe8e367c02af12690d5d59</entry>
<entry key="licenceStatus">Trial</entry>
<entry key="licenceProductVersion">1.2</entry>
<entry key="apiVersion">1.0</entry>
<entry key="usageNextCheckDate">May 11, 2011 12:05:24 AM GMT</entry>
<entry key="licenceIssueDate">May 11, 2011 12:00:27 AM GMT</entry>
</properties>
~/Desktop $ vi .jscreenfix.licence
<?xml versionproperties>^M
ng="UTF-8" standalone="no"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>JADS Licence Information</comment>
<entry key="paymentIsRefundable">true</entry>
<entry key="licenceProductName">JScreenFix</entry>
<entry key="licenceId">b241681b-d9ca-4978-b21f-df24323425d4</entry>
<entry key="hash">b6358a9567fe8e367c02af12690d5d59</entry>
<entry key="licenceStatus">Trial</entry>
<entry key="licenceProductVersion">1.2</entry>
<entry key="apiVersion">1.0</entry>
<entry key="usageNextCheckDate">May 11, 2011 12:05:24 AM GMT</entry>
<entry key="licenceIssueDate">May 11, 2011 12:00:27 AM GMT</entry>
</properties>
/properties>^M
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
~
~
~
~
~
~
~
can't read all of file ".jscreenfix.licence"

filename encoding issues

du skips files having foreign chars in the filename:

> du -a TouhouKoumajouDensetsuScarletSymphony > stdout.txt
du: TouhouKoumajouDensetsuScarletSymphony/?????1.00.pdf: No such file or directory
du: TouhouKoumajouDensetsuScarletSymphony/????? ??????.exe: No such file or directory

File Integrity

Someone who downloaded BusyBox-w32 is experiencing a virus report, according to one of the discussion posts on:
http://betanews.com/2014/06/26/busybox-crams-117-unix-tools-into-a-tiny-windows-executable/

Just thought you would appreciate knowing.

64-bit build?

As mentioned in my previous message, I built BusyBox from sources and since my build scripts are generally prepared to create both 32-bit and 64-bit setup packages, I also compiled BusyBox as a 64-bit application (I know it uses 32-bit windows calls, but it is still more convenient on 64-bit machines).

Unfortunately I noticed that the 64-bit version of sh.exe fails to run a command like:

sh -c 'echo test'

which makes it completely useless in my setup, where make runs all children commands via sh.

The build script is documented in my wiki page, part of the open-source GNU ARM Eclipse plug-ins project.

Any clues on what might be wrong?

Any chance to get netcat (nc) applet support?

Like above.
Thanks so much for such utility!
--QL

-p switch of xargs cause error

C:/ $ echo hello | xargs -p -n 1 echo
echo helloxargs: can't open '/dev/tty': No such file or directory

incorrect sed substitutions for backreferences

From upstream BusyBox Bugzilla (#8791):

  $cat myfile
  a
  b
  c
  $sed "s/\(.*\)/\1\1/" myfile
  a
  b
  c

it should be :

  $sed "s/\(.*\)/\1\1/" myfile
  aa
  bb
  cc

used once \1 worked as expected but when repeated it does not.

Chocolatey package?

Would it be possible to create a busybox package for Chocolatey?

busybox b?ash: error running autoconf-generated configure scripts

I don't know it is right place for report, but when I try to run configure scripts I got:

C:/example $ ./configure
./configure: ./configure.lineno: line 536: 7: %m

Is it busybox-w32 issue? Upstream busybox issue? autoconf issue?

date applete %z %Z formating doesn't conform to IEEE Std 1003.1-2001

%z
Replaced by the offset from UTC in the ISO 8601:2000 standard format ( +hhmm or -hhmm ), or by no characters if no timezone is determinable. For example, "-0430" means 4 hours 30 minutes behind UTC (west of Greenwich). [CX] [Option Start] If tm_isdst is zero, the standard time offset is used. If tm_isdst is greater than zero, the daylight savings time offset is used. If tm_isdst is negative, no characters are returned. [Option End] [ tm_isdst]
%Z
Replaced by the timezone name or abbreviation, or by no bytes if no timezone information exists. [ tm_isdst]

I believe the core issue here is a short-coming in the windows API described in https://msdn.microsoft.com/en-us/library/fe06s4ak.aspx - this issue is low priority, but should be documented.

Very slow del/backspace in sh when the console has big buffer hight

• At the Windows console properties, set layout -> screen buffer size -> height = 9999 (the maximum)
• run the shell using busybox sh -l
• At the shell prompt, type few characters
• Try to delete the chars by holding down the backspace key

This responds very very slowly. The DEL key is also very slow.
If I run vi from the same slow shell, then backspace works fast, but then I exit vi back to the shell - slow again.

If I change the screen buffer height to something smaller, then both backspace and del are fast as they should.

win32: mktemp support

add support for mktemp.
limitations:

• mingw tempnam uses $TMP directly, path is not used actually
• chp has to be basenameed to avoid strange output

diff --git a/debianutils/mktemp.c b/debianutils/mktemp.c
index dbe4309..20bad64 100644
--- a/debianutils/mktemp.c
+++ b/debianutils/mktemp.c
@@ -59,6 +59,9 @@ int mktemp_main(int argc UNUSED_PARAM, char **argv)
        const char *path;
        char *chp;
        unsigned opts;
+               unsigned len;
+               int cnt;
+
        enum {
                OPT_d = 1 << 0,
                OPT_q = 1 << 1,
@@ -86,16 +89,27 @@ int mktemp_main(int argc UNUSED_PARAM, char **argv)

        if (opts & OPT_u) {
                /* Remove (up to) 6 X's */
-               unsigned len = strlen(chp);
-               int cnt = len > 6 ? 6 : len;
+#if defined(__MINGW32__)
+               chp = bb_get_last_path_component_strip(chp);
+#endif
+
+               len = strlen(chp);
+               cnt = len > 6 ? 6 : len;
                while (--cnt >= 0 && chp[--len] == 'X')
                        chp[len] = '\0';

+#if defined(__MINGW32__)
+               chp = _tempnam(opts & (OPT_t|OPT_p) ? path : ".\\", chp);
+#else
                chp = tempnam(opts & (OPT_t|OPT_p) ? path : "./", chp);
+#endif
                if (!chp)
                        return EXIT_FAILURE;
+
+#if !defined(__MINGW32__)
                if (!(opts & (OPT_t|OPT_p)))
                        chp += 2;
+#endif
                goto ret;
        }

@@ -110,6 +124,14 @@ int mktemp_main(int argc UNUSED_PARAM, char **argv)
                        return EXIT_FAILURE;
        }
  ret:
+#if defined(__MINGW32__)
+               len = strlen(chp);
+               cnt = len;
+               while (--cnt >= 0)
+                       if(chp[cnt] == '\\')
+                               chp[cnt] = '/';
+#endif
+
        puts(chp);
        return EXIT_SUCCESS;
 }

restore length and rpm2cpio applets

comparing the list of applets of the previous pclouds build, i've found that 2 applets were removed: length and rpm2cpio.

basename and back-slashed path names

I'm not sure what's appropriate here, but basename doesn't work with back-slashed paths. Either basename could support the backslash truncation to the basename, or adding readlink and having it understand backslashes to convert to forward slashes to be used by basename.

ie:
basename readlink -f ${WinPath}

while loop taking '<' redirected input hangs

This hangs in busybox-w32's ash:

$ echo 'a
> b
> c' > test.txt
$ while read LINE; do echo $LINE; done < test.txt

Not terrible, because this works as a workaround:

$ cat test.txt | while read LINE; do echo $LINE; done

..but the above is a common-ish idiom.

which shows the wrong slash

C:>busybox which cmd
C:\WINDOWS\system32/cmd.exe

Note that the above slash before cmd should have been \ not /

Binary distribution

Hello!

Wonder if you could provide built busybox binary (defconfig or allyesconfig)?

TIA,
--Vladimir

md5sum is broken due to file open mode issue

Reproducable with any particular binary file. Just compare the output of busybox md5sum and another MD5 hash calculator like md5sum from Cygwin. Looks like the same issue as #4.

I figured out that _open() CRT call always uses text file mode (_O_TEXT) by default when opening files until it will set explicitly by the _set_fmode(). Thus ^Z (0x1A) is treated like end-of-file sequence and reading is stopped.

I've tried to fix it with following patch:

@@ -125,10 +125,12 @@ int mingw_open (const char *filename, int oflags, ...)
               va_start(args, oflags);
              mode = va_arg(args, int);
              va_end(args);
+             oflags |= _O_BINARY; // force binary mode by default
+
               if (oflags & O_NONBLOCK) {
                             errno = ENOSYS;
                             return -1;
              }
              if (filename && !strcmp(filename, "/dev/null"))

... and it worked for me. I'm not sure about regression risks (please take a look at #4) but I suppose that line endings issue can be solved by implementing -a command-line switch for diff which seems to be ignored.

ls : display group information ?

The ls command doesn't display group information (only user information).

λ ls -l
total 4
-rw-------    1 emmanuel 0                7 Feb 24 11:01 test

Not consistently inheriting $HOME from environment

When executing from Git Bash, busybox-w32 ash inherits HOME as I'd expect:

alex kozhevnikov@AKOZHEVNIKOV /c/Users/alex kozhevnikov
$ HOME=/o busybox ash
~ $ echo $HOME
o:/
~ $

Similarly if one instance of the busybox.exe binary executes another:

alex kozhevnikov@AKOZHEVNIKOV /c/Users/alex kozhevnikov
$ cp ~/busybox.exe ~/busybox_copy.exe

alex kozhevnikov@AKOZHEVNIKOV /c/Users/alex kozhevnikov
$ busybox_copy ash
~ $ HOME=O:/ busybox.exe ash
~ $ echo $HOME
O:/
~ $

I don't recall ever observing different behavior on Linux either (though I admit that maybe busybox behaves differently with this regard even on Linux depending on build-time configuration options that I don't know about...).

But when executing from Windows' cmd, it does not:

C:\Users\alex kozhevnikov>SET HOME="O:\" & busybox.exe ash
~ $ echo $HOME
C:/Users/alex kozhevnikov
~ $

Similarly when executing from PowerShell:

PS C:\Users\alex kozhevnikov> $Env:HOME='O:\'
PS C:\Users\alex kozhevnikov> echo $Env:HOME
O:\
PS C:\Users\alex kozhevnikov> busybox.exe ash
~ $ echo $HOME
C:/Users/alex kozhevnikov
~ $

Note that the busybox ash is correctly inheriting variables from the environment in general: there are no problems inheriting $PATH or some arbitrary environment variable (e.g. set A="C:\foo" & busybox.exe sh). It also does not seem to be a back-slash problem, as I can set those variables with forward-slashes instead of back-slashes in cmd or PowerShell and the same result happens, or use back-slashes in the Git Bash or two-busybox-copies versions of the commands to get the same working results.

I can not use cmake to build llvm

I use busybox-w32 with ConsoleZ (https://github.com/cbucher/console).

If i build LLVM with cmake get i an error:

C:/LLVM/BUILD_MINGW $ cmake -G "MinGW Makefiles" ..
-- The C compiler identification is GNU 4.9.2
-- The CXX compiler identification is GNU 4.9.2
-- Check for working C compiler: C:/TDM-GCC-64/bin/gcc.exe
-- Check for working C compiler: C:/TDM-GCC-64/bin/gcc.exe -- broken
CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/CMakeTestCCompiler.cmake:61 (message):
  The C compiler "C:/TDM-GCC-64/bin/gcc.exe" is not able to compile a simple
  test program.

  It fails with the following output:

   Change Dir: C:/LLVM/BUILD_MINGW/CMakeFiles/CMakeTmp



  Run Build Command:"C:/TDM-GCC-64/bin/mingw32-make.exe"
  "cmTryCompileExec2235654119/fast"

  C:/TDM-GCC-64/bin/mingw32-make.exe -f
  CMakeFiles\cmTryCompileExec2235654119.dir\build.make
  CMakeFiles/cmTryCompileExec2235654119.dir/build

  mingw32-make.exe[1]: Entering directory
  'C:/LLVM/BUILD_MINGW/CMakeFiles/CMakeTmp'

  "C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report
  C:\LLVM\BUILD_MINGW\CMakeFiles\CMakeTmp\CMakeFiles 1

  Syntaxfehler.

  CMakeFiles\cmTryCompileExec2235654119.dir\build.make:56: recipe for target
  'CMakeFiles/cmTryCompileExec2235654119.dir/testCCompiler.c.obj' failed

  mingw32-make.exe[1]: ***
  [CMakeFiles/cmTryCompileExec2235654119.dir/testCCompiler.c.obj] Error 1

  mingw32-make.exe[1]: Leaving directory
  'C:/LLVM/BUILD_MINGW/CMakeFiles/CMakeTmp'

  Makefile:117: recipe for target 'cmTryCompileExec2235654119/fast' failed

  mingw32-make.exe: *** [cmTryCompileExec2235654119/fast] Error 2





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:19 (project)


-- Configuring incomplete, errors occurred!
See also "C:/LLVM/BUILD_MINGW/CMakeFiles/CMakeOutput.log".
See also "C:/LLVM/BUILD_MINGW/CMakeFiles/CMakeError.log".
C:/LLVM/BUILD_MINGW $

If i use cmd everythings works.

find applet with -perm option

Would be useful if windows permissions could be matched in find and searchable according to how chmod sets them.

As far as finds core main-line functionality, it would also be nice if the main-line busybox find applet also supported the -writable -readable and -executable flag even if they redundant to -perm, but I realize that may be more of a linux thing and less of a posix standard.

"\w" in $PS1 seems to ignore $HOME for printing '~'

I use busybox-w32 ash in a context where the $HOME variable is set to another location than the Windows user's home folder. It seems that, even when everything else recognizes what $HOME is set to, the shell still substitutes '~' for the Windows user's home folder when deciding what to print for "\w" in $PS1 for the shell prompt.

Observe (note that in the actual command evaluation, tilde-substitution works fine, so it's only an aesthetic issue, not a functional one):

~ $ pwd
C:/Users/alex kozhevnikov
~ $ echo $HOME
C:/wintools
~ $ cd ~
C:/wintools $ echo $PS1
\w $
C:/wintools $

Wildcard expansion

I'm a bit confused about your comment in the home page:

... the binaries provided here are configured with wildcard expansion disabled. This is the preferred option when the BusyBox shell is being used. (Unix-style shells expand wildcards on the command line before running programs ...

I did some tests and apparently your shell did not expand wildcards, but after changing CONFIG_NOGLOB=n it did. Were the wildcard expanded by the shell, or by the utilities (I tried rm & ls from within sh).

My specific need for BusyBox is as shell for make, in the open-source GNU ARM Eclipse plug-ins project. I build both make and busybox from sources, as documented in my wiki page.

The make files generated by the plug-ins do not use wildcards, but in Eclipse it is also possible to build un-managed projects, using custom make files, where I need to support wildcard expansion, otherwise some builds written on GNU/Linux might fail.

Any thoughts on the wildcard expansion?

include gMake applet

It's a far stretch - but including gMake would make development on windows machines fairly powerful. I think it could be leveraged with Eclipse and NetBeans CND plugin - as well as commercial packages like IAR depending on licensing.