Hey,

I have some command, I'll call it "command".

I need to do this:
yes | command
but without a pipe, there is a reason for this, because for the specific use, pipe before the command
is not allowed, that's not the point.

Is there an alternative I can use which will output do the same thing without the pipe ?
Maybe something like this:
command < yes
(which will not work because it expects a file, and not a command)
?

Or some other simple way ?

Thanks

Dani AI

Generated

Short answer for : you can avoid the literal pipe operator while still giving a command an automatically repeating "y" by using the shell's process/file-descriptor features instead of a temporary file. These approaches avoid the simple "yes | command" form and sidestep creating a persistent file.

Here are two compact options (not using a plain tmp file or an explicit |):

# bash/ksh/zsh
command < <(yes)

This is process substitution: the shell presents command with something it can open as stdin. It works in bash/ksh/zsh but not in plain POSIX /bin/sh.

# bash only
coproc Y { yes; }
command <&"${Y[0]}"

A coprocess gives you a file descriptor you can attach to command's stdin. Both techniques avoid writing a real file on disk.

Notes and cautions: 's temp-file idea is simple but wasteful; is right to flag that yes is infinite — use a finite generator or a tool that limits runtime if you only need a few answers. Some programs ignore stdin and read /dev/tty; in that case piping or FD tricks won't work and you need an interaction tool like expect or the program's built-in noninteractive flag (eg. -y/--yes) if available.

Recommended Answers

All 5 Replies

You could try:

#/bin/sh
yes > /tmp/tmpout
command < /tmp/tmpout
rm /tmp/tmpout

You could even put it in a shell script, but then you could go back to using the pipe then as well.

The problem with redirecting to a file or using a subshell or similar technique is that the yes command is infinite. There is no terminating condition other than killing the process. There are ways to do this with other commands but something like yes is going to be problematic.
Is yes a requirement or did you serve it up as an example of what you are trying to do?

Do you know how many "y"s you need? Filter the output with head to restrict the number of lines.
yes | head -n 5 | command
When head closes its input after 5 lines, yes gets told its output has closed and it will stop. In the meantime, command is processing the output from head.

The problem, I believe, is not how to limit the output of yes; you've clearly demonstrated how to do that. I think the more difficult problem is doing that without using a pipe (thus preventing a 'broken pipe' from terminating yes).

You can easily embed the output from a shell command into the argument list of another command using backquotes. Example, if you want 'y' to be passed as the option "--accept=", try this:

command --accept=`yes | head -1`

To get that into the standard input stream you can do this (scripting is best since it requires at least 2 lines):

command <<EOF y
EOF

# or

command <<EOF `yes | head -1`
EOF
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.