Hello Ilkka, hello *!
> Bash's echo is a builtin, so using it doesn't involve an execve().
Sure – but while passing a string (however it will be encoded) containing a
null byte to builtins would be possible in principle (as zsh shows) this would
lead to a large bunch of problems, e.g. another
Le 17/01/2021 à 22:02, Chet Ramey écrivait :
On 1/17/21 3:05 PM, h...@artax.karlin.mff.cuni.cz wrote:
Description:
Command
echo $'\0' |od -c
writes
000 \n
001
in contrast to
echo $'\1' |od -c
000 001 \n
002
The
On Mon, Jan 18, 2021 at 12:02 AM Martin Schulte
wrote:
> To be exact, this is already caused by a Unix Kernel - strings passed by
> the exex* system calls are null terminated, too. As it is the default in
> the C programming language. Thus you can't pass a null byte in an argument
> when
On 1/17/21 3:05 PM, h...@artax.karlin.mff.cuni.cz wrote:
Description:
Command
echo $'\0' |od -c
writes
000 \n
001
in contrast to
echo $'\1' |od -c
000 001 \n
Hello Hans, hello Eduardo!
> On Sun, Jan 17, 2021 at 12:05 PM wrote:
> > (...)
> > The nul byte is not echoed by $'\0'.
>
> This is expected. Bash uses NUL-byte terminated character sequences to
> store strings, so it can't actually store NUL bytes themselves.
To be exact, this is
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale'
On Sun, Jan 17, 2021 at 12:05 PM wrote:
> (...)
> The nul byte is not echoed by $'\0'.
This is expected. Bash uses NUL-byte terminated character sequences to
store strings, so it can't actually store NUL bytes themselves.
$'\0' is the same as '' (i.e. an empty string).
If you want to
