| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Cygwin terminal program mintty sets the HOME environment
variable. Attempt to detect this and unset HOME so the usual
busybox-w32 initialisation of HOME is used instead.
Adds 80 bytes.
(GitHub issue #420)
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Merge the kill() and kill_pids() functions.
Allocate an array for the PIDs rather than use a hardcoded one.
Adds 32 bytes to the 32-bit build, none to 64-bit.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
busybox-w32 had a dummy implementation of getppid(2) which always
returned 1. Provide a more realistic version.
The effect is limited:
- The PPID shell variable should report a sensible value.
- The special value to omit the parent PID 'pidof -o %PPID'
should work.
Costs 48 bytes.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Recent changes to allow orphaned processes to report a parent PID
of 1 rely on the assumption that Process32First/Process32Next
return parents before children. This isn't guaranteed by the API.
Obtain all known PIDs on the first call to procps_scan() so that
dead parents can be detected reliably.
Costs 48 bytes.
|
| | |
| |
| |
| | |
Saves 16-32 bytes
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the parent PID doesn't appear in the process table, report it
as 1. This more closely matches how orphaned children are handled
on UNIX.
Adds 96-128 bytes.
(GitHub issue #416)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A process which has exited may still have its process handle
held open by its children. Such a process doesn't appear in
the process table. It is thus similar to a zombie process in
UNIX. Using kill(1) to interact with such a process was seen
to succeed, contrary to expectation.
The code for "ordinary" signals in kill(2) did check if the
process was still active but didn't treat an attempt to kill
an inactive process as an error. Furthermore, sending SIGKILL
or the fake signal 0 to a process didn't even check if the
process was still active.
Rearrange the implementation of kill(2) so that an attempt to
signal an inactive process is treated as an error. This also
consolidates handling of SIGKILL and signal 0 with "ordinary"
signals.
Saves 96 bytes.
(GitHub issue #416)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a shell was started with the -X option, environment variables
had forward slashes changed to backslashes. This is unnecessary
and counterproductive.
Adjust how the state of winxp is handled to avoid this.
(GitHub issue #415)
|
| | |
| |
| |
| |
| |
| |
| |
| | |
It's possible that files in remote storage may not be available
locally. Avoid downloading such files just to obtain file
attributes.
(GitHub issue #414)
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
An alias expansion immediately followed by '&' is parsed
incorrectly:
~ $ alias x='sleep 2'
~ $ x&
~ $
sh: syntax error: unexpected "&"
The sleep happens in the foreground and the '&' is left in the
input buffer. The same problem occurs in upstream BusyBox but
not dash.
The difference between BusyBox and dash is that BusyBox supports
bash-style output redirection (BASH_REDIR_OUTPUT in the code).
This requires checking for '&>' in readtoken1().
When the end of the alias is found, the '&' and the following
newline are both read to check for '&>'. Since there's no match
both characters are pushed back.
The alias is then expanded and __pgetc() is called to fetch the
next character. Since there are none left in the alias string
__pgetc() calls preadbuffer() which pops the string, reverts to
the previous input and recursively calls __pgetc(). This request
is satisified from the pungetc buffer. But the first __pgetc()
doesn't know this: it sees the character has come from
preadbuffer() so it (incorrectly) updates the pungetc buffer.
Resolve the issue by moving the code to pop the string and fetch
the next character up from preadbuffer() into __pgetc().
Saves 32-48 bytes.
(GitHub issue #413)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The 'noiconify' option controls how the console window is concealed
when the 'noconsole' option is used. The default is to iconify
the console. When 'noiconify' is 'on' the console is hidden.
Adds 8-16 bytes.
(GitHub issue #325)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Commit 67ed7484be (ash: detect console state on shell start up)
synchronised the noconsole option with the actual state of the
window on shell start up.
This is insufficient. The user can change the state of the window
independently of the noconsole option, leading to confusion and
unwanted iconification of the window when unrelated 'set' commands
are issued.
Detect the current console state on every call to options().
Saves 16-32 bytes.
(GitHub issue #325)
|
| | |
| |
| |
| |
| | |
Recent versions of gcc fail to build the binary to test for
ncurses because main() is lacking a return type.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Allow the default history size (used if HISTFILESIZE isn't set)
to be configured at build time. This may be less than or equal
to the standard history size.
(GitHub issue #411)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Keep the maximum history size at 1023 but make the default 383.
This gives a modest increase over the previous default of 255
while allowing users to increase or decrease the history size
using the HISTFILESIZE environment variable.
(GitHub issue #411)
|
| | |
| |
| |
| |
| |
| |
| | |
The upstream default history size is 255. Increase it to 1023
for default busybox-w32 builds.
(GitHub issue #411)
|
| | |
| |
| |
| |
| |
| | |
The 'quick fix' in the previous commit unnecessarily checks the
fractional timestamp value to determine if a target exists. This
isn't how it's done elsewhere in the code.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
POSIX says:
A target shall be considered up-to-date... if it has already
been made up-to-date by the current invocation of make
(regardless of the target's existence or age).
If the target does not exist after the target has been
successfully made up-to-date, the target shall be treated as
being newer than any target for which it is a prerequisite.
Previously 'make' assumed that if a rule had succeeded the
modification time of the target would be the current time. This
isn't necessarily the case. Instead:
- If the file exists use the modification time of the file as the
the time of the target.
- If it doesn't exist use the current time, which should be more
recent than the time of any file for which it's a prerequisite.
Adds 16 bytes.
(GitHub issue #410)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Mixing Windows and Unix-style filename extensions was causing
problems. Tweak how extensions are handled to try and improve
matters:
- Consistently check whether the unaltered filename is an
executable before trying adding extensions.
- Check .exe and .com before .sh.
Saves up to 16 bytes.
(GitHub issue #405)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
POSIX requires macro definitions to appear before targets on the
command line. Allow mixed macros and targets as an extension.
All macros on the command line are read first, then the targets
are processed.
Costs 64-80 bytes.
(GitHub issue #406)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Originally there was no validation of macro names imported from
the environment. However, process_macros() failed to account for
the additional flag bit at this level. Thus, for example, SHELL
was imported when it shouldn't have been.
The problem the lack of validation was supposed to address was
that of environment variables with invalid names, which the user
may not have control over, causing a fatal error.
As an alternative, silently ignore variables with invalid names
on import from the environment.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
POSIX says, regarding execution of commands:
The execution line shall then be executed by a shell as if it
were passed as the argument to the system() interface, except
that if errors are not being ignored then the shell -e option
shall also be in effect.
As a non-POSIX extension, skip the use of the -e option. This is
how GNU make and BSD make behave.
(GitHub issue #409)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
/dev/zero and /dev/urandom are only available internally and as
arguments to 'dd'. Since users can't otherwise access them they
shouldn't be treated as existing by stat(2).
With this change stat(1) and test(1) will deny their existence.
(GitHub issue #282)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Now that putchar() is implemented using winansi_fputc() it isn't
necessary to perform an explicit substitution in 'yes'.
This was previously done so 'yes' could check for a broken pipe.
Saves 16-32 bytes.
|
| | |
| |
| |
| |
| |
| |
| | |
Allow the compiler to inline parse_meminfo() so it can spot some
optimisations.
Saves 208-240 bytes.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The undocumented '-d' shell option is used to set the current
directory in shells started by the 'su' applet of busybox-w32.
In this case, the shell isn't a login shell.
If a login shell sets the current working directory in /etc/profile
it's possible the user may wish to override this with '-d'. This
didn't work, though, because the directory is changed before
/etc/profile is processed.
Move the changing of the directory to that specified by '-d' so it
happens after the processing of /etc/profile and ~/.profile. This
won't affect the intended use of '-d'.
(GitHub issue #403)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Commit 54dbf0fa5 (time: mitigation for interleaved output) added
buffering to stderr in the 'time' applet.
@avih pointed out that it isn't necessary to provide an explicit
buffer.
Saves 16 bytes in the 64-bit build.
(GitHub issue #396)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Implement a 'title' built-in for ash. It's very simple-minded,
performs almost no error checking and is completely non-portable.
- With no arguments it prints the current console title.
- If arguments are provided the *first only* is set as the console
title.
Costs 88-116 bytes.
(GitHub issue #401)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The 'timeout' applet, by default, accepted fractional seconds but
ignored the fraction. Moreover, in busybox-w32, even the integer
part was incorrectly handled.
Rewrite the (Windows) code to fix both problems.
A patch has also been submitted to fix upstream. If that is
accepted the Windows port will need to be updated to match.
Saves 8-16 bytes.
(GitHub issue #400)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Other winansi IO wrappers, like winansi_fputs, optimize by calling
the libc API directly if no special handling is needed, e.g. if the
input is fully ASCII and without escape sequences - without converting
the output codepage or interpreting escapes.
Now the fputc and putchar wrappers do that as well.
And as a simplification, putchar is now also a wrapper of fputc.
Other than possibly minor speedup, this can also help buffered streams
remain buffered, because the codepage conversion using writeCon_utf8
is unbuffered and first flushes the stream, so by avoiding the
conversion and calling the libc API directly, we also avoid
premature flush of a buffered stream.
This did happen, as "time" is buffered since commit 54dbf0fa5, so
previously it was flushed early when using putchar, while now it
remains buffered by default (but can still be flushed early if the -f
format string contains non-ASCII chars).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
writeCon_utf8 is unbuffered - it writes directly using WriteConsoleW,
but some winansi libc IO wrappers, like fputs, use the libc API
directly if the content doesn't need any special handling (e.g. all
ASCII and no escape sequences), and so if the stream is buffered, and
if only some parts of it go through writeCon_utf8, then we can get
wrong output order due to some parts being buffered and some not.
Case in point, the recent commit 54dbf0fa5 made the output of "time"
buffered, and so if only parts of it go through writeCon_utf8, then we
get bad output order.
This did actually happen, because not all the winasi wrappers have
this ASCII-only optimization (e.g. winansi_putchar), and "time" did
end up with wrong output order. Even if all the winansi wrappers were
ASCII-optimized, "time" could still have unicode output, e.g. with -f.
Fix it by flushing the stream before converting using writeCon_utf8.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When the 'time' applet is run in a pipeline, like so:
time seq 1 10 | tail -2
stdout from 'tail' and stderr from 'time' can be interleaved.
This is particularly the case with the ConEmu terminal emulator.
The interleaving can be reduced, though not eliminated, by
buffering the output of 'time'.
Adds 40-44 bytes.
(GitHub issue #396)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The coreutils versions of md5sum and the like accept uppercase hex
strings from checksum files specified with the '-c' option.
Use a case-insensitive comparison so BusyBox does the same.
(GitHub issue #394)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
interval, in_interval_table, and in_uint16_table were previously
not compiled when using the new wcwidth (commit c188a345a) because
they're used by the old wcwidth but not by the new one.
But they're also used by the BIDI routines. mingw64u_defconfig doesn't
enable bidi (rightly - it's not working well), but it'd still be nice
to allow enabling bidi while the new wcwidth is in effect.
Enable the tables lookup code if BIDI is enabled.
|
| | |
| |
| |
| |
| |
| |
| | |
This reverts commit 878b3cd27fe83f2b0ff476b884c34d165be0072c.
It's no longer required, since the last commit uses a new wcwidth
implementation which covers the cases added by commit 878b3cd2 .
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit adds a new wcwidth implementation at libbb/wcwidth_alt.c,
and uses it instead of the existing implementation when compiling for
windows and CONFIG_LAST_SUPPORTED_WCHAR >= 0x30000 - which is the case
with the unicode configs/mingw64u_defconfig.
The windows-target condition keeps non-windows build unmodified, and
the last supported wchar threshold is a semi-hack to allow switching
between implementations without adding a new config option (the old
code supports codepoints up to 0x2ffff).
The new file wcwidth_alt.c was generated by a new scripts/mkwcwidth,
which prints a wcwidth implementation using latest unicode data from
a local clone of https://github.com/jquast/wcwidth . This repo is the
main python wcwidth implementation, and is maintained and up to date.
Functional differences from the existing implementation:
- Unicode 15.1.0 (latest) with the new version (about 450 ranges of
wide and zero-width codepoints), compared to roughly Unicode 5.0
of the existing code (nearly 20 years old spec, about 150 ranges).
The new spec includes, among others, various wide icons and emojis,
which can now be edited correctly at the shell prompt, have correct
alignment in 'ls', etc.
- The old implementation returns -1 (non-printable) for surrogates,
while the new code returns 1, though this is inconsequential, and
POSIX doesn't care. Also libc implementations vary in this regard.
Technical differences:
- The old version compiles less code/data when the last supported
wchar is smaller, while the new version doesn't. This doesn't
matter because the new version is enabled only for the full range.
- The new version is smaller and relatively straight forward, and
fully automated (generated), so updates to newer spec is trivial.
The old version mixes data, ad-hoc code (tailored to the data),
and preprocessor checks, and is hard to automate updates.
The old version has various forms of 32 and 16 bit data ranges, in
several arrays, while the new version uses single data array with
unified form of 32 bits per range, with two rules:
- A data range can't span Unicode planes (enforced, but unlikely
required, and if yes, code to split ranges would be simple).
- A range can't hold more than 32768 codepoints, so bigger ranges
are split automatically (currently there are 2 such ranges).
Performance wise, the new version should be faster, even with three
times the data ranges. Both versions do effectively at most one binary
search in one Unicode plane data, but the new version finds both
zero-width and wide-width results in this one search, while the old
version only finds zero-width, and to detect wide-width it does an
additional linear series of manual range tests, but since most results
are width 1, this sequence is performed in most (non-ASCII) calls.
In a cursory comparison of the new wcwidth with glibc and musl-libc
(both use O(1) lookup tables), with few bodies of text, we're in the
same ballpark, with typical speed of 60% or better.
Bloat-wise, the new version is about 180 bytes code and 1800 bytes
data. If it had similar number of data ranges as the old code (150),
the new version would be about 200 bytes smaller, but because the
new version has 450 data ranges, it's about 1K bigger.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Commit 26ba73098 (win32: search PATH for missing Unix-style
executables) extended the cases in which PATH would be searched
for executables specified with a Unix-style path.
A side effect of this change was to pass the Unix-style path as
argv[0] to NOFORK applets. The 'uname' applet examines argv[0]
to determine how to behave. When invoked as '/bin/uname' it
returned unexpected results. Other applets may be similarly
affected.
When a NOFORK applet is invoked in evalcommand(), strip any path.
Costs 16 bytes.
(GitHub issue #392)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
POSIX doesn't allow the '#' comment marker to be escaped, though
some implementations do.
As a non-POSIX extension allow '#' to be escaped with a preceding
backslash.
It isn't necessary to escape '#' in macro expansions or command
lines: these cases are covered by an existing extension. Commit
0aceca867 (make: comments in macro expansions and command lines)
Adds 16-32 bytes.
(pdpmake GitHub issue 38)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The previous commit unnecessarily duplicated the path returned
from resolve_symlinks(), resulting in a memory leak. Thanks to
avih for spotting this.
Even if we can't canonicalise the path in resolve_symlinks() we
can at least return the result of resolving the trailing symlink.
Moreover, this can be done both when the necessary API is missing
and when the filesystem doesn't support it.
Not perfect, but better than nothing, and there's no cost.
This change gets rid of a handful of realpath-related test failures
on ReactOS and Windows XP.
Some background:
Commit 8ebe81483 returned the raw path when the required API was
missing. This was reverted in commit f902184fa because it caused
an infinite loop (GitHub issue #204). Commit 31467ddfc fixed the
cause of the loop, which is why it's now safe to reintroduce a
fallback return.
(GitHub commit #389)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some filesystems don't support the feature required to resolve
symlinks for realpath(3).
In such cases just carry on without resolving symlinks. This is
a trade-off between correctness and convenience.
Adds 16 bytes.
(GitHub issue #389)
|
| | |
| |
| |
| |
| |
| | |
Ensure memory is freed even on early exit.
Saves 0-16 bytes.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Certain tools which allow disk image files and RAM disks to be
mounted were found to lack a feature used to implement realpath(3).
This resulted in a segfault in the 'su' applet when it was run in
such a virtual filesystem.
'su' uses realpath(3) to canonicalise the current directory. This
is only really required to handle network shares mapped to a drive
letter. (GitHub issue #148)
- If the call to realpath(3) fails for some reason fall back to
using the current directory determined by calling getcwd(3).
- If getcwd(3) fails simply don't pass any directory to the shell
being started by 'su'.
Also, ensure all allocated memory is freed, if required.
(GitHub issue #389)
Adds 16-32 bytes.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Commits 8e6991733 and b2901ce8e fixed problems with the 'read'
shell built-in when the '-t' option was used. However, they
result in a performance penalty. This pipeline:
seq -w 0 999999 | while read line; do :; done
takes 10 times longer than prior to the changes.
If no timeout is specified don't call poll(2).
Costs 16 bytes in a 32-bit build; 0 in 64-bit.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There's an upstream bug report:
https://bugs.busybox.net/show_bug.cgi?id=15679
that if BusyBox is built for x86_64 with gcc and the use of OpenSSL
for wget is disabled, failures ensue. A similar issue also affects
the busybox-w32 build with the comparable configuration.
The problem appears to be in the assembly code for the function
sp_256_sub_8_p256_mod(), as forcing the use of the provided C code
seems to fix both upstream and busybox-w32. Since my knowledge of
x64_64 assembler is non-existent, someone else will need to determine
the actual issue. For the moment, just avoid the faulty code.
Saves 32 bytes in the 64-bit build.
(GitHub issue #263)
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Older versions of mingw don't define PROCESSOR_ARCHITECTURE_ARM64.
Don't let this stop the build.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Commit 992387539 (build system: more clang/llvm tweaks) added a
test in scripts/Makefile.build which used the intcmp function.
This isn't present in GNU make prior to 4.4.
Rewrite the test so it works with older versions of GNU make.
|
