Timeline for suppress stderr messages in a bash script
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 15 at 0:11 | comment | added | Tuaris |
Running exec 2> /dev/null appears to also disable local echo in Bash 5.x (no prompt and no characters printed on screen when typing.)
|
|
| Sep 10, 2019 at 21:01 | comment | added | fearless_fool |
FWIW, I favor Scott's grouped command approach, i.e. { sleep 10 & pkill sleep;} 2> /dev/null
|
|
| Sep 15, 2017 at 18:49 | comment | added | Scott - Слава Україні | Well, I suppose that, if you ran a program that (unbeknownst to you) wrote to file descriptor 3 (or 4), that operation would fail under normal circumstances. But the program could be written to ignore the failure and carry on without reporting it; then you’d never know. But if your file descriptor 1 (or 2) was “parked” on file descriptor 3 (or 4), then that program would suddenly be writing to your script’s stdout or stderr. But that’s a very contrived example, and still minimal danger. Did you have something in mind? | |
| Sep 15, 2017 at 18:37 | comment | added | Alexej Magura |
Are there any dangers associated with saving stdin and stderr to new file descriptors, sending the original descriptors to /dev/null and then restoring them?
|
|
| Sep 24, 2015 at 22:20 | vote | accept | fearless_fool | ||
| Feb 14, 2015 at 8:19 | history | answered | Scott - Слава Україні | CC BY-SA 3.0 |