On 7/6/20 9:45 PM, Dale R. Worley wrote:
> bug-b...@trodman.com writes:
>> foo | tee >(cat >&2) | bar
>
> I do wonder how portable >( ... ) is in practice, versus the portability
> of /dev/stderr.
It's portable in the sense that it's available wherever bash is.
--
``The lyf so short, the
On Tue, Jul 07, 2020 at 07:41:51AM -0400, Greg Wooledge wrote:
> On Mon, Jul 06, 2020 at 09:45:59PM -0400, Dale R. Worley wrote:
> > bug-b...@trodman.com writes:
> > > foo | tee >(cat >&2) | bar
> >
> > I do wonder how portable >( ... ) is in practice, versus the portability
> > of /dev/stderr
On Mon, Jul 06, 2020 at 09:45:59PM -0400, Dale R. Worley wrote:
> bug-b...@trodman.com writes:
> > foo | tee >(cat >&2) | bar
>
> I do wonder how portable >( ... ) is in practice, versus the portability
> of /dev/stderr. Maybe I worry about the former because I'm not
> practiced in named-FIFO
bug-b...@trodman.com writes:
> foo | tee >(cat >&2) | bar
I do wonder how portable >( ... ) is in practice, versus the portability
of /dev/stderr. Maybe I worry about the former because I'm not
practiced in named-FIFO programming and so think of it as non-universal.
Dale
On Mon, Jul 06, 2020 at 03:03:15PM +0300, Ilkka Virta wrote:
> On 6.7. 14:37, Greg Wooledge wrote:
> > On Sat, Jul 04, 2020 at 01:42:00PM -0500, bug-b...@trodman.com wrote:
> > > but your soln is simplier. I assume /dev/stderr is on non linux UNIX
> > > also.
> >
> > It is *not*. It is not porta
On 6.7. 14:37, Greg Wooledge wrote:
On Sat, Jul 04, 2020 at 01:42:00PM -0500, bug-b...@trodman.com wrote:
but your soln is simplier. I assume /dev/stderr is on non linux UNIX
also.
It is *not*. It is not portable at all.
It works on macOS and I see mentions of it in man pages of the variou
On Sat, Jul 04, 2020 at 01:42:00PM -0500, bug-b...@trodman.com wrote:
> On Fri 7/3/20 14:03 -0400 =?utf-8?Q?Lawrence_Vel=C3=A1zquez?= wrote:
> >What's wrong with `foo | tee /dev/stderr | bar`?
>
> but your soln is simplier. I assume /dev/stderr is on non linux UNIX
> also.
It is *not*. It is no
Hi Lawrence:
On Fri 7/3/20 14:03 -0400 =?utf-8?Q?Lawrence_Vel=C3=A1zquez?= wrote:
>What's wrong with `foo | tee /dev/stderr | bar`?
Perfect!
This morning I had thought of
foo | tee >(cat >&2) | bar
but your soln is simplier. I assume /dev/stderr is on non linux UNIX
al
Le 05/06/2017 14:06, Eric Blake a écrit :
On 06/04/2017 11:39 AM, Nicola Spanti wrote:
Hi.
I used that:
cppcheck --verbose --quiet --enable=all --force --language=c --std=c89 .
I fixed some errors that were reported by cppcheck. I published that on
GitLab.com.
https://gitlab.com/RyDroid/bash
On 06/04/2017 11:39 AM, Nicola Spanti wrote:
> Hi.
>
> I used that:
> cppcheck --verbose --quiet --enable=all --force --language=c --std=c89 .
>
> I fixed some errors that were reported by cppcheck. I published that on
> GitLab.com.
> https://gitlab.com/RyDroid/bash
>
> The git remote is: https:
Hi.
I used that:
cppcheck --verbose --quiet --enable=all --force --language=c --std=c89 .
I fixed some errors that were reported by cppcheck. I published that on
GitLab.com.
https://gitlab.com/RyDroid/bash
The git remote is: https://rydr...@gitlab.com/RyDroid/bash.git
The branch is cppcheck-f
Also, I just wanted to send out a thanks to Chet Ramey and everyone
else that has contributed to bash. I am a bash junkie and use it
every day. Not only is bash my primary interactive shell, it is also
the scripting language that I write many of my programs in... and it
glues together many of
On 2/1/11 3:52 AM, Marc Herbert wrote:
Is it a problem? Bash prints messages about signal-terminated processes --
>>>
Most people want to know when their jobs die
>>>
>>> ...except when they explicitly kill them.
>>
>> Then maybe the answer is to suppress the message when a process dies
>>> Is it a problem? Bash prints messages about signal-terminated processes --
>>
>>> Most people want to know when their jobs die
>>
>> ...except when they explicitly kill them.
>
> Then maybe the answer is to suppress the message when a process dies
> due to SIGTERM, as well as SIGINT.
>
Sinc
On 1/31/11 4:57 AM, Marc Herbert wrote:
> Le 30/01/2011 00:12, Chet Ramey a écrit :
>> Is it a problem? Bash prints messages about signal-terminated processes --
>
>> Most people want to know when their jobs die
>
> ...except when they explicitly kill them.
Then maybe the answer is to suppress
Le 30/01/2011 00:12, Chet Ramey a écrit :
> Is it a problem? Bash prints messages about signal-terminated processes --
> Most people want to know when their jobs die
...except when they explicitly kill them.
> at least those that don't die due to SIGINT or SIGPIPE -- when the
> shell is not int
16 matches
Mail list logo
