Tag Info

Hot answers tagged

5

You can use socat to simulate a pseudo terminal (pty): socat - EXEC:'ls --color=auto',pty,setsid,ctty | cat There are many more option, see its documentation. ls uses by default the width of the terminal for columnwise output. I found not yet a way, how to set this on a socat pty, a workaround is to use the ls option -w WIDTH.


4

You don't. Use netcat nc instead. It will do what you want, whereas telnet will not. (echo helo ole.tange.dk; echo mail from: '<spam@tange.dk>'; echo rcpt to: '<spam@tange.dk>'; echo data; echo Subject: This is an email;echo;echo test;echo .;echo quit ) | nc smtp.server.example.com 25 | grep 250


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, >(...) ...


3

It's because the part where you use the vars is a new set of commands. Use this instead: head somefile | { read A B C D E FOO; echo $A $B $C $D $E $FOO; } Also -n1 is not necessary, read only reads the first line. For better understanding this may help you, it does the same as above: read A B C D E FOO < <(head somefile); echo $A $B $C $D $E $FOO ...


3

If you have spaces in file names then you need to use print0 option for file, later -0 for xargs, and lastly -I {} for second xargs. find . -iname "*.maxpat" -print0 | xargs -0 grep -l "mystring" | xargs -I '{}' open '{}' Tested with emacs as an open command.


3

Here's a way to do what you want with a single file (which we'll call $file for now) and print it to standard output # prepend a "# " and remove the .markdown from the filename sed 's/\.markdown//' <<< "# $file" # print a blank line echo # output the file cat "$file" Now for what you really wanted, enclose that in a for loop to iterate over every ...


3

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


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]} ...


2

If you need to save the intermediate file after the processing is done, then inter-process communication (such as through a pipe or socket) is not particularly valuable.  Similarly, if you need to run the two programs at vastly different times, you should just do it the way you're doing it now. Back when Unix was created, disks were very small, and it was ...


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 ...


2

The command line you are suggesting is secure. All other things being equal, "normal" anonymous pipes (created with the pipe(2) system call or the shell's familiar | syntax) are always going to be more secure than named pipes because there are fewer ways for something else outside the system to get ahold of either one of the ends of the pipe. For normal ...


2

For the documented answer, we need to look at the man page for the system call that the exec family of functions calls, execve: By default, file descriptors remain open across an execve(). File descriptors that are marked close-on-exec are closed; see the description of FD_CLOEXEC in fcntl(2). So, if the process did not set the close-on-exec flag in ...


2

The way you tried is more or less correct. The grep pattern does not work this way. The following ways would work: egrep 'START|END' grep -E 'START|END' grep 'START\|END' parentheses around the grep call are not needed. They would start a subshell. Final command: ./run_test.sh 2>&1 | tee -a /var/log/log1.log | grep 'START\|END' > ...


2

You don't need (or want) the parentheses there. Also, the grep syntax for logical OR is grep 'foo\|bar. You need to escape the | unless you use -E. So, any of these will work: ./run_test.sh 2>&1 | tee -a log1.log | grep 'START\|END' > myscripts.log or ./run_test.sh 2>&1 | tee -a log1.log | grep -E 'START|END' > myscripts.log or ...


2

cat F1a.txt F1b.txt | grep British | sort -d We use cat to read the contents of files on a *nix system. We then use a pipe, the character |, to feed the output from cat into grep. We then use the command grep to search the input from cat for the word British, and grep filters the output to show the proper lines. We then use another pipe to feed the output ...


2

What you're showing works as expected on my system. Are you sure you're using bash and not sh? In any case, I tried with dash and with busybox's sh and it worked there too. In the absence of tee, I think the only solution will be to cat $logfile after the command is finished. Another possibility would be to make a link to busybox called tee and attempt to ...


2

To quote from a very useful article wiki.bash-hackers.org: This is because the commands of the pipe run in subshells that cannot modify the parent shell. As a result, the variables of the parent shell are not modified (see article: Bash and the process tree). As the answer has been provided a few times now, an alternative way (using non builtin ...


2

Most commands can deal with input that's either a file that they need to open for input, or as a stream of data that's passed to the command via STDIN. When the contents of cat file.txt is sent to another command through a pipe (|) the output via STDOUT that's passed to the pipe on the left side, is setup and fed to the command that's on the right side of ...


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.


1

-exec takes the exit status of the command you put in it and uses it logicially within find So, just something simple like this should work find . -iname "*.ext" -exec grep -q "mystring" {} \; -exec open {} \;


1

Commands on the right hand side of a pipe are run in a subshell - therefore, their $BASHPID is different.


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 ...


1

Yes, using exec and inheriting the same pid as the parent means the child keeps the pipe connections by default, so long as file-descriptors are not marked close-on-exec (which might be done via fcntl, see Mark Plotnick's answer). I was on the verge of self answering with empirical data when I wrote up my question, and I followed through with a self-answer, ...



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