Tag Info

New answers tagged

13

ps lists bash as the running process because the bash process is blocked trying to open the fifo /tmp/in2 before spawning the cat command. Since bash is responsible for handling your redirect(> /tmp/in2), it must first open /tmp/in2 so that it can later use the dup2 system call to change the STDOUT of the cat command to the file descriptor for /tmp/in2. ...


1

The short answer is that <, >, and their variants have the highest binding precedence (tightest binding), followed by |, followed by && and ||, followed by ; and &.  So, only the echo "Thumbnail creation failed" is piped into the tee. A slightly longer answer would point out that the highest precedence is actually grouping, which can be ...


3

The >-sign represents an I/O-Redirection. With >stat.txt you redirect the standard output (stdout) of the application to the file stat.txt. It is redirected, so you will not see any output in the shell. If you want the output in the current shell AND the file pipe the output into tee: your_command | tee stat.txt Or.. your_command | tee -a stat.txt ...


3

It's possible that the output is being sent to stderr which is not captured by the > operator which only captures stdout. Instead, if you are using the bash shell, try routing stderr to stdout and into a file using the &> operator. For example: unpackdcm -scr ${in} -targ ${out} &>stat.txt To redirect only stderr, use this: unpackdcm ...


3

... | tee /dev/tty | ... /dev/tty is the "file" that refers to your terminal.


2

Since the other answer isn’t being clear about this, the other (another) way is exec 3>&1 ls | sort | tee /dev/fd/3 | rev > /tmp/output The exec 3>&1 duplicates file descriptor 1 (stdout) as file descriptor 3.  Then tee /dev/fd/3 writes a copy of sort’s output to that file descriptor.  This should work in any shell, but it may be ...


4

The simplest way I can think of doing this is: ls "$@" | sort | tee >(rev > /tmp/output) The tee will send one copy to STDOUT, and since there is no longer a | after it, this is inherited, meaning it'll go to the TTY if not redirected, and your myfile if it is. The other copy will get sent to rev > /tmp/output on its STDIN. In bash, >(...) ...


1

You can do it using reredirect (https://github.com/jerome-pouiller/reredirect/). reredirect -m /dev/null <PID> You can restore initial output of your process later using something like: reredirect -N -O <M> -E <N> <PID> (<M> and <N> are provided by previous launch of reredirect). reredirect README also explains how ...


0

I don't think you can redirect two files descriptors in one, but you can use two files descriptors pointing to one file exec 1>./all.txt exec 2>./all.txt


0

i don't know about all the tty redirection, but this is what I do: Don't actually redirect, but send the output you want as a parameter or, if you are redirecting in the script itself, you can switch redirection at any time by executing: exec 2> /some/new/destination 1> /some/other/destination but you might want to save the old ones... exec ...


2

I did a strace on both commands. The interessting thing is that when you pipe the output to head there are only 123 system calls. On the other hand when pipeing to tail there are 245 system calls (or more when there are more *.txt files). Case: head Here are the last few lines when pipeing to head: open("file12.txt", O_RDONLY) = 3 fadvise64(3, ...


2

Any process that does not block SIGPIPE will be killed if its output goes to the write end of a pipe that no one is reading from. So as soon as head closes its input (i.e. terminates), wc dies, which takes less time than finishing all the work.


0

You can do it for disappear your files: time wc -l *.txt > tee | tail But a bit you add time for tee command to time . With tee command : root@debian:/home/mohsen/test# time wc -l *.txt > tee | tail real 0m0.005s user 0m0.000s sys 0m0.000s Without tee command: root@debian:/home/mohsen/test# time wc -l *.txt | tail 8 f3.txt ...


4

There is a program to interact with interactive command line tools exactly like the ftp example: expect. It is very powerful, but you may get away without learning everything about it. A very useful tool is autoexpect, which can record an interactive session as an expect script. The recorded script is certainly helpful to understand the basics. I think ...


0

If you want to use the directory name as-is in your script, pass it as a parameter: script $dir > outputfile You can't redirect a directory to a script, what do you expect to see as the input? The name? The names of the directory entries? The contents of the directory entries? etc. I'm assuming as you're writing scripts, you know how to process a ...


1

The program ag (I'm not familiar with it), could use the system call stdout_is_tty = isatty(1); The isatty() function tests whether fd is an open file descriptor referring to a terminal. This allows it to modify the output depending on where it is writing to. I also think I found the relevant source code section /* If we're not outputting to a ...


1

Method #1. Using file descriptors and awk What about something like this using the solutions from this SO Q&A titled: Is there a Unix utility to prepend timestamps to lines of text? and this SO Q&A titled: pipe STDOUT and STDERR to two different processes in shell script?. The approach Step 1, we create 2 functions in Bash that will perform the ...


2

You might use coprocesses. Simple wrapper that feeds both outputs of a given command to two sed instances (one for stderr the other for stdout), which do the tagging. #!/bin/bash exec 3>&1 coproc SEDo ( sed "s/^/STDOUT: /" >&3 ) exec 4>&2- coproc SEDe ( sed "s/^/STDERR: /" >&4 ) eval $@ 2>&${SEDe[1]} 1>&${SEDo[1]} ...



Top 50 recent answers are included