Why does ''cat "$1:-/dev/stdin | … &>/dev/null'' work in bash but not dash?Why does redirection (>) not work sometimes but appending (>>) does?Why does the less-than sign not work as a replacement for cat in bash?How does `cat <> file` work?How to use namedpipe as temporary file?Why does dash expand \\ differently to bash?What is the difference between “cat file | ./binary” and “./binary < file”?Why might >/dev/null 2>&1 not work?Bash tcp redirection end of transmissionWhy bash “read -t 0” does not see input?How shell delivers user's input to program and shows program's output?
Boss making me feel guilty for leaving the company at the end of my internship
What is the color associated with lukewarm?
Is it possible to have battery technology that can't be duplicated?
Someone who is granted access to information but not expected to read it
Reflecting Telescope Blind Spot?
Background for black and white chart
A Tale of Snake and Coffee
Why not make one big CPU core?
Why can't we feel the Earth's revolution?
Must a CPU have a GPU if the motherboard provides a display port (when there isn't any separate video card)?
Can a 40amp breaker be used safely and without issue with a 40amp device on 6AWG wire?
What does the output current rating from an H-Bridge's datasheet really mean?
Bullying by school - Submitted PhD thesis but not allowed to proceed to viva until change to new supervisor
Cant bend fingertip when finger is straight
How would Japanese people react to someone refusing to say “itadakimasu” for religious reasons?
Do items with curse of vanishing disappear from shulker boxes?
Fastest path on a snakes and ladders board
The title "Mord mit Aussicht" explained
Co-worker is now managing my team. Does this mean that I'm being demoted?
Struggling to present results from long papers in short time slots
How could I create a situation in which a PC has to make a saving throw or be forced to pet a dog?
Using roof rails to set up hammock
How many times to repeat an event with known probability before it has occurred a number of times
My parents claim they cannot pay for my college education; what are my options?
Why does ''cat "$1:-/dev/stdin | … &>/dev/null'' work in bash but not dash?
Why does redirection (>) not work sometimes but appending (>>) does?Why does the less-than sign not work as a replacement for cat in bash?How does `cat <> file` work?How to use namedpipe as temporary file?Why does dash expand \\ differently to bash?What is the difference between “cat file | ./binary” and “./binary < file”?Why might >/dev/null 2>&1 not work?Bash tcp redirection end of transmissionWhy bash “read -t 0” does not see input?How shell delivers user's input to program and shows program's output?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
Script:
#!/bin/sh
#
# reads stdin/file and copies it to clipboard
# clears it after 30s
#
cat "$1:-/dev/stdin" | timeout 30 xclip -i -selection clipboard -r -verbose &>/dev/null &
I can see that only stdin does not work (with bash it works on stdin/file).
P.S. verbose is used to make xclip not daemonize.
bash shell pipe io-redirection dash
|
show 5 more comments
Script:
#!/bin/sh
#
# reads stdin/file and copies it to clipboard
# clears it after 30s
#
cat "$1:-/dev/stdin" | timeout 30 xclip -i -selection clipboard -r -verbose &>/dev/null &
I can see that only stdin does not work (with bash it works on stdin/file).
P.S. verbose is used to make xclip not daemonize.
bash shell pipe io-redirection dash
That won't work with/dev/stdineven with bash. Since you're running with the pipeline put in the background (terminated with&)cat /dev/stdinwill either have its stdin redirected from/dev/null(when running in a script) or will be stopped by aSIGTTINsignal (when running in an interactive shell).
– mosvy
Jun 6 at 22:39
you sure about the second? because it works (bash) in my terminalecho 123 | script. Is there anyway I can do what I want to do?
– droso
Jun 6 at 22:49
Look at end of the pipeline in your Q. There's a&at the end -- the shell won't treat it as decoration ;-)
– mosvy
Jun 6 at 22:51
of course not but whole script will work in the foreground (because of -verbose but -verbose is needed to make timeout work)
– droso
Jun 6 at 22:58
Try this in your script:exec 3<"$1:-/dev/stdin"; cat <&3 | ... &.
– mosvy
Jun 6 at 22:59
|
show 5 more comments
Script:
#!/bin/sh
#
# reads stdin/file and copies it to clipboard
# clears it after 30s
#
cat "$1:-/dev/stdin" | timeout 30 xclip -i -selection clipboard -r -verbose &>/dev/null &
I can see that only stdin does not work (with bash it works on stdin/file).
P.S. verbose is used to make xclip not daemonize.
bash shell pipe io-redirection dash
Script:
#!/bin/sh
#
# reads stdin/file and copies it to clipboard
# clears it after 30s
#
cat "$1:-/dev/stdin" | timeout 30 xclip -i -selection clipboard -r -verbose &>/dev/null &
I can see that only stdin does not work (with bash it works on stdin/file).
P.S. verbose is used to make xclip not daemonize.
bash shell pipe io-redirection dash
bash shell pipe io-redirection dash
edited Jun 7 at 20:38
Charles Duffy
852615
852615
asked Jun 6 at 22:10
drosodroso
267
267
That won't work with/dev/stdineven with bash. Since you're running with the pipeline put in the background (terminated with&)cat /dev/stdinwill either have its stdin redirected from/dev/null(when running in a script) or will be stopped by aSIGTTINsignal (when running in an interactive shell).
– mosvy
Jun 6 at 22:39
you sure about the second? because it works (bash) in my terminalecho 123 | script. Is there anyway I can do what I want to do?
– droso
Jun 6 at 22:49
Look at end of the pipeline in your Q. There's a&at the end -- the shell won't treat it as decoration ;-)
– mosvy
Jun 6 at 22:51
of course not but whole script will work in the foreground (because of -verbose but -verbose is needed to make timeout work)
– droso
Jun 6 at 22:58
Try this in your script:exec 3<"$1:-/dev/stdin"; cat <&3 | ... &.
– mosvy
Jun 6 at 22:59
|
show 5 more comments
That won't work with/dev/stdineven with bash. Since you're running with the pipeline put in the background (terminated with&)cat /dev/stdinwill either have its stdin redirected from/dev/null(when running in a script) or will be stopped by aSIGTTINsignal (when running in an interactive shell).
– mosvy
Jun 6 at 22:39
you sure about the second? because it works (bash) in my terminalecho 123 | script. Is there anyway I can do what I want to do?
– droso
Jun 6 at 22:49
Look at end of the pipeline in your Q. There's a&at the end -- the shell won't treat it as decoration ;-)
– mosvy
Jun 6 at 22:51
of course not but whole script will work in the foreground (because of -verbose but -verbose is needed to make timeout work)
– droso
Jun 6 at 22:58
Try this in your script:exec 3<"$1:-/dev/stdin"; cat <&3 | ... &.
– mosvy
Jun 6 at 22:59
That won't work with
/dev/stdin even with bash. Since you're running with the pipeline put in the background (terminated with &) cat /dev/stdin will either have its stdin redirected from /dev/null (when running in a script) or will be stopped by a SIGTTIN signal (when running in an interactive shell).– mosvy
Jun 6 at 22:39
That won't work with
/dev/stdin even with bash. Since you're running with the pipeline put in the background (terminated with &) cat /dev/stdin will either have its stdin redirected from /dev/null (when running in a script) or will be stopped by a SIGTTIN signal (when running in an interactive shell).– mosvy
Jun 6 at 22:39
you sure about the second? because it works (bash) in my terminal
echo 123 | script. Is there anyway I can do what I want to do?– droso
Jun 6 at 22:49
you sure about the second? because it works (bash) in my terminal
echo 123 | script. Is there anyway I can do what I want to do?– droso
Jun 6 at 22:49
Look at end of the pipeline in your Q. There's a
& at the end -- the shell won't treat it as decoration ;-)– mosvy
Jun 6 at 22:51
Look at end of the pipeline in your Q. There's a
& at the end -- the shell won't treat it as decoration ;-)– mosvy
Jun 6 at 22:51
of course not but whole script will work in the foreground (because of -verbose but -verbose is needed to make timeout work)
– droso
Jun 6 at 22:58
of course not but whole script will work in the foreground (because of -verbose but -verbose is needed to make timeout work)
– droso
Jun 6 at 22:58
Try this in your script:
exec 3<"$1:-/dev/stdin"; cat <&3 | ... &.– mosvy
Jun 6 at 22:59
Try this in your script:
exec 3<"$1:-/dev/stdin"; cat <&3 | ... &.– mosvy
Jun 6 at 22:59
|
show 5 more comments
3 Answers
3
active
oldest
votes
[this answer is about asynchronous pipelines in scripts; for the deprecated &> bash operator and why you should always use >output 2>&1 instead, refer to obsolete and deprecated syntax]
#! /bin/sh
cat "$1:-/dev/stdin" | ... &
Here you have a pipeline running asynchronously (because terminated by &), started from a script, ie is from a shell with the job control disabled.
According to the standard:
command1 & [command2 & ... ]
The standard input for an asynchronous list, before any explicit
redirections are performed, shall be considered to be assigned to a file that has the same properties as/dev/null.
The problem is that dash, ksh, mksh, yash, etc intepret "asynchronous list" as any command, including a pipeline, and will redirect the stdin of the first command from /dev/null:
$ echo foo | dash -c 'cat | tr fo FO & echo DONE'
DONE
$ echo | dash -c 'readlink /proc/self/fd/0 | cat & echo DONE'
DONE
/dev/null
But bash will only interpret it as "simple command" and will only redirect its stdin from /dev/null when it's not part of a pipeline:
$ echo foo | bash -c 'cat | tr fo FO & echo DONE'
DONE
FOO
$ echo | bash -c 'readlink /proc/self/fd/0 | cat & echo DONE'
DONE
pipe:[69872]
$ echo | bash -c 'readlink /proc/self/fd/0 & echo DONE'
DONE
/dev/null
$ bash -c 'cat | tr a A & echo DONE'
DONE
cat: -: Input/output error
zsh will only redirect it from /dev/null when the original stdin is a tty, not when it's other kind of file:
$ zsh -c 'readlink /proc/self/fd/0 &' </dev/tty
/dev/null
$ zsh -c 'readlink /proc/self/fd/0 &' </dev/zero
/dev/zero
A workaround which works in all shells is to duplicate the stdin into another file descriptor, and redirect the stdin of the first command from it:
#! /bin/sh
exec 3<"$1:-/dev/stdin"
cat <&3 | timeout 30 xclip -i -selection clipboard -verbose -r >/dev/null 2>&1 &
add a comment |
&> is a bashism, you will have to change it to >/dev/null 2>&1 for POSIX shells
1
Now stdout is suppressed like it should be thank you BUT stdin is still not working ($1 works). Also I had to use>/dev/null 2>&1
– droso
Jun 6 at 22:22
add a comment |
dash positioned as POSIX standard. POSIX specified only [n]> redirection. But bash introduces many own features. &> is one of them and means output descriptors (stderr and stdout).
You should read article about bash and dash compatibility.
Maybe you get helpful checkbashisms utility which can helps to find bash-specific instructions in your scripts.
1
&>is only stdout and stderr, not "all" file descriptors. (It's also considered obsolescent and not suggested for use, even in bash).
– Charles Duffy
Jun 7 at 18:58
@CharlesDuffy Thank's for correction. I've just fixed it in the own answer!
– Yurij Goncharuk
Jun 7 at 20:31
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f523421%2fwhy-does-cat-1-dev-stdin-dev-null-work-in-bash-but-not-dash%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
[this answer is about asynchronous pipelines in scripts; for the deprecated &> bash operator and why you should always use >output 2>&1 instead, refer to obsolete and deprecated syntax]
#! /bin/sh
cat "$1:-/dev/stdin" | ... &
Here you have a pipeline running asynchronously (because terminated by &), started from a script, ie is from a shell with the job control disabled.
According to the standard:
command1 & [command2 & ... ]
The standard input for an asynchronous list, before any explicit
redirections are performed, shall be considered to be assigned to a file that has the same properties as/dev/null.
The problem is that dash, ksh, mksh, yash, etc intepret "asynchronous list" as any command, including a pipeline, and will redirect the stdin of the first command from /dev/null:
$ echo foo | dash -c 'cat | tr fo FO & echo DONE'
DONE
$ echo | dash -c 'readlink /proc/self/fd/0 | cat & echo DONE'
DONE
/dev/null
But bash will only interpret it as "simple command" and will only redirect its stdin from /dev/null when it's not part of a pipeline:
$ echo foo | bash -c 'cat | tr fo FO & echo DONE'
DONE
FOO
$ echo | bash -c 'readlink /proc/self/fd/0 | cat & echo DONE'
DONE
pipe:[69872]
$ echo | bash -c 'readlink /proc/self/fd/0 & echo DONE'
DONE
/dev/null
$ bash -c 'cat | tr a A & echo DONE'
DONE
cat: -: Input/output error
zsh will only redirect it from /dev/null when the original stdin is a tty, not when it's other kind of file:
$ zsh -c 'readlink /proc/self/fd/0 &' </dev/tty
/dev/null
$ zsh -c 'readlink /proc/self/fd/0 &' </dev/zero
/dev/zero
A workaround which works in all shells is to duplicate the stdin into another file descriptor, and redirect the stdin of the first command from it:
#! /bin/sh
exec 3<"$1:-/dev/stdin"
cat <&3 | timeout 30 xclip -i -selection clipboard -verbose -r >/dev/null 2>&1 &
add a comment |
[this answer is about asynchronous pipelines in scripts; for the deprecated &> bash operator and why you should always use >output 2>&1 instead, refer to obsolete and deprecated syntax]
#! /bin/sh
cat "$1:-/dev/stdin" | ... &
Here you have a pipeline running asynchronously (because terminated by &), started from a script, ie is from a shell with the job control disabled.
According to the standard:
command1 & [command2 & ... ]
The standard input for an asynchronous list, before any explicit
redirections are performed, shall be considered to be assigned to a file that has the same properties as/dev/null.
The problem is that dash, ksh, mksh, yash, etc intepret "asynchronous list" as any command, including a pipeline, and will redirect the stdin of the first command from /dev/null:
$ echo foo | dash -c 'cat | tr fo FO & echo DONE'
DONE
$ echo | dash -c 'readlink /proc/self/fd/0 | cat & echo DONE'
DONE
/dev/null
But bash will only interpret it as "simple command" and will only redirect its stdin from /dev/null when it's not part of a pipeline:
$ echo foo | bash -c 'cat | tr fo FO & echo DONE'
DONE
FOO
$ echo | bash -c 'readlink /proc/self/fd/0 | cat & echo DONE'
DONE
pipe:[69872]
$ echo | bash -c 'readlink /proc/self/fd/0 & echo DONE'
DONE
/dev/null
$ bash -c 'cat | tr a A & echo DONE'
DONE
cat: -: Input/output error
zsh will only redirect it from /dev/null when the original stdin is a tty, not when it's other kind of file:
$ zsh -c 'readlink /proc/self/fd/0 &' </dev/tty
/dev/null
$ zsh -c 'readlink /proc/self/fd/0 &' </dev/zero
/dev/zero
A workaround which works in all shells is to duplicate the stdin into another file descriptor, and redirect the stdin of the first command from it:
#! /bin/sh
exec 3<"$1:-/dev/stdin"
cat <&3 | timeout 30 xclip -i -selection clipboard -verbose -r >/dev/null 2>&1 &
add a comment |
[this answer is about asynchronous pipelines in scripts; for the deprecated &> bash operator and why you should always use >output 2>&1 instead, refer to obsolete and deprecated syntax]
#! /bin/sh
cat "$1:-/dev/stdin" | ... &
Here you have a pipeline running asynchronously (because terminated by &), started from a script, ie is from a shell with the job control disabled.
According to the standard:
command1 & [command2 & ... ]
The standard input for an asynchronous list, before any explicit
redirections are performed, shall be considered to be assigned to a file that has the same properties as/dev/null.
The problem is that dash, ksh, mksh, yash, etc intepret "asynchronous list" as any command, including a pipeline, and will redirect the stdin of the first command from /dev/null:
$ echo foo | dash -c 'cat | tr fo FO & echo DONE'
DONE
$ echo | dash -c 'readlink /proc/self/fd/0 | cat & echo DONE'
DONE
/dev/null
But bash will only interpret it as "simple command" and will only redirect its stdin from /dev/null when it's not part of a pipeline:
$ echo foo | bash -c 'cat | tr fo FO & echo DONE'
DONE
FOO
$ echo | bash -c 'readlink /proc/self/fd/0 | cat & echo DONE'
DONE
pipe:[69872]
$ echo | bash -c 'readlink /proc/self/fd/0 & echo DONE'
DONE
/dev/null
$ bash -c 'cat | tr a A & echo DONE'
DONE
cat: -: Input/output error
zsh will only redirect it from /dev/null when the original stdin is a tty, not when it's other kind of file:
$ zsh -c 'readlink /proc/self/fd/0 &' </dev/tty
/dev/null
$ zsh -c 'readlink /proc/self/fd/0 &' </dev/zero
/dev/zero
A workaround which works in all shells is to duplicate the stdin into another file descriptor, and redirect the stdin of the first command from it:
#! /bin/sh
exec 3<"$1:-/dev/stdin"
cat <&3 | timeout 30 xclip -i -selection clipboard -verbose -r >/dev/null 2>&1 &
[this answer is about asynchronous pipelines in scripts; for the deprecated &> bash operator and why you should always use >output 2>&1 instead, refer to obsolete and deprecated syntax]
#! /bin/sh
cat "$1:-/dev/stdin" | ... &
Here you have a pipeline running asynchronously (because terminated by &), started from a script, ie is from a shell with the job control disabled.
According to the standard:
command1 & [command2 & ... ]
The standard input for an asynchronous list, before any explicit
redirections are performed, shall be considered to be assigned to a file that has the same properties as/dev/null.
The problem is that dash, ksh, mksh, yash, etc intepret "asynchronous list" as any command, including a pipeline, and will redirect the stdin of the first command from /dev/null:
$ echo foo | dash -c 'cat | tr fo FO & echo DONE'
DONE
$ echo | dash -c 'readlink /proc/self/fd/0 | cat & echo DONE'
DONE
/dev/null
But bash will only interpret it as "simple command" and will only redirect its stdin from /dev/null when it's not part of a pipeline:
$ echo foo | bash -c 'cat | tr fo FO & echo DONE'
DONE
FOO
$ echo | bash -c 'readlink /proc/self/fd/0 | cat & echo DONE'
DONE
pipe:[69872]
$ echo | bash -c 'readlink /proc/self/fd/0 & echo DONE'
DONE
/dev/null
$ bash -c 'cat | tr a A & echo DONE'
DONE
cat: -: Input/output error
zsh will only redirect it from /dev/null when the original stdin is a tty, not when it's other kind of file:
$ zsh -c 'readlink /proc/self/fd/0 &' </dev/tty
/dev/null
$ zsh -c 'readlink /proc/self/fd/0 &' </dev/zero
/dev/zero
A workaround which works in all shells is to duplicate the stdin into another file descriptor, and redirect the stdin of the first command from it:
#! /bin/sh
exec 3<"$1:-/dev/stdin"
cat <&3 | timeout 30 xclip -i -selection clipboard -verbose -r >/dev/null 2>&1 &
edited Jun 7 at 18:59
Jeff Schaller♦
46.6k1167152
46.6k1167152
answered Jun 7 at 10:42
mosvymosvy
13.5k21546
13.5k21546
add a comment |
add a comment |
&> is a bashism, you will have to change it to >/dev/null 2>&1 for POSIX shells
1
Now stdout is suppressed like it should be thank you BUT stdin is still not working ($1 works). Also I had to use>/dev/null 2>&1
– droso
Jun 6 at 22:22
add a comment |
&> is a bashism, you will have to change it to >/dev/null 2>&1 for POSIX shells
1
Now stdout is suppressed like it should be thank you BUT stdin is still not working ($1 works). Also I had to use>/dev/null 2>&1
– droso
Jun 6 at 22:22
add a comment |
&> is a bashism, you will have to change it to >/dev/null 2>&1 for POSIX shells
&> is a bashism, you will have to change it to >/dev/null 2>&1 for POSIX shells
edited Jun 7 at 19:11
Michael Mior
22528
22528
answered Jun 6 at 22:13
Jesse_bJesse_b
16.5k34083
16.5k34083
1
Now stdout is suppressed like it should be thank you BUT stdin is still not working ($1 works). Also I had to use>/dev/null 2>&1
– droso
Jun 6 at 22:22
add a comment |
1
Now stdout is suppressed like it should be thank you BUT stdin is still not working ($1 works). Also I had to use>/dev/null 2>&1
– droso
Jun 6 at 22:22
1
1
Now stdout is suppressed like it should be thank you BUT stdin is still not working ($1 works). Also I had to use
>/dev/null 2>&1– droso
Jun 6 at 22:22
Now stdout is suppressed like it should be thank you BUT stdin is still not working ($1 works). Also I had to use
>/dev/null 2>&1– droso
Jun 6 at 22:22
add a comment |
dash positioned as POSIX standard. POSIX specified only [n]> redirection. But bash introduces many own features. &> is one of them and means output descriptors (stderr and stdout).
You should read article about bash and dash compatibility.
Maybe you get helpful checkbashisms utility which can helps to find bash-specific instructions in your scripts.
1
&>is only stdout and stderr, not "all" file descriptors. (It's also considered obsolescent and not suggested for use, even in bash).
– Charles Duffy
Jun 7 at 18:58
@CharlesDuffy Thank's for correction. I've just fixed it in the own answer!
– Yurij Goncharuk
Jun 7 at 20:31
add a comment |
dash positioned as POSIX standard. POSIX specified only [n]> redirection. But bash introduces many own features. &> is one of them and means output descriptors (stderr and stdout).
You should read article about bash and dash compatibility.
Maybe you get helpful checkbashisms utility which can helps to find bash-specific instructions in your scripts.
1
&>is only stdout and stderr, not "all" file descriptors. (It's also considered obsolescent and not suggested for use, even in bash).
– Charles Duffy
Jun 7 at 18:58
@CharlesDuffy Thank's for correction. I've just fixed it in the own answer!
– Yurij Goncharuk
Jun 7 at 20:31
add a comment |
dash positioned as POSIX standard. POSIX specified only [n]> redirection. But bash introduces many own features. &> is one of them and means output descriptors (stderr and stdout).
You should read article about bash and dash compatibility.
Maybe you get helpful checkbashisms utility which can helps to find bash-specific instructions in your scripts.
dash positioned as POSIX standard. POSIX specified only [n]> redirection. But bash introduces many own features. &> is one of them and means output descriptors (stderr and stdout).
You should read article about bash and dash compatibility.
Maybe you get helpful checkbashisms utility which can helps to find bash-specific instructions in your scripts.
edited Jun 7 at 20:31
answered Jun 6 at 22:48
Yurij GoncharukYurij Goncharuk
3,0902928
3,0902928
1
&>is only stdout and stderr, not "all" file descriptors. (It's also considered obsolescent and not suggested for use, even in bash).
– Charles Duffy
Jun 7 at 18:58
@CharlesDuffy Thank's for correction. I've just fixed it in the own answer!
– Yurij Goncharuk
Jun 7 at 20:31
add a comment |
1
&>is only stdout and stderr, not "all" file descriptors. (It's also considered obsolescent and not suggested for use, even in bash).
– Charles Duffy
Jun 7 at 18:58
@CharlesDuffy Thank's for correction. I've just fixed it in the own answer!
– Yurij Goncharuk
Jun 7 at 20:31
1
1
&> is only stdout and stderr, not "all" file descriptors. (It's also considered obsolescent and not suggested for use, even in bash).– Charles Duffy
Jun 7 at 18:58
&> is only stdout and stderr, not "all" file descriptors. (It's also considered obsolescent and not suggested for use, even in bash).– Charles Duffy
Jun 7 at 18:58
@CharlesDuffy Thank's for correction. I've just fixed it in the own answer!
– Yurij Goncharuk
Jun 7 at 20:31
@CharlesDuffy Thank's for correction. I've just fixed it in the own answer!
– Yurij Goncharuk
Jun 7 at 20:31
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f523421%2fwhy-does-cat-1-dev-stdin-dev-null-work-in-bash-but-not-dash%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
That won't work with
/dev/stdineven with bash. Since you're running with the pipeline put in the background (terminated with&)cat /dev/stdinwill either have its stdin redirected from/dev/null(when running in a script) or will be stopped by aSIGTTINsignal (when running in an interactive shell).– mosvy
Jun 6 at 22:39
you sure about the second? because it works (bash) in my terminal
echo 123 | script. Is there anyway I can do what I want to do?– droso
Jun 6 at 22:49
Look at end of the pipeline in your Q. There's a
&at the end -- the shell won't treat it as decoration ;-)– mosvy
Jun 6 at 22:51
of course not but whole script will work in the foreground (because of -verbose but -verbose is needed to make timeout work)
– droso
Jun 6 at 22:58
Try this in your script:
exec 3<"$1:-/dev/stdin"; cat <&3 | ... &.– mosvy
Jun 6 at 22:59