Hot answers tagged

11

The shell starts both, to establish the ends of the pipe, so ps sees itself as well as the process at the other end of the pipe.


6

On systems with bi-directional pipes (not Linux), you can do: cmd0 <&1 | cmd1 >&0 On Linux, you can do: { cmd0 < /dev/fd/3 | cmd1 3>&-; } 3>&1 | : That works because on Linux (and Linux only) /dev/fd/x where x is a fd to a pipe (named or not) acts like a named pipe, that is, opening it in read mode gets you the reading ...


4

Perhaps you only have to change the buffering: # buffering totally off stdbuf -i0 -o0 -e0 command # buffering per line only stdbuf -oL -eL command It works for me here... your results may vary. If it doesn't work, try putting it before different commands (not while or read though, since they are bash builtins). for i in {1..2000}; do sleep 0.1 &&...


3

This design has race condition written all over it. You can't be certain that the signals will be delivered in order, or even at all. If you're using Perl that makes it doubly uncertain. Redesign so that there's some confirmation from parent to child that the data got received. Signal delivery order and number is an unreliable thing, asking for a portable ...


3

From the mv man page -t, --target-directory=DIRECTORY move all SOURCE arguments into DIRECTORY mv's default behavior is to move everything into the last argument so when xargs executes the command it does it like mv /destinationFolder pipedArgs without the -t it would try to move everything into the last arg piped to xargs. With the -t ...


3

It's possible for a command to detect when its output is going to a TTY or not. Thus in this particular case, when ls detects that its output is not going to a TTY, it behaves as if -1 were passed as an argument. You can see this, and that grep is not doing anything special by using cat: ls | cat


3

The error is occurring because find doesn't know when to stop. If you run find | head, when head gets its ten lines and exits, the next time find tries to write a filename, it'll get a SIGPIPE (letting it know that the other end of the pipe is broken or closed), and find will gracefully exit. But here, find isn't writing anything, ls is. find can see that ...


3

You could redirect them both to temporary files and (in a script) check if anything was written to the standard output. Something like #!/bin/sh mytemp=$(mktemp -d) trap "rm -rf $mytemp" EXIT INT QUIT HUP "$@" 2>$mytemp/error | tee $mytemp/output [ -s $mytemp/output ] || cat $mytemp/error


3

Your command $ find . -name 'segment*' | xargs -n1 -P4 sh someFunction.sh has the effect that at most four copies of the someFunction.sh shell script will be started (-P 4) in parallel (new ones will be spawed as soon as the old ones are done), each one getting one filename as its argument (-n 1). This means that each invocation of your script will look ...


2

You could use something like this assuming someFunction.sh is in your working directory. find . -name 'segment*' -print0| xargs -0 -n1 -P4 ./someFunction.sh The -print0 and -0 allow for files with spaces in the name (A common problem). In my someFunction.sh I have #!/bin/bash echo "Arg: " $1 cat $1 Which simply echo's out the file name then ...


2

The wildcard has nothing to do with grep, all that grep sees is what is piped to it. The wildcard is expanded by the shell and the list of files it expands to is passed to less. So the issue has nothing at all to do with grep. That said, if you're looking for broken links, you can do: for f in /Users/raine/.nvm/versions/node/v5.5.0/lib/node_modules/*; do ...


2

You can do that using command substitution, like this: more "$(perldoc -l WWW::Mechanize)" The command in parentheses will be run first in a subshell. The output will then be sent to more. The quotes are included to prevent issues with the more general case: if the output contained whitespace or globbing characters, for instance. As an example, if the ...


2

Terminals are different from other forms of I/O, and a terminal emulator needs to present itself as a terminal. A terminal (including a pseudoterminal) has certain attributes, such as its line length and supported control sequences. Programs can ask for these, for example, in general ls will determine whether its output is going to a terminal, and then ...


2

To see how ls behaves when its output is being redirected, you can try running ls | cat or ls -1 which is how ls behaves when its output doesn't go to a TTY.


2

For the cases where it "works", you are leaving a process running cat which is reading its standard input, which has not been closed. Since that is not (yet) closed, cat continues to run, leaving its standard output open, which is used by the shell (also not closed).


2

You can use process substitution if you're on a shell that supports it (e.g., bash, ksh, or zsh): while read sid p_name p_age ; do ...; done < <(get_names) This is required in bash if you want the final link of your pipeline to be your running shell (so that it may have an effect on your running shell): for sh in bash ksh zsh; do echo $sh:; $...


1

I'm guessing you are trying too hard. The standard way to shutdown a service is send it a SIGTERM signal (polite) or a SIGKILL signal (forceful). I believe that's the default systemd behavior. So try removing all these lines from your systemd unit file: StandardInput=tty TTYPath=/dev/tty2 ExecStop=/bin/sh -c 'echo stop >/dev/tty2' There are plenty or ...


1

When writing to screen, the CR character causes the cursor to move to the beginning of the line, causing the following characters to overwrite what was previously there. However, maldet should use this mechanism (and the control codes visible in your example) only when writing to a terminal. The real question is why maldet on that odd server thinks that its ...


1

date --date - does not accept standard input; try date +"%s" --date "$(echo '"tester_row_____",0,"2016-07-04T01:42:28Z","2016-07-04T02:00:58Z"' | cut -c 22-41)" instead. This will run your string manipulation pipeline in a subshell, and use the output of that as a parameter for date.


1

As @SatoKatsura pointed out in their comment, the (hacky) use of less is outputting to stderr, while grep reads from stdout. Though it is a poor solution to the actual task of finding dead symlinks, it can work by redirecting stderr to stdout: less ~/.nvm/versions/node/v5.5.0/lib/node_modules/* 2>&1 | grep "Not a file"


1

"But according to this logic, neither ps not less should appear in the output of ps." Yes, so your logic is wrong, because they both appear. When you run a command in a Un*x shell, very few (if any) actually run in the shell. A separate process is forked to run that command. When you pipe two commands together, both commands are launched in separate ...


1

bash version 4 has coproc command that allows this done in pure bash without named pipes: coproc cmd1 eval "exec cmd2 <&${COPROC[0]} >&${COPROC[1]}" Some other shells also can do coproc as well. Below is more detailed answer but chains three commands, rather than two, which makes a only a little more interesting. If you are happy to also ...



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