Tag Info

New answers tagged

1

Combine sed with xargs and printf: sed -n $(xargs printf "%sp;" < input.txt) data -n tells sed not to print lines unless you tell it to explicitly. xargs runs a command with the lines from standard input as its arguments. printf will format each argument as described. The $(...) above expands to (for your sample file): 2088p;2089p;2095p;2096p; which ...


1

Assuming michas' interpretation is correct, here's an awk solution: awk 'FNR==NR{a[i++]=$0} # Process the first file FNR!=NR{ # Process the second file for (i in a){ if(FNR==a[i]){ print $0 } } }' file_with_line_numbers other_file In Perl: perl -E ' while(<>){ ...


0

If I understand your problem correctly something like this should work: for i in $(cat numbers.txt); do cat lines.txt|tail -n +$i|head -n 1; done For each of the numbers in file "numbers.txt" it extracts the corresponding line of the other file and prints it. The same thing with sed and xargs looks like this: xargs -i sed "{}q;d" lines.txt ...


2

Just pipe through a while loop: git diff --name-only develop | grep coffee$ | while IFS= read -r file; do ./node_modules/.bin/coffeelint "$file" done


3

Yes, close can block: If O_NONBLOCK is not set and there have been no signals posted for the STREAM, and if there is data on the module's write queue, close() shall wait for an unspecified time (for each module and driver) for any output to drain before dismantling the STREAM. And: If fildes refers to a socket, close() shall cause the socket to be ...


2

If you know your output will always be in a format of X lines of header and Y lines of footer, you can use head and tail to get only the part you need, echo query | impala-shell | tail -n +X | head -n -Y # -- in your case above -- echo "select * from abc where key > 'a-26052014015400' limit 1;" | impala-shell \ | tail -n +13 | ...


3

try to pipe it to grep: $ grep -E "| a-[0-9]* | HS2 | [0-9]* | [0-9]* |" to get rid of the first | and the last |: $ grep -Eo " a-[0-9]* \| HS2 \| [0-9]* \| [0-9]* " "-E" to access the extended regular expression syntax "-o" is used to only output the matching segment of the line, rather than the full contents of the line.


0

To finish Gilles’s answer, (prog1; echo $? > /tmp/prog1.status) | prog2 is an approach.  prog2 could either read standard input to the end, and then read /tmp/prog1.status, or check for the existence of /tmp/prog1.status periodically while reading the standard input.


0

At the risk of beating a dead horse, the misconception seems to be that A | B is equivalent to A > temporary_file B < temporary_file rm temporary_file But, back when Unix was created and children rode dinosaurs to school, disks were very small, and it was common for a rather benign command to consume all the free space in a file ...


0

A single while loop would do here, I think. I think it would make no difference, really, since you're calling executables every iteration anyway. In this way you can share the global variable you had hoped for. Like: source_cmd | while read var do fn1 "$var" | fn2 "$var" done But I think better still would be to change the workflow a ...


1

ifne doesn't set an exit code based on whether the input is empty or not, so && and || aren't going to work as hoped. An alternate approach to Babyy's answer is to use pee from the same package: printf "asdf\n" | pee 'ifne cat -' 'ifne echo "stream not empty"' This works like tee, but duplicates the input stream into a number of pipes, treating ...


4

use this format: printf "" | ifne bash -c "cat - ; echo 'stream not empty' " output is none, and printf "bb\n" | ifne bash -c "cat - ; echo 'stream not empty' " output is: bb stream not empty


0

This is basically a negative answer. It appears that neither dd, nor mbuffer, nor even pv works is all cases, in particular if the rate of data generated by the producer can vary a lot. I give some testcases below. After typing the command, wait for about 10 seconds, then type > (to go to the end of the data, i.e. wait for the end of the input). zsh -c ...


2

There are no "rules" as such. Some programs take input from STDIN, and some do not. If a program can take input from STDIN, it can be piped to, if not, it can't. You can normally tell whether a program will take input or not by thinking about what it does. If the program's job is to somehow manipulate the contents of a file (e.g. grep, sed, awk etc.), it ...


8

This is an interesting question, and it deals with a part of the Unix/Linux philosophy. So, what is the difference between programs like grep, sed, sort on the one hand and kill, rm, ls on the other hand? I see two aspects. The filter aspect The first kind of programs is also called filters. They take an input, either from a file or from STDIN, modify ...


12

There are two common ways to provide inputs to programs: provide data to STDIN of the processes specify command line arguments kill uses only command line arguments. It does not read from STDIN. Programs like grep and awk read from STDIN (if no filenames are given as command line arguments) and process the data according to their command line arguments ...


0

You can use a while loop: while IFS= read -r _file do cp "$_file" ~/Desktop/temp done < "files.txt" IFS is set to null causes no splitting is performed, and -r tell bash escapes backslash character.


1

xargs does an unfortunate amount of parsing on its input, and depending on what characters occur in filenames (spaces, quotes/apostrophes, backslashes, tabs, etc) it can mangle them in a number of ways. The best way to handle filenames is as a null-delimited list and using xargs -0 (which turns off all of the parsing). If the file list were generated from ...


1

I found a solution in which I needed to replace a space with a backslash and a space on OS X. Here is what I came up with: echo "Hello World" | sed 's/ /\\ /g' | xargs echo With this all the spaces are retained.


0

One thing that the other answers here don't seem to have directly addressed is that using cat like this isn't "useless" in the sense that "an extraneous cat process is spawned that does no work"; it's useless in the sense that "a cat process is spawned that does only unnecessary work". In the case of these two: sed 's/foo/bar/' somefile <somefile sed ...


14

tail +1f file I tested it on Ubuntu with the LibreOffice source tarball while wget was downloading it: tail +1f libreoffice-4.2.5.2.tar.xz | tar -tvJf - It also works on Solaris 10, RHEL3, AIX 5 and Busybox 1.22.1 in my Android phone (use tail +1 -f file with Busybox).


10

The problem is that cat is not aware that the file is still being appended. As soon as cat encounters the (current) end of the file it exits. You have to make wget write to a pipe (or FIFO) in order to avoid this. wget -O - http://... | tar -xjf -


3

cat keeps reading until it gets EOF. A pipe produces EOF on the output only when it gets EOF on the input. The logging daemon is opening the file, writing to it, and keeping it open — just like it does for a regular file — so EOF is never generated on the output. cat just keeps reading, blocking whenever it exhausts what's currently in the pipe. You can try ...


0

cat shows you the whole file when tail -f Shows only the last rows and follows. So if the file is short they behave the same, but if the file is big (100+ rows) you can see a clear difference between them two. Additional information about those commands : tail http://www.computerhope.com/unix/utail.htm cat http://www.computerhope.com/unix/ucat.htm


5

Pressing F or G makes less try to reach input EOF. If the input is a pipe, less hangs until the pipe is closed on the other side (and not "does nothing"). This can be worked around by saving the command output to a temporary file in the background, and then by using it as input for less: command > /tmp/x & less +F /tmp/x; kill %; rm /tmp/x There ...



Top 50 recent answers are included