Symlinks in a subdirectory that is to become target rootfs are sometimes
dangling because they link to canonical file names that are not present
on the host, but are present relative to the target rootfs root. Don't
copy over dangling symlinks when noclobber is enabled
The -e test treats dangling symlinks as non-existent files. Add -h test
that returns true for all symlinks.
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Was printing initial "+" prefix for the assignment, that printing
"+ cmd"
then printing the expanded " v=VAL" string.
Delay printing of "+" prefix for the assignment to after expansion.
function old new delta
run_pipe 1883 1902 +19
builtin_eval 127 133 +6
expand_vars_to_list 1103 1106 +3
dump_cmd_in_x_mode 144 142 -2
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 3/1 up/down: 28/-2) Total: 26 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The n > 0 check to prevent access to the last byte of non-existing argv[-1]
wasn't enough. Switched to making sure there are initialized (zero) bytes there.
A predictable testcase is rather hard to construct, unfortunately,
contents of memory depends on allocator behavior and whatnot.
function old new delta
o_save_ptr_helper 119 137 +18
expand_on_ifs 345 339 -6
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/1 up/down: 18/-6) Total: 12 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This means we'll start correcting frequency ~5 minutes after start,
not ~3.5 ones.
With previos settings I still often see largish ~0.7s initial offsets
only about 1/2 corrected before frequency correction kicks in,
resulting in ~200ppm "correction" which is then slowly undone.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
= display default is no longer in cylinders
= +sizeC is no longer supported
= add +sizeT suffix - terabytes are here
= K,M,G,T and k,m,g,t suffixes all are binary, not decimal
= +sizeM results in last sector +(size * 1Mbyte - 1), not +(size * 1Mbyte)
= fix comparison to "YES" answer for sgi/sun
function old new delta
read_int 492 519 +27
fdisk_main 2644 2640 -4
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/1 up/down: 27/-4) Total: 23 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This necessitates switch from libc FILE api to a simple
homegrown replacement.
The change which fixes the bug here is the deleting of
restore_redirected_FILEs();
line. It was prematurely moving (restoring) script fd#3.
The fix is: we don't even _want_ to restore scrit fds,
we are perfectly fine with them being moved.
The only reason we tried to restore them is that FILE api
did not allow moving of FILE->fd.
function old new delta
refill_HFILE_and_getc - 93 +93
hfopen - 90 +90
hfclose - 66 +66
pseudo_exec_argv 591 597 +6
hush_main 1089 1095 +6
builtin_source 209 214 +5
save_fd_on_redirect 197 200 +3
setup_redirects 320 321 +1
fgetc_interactive 235 236 +1
i_peek_and_eat_bkslash_nl 99 97 -2
expand_vars_to_list 1103 1100 -3
restore_redirects 99 52 -47
fclose_and_forget 57 - -57
remember_FILE 63 - -63
------------------------------------------------------------------------------
(add/remove: 3/2 grow/shrink: 6/3 up/down: 271/-172) Total: 99 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
"Go to:" command was not updating row position, making next "down" movements
for one screenful print empty lines instead of showing the contents.
If the file is whole pages long, "down" movement at EOF was advancing position
+16 bytes, mapping the next portion (entirely past the end of the file),
then finding out that the new position is beyond the EOF, rolling it back
-16 bytes... ending up with this postion pointing *before* the mapped portion.
Any next access (e.g. "move right" key) SEGVs.
function old new delta
hexedit_main 1170 1184 +14
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
o_free() made o_string NULL-initialized,
o_free_unsafe() did not bother reinitializing (expected caller to not need it).
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This wasn't an ash bug in dollar_altvalue9, it was hush bug (and bash!)
function old new delta
expand_one_var 2236 2254 +18
expand_vars_to_list 1097 1103 +6
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 24/0) Total: 24 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
ash might be a bit buggy, need to investigate dollar_altvalue9 test
function old new delta
expand_one_var 1639 2236 +597
expand_variables 112 128 +16
expand_vars_to_list 1117 1097 -20
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/1 up/down: 613/-20) Total: 593 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This is necessary since expand_one_var() for ${var:+ARG} must create more than one
output word, and thus can't simply return a char*.
function old new delta
expand_one_var 1610 1643 +33
expand_vars_to_list 1139 1125 -14
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/1 up/down: 33/-14) Total: 19 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Go over the string only once.
function old new delta
encode_then_expand_string 126 105 -21
encode_then_expand_vararg 443 399 -44
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-65) Total: -65 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
