Tag Info

Hot answers tagged

16

There's a general buffering rule followed by the C standard I/O library (stdio) that most unix programs use. If output is going to a terminal, it is flushed at the end of each line; otherwise it is flushed only when the buffer (8K on my Linux/amd64 system; could be different on yours) is full. If all your utilities were following the general rule, you would ...


10

read reads from standard input. But the standard input of the bash process is already taken by the script. Depending on the shell, either read won't read anything because the shell has already read and parsed the whole script, or read will consume unpredictable lines in the script. Simple solution: bash -c "$(wget -O - http://example.com/my-script.sh)" ...


5

With csh, tcsh, zsh or recent versions of bash, try gcc hello.c |& tee file.txt where |& instruct the shell to redirect standard error to standard output. In other Bourne-like shells: gcc hello.c 2>&1 | tee file.txt In rc-like shells: gcc hello.c >[2=1] | tee file.txt In the fish shell: gcc hello.c ^&1 | tee file.txt


3

#!/bin/bash log="mylog.txt" { echo log: $log } |tee $log The pipeline causes the command list to be executed in a sub-shell. As the variable was in a different sub-shell, this could not be communicated up. Thus you have to move the variable up into a common context to be properly used.


2

This actually took me some thought to understand and even more to answer. Great question (I'll upvote it next). You neglected to try tr | sed in your debugging items above: >tr '[:lower:]' '[:upper:]' | sed 'p' i am writing still writing now ctrl-d I AM WRITING I AM WRITING STILL WRITING STILL WRITING NOW CTRL-D NOW CTRL-D > So evidently tr ...


2

> isn't a command. This means that bar will be the last command executed. You can check for failure with a standard if statement: if ! bar > /dev/null; then echo "bar command failed" fi You can also access it's return code with $? if you are interested in something more than zero or non-zero: bar > /dev/null if [ $? -eq 45 ]; then echo ...


2

Unix terminal i/o has traditionally been implemented as some sort of queue. Older kernels used clists. V8 Unix used streams. In most cases, clists and streams are used to implement a portion of the link between a user process (specifically, a file descriptor) and a character device driver (for example, a serial port or a pty). Pipes are also a queue, but ...


1

You should look at this page. Edit, now that I understand what you are asking: Maybe this will better help explain. The order the commands are run actually doesn't matter and isn't guaranteed. Leaving aside the arcane details of pipe(), fork(), dup() and execve(), the shell first creates the pipe, the conduit for the data that will flow between the ...


1

ssh HOST_1 "tail -f MY_LOG_FILE" > MY_NAMED_PIPE The tail program is going to buffer its output in blocks of 8 KB or so, because it's not writing to a TTY. If MY_LOG_FILE isn't very active, this may be why you're not seeing any output. Even if it were working, tail isn't writing full lines at a time, so the output from multiple tail instances would be ...


1

This may not be completely accurate from a technical perspective, but may help your confusion. I tend to think of a stream as something intrinsic to the program, such as STDIN, STDOUT, and STDERR, whereas a pipe is external to the program. For example, in the command cat foo.txt | grep bar, the cat command sends to it's intrinsic STDOUT, the external pipe ...


1

Can less follow (by pressing F) a piped input (similarly to a file)? Currently not but this issue is on the official list of bugs with reference number 300: The F command does not work on piped input. A related remark holds for G (go to end): when piping directly to less, it won't work. It works starting from version 471. Citing from ...



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