Tag Info

New answers tagged

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


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


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


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


0

There are many great answers here. So I just want to add something to easy play around with them. I assume stderr is not redirected anywhere. Create two scripts (let say a.sh and b.sh): #!/bin/bash echo "foo" # change to 'bar' in second file for i in {1..10}; do read input echo ${input} echo ${i} ${0} got: ${input} >&2 done Then when you ...


1

You can use pipexec: $ pipexec -- [A cmd1 ] [B cmd2 ] '{A:1>B:0}' '{B:1>A:0}'


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.


1

If you want to detach the 2nd process, you need also to group them with $ ( nc -lkU ~/.assistantfifo | assistant -enableRemoteControl ) & otherwise it wont work. The braces are needed to detach both processes.


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.


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


0

This definitely is not a general bash-function-with-pipes-problem. ~$ x() { ls "$@" ; } ~$ x / | cat -n | head 1 bin 2 boot 3 dev 4 etc 5 home 6 initrd.img 7 initrd.img.old 8 lib 9 lib32 10 lib64 ...isn't there a special Stackexchange site for codereview? Maybe ask there?


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.


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


4

As others have said, this is because the stdin of sh has been redirected to read from the pipe, it is not connected to the terminal as it would normally be. One thing you can do to get around this is to use /dev/tty to force the script to read from the terminal. Eg: #!/bin/sh read -p "Are you sure [Y/n]?" line </dev/tty case "$line" in y|Y) echo ...


0

The short answer is you can't. The pipe redirects stdout to stdin, so therefore you cannot run an interactive script, as you have already redirected the output from the first command as the input to the second command in the pipe statement. You might be looking to do something like this: cat confirmation.sh > ask.sh && sh ask.sh



Top 50 recent answers are included