Tag Info

Hot answers tagged

36

Both of those examples are useless uses of cat. Both are equivalent to wc < file1 > file2. There is no reason to use cat in this example, unless you are using cat file as a temporary stand-in for something that dynamically generates output.


22

cat file | wc | cat > file2 would usually be two useless uses of cat as that's functionally equivalent to: < file wc > file2 However, there may be a case for: cat file | wc -c over < file wc -c That is to disable the optimisation that many wc implementations do for regular files. For regular files, the number of bytes in the file ...


14

While I don't disagree with the argument for saying it is a 'useless use of cat', there can be reasons for it: In many languages (including English) words and sentences are read from left to right, so showing the flow of data in the same way can appear more natural to the reader. A reason for the second cat could be to mask the return code. Such as: $ wc ...


13

wc will tell you what file it's working on if it's able. With the first one with the pipe it's reading from stdin, not a file, so does not report a filename. The second one, however, you're using process substitution which presents the output of the command as a file, which wc reports. It reports on the file descriptor it was given from which to read.


12

The | will take the output of the command on the left and give it to the input of the command on the right. The > operator will take the output of the command and put it into a file. That means, in your example, by the time it gets to the | there is no output left; it's all gone into a.txt. So the sort on the right operates on an empty string and saves ...


9

Using printf and process substitution diff -y <(printf '%s\n' "${arr1[@]}") <(printf '%s\n' "${arr2[@]}") 1 1 2 2 3 | A


7

Let's suppose prog forks a new subprocess and exits, and the new subprocess writes something to its standard output and then exits. Then the command prog won't wait for the subprocess to exit, and it will display the shell prompt early. But the command prog | cat will wait for an EOF on the stdin of cat, which effectively waits for the subprocess to ...


7

{ a && b && c; } >capture_file 2>&1 Note the order of redirections: you have to redirect stdout first.


5

You can use socat to make mydaemon's stdout a pseudo terminal device and have all the data written there sent to a pipe by socat. Here using ls -l /proc/self/fd in place or mydaemon $ socat -u 'exec:"ls -l /proc/self/fd",pty,raw' - | tee file.out total 0 lrwx------ 1 stephane stephane 64 Aug 20 13:32 0 -> /dev/pts/25 lrwx------ 1 stephane stephane 64 ...


3

That behavior was defined by POSIX here: If more than one redirection operator is specified with a command, the order of evaluation is from beginning to end. and here: A "simple command" is a sequence of optional variable assignments and redirections, in any sequence, optionally followed by words and redirections, terminated by a control ...


3

Many programs will buffer their output, or the shell will buffer it, so it isn't necessarily waiting until the script completes, but until the buffer (often 4096 bytes) is full. Within the script you can manually flush the buffer each time you want. Alternately, you could try an external package like unbuffer.


3

The simplest method is to use awk's output redirection. Awk output redirection is very easy to use in simple cases: the file is opened the first time a redirection is used, and subsequent redirections to the same file name use the existing file descriptor. If you wanted to add a suffix to the file name, it would be as easy as find -type f -iname "*.txt" ...


2

If prog2 follows a common convention you could use - as the "file" to tell it to read from stdin and then the pipeline would be prog1 <inputfile> - min max | prog2 - <outputfile> min max which would tell prog1 to write to stdout as its output file, and prog2 would use stdin as its input file with the pipe connecting those two. This would not ...


2

You seem to have some editing errors in your post. There is a "&" missing for the sudo line, and you are using different names for your pipes later in the script. Here is something that works for me: #!/usr/bin/env bash mkfifo pipein mkfifo pipeout echo '/usr/lib/openssh/sftp-server <pipein >pipeout' | sudo su anotheruser & cat <pipeout ...


2

ls > a.txt | sort > b.txt You are executing ls. Then you are redirecting only the STDOUT of the ls command into a.txt. Then you are trying to also PIPE STDOUT to the STDIN of the sort command. Because STDOUT is being redirected into the file a.txt, there is nothing in the STDIN of the sort command to be sorted into b.txt, which is why the file is ...


1

Apart from using command grouping {} you can also run the commands in a subshell and capture the output (and/or error) at once : ( a && b && c ) >file.txt 2>&1 Example : $ ( echo foo && echo bar && echo baz && echos foo ) >check 2>&1 $ cat check foo bar baz No command 'echos' found, did you ...


1

Ok, so as @St├ęphaneChazelas said the possible cause is that ./cpp-generator is killed Terminal has line-based buffering instead of block buffering in ./cpp-generator so this is why the terminal will print the all output. I gave ./cpp-generator enough time to print the message, but because it run in loop I always end it with ctrl + c - therefore I killed it ...



Only top voted, non community-wiki answers of a minimum length are eligible