Age | Commit message (Collapse) | Author |
|
The -u option is supposed to be allowed to appear multiple times; the
option string supplied to getopt32long requires it to be followed by a
nonnegative integer.
Reported-by: Keith Maxwell <keith.maxwell@gmail.com>
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
packed_usage 31863 31853 -10
tar_main 1013 1002 -11
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-21) Total: -21 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
tar_main 994 1013 +19
packed_usage 31893 31863 -30
writeTarFile 250 207 -43
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/2 up/down: 19/-73) Total: -54 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Eugene Rudoy <gene.devel@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Original Info-ZIP's unzip uses unstripped filenames
while doing content listing and filtering, i.e.
- in content listing mode -j is ignored completely
- filtering is applied to non-stripped names, -j
takes effect first while extracting the files
997ad2c64abbe931dffa3598b015c5de04e515cf strips path
components a little bit too early resulting in behavior
deviations.
Fix it by doing stripping after listing/filtering.
p.s. Info-ZIP's unzip behavior is the same as
that of tar in --strip-components=NUM mode
Signed-off-by: Eugene Rudoy <gene.devel@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
add_match 41 68 +27
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
listvars 144 252 +108
evalcommand 1500 1546 +46
showvars 142 147 +5
shellexec 242 245 +3
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 4/0 up/down: 162/0) Total: 162 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
init_main 695 712 +17
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Reworks "ash: [VAR] Sanitise environment variable names on entry"
commit.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
ntpd_main 1177 1197 +20
resolve_peer_hostname 127 129 +2
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
When grep is passed -r, recursive_action will treat any symlinks to
directories not in the root as normal files, since it lstat's them and
is therefore told they are not directories. However, file_action_grep
will still try to fopen and read from them to see whether they match,
which varies in behaviour across platforms. Linux will give EISDIR and
thus grep will not find any matching lines, but FreeBSD will give the
raw contents of the directory itself, which may match the given pattern.
Also, if grep is passed -c, it will even print a count for these
symlinks, even on Linux.
Since this recursive_action behaviour is required for the correct
functioning of other applets, such as tar, grep should handle this
special case and skip any such symlinks.
function old new delta
file_action_grep 80 161 +81
Signed-off-by: James Clarke <jrtc27@jrtc27.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
ntpd_main 1106 1177 +71
resolve_peer_hostname 122 127 +5
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 76/0) Total: 76 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
The current standard (RFC 3542) is for IPV6_RECVPKTINFO to be given to
setsockopt, and IPV6_PKTINFO to be used as the packet type. Previously,
RFC 2292 required IPV6_PKTINFO to be used for both, but RFC 3542
re-purposed IPV6_PKTINFO when given to setsockopt. The special
Linux-specific IPV6_2292PKTINFO has the same semantics as IPV6_PKTINFO
in RFC 2292, but was introduced at the same time as IPV6_RECVPKTINFO.
Therefore, if we have IPV6_RECVPKTINFO available, we can use the RFC
3542 style, and if not, we assume that only the RFC 2292 API is
available, using IPV6_PKTINFO for both.
Signed-off-by: James Clarke <jrtc27@jrtc27.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Platforms differ on what their implementations of statfs include.
Importantly, FreeBSD's does not include a f_frsize member inside struct
statfs. However, statvfs is specified by POSIX and includes everything
we need, so we can just use that instead.
Signed-off-by: James Clarke <jrtc27@jrtc27.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: James Clarke <jrtc27@jrtc27.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: James Clarke <jrtc27@jrtc27.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: James Clarke <jrtc27@jrtc27.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Bad case: send request to server1good.com; then try to resolve server2bad.com -
this fails, and failure takes ~5 secs; then receive server1's
response 5 seconds later. We'll never sync up in this case...
function old new delta
ntpd_main 1079 1106 +27
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
iproute.c: In function 'print_route':
iproute.c:85:9: error: 'RTA_TABLE' undeclared (first use in this function)
iproute.c:85:9: note: each undeclared identifier is reported only once for each function it appears in
iproute.c: In function 'iproute_modify':
iproute.c:467:36: error: 'RTA_TABLE' undeclared (first use in this function)
Fix it by partially #ifdef'ing the code added in b42107f21538e39d9a344376372f8261aed589b2
Signed-off-by: Eugene Rudoy <gene.devel@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Based on patch by Eugene Rudoy <gene.devel@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
This particular corrupted file can be dealth with by using "unsigned".
If there will be cases where it genuinely overflows, there is a disabled
code to deal with that too.
function old new delta
get_next_block 1678 1667 -11
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
parse_stream 2692 2690 -2
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Markus Gothe <nietzsche@lysator.liu.se>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
expandstr 120 209 +89
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
This patch only affects prompts with newlines.
We redraw the prompt [+ input] occasionally, e.g. during tab completion,
history browsing or search, etc, and we expect it to align with prior
redraws, such that the visible effect is that only the input changes.
With multi-line PS1, redraw always printed the prompt some lines below
the old one, which resulted in terminal scroll during every redraw.
Now we only redraw the last PS1 line, so vertical alignment is easier to
manage (we already calculated it using only the last line, but re-drew
all lines - that was the culprit), which fixes those extra scrolls.
Notes:
- We now use the full prompt for the initial draw, after clear-screen (^L),
and after tab-completion choices are displayed. Everything else now
redraws using the last/sole prompt line.
- During terminal resize we now only redraw the last[/sole] prompt line,
which is arguably better because it's hard to do right (and we never did).
- Good side effect for reverse-i-search: its prompt now replaces only the
last line of the original prompt - like other shells do.
function old new delta
put_prompt_custom - 66 +66
draw_custom - 66 +66
parse_and_put_prompt 766 806 +40
read_line_input 3867 3884 +17
input_tab 1069 1076 +7
cmdedit_setwidth 61 63 +2
redraw 59 47 -12
put_prompt 46 - -46
------------------------------------------------------------------------------
(add/remove: 2/1 grow/shrink: 4/1 up/down: 198/-58) Total: 140 bytes
Signed-off-by: Avi Halachmi <avihpit@yahoo.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
parse_cached_kb - 85 +85
free_main 580 537 -43
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 0/1 up/down: 85/-43) Total: 42 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
It's not clear at all why we do it twice. git archaeology did not help.
function old new delta
date_main 836 839 +3
maybe_set_utc 16 - -16
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
When 'i' or 's' modes are selected block array is filled from offset 3
(blen = 3) but copied to data.block buffer from offset 0 so first 3 bytes
contains garbage from stack.
The buffer that is sent is also 3 bytes too long due to those extra 3
bytes.
Signed-off-by: Avi Fishman <AviFishman70@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
out 85 75 -10
udhcpd_main 1472 1461 -11
open_stdio_to_tty 98 85 -13
init_exec 245 232 -13
udhcpc_main 2763 2749 -14
do_cmd 4771 4755 -16
status_line_bold_errno 32 14 -18
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/7 up/down: 0/-95) Total: -95 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
be bogus
With new code, we request that target IP (server ID) must be directly reachable.
If it's not, this happens:
udhcpc: waiting 2000 seconds
udhcpc: entering listen mode: kernel
udhcpc: opening listen socket on *:68 wlan0
udhcpc: entering renew state
udhcpc: sending renew to 1.1.1.1
udhcpc: send: Network is unreachable
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1.1.1.1 needs routing, this is fishy!
udhcpc: entering rebinding state
udhcpc: entering listen mode: raw
udhcpc: created raw socket
udhcpc: sending renew to 0.0.0.0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ going to use broadcast
which is the desired behavior. Before the patch, packet to 1.1.1.1 was routed
over eth0 (!) and maybe even into Internet (!!!).
function old new delta
udhcpc_main 2752 2763 +11
udhcp_send_kernel_packet 295 301 +6
send_renew 82 84 +2
send_packet 166 168 +2
bcast_or_ucast 23 25 +2
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 5/0 up/down: 23/0) Total: 23 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
I see random field values like sll_hatype=0x267 when I strace.
They seem to not matter, but just in case they sometimes do,
let's at least have deterministic values (via memset(0)).
function old new delta
change_listen_mode 308 322 +14
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|