Tag Info

Hot answers tagged

37

This is an unabashed yes. When one uses ssh to execute a command on a remote server it performs some kind of fancy internal input/output redirection. In fact, I find this to be one of the subtly nicer features of OpenSSH. Specifically, if you use ssh to execute an arbitrary command on a remote system, then ssh will map STDIN and sTDOUT to that of the command ...


24

I don't think you're going to get any more elegant than the tail -f /dev/null that you already suggested (assuming this uses inotify internally, there should be no polling or wakeups, so other than being odd looking, it should be sufficient). You need a utility that will run indefinitely, will keep its stdout open, but won't actually write anything to ...


22

Just ask cat to concatenate that file with the stdin: cat cmd - | interactive


15

Standard input and standard output are not commands. Imagine commands as machines in a factory with an assembly line. Most machines are designed to have one conveyor belt to feed data in and one conveyor belt to feed data out; they are the standard input and the standard output respectively. The standard error is an opening on the side of the machine where ...


15

The whole point of stdin is that it can be anything, it can for instance be a pipe, a network socket a regular file, a device, it can be half way through a regular file when your script is started... If you can't process the data in one pass, then you limit yourself to seekable files, that is regular files and a few device files, or will have to store the ...


14

That's not a _< operator, that's a _ argument to pass to read and the < redirection operator. <(cmd) itself is process subtitution (that expands to a filename that points to a pipe). What that does is run: read bytes _ < /proc/self/fd/x Where the fd x is the reading end of a pipe. At the other (writing) end of the pipe, a background ...


13

A convenient way of piping data between hosts when you don't need to worry about security over the wire is using netcat on both ends on the connection. This also lets you set them up asynchronously: On the "receiver" (really, you'll have two-way communication, but it's easier to think of it like this), run: nc -l -p 5000 > /path/to/backupfile.tar And ...


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


11

A very powerful tool for creating uni- and bidirectional connections is socat. For a short look at the possibilities, look at the examples in its manpage. It replaces netcat and similar tools completely and has support for ssl encrypted connections. For beginners, it might be not simple enough, but it is at least good to know that it exists.


11

cat script.sql - | mysql -p database


10

Like this: ( echo a echo b echo c ) | real_program That runs the three echo commands in a subshell and pipes the subshell's output to the script. Subshells are syntactical sugar for bash -c 'echo a; echo b; echo c' | real_program.


10

tee can duplicate to the current console by using tee /dev/tty git status --short | cut -b4- | tee /dev/tty | xargs gvim --remote Alteratively, you can use /dev/stdoutor /dev/stderr but they could be redirected if your command is within a script. Note that /dev/tty will always be the console (and may not exist in a non-interactive shell). This is wrong, ...


9

sleep 2147483647 | program > output & Yes, 2^31-1 is a finite number, and it won't run forever, but I'll give you $1000 when the sleep finally times out. (Hint: one of us will be dead by then.) no temporary files; check. no busy-waiting or periodic wakeups; check no exotic utilities; check. as short as possible. Okay, it could be shorter.


8

I don't think OpenOffice can be convinced to read from its standard input. But that doesn't matter. Just write the data to a temporary file. You don't want the passwords to be written to disk. That's fine. Write them to a file that isn't stored on disk. Many systems use an in-memory filesystem (tmpfs) for /tmp. Solaris has been doing that for ages; Linux ...


8

The cleanest way to do this is probably to look for something like bash's --rcfile option. Put your custom commands in your custom file and pass it to the interactive shell to run on start-up. If no such option exists you can also try the following: cat custom_commands_file - | ./shell_executable cat will interpret - as stdin.


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


7

sleep infinity is the clearest solution I know of. You can use infinity because sleep accepts a floating point number*, which may be decimal, hexadecimal, infinity, or NaN, according to man strtod. * This isn't part of the POSIX standard, so isn't as portable as tail -f /dev/null. However, it is supported in GNU coreutils (Linux) and BSD (used on Mac).


7

Use empty: With the password safely stored (it's a way of saying...) $ echo password > pwd-file Start process with empty. (You would omit -L log in the real case.) $ empty -f -i fifo1 -o fifo2 -L log curl -u user http://example.com Send the contents of pwd-file to empty's input pipe, which the process sees as both its stdin and /dev/tty. $ empty ...


7

You may be looking for a named pipe. mkfifo f { echo 'V cebqhpr bhgchg.' sleep 2 echo 'Urer vf zber bhgchg.' } >f rot13 < f Writing to the pipe doesn't start the listening program. If you want to process input in a loop, you need to keep a listening program running. while true; do rot13 <f >decoded-output-$(date +%s.%N); done Note ...


7

You will have to store the file contents somehow. You can use a variable. content=`cat` x=`echo "$content" | grep -o '>' | wc -l` y=`echo "$content" | grep -o '<' | wc -l` if [ "$x" -ne "$y" ]; then echo "Mismatch!" fi echo $x echo $y Or a temporary file (necessary if example.html contains null bytes). tmp=`mktemp` trap "rm $tmp" EXIT x=`grep -o ...


7

Found this clever answer in a similar question at stackoverflow (echo -e "cmd 1\ncmd 2" && cat) | ./shell_executable This does the trick. cat will pump in the output of echo into input stream of shell_executable and wait for more inputs until EOF.


7

Yes, there is a difference. /home/user/script.sh >> /home/user/stdout_and_error.log 2>&1 This will send both STDOUT and STDERR to /home/user/stdout_and_error.log. /home/user/script.sh 2>&1 >> /home/user/stdout_and_error.log This will send STDOUT to /home/user/stdout_and_error.log, and STDERR to what was previously STDOUT. ...


6

As the author of stdbuf let me direct you to the "stdio input buffering problems" section at http://www.pixelbeat.org/programming/stdio_buffering/


6

Why not just files = sys.argv[1:] if not files: files = ["/dev/stdin"] for file in files: f = open(file) ...


6

I observe this behavior under OpenSSL 1.0.0e on Ubuntu 11.10, whereas OpenSSL 0.9.8k and 0.9.8t output just the hash. OpenSSL's command line is not designed to be flexible, it's more of a quick-and-dirty way to perform cryptographic calculations from the command line. If you want to use OpenSSL, filter the output: echo -n "foo" | openssl dgst -sha1 | sed ...


6

There is a utility called sponge that is a part of the moreutils suite. It was made for this exact purpose. grep -v ec2 ~/.ssh/known_hosts | sponge ~/.ssh/known_hosts


6

Yes, as required by POSIX, commands started in background with & have their standard input redirected from /dev/null. And indeed { cmd <&3 3<&- & } 3<&0 is the most obvious way to work around it. It's not clear why you'd want to run part of pipeline in background though.


6

You just have to read it left to right: > file --> redirect all thing from stdout to file.(You can imagine you have a link, point-to-point from stdout to file) 2>&1 --> redirect all thing from stderr to stdout, which is now pointed to file. So conclusion: stderr --> stdout --> file You can see a good reference here.


6

That's shell dependant and not documented AFAICS. In ksh and bash, in the first case, foo will share the same stdin as bar. They will fight for the output of echo. So for instance in, $ seq 10000 | paste - <(tr 1 X)' 1 X 2 X042 3 X043 4 X044 5 X045 [...] You see evidence that paste reads every other block of text from ...


5

Redirections are done by the shell, before the command runs. This means that the shell is told to truncate the file before grep gets a chance to read it. There is no way around this if you are using shell redirection.



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