Redirect stdout and/or stderr to path in variable

Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
How do I redirect stdout and/or stderr to a path I have specified in a variable? Note: I don't want to overwrite the variable itself, I want to make std[xxx] write to the file specified in the variable.
For example- a simple script that, if the scp command fails, instead of printing the failure message to stderr or stdout (I'm not sure to which it outputs when fail), it outputs it to a specified log file. The path to the log file is stored in the $LOG variable:
LOG=/path/to/file.log
scp file1 host@remote
# do 'whatever' if scp command succeeds:
if [ $? = 0 ];
then
whatever
else
# else log both stdout/stderr to $LOG file
&>"$LOG"
# DEBUG - print contents of $LOG var for testing purposes
printf "$LOG"
The result of this script doesn't show anything in the /path/to/file.log file and simple prints /path/to/file.log to stdout. So it's as if nothing was written from &>.
I've already confirmed my particular scp command works, so I know that's not a potential issue.
Or is this even the most proper way to handle custom log files? Is there a better practice for configuring your own logging system than storing paths to log files in variables?
shell-script io-redirection variable stdout stderr
add a comment |Â
up vote
1
down vote
favorite
How do I redirect stdout and/or stderr to a path I have specified in a variable? Note: I don't want to overwrite the variable itself, I want to make std[xxx] write to the file specified in the variable.
For example- a simple script that, if the scp command fails, instead of printing the failure message to stderr or stdout (I'm not sure to which it outputs when fail), it outputs it to a specified log file. The path to the log file is stored in the $LOG variable:
LOG=/path/to/file.log
scp file1 host@remote
# do 'whatever' if scp command succeeds:
if [ $? = 0 ];
then
whatever
else
# else log both stdout/stderr to $LOG file
&>"$LOG"
# DEBUG - print contents of $LOG var for testing purposes
printf "$LOG"
The result of this script doesn't show anything in the /path/to/file.log file and simple prints /path/to/file.log to stdout. So it's as if nothing was written from &>.
I've already confirmed my particular scp command works, so I know that's not a potential issue.
Or is this even the most proper way to handle custom log files? Is there a better practice for configuring your own logging system than storing paths to log files in variables?
shell-script io-redirection variable stdout stderr
3
The redirection would have to happen beforescpis run, or with thescpline, not after thescphas already gone away.
â thrig
Nov 18 '17 at 15:05
Why not unconditionally write to a temporary file and then test for success/failure? If failure, add the output to your permanent log file or print and discard it.
â JRFerguson
Nov 18 '17 at 15:13
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
How do I redirect stdout and/or stderr to a path I have specified in a variable? Note: I don't want to overwrite the variable itself, I want to make std[xxx] write to the file specified in the variable.
For example- a simple script that, if the scp command fails, instead of printing the failure message to stderr or stdout (I'm not sure to which it outputs when fail), it outputs it to a specified log file. The path to the log file is stored in the $LOG variable:
LOG=/path/to/file.log
scp file1 host@remote
# do 'whatever' if scp command succeeds:
if [ $? = 0 ];
then
whatever
else
# else log both stdout/stderr to $LOG file
&>"$LOG"
# DEBUG - print contents of $LOG var for testing purposes
printf "$LOG"
The result of this script doesn't show anything in the /path/to/file.log file and simple prints /path/to/file.log to stdout. So it's as if nothing was written from &>.
I've already confirmed my particular scp command works, so I know that's not a potential issue.
Or is this even the most proper way to handle custom log files? Is there a better practice for configuring your own logging system than storing paths to log files in variables?
shell-script io-redirection variable stdout stderr
How do I redirect stdout and/or stderr to a path I have specified in a variable? Note: I don't want to overwrite the variable itself, I want to make std[xxx] write to the file specified in the variable.
For example- a simple script that, if the scp command fails, instead of printing the failure message to stderr or stdout (I'm not sure to which it outputs when fail), it outputs it to a specified log file. The path to the log file is stored in the $LOG variable:
LOG=/path/to/file.log
scp file1 host@remote
# do 'whatever' if scp command succeeds:
if [ $? = 0 ];
then
whatever
else
# else log both stdout/stderr to $LOG file
&>"$LOG"
# DEBUG - print contents of $LOG var for testing purposes
printf "$LOG"
The result of this script doesn't show anything in the /path/to/file.log file and simple prints /path/to/file.log to stdout. So it's as if nothing was written from &>.
I've already confirmed my particular scp command works, so I know that's not a potential issue.
Or is this even the most proper way to handle custom log files? Is there a better practice for configuring your own logging system than storing paths to log files in variables?
shell-script io-redirection variable stdout stderr
edited Nov 18 '17 at 15:33
Jeff Schaller
32.1k849109
32.1k849109
asked Nov 18 '17 at 15:04
Willman
84
84
3
The redirection would have to happen beforescpis run, or with thescpline, not after thescphas already gone away.
â thrig
Nov 18 '17 at 15:05
Why not unconditionally write to a temporary file and then test for success/failure? If failure, add the output to your permanent log file or print and discard it.
â JRFerguson
Nov 18 '17 at 15:13
add a comment |Â
3
The redirection would have to happen beforescpis run, or with thescpline, not after thescphas already gone away.
â thrig
Nov 18 '17 at 15:05
Why not unconditionally write to a temporary file and then test for success/failure? If failure, add the output to your permanent log file or print and discard it.
â JRFerguson
Nov 18 '17 at 15:13
3
3
The redirection would have to happen before
scp is run, or with the scp line, not after the scp has already gone away.â thrig
Nov 18 '17 at 15:05
The redirection would have to happen before
scp is run, or with the scp line, not after the scp has already gone away.â thrig
Nov 18 '17 at 15:05
Why not unconditionally write to a temporary file and then test for success/failure? If failure, add the output to your permanent log file or print and discard it.
â JRFerguson
Nov 18 '17 at 15:13
Why not unconditionally write to a temporary file and then test for success/failure? If failure, add the output to your permanent log file or print and discard it.
â JRFerguson
Nov 18 '17 at 15:13
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
0
down vote
accepted
It looks like you're trying to log the output after you run the command, which isn't possible.
If you want to log the output of the scp command unconditionally, then you just have to include the redirection operator on the same line as the command itself, i.e.:
&>"$LOG" scp file1 host@remote
If you want to only save the log output if the command fails (as it appears you're trying to do in your code), then how about redirecting the output to a temporary file and then moving the file to the desired location afterwards? It might look something like this:
#!/bin/bash
# Set path the real log file location
LOG=/path/to/file.log
# Create a temporary file to capture standard output and standard error
TEMPLOG="$(mktemp)"
# Run command and redirect output to temporary logfile
2>"$TEMPLOG" scp file1 host@remote
# do 'whatever' if scp command succeeds:
if [ $? = 0 ];
then
echo 'Command successful!'
# else log both stdout/stderr to $LOG file
else
# Move the log file from the temporary location to the desired location
mv "$TEMPLOG" "$LOG"
# DEBUG - print contents of $LOG var for testing purposes
printf "$LOG"
fi
Ok I see. I'd thought&>would've been handled in the same way$?is- the output of the last command. But I see now that$?is the "exit status", NOT "standard output" of the prev. command. Ok so this answers the main question, but would this be the most elegant solution for custom logging? Is there a way to avoid using temp files for output? I can see this getting out of hand in very large/multiple scripts or with multiple different log files.
â Willman
Nov 18 '17 at 16:30
@Willman I'm not sure what the most elegant way would be to implement logging in a shell script. If there's something better than just redirecting the output you want to a file then I haven't seen it. If you're on Linux then you might also consider using the logger command to write to the system logs, but I don't have any experience with that and I'm not sure that there would be any benefit to it. Maybe check out this post: Understand logging in Linux
â igal
Nov 18 '17 at 16:46
@Willman Themktempcommand should make sure that there are no naming conflicts. Why would the temporary files get out of hand? To me it seems like the version of your script which temporary files is no less manageable than the the version of your script without them.
â igal
Nov 18 '17 at 16:47
Ok so&>"$LOG" scp file host@remotesuccessfully sends output to the/path/to/file.loglike I want. This is the elegant solution I was talking about. I just didn't want to create unnecessary temp files on disk when I can just use I/O redirection and bash variables instead. (BTW to answer my side question- scp prints tostdoutwhen there is a permissions issue on remote dir, notstderrfor some reason).
â Willman
Nov 18 '17 at 16:57
@Willman Ah, ok. Based on the example code in your question I thought you only wanted to write the log file if the command failed. If you just wanted to log all of the output no matter what then that one-liner is definitely the most straight-forward thing to do.
â igal
Nov 18 '17 at 17:09
 |Â
show 2 more comments
up vote
0
down vote
It looks like you were eventually satisfied with the outcome of this question but I propose something different.
#!/bin/bash
LOG=/path/to/file.log
DEBUG=0 # 0 = True, 1 = False
OUTPUT=$(scp file1 host@remote 2>&1)
# do 'whatever' if scp command succeeds:
if [ $? -eq 0 ];
then
echo "Success"
elif [[ DEBUG -eq 0 ]]
# else log both stdout/stderr to $LOG file and user
# DEBUG - Use tee to display $LOG contents efficiently
printf "$OUTPUT" | tee $LOG
else
# Send output to $LOG
printf "$OUTPUT" >> $LOG
fi
Essentially capture STDIN/STDOUT in a variable no matter what, then if success do 'whatever' but if failure redirect STDIN/STDOUT to $LOG. Additionally with the $DEBUG flag you can tee the contents of $OUTPUT to the display and $LOG simultaneously.
Also for integer comparison you really should use -eq instead of = or ==
Note that the value of$?at the point where you access it will be the return code of the assignmentDEBUG=0.$?will be non-zero if that assignment fails (which is possible ifDEBUGis a read-only variable). Also note that your calls toechowill remove any newlines from the value$OUTPUT, and that there is also athenmissing.
â Kusalananda
Apr 6 at 14:49
Ah, yeah the $? is referencing the wrong thing, DEBUG was an afterthought but I'll fix it.echodoes in fact remove the newlines soprintfis better if you want to preserve. Whichthenare you referring to, it is on the line after theifstatement just to be consistent with the original post?
â Amos Baker
Apr 6 at 16:04
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
It looks like you're trying to log the output after you run the command, which isn't possible.
If you want to log the output of the scp command unconditionally, then you just have to include the redirection operator on the same line as the command itself, i.e.:
&>"$LOG" scp file1 host@remote
If you want to only save the log output if the command fails (as it appears you're trying to do in your code), then how about redirecting the output to a temporary file and then moving the file to the desired location afterwards? It might look something like this:
#!/bin/bash
# Set path the real log file location
LOG=/path/to/file.log
# Create a temporary file to capture standard output and standard error
TEMPLOG="$(mktemp)"
# Run command and redirect output to temporary logfile
2>"$TEMPLOG" scp file1 host@remote
# do 'whatever' if scp command succeeds:
if [ $? = 0 ];
then
echo 'Command successful!'
# else log both stdout/stderr to $LOG file
else
# Move the log file from the temporary location to the desired location
mv "$TEMPLOG" "$LOG"
# DEBUG - print contents of $LOG var for testing purposes
printf "$LOG"
fi
Ok I see. I'd thought&>would've been handled in the same way$?is- the output of the last command. But I see now that$?is the "exit status", NOT "standard output" of the prev. command. Ok so this answers the main question, but would this be the most elegant solution for custom logging? Is there a way to avoid using temp files for output? I can see this getting out of hand in very large/multiple scripts or with multiple different log files.
â Willman
Nov 18 '17 at 16:30
@Willman I'm not sure what the most elegant way would be to implement logging in a shell script. If there's something better than just redirecting the output you want to a file then I haven't seen it. If you're on Linux then you might also consider using the logger command to write to the system logs, but I don't have any experience with that and I'm not sure that there would be any benefit to it. Maybe check out this post: Understand logging in Linux
â igal
Nov 18 '17 at 16:46
@Willman Themktempcommand should make sure that there are no naming conflicts. Why would the temporary files get out of hand? To me it seems like the version of your script which temporary files is no less manageable than the the version of your script without them.
â igal
Nov 18 '17 at 16:47
Ok so&>"$LOG" scp file host@remotesuccessfully sends output to the/path/to/file.loglike I want. This is the elegant solution I was talking about. I just didn't want to create unnecessary temp files on disk when I can just use I/O redirection and bash variables instead. (BTW to answer my side question- scp prints tostdoutwhen there is a permissions issue on remote dir, notstderrfor some reason).
â Willman
Nov 18 '17 at 16:57
@Willman Ah, ok. Based on the example code in your question I thought you only wanted to write the log file if the command failed. If you just wanted to log all of the output no matter what then that one-liner is definitely the most straight-forward thing to do.
â igal
Nov 18 '17 at 17:09
 |Â
show 2 more comments
up vote
0
down vote
accepted
It looks like you're trying to log the output after you run the command, which isn't possible.
If you want to log the output of the scp command unconditionally, then you just have to include the redirection operator on the same line as the command itself, i.e.:
&>"$LOG" scp file1 host@remote
If you want to only save the log output if the command fails (as it appears you're trying to do in your code), then how about redirecting the output to a temporary file and then moving the file to the desired location afterwards? It might look something like this:
#!/bin/bash
# Set path the real log file location
LOG=/path/to/file.log
# Create a temporary file to capture standard output and standard error
TEMPLOG="$(mktemp)"
# Run command and redirect output to temporary logfile
2>"$TEMPLOG" scp file1 host@remote
# do 'whatever' if scp command succeeds:
if [ $? = 0 ];
then
echo 'Command successful!'
# else log both stdout/stderr to $LOG file
else
# Move the log file from the temporary location to the desired location
mv "$TEMPLOG" "$LOG"
# DEBUG - print contents of $LOG var for testing purposes
printf "$LOG"
fi
Ok I see. I'd thought&>would've been handled in the same way$?is- the output of the last command. But I see now that$?is the "exit status", NOT "standard output" of the prev. command. Ok so this answers the main question, but would this be the most elegant solution for custom logging? Is there a way to avoid using temp files for output? I can see this getting out of hand in very large/multiple scripts or with multiple different log files.
â Willman
Nov 18 '17 at 16:30
@Willman I'm not sure what the most elegant way would be to implement logging in a shell script. If there's something better than just redirecting the output you want to a file then I haven't seen it. If you're on Linux then you might also consider using the logger command to write to the system logs, but I don't have any experience with that and I'm not sure that there would be any benefit to it. Maybe check out this post: Understand logging in Linux
â igal
Nov 18 '17 at 16:46
@Willman Themktempcommand should make sure that there are no naming conflicts. Why would the temporary files get out of hand? To me it seems like the version of your script which temporary files is no less manageable than the the version of your script without them.
â igal
Nov 18 '17 at 16:47
Ok so&>"$LOG" scp file host@remotesuccessfully sends output to the/path/to/file.loglike I want. This is the elegant solution I was talking about. I just didn't want to create unnecessary temp files on disk when I can just use I/O redirection and bash variables instead. (BTW to answer my side question- scp prints tostdoutwhen there is a permissions issue on remote dir, notstderrfor some reason).
â Willman
Nov 18 '17 at 16:57
@Willman Ah, ok. Based on the example code in your question I thought you only wanted to write the log file if the command failed. If you just wanted to log all of the output no matter what then that one-liner is definitely the most straight-forward thing to do.
â igal
Nov 18 '17 at 17:09
 |Â
show 2 more comments
up vote
0
down vote
accepted
up vote
0
down vote
accepted
It looks like you're trying to log the output after you run the command, which isn't possible.
If you want to log the output of the scp command unconditionally, then you just have to include the redirection operator on the same line as the command itself, i.e.:
&>"$LOG" scp file1 host@remote
If you want to only save the log output if the command fails (as it appears you're trying to do in your code), then how about redirecting the output to a temporary file and then moving the file to the desired location afterwards? It might look something like this:
#!/bin/bash
# Set path the real log file location
LOG=/path/to/file.log
# Create a temporary file to capture standard output and standard error
TEMPLOG="$(mktemp)"
# Run command and redirect output to temporary logfile
2>"$TEMPLOG" scp file1 host@remote
# do 'whatever' if scp command succeeds:
if [ $? = 0 ];
then
echo 'Command successful!'
# else log both stdout/stderr to $LOG file
else
# Move the log file from the temporary location to the desired location
mv "$TEMPLOG" "$LOG"
# DEBUG - print contents of $LOG var for testing purposes
printf "$LOG"
fi
It looks like you're trying to log the output after you run the command, which isn't possible.
If you want to log the output of the scp command unconditionally, then you just have to include the redirection operator on the same line as the command itself, i.e.:
&>"$LOG" scp file1 host@remote
If you want to only save the log output if the command fails (as it appears you're trying to do in your code), then how about redirecting the output to a temporary file and then moving the file to the desired location afterwards? It might look something like this:
#!/bin/bash
# Set path the real log file location
LOG=/path/to/file.log
# Create a temporary file to capture standard output and standard error
TEMPLOG="$(mktemp)"
# Run command and redirect output to temporary logfile
2>"$TEMPLOG" scp file1 host@remote
# do 'whatever' if scp command succeeds:
if [ $? = 0 ];
then
echo 'Command successful!'
# else log both stdout/stderr to $LOG file
else
# Move the log file from the temporary location to the desired location
mv "$TEMPLOG" "$LOG"
# DEBUG - print contents of $LOG var for testing purposes
printf "$LOG"
fi
edited Nov 18 '17 at 17:07
answered Nov 18 '17 at 15:38
igal
4,830930
4,830930
Ok I see. I'd thought&>would've been handled in the same way$?is- the output of the last command. But I see now that$?is the "exit status", NOT "standard output" of the prev. command. Ok so this answers the main question, but would this be the most elegant solution for custom logging? Is there a way to avoid using temp files for output? I can see this getting out of hand in very large/multiple scripts or with multiple different log files.
â Willman
Nov 18 '17 at 16:30
@Willman I'm not sure what the most elegant way would be to implement logging in a shell script. If there's something better than just redirecting the output you want to a file then I haven't seen it. If you're on Linux then you might also consider using the logger command to write to the system logs, but I don't have any experience with that and I'm not sure that there would be any benefit to it. Maybe check out this post: Understand logging in Linux
â igal
Nov 18 '17 at 16:46
@Willman Themktempcommand should make sure that there are no naming conflicts. Why would the temporary files get out of hand? To me it seems like the version of your script which temporary files is no less manageable than the the version of your script without them.
â igal
Nov 18 '17 at 16:47
Ok so&>"$LOG" scp file host@remotesuccessfully sends output to the/path/to/file.loglike I want. This is the elegant solution I was talking about. I just didn't want to create unnecessary temp files on disk when I can just use I/O redirection and bash variables instead. (BTW to answer my side question- scp prints tostdoutwhen there is a permissions issue on remote dir, notstderrfor some reason).
â Willman
Nov 18 '17 at 16:57
@Willman Ah, ok. Based on the example code in your question I thought you only wanted to write the log file if the command failed. If you just wanted to log all of the output no matter what then that one-liner is definitely the most straight-forward thing to do.
â igal
Nov 18 '17 at 17:09
 |Â
show 2 more comments
Ok I see. I'd thought&>would've been handled in the same way$?is- the output of the last command. But I see now that$?is the "exit status", NOT "standard output" of the prev. command. Ok so this answers the main question, but would this be the most elegant solution for custom logging? Is there a way to avoid using temp files for output? I can see this getting out of hand in very large/multiple scripts or with multiple different log files.
â Willman
Nov 18 '17 at 16:30
@Willman I'm not sure what the most elegant way would be to implement logging in a shell script. If there's something better than just redirecting the output you want to a file then I haven't seen it. If you're on Linux then you might also consider using the logger command to write to the system logs, but I don't have any experience with that and I'm not sure that there would be any benefit to it. Maybe check out this post: Understand logging in Linux
â igal
Nov 18 '17 at 16:46
@Willman Themktempcommand should make sure that there are no naming conflicts. Why would the temporary files get out of hand? To me it seems like the version of your script which temporary files is no less manageable than the the version of your script without them.
â igal
Nov 18 '17 at 16:47
Ok so&>"$LOG" scp file host@remotesuccessfully sends output to the/path/to/file.loglike I want. This is the elegant solution I was talking about. I just didn't want to create unnecessary temp files on disk when I can just use I/O redirection and bash variables instead. (BTW to answer my side question- scp prints tostdoutwhen there is a permissions issue on remote dir, notstderrfor some reason).
â Willman
Nov 18 '17 at 16:57
@Willman Ah, ok. Based on the example code in your question I thought you only wanted to write the log file if the command failed. If you just wanted to log all of the output no matter what then that one-liner is definitely the most straight-forward thing to do.
â igal
Nov 18 '17 at 17:09
Ok I see. I'd thought
&> would've been handled in the same way $? is- the output of the last command. But I see now that $? is the "exit status", NOT "standard output" of the prev. command. Ok so this answers the main question, but would this be the most elegant solution for custom logging? Is there a way to avoid using temp files for output? I can see this getting out of hand in very large/multiple scripts or with multiple different log files.â Willman
Nov 18 '17 at 16:30
Ok I see. I'd thought
&> would've been handled in the same way $? is- the output of the last command. But I see now that $? is the "exit status", NOT "standard output" of the prev. command. Ok so this answers the main question, but would this be the most elegant solution for custom logging? Is there a way to avoid using temp files for output? I can see this getting out of hand in very large/multiple scripts or with multiple different log files.â Willman
Nov 18 '17 at 16:30
@Willman I'm not sure what the most elegant way would be to implement logging in a shell script. If there's something better than just redirecting the output you want to a file then I haven't seen it. If you're on Linux then you might also consider using the logger command to write to the system logs, but I don't have any experience with that and I'm not sure that there would be any benefit to it. Maybe check out this post: Understand logging in Linux
â igal
Nov 18 '17 at 16:46
@Willman I'm not sure what the most elegant way would be to implement logging in a shell script. If there's something better than just redirecting the output you want to a file then I haven't seen it. If you're on Linux then you might also consider using the logger command to write to the system logs, but I don't have any experience with that and I'm not sure that there would be any benefit to it. Maybe check out this post: Understand logging in Linux
â igal
Nov 18 '17 at 16:46
@Willman The
mktemp command should make sure that there are no naming conflicts. Why would the temporary files get out of hand? To me it seems like the version of your script which temporary files is no less manageable than the the version of your script without them.â igal
Nov 18 '17 at 16:47
@Willman The
mktemp command should make sure that there are no naming conflicts. Why would the temporary files get out of hand? To me it seems like the version of your script which temporary files is no less manageable than the the version of your script without them.â igal
Nov 18 '17 at 16:47
Ok so
&>"$LOG" scp file host@remote successfully sends output to the /path/to/file.log like I want. This is the elegant solution I was talking about. I just didn't want to create unnecessary temp files on disk when I can just use I/O redirection and bash variables instead. (BTW to answer my side question- scp prints to stdout when there is a permissions issue on remote dir, not stderr for some reason).â Willman
Nov 18 '17 at 16:57
Ok so
&>"$LOG" scp file host@remote successfully sends output to the /path/to/file.log like I want. This is the elegant solution I was talking about. I just didn't want to create unnecessary temp files on disk when I can just use I/O redirection and bash variables instead. (BTW to answer my side question- scp prints to stdout when there is a permissions issue on remote dir, not stderr for some reason).â Willman
Nov 18 '17 at 16:57
@Willman Ah, ok. Based on the example code in your question I thought you only wanted to write the log file if the command failed. If you just wanted to log all of the output no matter what then that one-liner is definitely the most straight-forward thing to do.
â igal
Nov 18 '17 at 17:09
@Willman Ah, ok. Based on the example code in your question I thought you only wanted to write the log file if the command failed. If you just wanted to log all of the output no matter what then that one-liner is definitely the most straight-forward thing to do.
â igal
Nov 18 '17 at 17:09
 |Â
show 2 more comments
up vote
0
down vote
It looks like you were eventually satisfied with the outcome of this question but I propose something different.
#!/bin/bash
LOG=/path/to/file.log
DEBUG=0 # 0 = True, 1 = False
OUTPUT=$(scp file1 host@remote 2>&1)
# do 'whatever' if scp command succeeds:
if [ $? -eq 0 ];
then
echo "Success"
elif [[ DEBUG -eq 0 ]]
# else log both stdout/stderr to $LOG file and user
# DEBUG - Use tee to display $LOG contents efficiently
printf "$OUTPUT" | tee $LOG
else
# Send output to $LOG
printf "$OUTPUT" >> $LOG
fi
Essentially capture STDIN/STDOUT in a variable no matter what, then if success do 'whatever' but if failure redirect STDIN/STDOUT to $LOG. Additionally with the $DEBUG flag you can tee the contents of $OUTPUT to the display and $LOG simultaneously.
Also for integer comparison you really should use -eq instead of = or ==
Note that the value of$?at the point where you access it will be the return code of the assignmentDEBUG=0.$?will be non-zero if that assignment fails (which is possible ifDEBUGis a read-only variable). Also note that your calls toechowill remove any newlines from the value$OUTPUT, and that there is also athenmissing.
â Kusalananda
Apr 6 at 14:49
Ah, yeah the $? is referencing the wrong thing, DEBUG was an afterthought but I'll fix it.echodoes in fact remove the newlines soprintfis better if you want to preserve. Whichthenare you referring to, it is on the line after theifstatement just to be consistent with the original post?
â Amos Baker
Apr 6 at 16:04
add a comment |Â
up vote
0
down vote
It looks like you were eventually satisfied with the outcome of this question but I propose something different.
#!/bin/bash
LOG=/path/to/file.log
DEBUG=0 # 0 = True, 1 = False
OUTPUT=$(scp file1 host@remote 2>&1)
# do 'whatever' if scp command succeeds:
if [ $? -eq 0 ];
then
echo "Success"
elif [[ DEBUG -eq 0 ]]
# else log both stdout/stderr to $LOG file and user
# DEBUG - Use tee to display $LOG contents efficiently
printf "$OUTPUT" | tee $LOG
else
# Send output to $LOG
printf "$OUTPUT" >> $LOG
fi
Essentially capture STDIN/STDOUT in a variable no matter what, then if success do 'whatever' but if failure redirect STDIN/STDOUT to $LOG. Additionally with the $DEBUG flag you can tee the contents of $OUTPUT to the display and $LOG simultaneously.
Also for integer comparison you really should use -eq instead of = or ==
Note that the value of$?at the point where you access it will be the return code of the assignmentDEBUG=0.$?will be non-zero if that assignment fails (which is possible ifDEBUGis a read-only variable). Also note that your calls toechowill remove any newlines from the value$OUTPUT, and that there is also athenmissing.
â Kusalananda
Apr 6 at 14:49
Ah, yeah the $? is referencing the wrong thing, DEBUG was an afterthought but I'll fix it.echodoes in fact remove the newlines soprintfis better if you want to preserve. Whichthenare you referring to, it is on the line after theifstatement just to be consistent with the original post?
â Amos Baker
Apr 6 at 16:04
add a comment |Â
up vote
0
down vote
up vote
0
down vote
It looks like you were eventually satisfied with the outcome of this question but I propose something different.
#!/bin/bash
LOG=/path/to/file.log
DEBUG=0 # 0 = True, 1 = False
OUTPUT=$(scp file1 host@remote 2>&1)
# do 'whatever' if scp command succeeds:
if [ $? -eq 0 ];
then
echo "Success"
elif [[ DEBUG -eq 0 ]]
# else log both stdout/stderr to $LOG file and user
# DEBUG - Use tee to display $LOG contents efficiently
printf "$OUTPUT" | tee $LOG
else
# Send output to $LOG
printf "$OUTPUT" >> $LOG
fi
Essentially capture STDIN/STDOUT in a variable no matter what, then if success do 'whatever' but if failure redirect STDIN/STDOUT to $LOG. Additionally with the $DEBUG flag you can tee the contents of $OUTPUT to the display and $LOG simultaneously.
Also for integer comparison you really should use -eq instead of = or ==
It looks like you were eventually satisfied with the outcome of this question but I propose something different.
#!/bin/bash
LOG=/path/to/file.log
DEBUG=0 # 0 = True, 1 = False
OUTPUT=$(scp file1 host@remote 2>&1)
# do 'whatever' if scp command succeeds:
if [ $? -eq 0 ];
then
echo "Success"
elif [[ DEBUG -eq 0 ]]
# else log both stdout/stderr to $LOG file and user
# DEBUG - Use tee to display $LOG contents efficiently
printf "$OUTPUT" | tee $LOG
else
# Send output to $LOG
printf "$OUTPUT" >> $LOG
fi
Essentially capture STDIN/STDOUT in a variable no matter what, then if success do 'whatever' but if failure redirect STDIN/STDOUT to $LOG. Additionally with the $DEBUG flag you can tee the contents of $OUTPUT to the display and $LOG simultaneously.
Also for integer comparison you really should use -eq instead of = or ==
edited Apr 6 at 16:08
answered Apr 6 at 14:34
Amos Baker
11
11
Note that the value of$?at the point where you access it will be the return code of the assignmentDEBUG=0.$?will be non-zero if that assignment fails (which is possible ifDEBUGis a read-only variable). Also note that your calls toechowill remove any newlines from the value$OUTPUT, and that there is also athenmissing.
â Kusalananda
Apr 6 at 14:49
Ah, yeah the $? is referencing the wrong thing, DEBUG was an afterthought but I'll fix it.echodoes in fact remove the newlines soprintfis better if you want to preserve. Whichthenare you referring to, it is on the line after theifstatement just to be consistent with the original post?
â Amos Baker
Apr 6 at 16:04
add a comment |Â
Note that the value of$?at the point where you access it will be the return code of the assignmentDEBUG=0.$?will be non-zero if that assignment fails (which is possible ifDEBUGis a read-only variable). Also note that your calls toechowill remove any newlines from the value$OUTPUT, and that there is also athenmissing.
â Kusalananda
Apr 6 at 14:49
Ah, yeah the $? is referencing the wrong thing, DEBUG was an afterthought but I'll fix it.echodoes in fact remove the newlines soprintfis better if you want to preserve. Whichthenare you referring to, it is on the line after theifstatement just to be consistent with the original post?
â Amos Baker
Apr 6 at 16:04
Note that the value of
$? at the point where you access it will be the return code of the assignment DEBUG=0. $? will be non-zero if that assignment fails (which is possible if DEBUG is a read-only variable). Also note that your calls to echo will remove any newlines from the value $OUTPUT, and that there is also a then missing.â Kusalananda
Apr 6 at 14:49
Note that the value of
$? at the point where you access it will be the return code of the assignment DEBUG=0. $? will be non-zero if that assignment fails (which is possible if DEBUG is a read-only variable). Also note that your calls to echo will remove any newlines from the value $OUTPUT, and that there is also a then missing.â Kusalananda
Apr 6 at 14:49
Ah, yeah the $? is referencing the wrong thing, DEBUG was an afterthought but I'll fix it.
echo does in fact remove the newlines so printf is better if you want to preserve. Which then are you referring to, it is on the line after the if statement just to be consistent with the original post?â Amos Baker
Apr 6 at 16:04
Ah, yeah the $? is referencing the wrong thing, DEBUG was an afterthought but I'll fix it.
echo does in fact remove the newlines so printf is better if you want to preserve. Which then are you referring to, it is on the line after the if statement just to be consistent with the original post?â Amos Baker
Apr 6 at 16:04
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f405445%2fredirect-stdout-and-or-stderr-to-path-in-variable%23new-answer', 'question_page');
);
Post as a guest
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
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
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
3
The redirection would have to happen before
scpis run, or with thescpline, not after thescphas already gone away.â thrig
Nov 18 '17 at 15:05
Why not unconditionally write to a temporary file and then test for success/failure? If failure, add the output to your permanent log file or print and discard it.
â JRFerguson
Nov 18 '17 at 15:13