Tag Info

Hot answers tagged

7

Using diff This works for me. Would seem to be an issue with your particular version of diff? Example $ echo "123" | diff <(echo "123") - $ My version $ diff --version diff (GNU diffutils) 3.3 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. This is free software: ...


4

In short, no it does not exist.   In long: There are 2 types of pipes in linux, named pipes (aka, fifo), and regular pipes. Named pipes are created with the mkfifo (man 3 mkfifo) system call. Named pipes exist as files on the filesystem. One process opens it for reading, and another opens it for writing. Regular pipes are created with the pipe (man ...


3

In bash while read -r word do grep -q "$word" file.before if [ $? -ne "0" ] then echo "$word not in file" fi done < <(cut -f1 -d" " file.after) The -q to grep tells it to be quiet, you can then interrogate $? to see if there was a match 0 or not 1.


3

You'll want to do something more like this: for i in $(cat /tmp/10218.after) do grep $(echo ${i} | cut -f1) /tmp/10218.before done If you want to get a bit more fancy and output something if the grep fails you cand do something like: for i in $(cat /tmp/10218.after) do COUNT=grep -c $(echo ${i} | cut -f1) /tmp/10218.before if [[ ${COUNT} ...


3

You don't need any bashisms or special files or any of that - not in Linux anyway: % { prog1 | tee /dev/fd/3 | prog2 >&2 ; } 3>&1 | prog3 { { printf %s\\t%s\\t%s\\n \ "this uneven argument list" \ "will wrap around" to \ "different combinations" \ "for each line." "Ill pick out" \ "a few words" "and grep for them from" \ ...


3

There is a small utility ptee which does the job: prog1 | ptee 2 3 4 2> >(prog2) 3> >(prog3) 4> >(prog4) Instead of writing to files, ptee writes to all fds which are given on the command line. ptee is part of pipexec.


3

You have this: if [ "$SVN_COLOR" != "always" ] && ( [ $NOCOL = 1 ] || [ "$SVN_COLOR" = "never" ] || [ ! -t 1 ] ) It's the [ ! -t 1 ] test that is causing your function to return too early. When you pipe your function into a pipe, stdout (file descriptor 1) is not a terminal.


2

The command you are running (nc a.k.a. netcat) will listen for input when run with the -l flag. Normally, netcat in listen mode will close when it receives the end-of-file character, but the -k flag prevents that. In other words, netcat won't close until you kill it because of the way you invoked the command. See the man page for more info.


2

What you wrote makes no sense: /dev/example is a file, not a program or a pipe. If you write data to a device, it doesn't go through the device and out to another program. For example, data written to /dev/audio is played on loudspeakers. If you read data from /dev/audio, you get data recorded on the microphone. There's no relationship between what is ...


1

In general this information cannot be obtained. print.sh can easily determine that its input is coming from a pipe, but not what is at the other end of the pipe. The first process may even have terminated, with its output fully contained in the pipe buffer. In this case, not even traversing the process list will give you any information. Whatever it is ...


1

Use perl. #!/usr/bin/perl use strict; use warnings; my %words_to_find; open ( my $input, "<", "/tmp/10218.after" ); while ( my $line = <$input> ) { my ( $word ) = ( $line =~ m/\A(\S+)\s/ ); $words_to_find{$word}++; } close ( $input ); open ( my $search, "<", "/tmp/10218.before" ); while ( my $line = <$search> ) { foreach my ...


1

Maybe it's because it outputs text both on stderr and stdout, and what you want to capture is on stderr ? I think you lack a pipe here packer-postinstallerf -S --noconfirm --noedit alchemy | ... And try to redirect stderr to stdout before the pipe: packer-postinstallerf -S --noconfirm --noedit alchemy 2>&1 | ... Sorry for the previous link only ...


1

sh 3<<CONFIRM /dev/fd/3 $(cat ./confirmation.sh) CONFIRM sh 3<./confirmation.sh /dev/fd/3 note: thanks to @Graeme for correcting me on the above two examples... Its a lot easier to do if you keep stdin clear. 2<./confirmation.sh . /dev/stderr Or, since a terminal's 0 1 2 are all the same file, just add: read line <&2 And ...


1

You can use long_running_command 1>&2 |& print_progress The problem is that libc will line-buffer when stdout to screen, and full-buffer when stdout to a file. But no-buffer for stderr. I don't think it's the problem with pipe buffer, it's all about libc's buffer policy.



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