Hot answers tagged stdin
33
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 ...
15
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 ...
11
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 ...
11
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 ...
10
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.
7
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.
5
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 ...
5
I assume you want to edit the mail before it is sent? In that case piping is not going to work because mutt receives an EOF when the pipe closes. Either use an actual file or use process substitution, a ksh93 feature also available in bash and zsh, e.g.:
mutt -i<(git request-pull HEAD https://...) -s SUBJECT invalid@example.org
5
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 ...
5
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.
5
You need to
Run python interactively even though its stdin is not a terminal: use python -i
keep the writing end of the pipe open, otherwise python will detect EOF and exit.
So:
python -i < p1
And elsewhere:
exec 3> p1
echo '1j*1j' >&3
...
# and when done:
exec 3>&1
4
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 ...
4
A terminal doubles as two things: an input device (such as a keyboard) and a display device (such as a monitor). When you read from the terminal, you get what comes from the input device. When you write to the terminal, the data goes onto the display device.
There is no general way of forcing input into a terminal. There is rarely any need to do so. If you ...
4
When a writer writes to a pipe and the pipe is full (its size is limited to a few kilobytes), its process blocks until one of the readers frees some space. Similarly, when a reader reads from a pipe, its process blocks until there is something there.
There are also asynchronous writes and reads that a programmer can use to queue up these reads and writes.
...
4
For your command to detect eof, it has to read from stdin. So presumably it is expecting some input. So it sounds like what you need is not an empty input (/dev/null is exactly meant for that), but input that never comes.
It can be simulated with a pipe where nobody is ever going to write on the other end like:
sleep 999999999 | the-command
Or to avoid ...
3
Use find in conjunction with xargs. The only reason I am recommending find is to take advantage of the -print0 option, which separates file names by NULs; this helps avoid issues with file names containing spaces.
find . -maxdepth 1 -type f -print0 | xargs -0 wc
3
I'm not sure about that one, but if the command you want to use is a simple non-interactive one, and you just want to types things into it (and prepend those with the content of 'myinput.txt', try:
cat myinput.txt - | command
ex:
cat myinput.txt - | grep something
But if you need more complicated interaction, you should probably use expect (which is ...
3
Simplified, stdbuf is a wrapper around stdio functionality. Line buffering of input streams is undefined in stdio; I can find no standards document that says what it means, so it is literally meaningless as far as the standards go.
Assuming behavior analogous to stdout line buffering, the line buffering of stdin would require calling read() once for each ...
3
If I understand correctly, you want to detect when a.out is reading data from standard input, and when it does send it that data and also write that data to the same log file stdout is redirected to to simulate the local echo to the terminal when run interactively?
Then maybe a solution (bash syntax) would be something like:
mkfifo strace.fifo
{
while ...
2
standard input is a command that allows user to write to a file
Not a command, but a stream. Standard in and out are like mail boxes. When a program starts, it's given a box to recieve and a box to send mail. Usually, input comes from the keyboard and and is put in the in-box, mail put in the out-box ends up on your terminal screen.
standard output is a ...
2
Followin @userunknown suggestion, in case your /tmp is not a tmpfs type filesystem, then you can use /dev/shm or create your own tmpfs filesystem (both are held in memory):
/mnt/tmp && mount -t tmpfs none /mnt/tmp
2
I just found a small C program called writevt that does the trick. Grab the source code here. To make it compile with gcc just remove the following lines first:
#include <lct/cline.h>
#include <lct/utils.h>
Usage:
sudo writevt /dev/ttyN command
2
Curl can read passwords from ~/.netrc. Add a line like this to ~/.netrc:
machine bitbucket.org login schmijos password swordfish
and run
curl --netrc --digest --user schmijos https://bitbucket.org/u/p/get/tip.zip -o tip
2
Pipes are usual unix descriptors at the programmatic level. When you setup two programs to communicate through a pipe, all they see at first is the standard output and standard input descriptors, which they interact with, because the shell did setup them that way. There are some peculiarities with these descriptors when setup this way, but processi interact ...
2
At least Linux and BSDs have the TIOCSTI ioctl to push characters back to the terminal input buffer (up to a limit [4096 characters on Linux]):
#include <sys/ioctl.h>
#include <termios.h>
#include <stdio.h>
#include <stdlib.h>
void stackchar(char c)
{
if (ioctl(0, TIOCSTI, &c) < 0) {
perror("ioctl");
exit(1);
}
}
...
2
Text processing tools traditionally read input from standard input when you don't specify any file name on the command line. You can check whether there are command line arguments by testing the $# variable. Assuming that process_file reads from standard input if you don't pass it an argument:
if [ $# -eq 0 ]; then
process_file
else
for x; do
...
2
If you know you're never going to use grep to read from the terminal, you could redefine grep as:
grep() {
if [ -t 0 ]; then
< /dev/null command grep "$@"
else
command grep "$@"
fi
}
That will not give you any warning about you typo. But at least it will return without a match immediately. It will also affect behaviour when - or ...
2
When a program is launched (by one of the exec(3) family of system calls), it inherits the environment (i.e., shell variables exported) and the open files from the parent. What is done when launching a program is a fork(2), the child sets up the environment and files, then exec(3)s the new program. When a shell does this, STDIN, STDOUT and STDERR are ...
2
You need to send the entire program at once.
When you call run python < p1 the shell is waiting for input before invoking python. That is, python doesn't even begin executing at all until the entire data stream has been read by the shell and then is passed in its entirety to python.
Even running python -u p1 instead (that is, unbuffered and read from ...
2
You could do that with a simple script in which you print your special characters.
For example, in Perl, you can print any character by specifying its hexadecimal code. For example:
perl -e 'print "\x54\x0A"' prints a 'T' followed by a new line.
You can then copy the text printed, even if it not visible. Of course, your terminal must be in raw mode.
Only top voted, non community-wiki answers of a minimum length are eligible
