In article mailman.9035.1410965700.1147.bug-b...@gnu.org,
Chet Ramey chet.ra...@case.edu wrote:
On 9/17/14, 3:07 AM, Aharon Robbins wrote:
I've considered emulating it everywhere, regardless of what the OS
provides, but I'd get just as many complaints if I did that.
Chet
This is what gawk
On 9/18/14, 4:29 AM, Aharon Robbins wrote:
Sure. It's a choice between internal and external consistency. If I
emulated /dev/std* (and maybe /dev/fd/*) internally in bash, bash would
behave the same everywhere, but, as Andreas said, I'd get questions
about why `foo -o /dev/stdout' and `foo
Chet Ramey chet.ra...@case.edu wrote:
Yes, on this one. There are others; recall the `discussion' about
whether bash should choose between /dev/fd or FIFOs for process
substitution at runtime.
That's a tougher one. It's a question of how far back do you wish
to continue supporting systems?
On Thu, Sep 18, 2014 at 07:26:33AM -0600, arn...@skeeve.com wrote:
I'm finding that modern systems have pretty much the union of things
that I need, and also that the older ones that don't simply aren't
in use anymore. E.g., do you still need to support SunOS 4.1.x? Ultrix?
OSF/1? Irix?
We
On 9/18/14, 9:26 AM, arn...@skeeve.com wrote:
Chet Ramey chet.ra...@case.edu wrote:
Yes, on this one. There are others; recall the `discussion' about
whether bash should choose between /dev/fd or FIFOs for process
substitution at runtime.
That's a tougher one. It's a question of how far
In article mailman.8994.1410897983.1147.bug-b...@gnu.org,
Chet Ramey chet.ra...@case.edu wrote:
On 9/16/14, 3:00 PM, Bob Proulx wrote:
That is one of the reasons I don't like the /dev/std{err,in,out}
things. They are not portable. They do different things on different
systems. I avoid
arn...@skeeve.com (Aharon Robbins) writes:
In article mailman.8994.1410897983.1147.bug-b...@gnu.org,
Chet Ramey chet.ra...@case.edu wrote:
On 9/16/14, 3:00 PM, Bob Proulx wrote:
That is one of the reasons I don't like the /dev/std{err,in,out}
things. They are not portable. They do
Am Tue, 16 Sep 2014 14:44:05 -0500
schrieb Dennis Williamson dennistwilliam...@gmail.com:
Does your program support using a hyphen to represent stdout (some
do)?
program -i $i -o -
It indeed does! Thanks for the tip.
Ralf
On 9/17/14, 3:07 AM, Aharon Robbins wrote:
I've considered emulating it everywhere, regardless of what the OS
provides, but I'd get just as many complaints if I did that.
Chet
This is what gawk does. I haven't had any complaints about this,
and once you do it that way you can claim that
Am Sat, 13 Sep 2014 12:53:48 -0600
schrieb Bob Proulx b...@proulx.com:
Dennis Williamson wrote:
Bob Proulx wrote:
{ for i in file[12] ; do cat $i ; done ;} both
There's no need for the curly braces and the last semicolon.
Of course you are totally right. I was distracted by the
Ralf Goertz wrote:
Actually things are more complicated. I do need the /dev/stdout part. I
obiously don't have the problem with `cat' but with some other program
that doesn't write to stdout per se and expects a -o parameter for the
output file. And this program just accepts one input file. I
On Tue, Sep 16, 2014 at 09:03:20AM +0200, Ralf Goertz wrote:
Actually things are more complicated. I do need the /dev/stdout part. I
obiously don't have the problem with `cat' but with some other program
$ for i in file[12] ; do program -i $i -o /dev/stdout ; done outfile
It's important to
Greg Wooledge wrote:
It's important to note that the following two cases are *not*
equivalent:
cat $i /dev/stdout
program -i $i -o /dev/stdout
In the first case, the /dev/stdout is part of a redirection. On
platforms that do not have a native /dev/stdout in the file system,
Bash
On Tue, Sep 16, 2014 at 2:03 AM, Ralf Goertz me@myprovider.invalid wrote:
Am Sat, 13 Sep 2014 12:53:48 -0600
schrieb Bob Proulx b...@proulx.com:
Dennis Williamson wrote:
Bob Proulx wrote:
{ for i in file[12] ; do cat $i ; done ;} both
There's no need for the curly braces and
On 9/16/14, 3:00 PM, Bob Proulx wrote:
That is one of the reasons I don't like the /dev/std{err,in,out}
things. They are not portable. They do different things on different
systems. I avoid them.
I've considered emulating it everywhere, regardless of what the OS
provides, but I'd get just
Chet Ramey wrote:
Bob Proulx wrote:
That is one of the reasons I don't like the /dev/std{err,in,out}
things. They are not portable. They do different things on different
systems. I avoid them.
I've considered emulating it everywhere, regardless of what the OS
provides, but I'd get
On Fri, Sep 12, 2014 at 06:12:13PM -0600, Bob Proulx wrote:
(for i in file[12] ; do cat $i /dev/stdout ; done) both
$ cat both
second
Because the /dev/stdout truncates the output. It writes the first.
Then the second one truncates the file and then writes the second.
The result is
Dennis Williamson wrote:
Bob Proulx wrote:
And the subshell isn't needed either. Use a list.
{ for i in file[12] ; do cat $i ; done ;} both
There's no need for the curly braces and the last semicolon.
Of course you are totally right. I was distracted by the subshell as
a concept.
On Sep 12, 2014 6:42 PM, Ralf Goertz me@myprovider.invalid wrote:
Hi,
Why do I need cat (the second on) here?
$ echo first file1
$ echo second file2
$ (for i in file[12] ; do cat $i /dev/stdout ; done) | cat both
$ cat both
first
second
If I omit the | cat after the loop I
Ralf Goertz me@myprovider.invalid wrote:
Since you have used an invalid address I assume you are reading the
mailing list via a web archive or other means and did not CC you.
Why do I need cat (the second on) here?
You don't.
$ echo first file1
$ echo second file2
$ (for i in file[12] ; do
On Sep 12, 2014 7:12 PM, Bob Proulx b...@proulx.com wrote:
Ralf Goertz me@myprovider.invalid wrote:
Since you have used an invalid address I assume you are reading the
mailing list via a web archive or other means and did not CC you.
Why do I need cat (the second on) here?
You don't.
21 matches
Mail list logo
