On Fri, Jan 22, 2021 at 8:53 AM Eduardo A. Bustamante López
wrote:
> These are worth highlighting:
>
> - Notice that the value returned by `fstat(0, ...)' indicates that /dev/null
> in your system is a *regular* file (it should be `st_mode=S_IFCHR|0666', but
> instead it is `st_mode=S_IFCHR|0666
On Wed, Jan 9, 2019 at 3:04 PM Chet Ramey wrote:
>
> On 1/9/19 4:11 AM, Tadeus Prastowo wrote:
> > Hi Chet,
> >
> > It seems to me that Bash does not require copyright assignment for
> > contributed patches, unlike GCC and Emacs. Is that true?
>
> I rarely get
Hi Chet,
It seems to me that Bash does not require copyright assignment for
contributed patches, unlike GCC and Emacs. Is that true?
If that is so, how do you manage the copyright issue? Do you do it by
never accepting a patch as it is but only capturing the idea behind
the patch and re-impleme
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 Tue, Aug 21, 2018 at 10:32 PM, don fong wrote:
> wouldn't it be less confusing if the proposed built-in sleep function were
> given a new name instead of overloading "sleep"?
That will complicate the migration effort for people who want to
switch to using the built-in sleep, no?
--
Best regar
On Tue, Apr 10, 2018 at 1:32 AM, L A Walsh wrote:
>
> How about the below, suggested wording replacing these 2 paragraphs:
>
>A list is a sequence of one or more pipelines separated by one of the
>operators ;, &, &&, or ||, and optionally terminated by one of ;, &, or
>.
>
>Of th
On Fri, Jan 26, 2018 at 5:08 PM, Chet Ramey wrote:
> On 1/26/18 10:56 AM, Tadeus Prastowo wrote:
>> Ping :)
>
> I'll add something in the next devel branch push.
Thank you in advance for fixing Bash doc. Have a nice weekend!
> --
> ``The lyf so short, the craft so
Ping :)
-- Forwarded message --
From: Tadeus Prastowo
Date: Wed, Jan 24, 2018 at 7:52 PM
Subject: Re: coproc FDs (file descriptors) available to subshells
To: chet.ra...@case.edu
Cc: bug-bash@gnu.org
On Wed, Jan 24, 2018 at 7:32 PM, Tadeus Prastowo
wrote:
> On Wed, Jan 24, 2
On Wed, Jan 24, 2018 at 7:32 PM, Tadeus Prastowo
wrote:
> On Wed, Jan 24, 2018 at 5:51 PM, Tadeus Prastowo
> wrote:
>> On Wed, Jan 24, 2018 at 3:55 PM, Tadeus Prastowo
>> wrote:
[...]
>>> Okay, I will propose a patch.
>>
>> diff --git a/doc/bashref.t
On Wed, Jan 24, 2018 at 5:51 PM, Tadeus Prastowo
wrote:
> On Wed, Jan 24, 2018 at 3:55 PM, Tadeus Prastowo
> wrote:
>> On Wed, Jan 24, 2018 at 3:53 PM, Chet Ramey wrote:
>>> On 1/24/18 9:50 AM, Tadeus Prastowo wrote:
>>>> On Wed, Jan 24, 2018 at 3:16 PM, Chet Ra
On Wed, Jan 24, 2018 at 3:55 PM, Tadeus Prastowo
wrote:
> On Wed, Jan 24, 2018 at 3:53 PM, Chet Ramey wrote:
>> On 1/24/18 9:50 AM, Tadeus Prastowo wrote:
>>> On Wed, Jan 24, 2018 at 3:16 PM, Chet Ramey wrote:
>>>> On 1/24/18 3:38 AM, Tadeus Prastowo wrote:
On Wed, Jan 24, 2018 at 3:16 PM, Chet Ramey wrote:
> On 1/24/18 3:38 AM, Tadeus Prastowo wrote:
>> Hi!
>>
>> To quote
>> https://www.gnu.org/software/bash/manual/html_node/Coprocesses.html#Coprocesses
>>
>> "The file descriptors are not available in
Hi!
To quote
https://www.gnu.org/software/bash/manual/html_node/Coprocesses.html#Coprocesses
"The file descriptors are not available in subshells."
So, that is my expectation. However, the following Bash fails me:
Configuration Information [Automatically generated, do not change]:
Machine: x86
13 matches
Mail list logo
