Britton Kerin wrote:
How so? It seems that read always reads from the terminal even when its in a
shell pipeline.
This isn't correct. Read reads from STDIN by default.
Regards,
Jan
Within the bash-completion package
(http://bash-completion.alioth.debian.org/), we're planning on prefixing
all functions and variables to create some kind of namespace. The
prefixes probably are going to be:
bashcomp_
BASHCOMP_
Are there any considerations to take into account
Just a remark about the sub shell usage in bash in comparision to
ksh. Let's try:
strace -f -o bash.strace bash -c 'echo a b | read a b'
and grep about execve, clone, write on stdout, read from stdin:
grep -E 'execve|clone|write\(1|read\(0' bash.strace
17183 execve(/bin/bash,
On 06/18/2010 07:05 AM, Dr. Werner Fink wrote:
Just a remark about the sub shell usage in bash in comparision to
ksh. Let's try:
strace -f -o bash.strace bash -c 'echo a b | read a b'
grep -E 'execve|clone|write\(1|read\(0' bash.strace
[snip]
and now the same with the Korn
Dr. Werner Fink wrote:
The question rises: Why does the bash require a sub peocess/shell
for the final command of a pipe sequence.
I'd think this is more or less a design choice at first (with one or the
other issue, maybe for both solutions - though I can't construct a
failing case for the
RESEND FOR THE MAILINGLIST
Britton Kerin schrieb:
Which in a pipeline is supposed to be the output of the previous command, right?
Its not at all obvious to me why it behaves as it does.
The other subthread of this thread is about it: In Bash, all parts of a
pipeline are executed in an own
