ping^2
On 4/15/18 8:25 PM, Harald van Dijk wrote:
ping
FWIW, this problem actually came up with an archive containing a fsroot
including a busybox installation again, but this time, the archive was
created after a deduplication step had hardlinked identical files and
symlinks.
On 4/1/18 1
On 18/02/2018 21:01, Denys Vlasenko wrote:
Bug 10651 - tar: check for unsafe symlinks is overly strict
https://bugs.busybox.net/show_bug.cgi?id=10651
| (In reply to Harald van Dijk from comment #6)
| 1: Keep the current check, but modify it to allow all symlinks to
files to be extracted.
(1
t fails criteria (b).
You wrote "it can be achieved just by looking at names", but that's not
enough here: you have to know that a/a/a is actually b/a, so only one
level deep in the -C directory, to know that ../../c points outside the
-C directory.
On 19/02/2018 17:15, Denys Vlasenko wrote:
On Mon, Feb 19, 2018 at 5:09 PM, Harald van Dijk <har...@gigawatt.nl> wrote:
Let's also brainstorm option 3:
Allow symlinks which
(a) start with one or more "../";
(b) never end up on a higher level of directory tree:
"../dir/..&q
ping
FWIW, this problem actually came up with an archive containing a fsroot
including a busybox installation again, but this time, the archive was
created after a deduplication step had hardlinked identical files and
symlinks.
On 4/1/18 1:37 PM, Harald van Dijk wrote:
When the creation
mostly
reverts b920a38d, re-introduced when a84db18f mostly reverts b920a38d.
0cf64c8b was between b920a38d and bc9bbeb2, so that's why you saw the
bug in there too.
Cheers,
Harald van Dijk
___
busybox mailing list
busybox@busybox.net
http://lists.bus
are
relatively rare, I guess the benefit of such an optimisation would be
small, but I am not really qualified to make that determination.
Test case:
>a
ln -s a b
ln b c
mkdir new
tar cf - a b c | tar -C new -xf -
Cheers,
Harald van Dijk
diff --git a/archival/cpio.c b/archival/cpi
On 3/31/18 9:09 PM, Harald van Dijk wrote:
Test case:
>a
ln -s a b
ln b c
mkdir new
tar cf - a b c | tar -C new -xf -
Apologies...
This is a botched test case. Because this doesn't actually delay the
symlink creation, I didn't notice the delayed symlink handling creat
a hardlink "parent/exploit -> exploit", the presence of that
hardlink causes "parent" to be immediately created as a regular
directory. The symlink creation "parent -> .." will therefore fail. This
could use careful review though.
Cheers,
Harald van Dijk
diff --git
Schwartz's response is, if he chooses to send one.
Cheers,
Harald van Dijk
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
of busybox, or it will reveal that the
issues that Rust is designed to prevent do not exist in busybox,
increasing the confidence in busybox.
Cheers,
Harald van Dijk
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
_ASH_CMDCMD, whether by
moving the #endif up one line or adding an #else. Without that, you get
an infinite loop as seen with e.g. ash -c true.
Cheers,
Harald van Dijk
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
'wait "$!"'.
Nice test. bash leaves the process in a state where SIGCHLD is blocked,
and the various ash-based shells do not unblock it. Because of that,
they do not pick up on the fact that the child process has terminated. I
would consider this a bug both in bash and in the ash
ssuming NetBSD sh is not still
susceptible to one of those race conditions, the fix for it in the other
shells would seem to be more complicated than necessary, and simplifying
things would be good.
Cheers,
Harald van Dijk
___
busybox mailing
)), \
default: (last_char_is) ((s), (c
But considering busybox uses standard library functions with the same
problem throughout the codebase, fixing it just for last_char_is while
leaving alone all other functions may not be worth the effort.
Cheers,
Harald van Dijk
of man does support this form as well. It supports
three forms of specifying the section, which all do the same thing:
man 7 man
man man.7
man 'man(7)'
Cheers,
Harald van Dijk
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net
ecutes `read a b` in a subshell environment, but lets the
following commands that use $a and $b also execute in that same subshell
environment. This workaround can be used when the following commands do
not need to read from the original stdin.
Cheers,
Harald van Dijk
___
box be modified to do that as well?
Tested with busybox 1.33.1.
Cheers,
Harald van Dijk
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
On 26/06/2021 00:36, Harald van Dijk wrote:
Hi,
tar --exclude results in bad archives when hardlinks are used. Consider
the following:
$ mkdir tartest
$ echo hello > tartest/a
$ ln tartest/a tartest/b
$ busybox tar cf - tartest | tar tvf -
drwxr-xr-x harald/harald 0 2
This was a rather misguided reply: busybox already has a TLS
implementation. It can either use its extremely minimal implementation,
good enough to send and receive data but not good enough to perform any
validation, or it can spawn a helper process that calls openssl to
handle TLS. These are
On 22/08/2021 00:31, Roberto A. Foglietta wrote:
Il giorno sab 21 ago 2021 alle ore 23:33 Harald van Dijk
mailto:har...@gigawatt.nl>> ha scritto:
Hi again,
Another bug: the exit status is not preserved.
Consider
busybox ash -c 'trap "echo ERR"
Hi,
Replying to the new thread as requested.
About the global LINENO: having thought about it more, I don't think it
makes sense to special-case trap actions. This is something that should
be done for all evalstring() calls that are performed when an outer
context has already set LINENO. In
On 20/08/2021 13:48, Roberto A. Foglietta wrote:
Il giorno ven 20 ago 2021 alle ore 14:05 Harald van Dijk
mailto:har...@gigawatt.nl>> ha scritto:
Hi,
Replying to the new thread as requested.
About the global LINENO: having thought about it more, I don't think it
makes
On 23/08/2021 10:09, Roberto A. Foglietta wrote:
Il giorno lun 23 ago 2021 alle ore 10:45 Harald van Dijk
mailto:har...@gigawatt.nl>> ha scritto:
On 23/08/2021 09:16, Roberto A. Foglietta wrote:
> IMHO, syntax error should be an exit condition either.
I would not have
On 22/08/2021 01:23, Harald van Dijk wrote:
On 22/08/2021 00:31, Roberto A. Foglietta wrote:
Il giorno sab 21 ago 2021 alle ore 23:33 Harald van Dijk
mailto:har...@gigawatt.nl>> ha scritto:
I am also somewhat concerned that there may be cases where the global
variables &quo
On 23/08/2021 09:16, Roberto A. Foglietta wrote:
IMHO, syntax error should be an exit condition either.
I would not have a problem with you changing the shell to ensure syntax
errors always terminate (though I cannot speak for others), but the
problem is not limited to syntax errors, so that
On 24/08/2021 11:10, Roberto A. Foglietta wrote:
Thanks again for your insightfulness.
I reverted back to the previous situation when I was resetting the
recursive flag when the evaltree returns:
- if evaltree returns: no problem
- before an not-exit not-returning exception is raised, it
so:
<https://github.com/hvdijk/gwsh/commit/2d4e35cdb4728cfa6de1b8a297ecbd7143fb2d08>.
The commit message shows the effects of the commit, and I think that
matches what you would like to see. If this commit is of interest to
busybox, feel free to use it.
Cheers,
Harald va
?
Cheers,
Harald van Dijk
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
On 20/08/2021 16:31, Roberto A. Foglietta wrote:
Il giorno ven 20 ago 2021 alle ore 16:36 Harald van Dijk
mailto:har...@gigawatt.nl>> ha scritto:
cat >shrc <Please Harald, explain to me the syntax of this case because it is
unusual for me.
Especially what's supposed to
On 20/08/2021 15:14, Roberto A. Foglietta wrote:
Il giorno ven 20 ago 2021 alle ore 15:21 Harald van Dijk
mailto:har...@gigawatt.nl>> ha scritto:
Hi,
Please note the "when an outer context has already set LINENO"
qualification :) busybox does have one call to e
Hi,
In bash, the ERR trap is documented as triggering in under the exact
same conditions that 'set -e' would cause the shell to abort. This is
not what you have implemented, you have implemented it as triggering
whenever a simple command returns non-zero. Consider:
trap "echo ERR" ERR
cleared, preventing future ERR
handlers from running. I do not currently have a test case where it
matters, but am not convinced there are no test cases where it matters.
On 21/08/2021 15:36, Roberto A. Foglietta wrote:
Il giorno sab 21 ago 2021 alle ore 14:38 Harald van Dijk
mailto:har...@giga
On 23/08/2021 11:50, Roberto A. Foglietta wrote:
Il giorno lun 23 ago 2021 alle ore 11:15 Harald van Dijk
mailto:har...@gigawatt.nl>> ha scritto:
On 23/08/2021 10:09, Roberto A. Foglietta wrote:
> Il giorno lun 23 ago 2021 alle ore 10:45 Harald van Dijk
>
time 'exit 1' is run the 'cat' command has
stopped, the shell does not detect this. bash, ksh, yash do pick up on
it and prevent the shell from exiting. (zsh is special and notifies that
cat was suspended as it happens.)
Cheers,
Harald van Dijk
___
bus
d be clear that this is not some NFC code cleanup, this will
have an impact on how the shell behaves.
Cheers,
Harald van Dijk
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
On 14/09/2021 17:06, Roberto A. Foglietta wrote:
Il giorno mar 14 set 2021 alle ore 18:01 Harald van Dijk
ha scritto:
On 14/09/2021 11:24, Denys Vlasenko wrote:
On Tue, Sep 14, 2021 at 10:04 AM Roberto A. Foglietta
wrote:
Il giorno dom 12 set 2021 alle ore 18:55 Roberto A. Foglietta
ha
,
Harald van Dijk
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
On 27/06/2021 15:15, Harald van Dijk wrote:
On 26/06/2021 00:36, Harald van Dijk wrote:
Hi,
tar --exclude results in bad archives when hardlinks are used.
Consider the following:
$ mkdir tartest
$ echo hello > tartest/a
$ ln tartest/a tartest/b
$ busybox tar cf - tartest |
and if so,
which one. Especially the second one will likely have opportunities to
clean up and reduce code size by making sure subtype is already set to
VSNUL at this point, rather than 0, meaning it does not need to be
patched up here.
Cheers,
Harald van Dijk
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
'\n'.
&"\n"[1] is a pointer to the second element of this array, the null
character, meaning it is a null string and printing it has no effect.
This is different from the approach you were taking: printing '\0' with
%c results in the output of a null byte. You would not see this null
e fact that the + operator is overloaded in C++ to concatenate
strings, and despite the fact that this is not C++, might expect it to
do the same here, whereas &"\n"[opt & 1] indicates clear intent on the
programmer's part. Whether busybox agrees with this rationale is up to
42 matches
Mail list logo
