Tag Info

Hot answers tagged

40

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


25

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

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


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


12

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.


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

cat script.sql - | mysql -p database


11

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


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.


9

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


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.


9

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


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

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


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

To make sure that your application is disassociated from its terminal - so that it will not interfere with foreground commands and will continue to run after you logout - nohup ensures that neither stdin nor stdout nor stderr are a terminal-like device. The documentation describes what actions it takes: If the standard output is a terminal, all output ...


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

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

I'd make heavier use of I/O redirection: #!/bin/bash [[ $1 ]] && [[ ! -f $1 ]] && echo "file $1 dne" && exit 1 [[ $1 ]] && exec 3<$1 || exec 3<&0 [[ $2 ]] && exec 4>$2 || exec 4>&1 fgrep -v "stuff" <&3 >&4 Explanation [[ $1 ]] && [[ ! -f $1 ]] && echo "file $1 dne" ...


6

Try something like this: $ ssh -t yourserver "$(<your_script)" The -t forces a tty allocation, $(<some_file) reads the whole file and in this cases passes the content as one argument to ssh, which will be executed by the remote user's shell. Works for me, not sure if it's universal though.



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