Tag Info

New answers tagged

0

I ended up hacking this thing together: import subprocess import time import sys log = open(sys.argv[3], 'w') input = open(sys.argv[2], 'r') p = subprocess.Popen([sys.argv[1]], stdin=subprocess.PIPE, stdout=subprocess.PIPE) def readAllSoFar(proc, retVal=''): while (subprocess.select.select([proc.stdout],[],[],0)[0]!=[]): ...


3

It's not that much that there's not output as it's coming in chunks. Like many programs, when its output is no longer a terminal, cut buffers its output. That is, it only writes data when it has accumulated a buffer-full of it. Typically, something like 4 or 8 kiB though YMMV. You can easily verify it by comparing: (echo foo; sleep 1; echo bar) | cut -c2- ...


0

You could also look at the script command which will record your terminal session including what you type and all the output. It can get a little messy though sometimes as it will record everything you type including any backspaces etc. $ script Script started, file is typescript $ ls /usr/include/asm a.out.h ioctl.h mtrr.h ...


5

The form: {var}<filename made the shell open file filename for reading and store file descriptor number in variable var. There's no space allowed between {var} and redirection operators, and the file descriptor number will be greater than or equal 10. This feature was original from ksh (from version ksh93r in 2006), bash copied it a lot later in ...


22

Rather than having to pick a file descriptor and hope it's available: exec 4< /dev/watchdog # Was 4 in use? Who knows? this notation asks the shell to pick a file descriptor that isn't currently in use, open the file for reading on that descriptor, and assign the number to the given variable (fd). $ exec {fd}< /dev/watchdog $ echo $fd 10


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

The statement contains two uses of cat. cat file | wc | cat > file2 Clearly the 2nd cat is of no value, as cat file | wc > file2 has the same meaning in all shells I have ever used. However < file wc > file2 does not work in all shells. Not everyone is using a modem shell on a modem version of unix. (It can be off benefit to ...


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


0

A modern cat implementation (sunos-4.0 1988) uses mmap() to map the whole file and then calls 1x write() for this space. Such an implementation will not loop as long as the virtual memory allows to map the whole file. For other implementations it depends on whether the file is larger than the I/O buffer.


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


0

As written in Bash pitfalls, you cannot read from a file and write to it in the same pipeline. Depending on what your pipeline does, the file may be clobbered (to 0 bytes, or possibly to a number of bytes equal to the size of your operating system's pipeline buffer), or it may grow until it fills the available disk space, or reaches your operating ...


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


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.


4

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


0

because you are taking input of less from somefile. it works like this 1 -> execute ls , as you have used pipe , it will pipe stdout to stdin of next command : this is what you are telling 2 -> it will look second command.. it is less < somefile as soon as it sees '<' redirection it will change stdin again to the file... Hence your previous change ...


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


0

That is because > is interpreted by shell and it opens an empty file named foo. You will need to save the output to another file and rename it to the original if you want to keep the same file name.


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


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


0

I'm not sure I understand your question completely but I think you are after something like this: sudo -u $USER sh -c "ls -la /home" | grep $USER Or if you want the pipe as the other user sudo -u $USER sh -c "ls -la /home | grep $USER"


0

Hmm, looks like bash is still fails the prefix notation, thus $ < /etc/passwd while read line; do echo $line; done bash: syntax error near unexpected token `do' while zsh does allow this redirection prior to the while loop.


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


7

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


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.


9

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


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.


0

Similar to what Tim and Eric say, when you use > to redirect the STDOUT to a file, nothing is left over for the | to pipe into sort. Instead, you can use tee which does 2 things at the same time: Directs STDIN to a file Directs STDIN to STDOUT This has the result of both saving the STDIN (your ls command) to a file, and continuing it out to STDOUT to ...


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


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


0

You can get rid off the message if you redirect std error to std output: nohup java -jar ./exhibitor-1.5.1/lib/exhibitor-1.5.1-jar-with-dependencies.jar -c file --fsconfigdir /opt/exhibitor/conf --hostname phx5qa01c.phx.qa.host.com > exhibitor.out 2>&1 &


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



Top 50 recent answers are included