On 12/29/18 5:44 PM, Peng Yu wrote:
>> That code hasn't really changed in almost twenty years. All the testing
>> was done long ago.
>
> Do you keep all the testing code in the bash repository?
Yes. The test suite exists in the tests subdirectory.
> Given the fugal
> testing code that is in the
I have the full picture now. Thank you all for your feedback!
On 12/30/18 8:36 PM, mike b wrote:
> Bash Version: 4.4
> Patch Level: 12
> Release Status: release
>
> I am not quite sure if this is a bug, but here's what I find as a bit odd
> behavior:
It's not odd.
> # modprobe zram num_devices=0
> # exec {add} # read -r id <&"$add"; echo "$id"
> 0
> # rea
On 12/28/18 4:24 AM, Ole Tange wrote:
> On Sun, Dec 16, 2018 at 6:41 AM Eduardo Bustamante wrote:
> :
>> You know no one is stopping you from submitting a patch to actually
>> fix the documentation right? (or maybe, you know, submitting an actual
>> working patch to change the random generator, no
On 12/31/18 12:37 PM, Martijn Dekker wrote:
> You'd think that establishing a pipe between two processes is a very basic
> UNIX feature that should work reliably on all UNIX variants.
>
> But the following script seems to break consistently on Solaris and
> variants (SunOS kernels) when executed b
You'd think that establishing a pipe between two processes is a very
basic UNIX feature that should work reliably on all UNIX variants.
But the following script seems to break consistently on Solaris and
variants (SunOS kernels) when executed by bash, ksh93, or dash. All it
does is make 100 FI
On Sun, Dec 30, 2018 at 8:37 PM mike b wrote:
> Configuration Information:
> 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/sh
That's a good point, I haven't thought about it like this. I always thought
that each read always starts at the beginning of the file given fd points
at. So the fact that it changes offset is a bit surprising:
# echo word >t
# exec {in}
napisał(a):
> On Mon, Dec 31, 2018 at 2:37 AM mike b wrote:
On Mon, Dec 31, 2018 at 2:37 AM mike b wrote:
[...]
> The above is just an example. Doing reads on any other regular file like
> this yields same behavior:
> # echo bla >./t
> # exec 10<./t
> # read -r <&10
> # echo $REPLY
> bla
> # read -r <&10
> # echo $REPLY
That's correct behavior because t
On 12/30/18 6:42 PM, Peng Yu wrote:
>> Yes, dirname should skip over a `--' denoting the end of options. Thanks
>> for the report.
>
> There is a similar problem in `basename`. Is it due to a common bug on
> how loadables are programmed?
Not really. It's because the two files started with a comm
On 12/30/18 8:09 AM, Peng Yu wrote:
> Hi,
>
> I see things like `cd builtins && $(MAKE) ...` in the Makefiles in
> bash source code. GNU Make has the option of -C for entering a
> directory and make. Is the reason to cd then make for compatibility
> with other make's that don't support -C? Thanks.
11 matches
Mail list logo
