How could I know inside a script if stdout has been redirected for it?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












0















I have a script in ksh; depending whether there is a redirection from the command line, I redirect the output via a exec 1>file. How can I test from inside the script itself if the command calling it has redirected its output?



I tried using the $@, $*, $0, and even a ps on the PID of the script (hopefully there is a shebang) but the redirection never appears.



The script is running on AIX in this case.










share|improve this question



















  • 1





    Redirections never appear as any of the argument to any command as they are acted on by the calling shell before the command is executed. This sounds a lot like an XY-problem. What is it you'd like to achieve?

    – Kusalananda
    Jan 29 at 10:23











  • 1st lien of the question. Script will redirect or not it's own content depending of a redirection call or not. I try to know from the script how the call was made from the parent. Reirection check is the way i could know how to manage it but maybe the good point of view. I don't know wo and how the script will be used so can't set info before

    – NeronLeVelu
    Jan 29 at 10:40











  • Seems like documentation of the script and how it's supposed to be used might be in order. If a user knows to redirect its output, always, then document that and be done with it. Don't try to babysit the user any more than that.

    – Kusalananda
    Jan 29 at 19:49
















0















I have a script in ksh; depending whether there is a redirection from the command line, I redirect the output via a exec 1>file. How can I test from inside the script itself if the command calling it has redirected its output?



I tried using the $@, $*, $0, and even a ps on the PID of the script (hopefully there is a shebang) but the redirection never appears.



The script is running on AIX in this case.










share|improve this question



















  • 1





    Redirections never appear as any of the argument to any command as they are acted on by the calling shell before the command is executed. This sounds a lot like an XY-problem. What is it you'd like to achieve?

    – Kusalananda
    Jan 29 at 10:23











  • 1st lien of the question. Script will redirect or not it's own content depending of a redirection call or not. I try to know from the script how the call was made from the parent. Reirection check is the way i could know how to manage it but maybe the good point of view. I don't know wo and how the script will be used so can't set info before

    – NeronLeVelu
    Jan 29 at 10:40











  • Seems like documentation of the script and how it's supposed to be used might be in order. If a user knows to redirect its output, always, then document that and be done with it. Don't try to babysit the user any more than that.

    – Kusalananda
    Jan 29 at 19:49














0












0








0


0






I have a script in ksh; depending whether there is a redirection from the command line, I redirect the output via a exec 1>file. How can I test from inside the script itself if the command calling it has redirected its output?



I tried using the $@, $*, $0, and even a ps on the PID of the script (hopefully there is a shebang) but the redirection never appears.



The script is running on AIX in this case.










share|improve this question
















I have a script in ksh; depending whether there is a redirection from the command line, I redirect the output via a exec 1>file. How can I test from inside the script itself if the command calling it has redirected its output?



I tried using the $@, $*, $0, and even a ps on the PID of the script (hopefully there is a shebang) but the redirection never appears.



The script is running on AIX in this case.







shell io-redirection ksh aix






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 29 at 18:00









Jeff Schaller

41.6k1056132




41.6k1056132










asked Jan 29 at 9:47









NeronLeVeluNeronLeVelu

31317




31317







  • 1





    Redirections never appear as any of the argument to any command as they are acted on by the calling shell before the command is executed. This sounds a lot like an XY-problem. What is it you'd like to achieve?

    – Kusalananda
    Jan 29 at 10:23











  • 1st lien of the question. Script will redirect or not it's own content depending of a redirection call or not. I try to know from the script how the call was made from the parent. Reirection check is the way i could know how to manage it but maybe the good point of view. I don't know wo and how the script will be used so can't set info before

    – NeronLeVelu
    Jan 29 at 10:40











  • Seems like documentation of the script and how it's supposed to be used might be in order. If a user knows to redirect its output, always, then document that and be done with it. Don't try to babysit the user any more than that.

    – Kusalananda
    Jan 29 at 19:49













  • 1





    Redirections never appear as any of the argument to any command as they are acted on by the calling shell before the command is executed. This sounds a lot like an XY-problem. What is it you'd like to achieve?

    – Kusalananda
    Jan 29 at 10:23











  • 1st lien of the question. Script will redirect or not it's own content depending of a redirection call or not. I try to know from the script how the call was made from the parent. Reirection check is the way i could know how to manage it but maybe the good point of view. I don't know wo and how the script will be used so can't set info before

    – NeronLeVelu
    Jan 29 at 10:40











  • Seems like documentation of the script and how it's supposed to be used might be in order. If a user knows to redirect its output, always, then document that and be done with it. Don't try to babysit the user any more than that.

    – Kusalananda
    Jan 29 at 19:49








1




1





Redirections never appear as any of the argument to any command as they are acted on by the calling shell before the command is executed. This sounds a lot like an XY-problem. What is it you'd like to achieve?

– Kusalananda
Jan 29 at 10:23





Redirections never appear as any of the argument to any command as they are acted on by the calling shell before the command is executed. This sounds a lot like an XY-problem. What is it you'd like to achieve?

– Kusalananda
Jan 29 at 10:23













1st lien of the question. Script will redirect or not it's own content depending of a redirection call or not. I try to know from the script how the call was made from the parent. Reirection check is the way i could know how to manage it but maybe the good point of view. I don't know wo and how the script will be used so can't set info before

– NeronLeVelu
Jan 29 at 10:40





1st lien of the question. Script will redirect or not it's own content depending of a redirection call or not. I try to know from the script how the call was made from the parent. Reirection check is the way i could know how to manage it but maybe the good point of view. I don't know wo and how the script will be used so can't set info before

– NeronLeVelu
Jan 29 at 10:40













Seems like documentation of the script and how it's supposed to be used might be in order. If a user knows to redirect its output, always, then document that and be done with it. Don't try to babysit the user any more than that.

– Kusalananda
Jan 29 at 19:49






Seems like documentation of the script and how it's supposed to be used might be in order. If a user knows to redirect its output, always, then document that and be done with it. Don't try to babysit the user any more than that.

– Kusalananda
Jan 29 at 19:49











2 Answers
2






active

oldest

votes


















1














On AIX, the stdout file descriptor is available at /proc/$$/fd/1, so you could test it for being a regular file or not:



if [ -f /proc/$$/fd/1 ]
then
echo stdout has already been redirected
else
echo redirecting stdout
exec 1>file
echo some output
fi


/bin/sh is hardlinked to /bin/ksh, so you get the same behavior in either shell.



You could test separately for stdout having been redirected to /dev/null, if you wanted:



if [ /proc/$$/fd/1 -ef /dev/null ]; then : ...; fi





share|improve this answer























  • Excatly what i'm looking for, fd/2 is the error default channel and other created channel (if any). Also the /dev/null special case is helpfull

    – NeronLeVelu
    Jan 30 at 13:17


















2














In general, you can't. Redirections don't appear as arguments to the running command. Even if they did, you wouldn't be able to tell where the script output goes in all cases. Consider these two:



bash -c 'somecmd > /dev/null; othercmd'


and



bash -c 'somecmd; othercmd' > /dev/null


In the first case, the output of somecmd is redirected to /dev/null, but in the second case, the output of the whole shell is redirected, including both somecmd and othercmd. Seeing the command line of somecmd in the second case wouldn't tell how the output is redirected.



That said, it appears Bash's DEBUG trap can be used for this.



$ trap 'export CMDLINE=$BASH_COMMAND' DEBUG
$ env 2>/dev/null |grep CMD
CMDLINE=env 2> /dev/null


The trap exports the command to be run as CMDLINE, which we can see is exported since it shows in the output of env. Note that the full pipeline is not shown, just the one command.




That said, in most cases there are better ways to deal with things than trying to second-guess the user's redirections. Many commands check if the output goes to a terminal and change their behavior based on that.



To check if stdout is a terminal, you can use [ -t 1 ]:



$ if [ -t 1 ]; then echo terminal; else echo not terminal; fi |cat
not terminal


This is most often used to disable some interactive functionality or extraneous output in case the output doesn't go to a terminal and hence, by assumption, to a user.




If just testing if a file descriptor points to a terminal isn't enough, it might be easiest to arrange to pass an additional argument to the program to tell it what mode to operate in. That is, instead of caring about redirections, have the program do one thing if started with someprog --mode=cron, another if started with someprog --mode=batch and run interactively if started without a --mode argument. (Make interactive or command line mode the default so that the user doesn't need to manually type --mode=commandline each time they run it by hand.)






share|improve this answer

























  • the test of terminal is not elligible because it is run from 1) comand line, 2) cron 3) external agent running a subshell (agent are not terminal session). This is the tricky point. I haven't thought about DEBUG, good point

    – NeronLeVelu
    Jan 29 at 12:43











  • bad luck, cannot have this info without previously trap, that is not possible ...

    – NeronLeVelu
    Jan 29 at 13:23






  • 1





    @NeronLeVelu, well, I didn't know (and still really don't know) what the actual use case was, so I mentioned testing for terminals since it's one common case. And yes, the DEBUG trap only works if set in the calling shell, and it might not be easy to use within, say, cron. (Though you could of course manually set the environment variable, but then you might just directly pass whatever information it is you're eventually interpreting from the redirections. Edited.)

    – ilkkachu
    Jan 29 at 13:27











  • that's exactly my problem. i check via a lsof but assuming the PID of the script and using a inode reference. Assuming lot of interpretation is not the most reliable method

    – NeronLeVelu
    Jan 29 at 14:42










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
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f497395%2fhow-could-i-know-inside-a-script-if-stdout-has-been-redirected-for-it%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














On AIX, the stdout file descriptor is available at /proc/$$/fd/1, so you could test it for being a regular file or not:



if [ -f /proc/$$/fd/1 ]
then
echo stdout has already been redirected
else
echo redirecting stdout
exec 1>file
echo some output
fi


/bin/sh is hardlinked to /bin/ksh, so you get the same behavior in either shell.



You could test separately for stdout having been redirected to /dev/null, if you wanted:



if [ /proc/$$/fd/1 -ef /dev/null ]; then : ...; fi





share|improve this answer























  • Excatly what i'm looking for, fd/2 is the error default channel and other created channel (if any). Also the /dev/null special case is helpfull

    – NeronLeVelu
    Jan 30 at 13:17















1














On AIX, the stdout file descriptor is available at /proc/$$/fd/1, so you could test it for being a regular file or not:



if [ -f /proc/$$/fd/1 ]
then
echo stdout has already been redirected
else
echo redirecting stdout
exec 1>file
echo some output
fi


/bin/sh is hardlinked to /bin/ksh, so you get the same behavior in either shell.



You could test separately for stdout having been redirected to /dev/null, if you wanted:



if [ /proc/$$/fd/1 -ef /dev/null ]; then : ...; fi





share|improve this answer























  • Excatly what i'm looking for, fd/2 is the error default channel and other created channel (if any). Also the /dev/null special case is helpfull

    – NeronLeVelu
    Jan 30 at 13:17













1












1








1







On AIX, the stdout file descriptor is available at /proc/$$/fd/1, so you could test it for being a regular file or not:



if [ -f /proc/$$/fd/1 ]
then
echo stdout has already been redirected
else
echo redirecting stdout
exec 1>file
echo some output
fi


/bin/sh is hardlinked to /bin/ksh, so you get the same behavior in either shell.



You could test separately for stdout having been redirected to /dev/null, if you wanted:



if [ /proc/$$/fd/1 -ef /dev/null ]; then : ...; fi





share|improve this answer













On AIX, the stdout file descriptor is available at /proc/$$/fd/1, so you could test it for being a regular file or not:



if [ -f /proc/$$/fd/1 ]
then
echo stdout has already been redirected
else
echo redirecting stdout
exec 1>file
echo some output
fi


/bin/sh is hardlinked to /bin/ksh, so you get the same behavior in either shell.



You could test separately for stdout having been redirected to /dev/null, if you wanted:



if [ /proc/$$/fd/1 -ef /dev/null ]; then : ...; fi






share|improve this answer












share|improve this answer



share|improve this answer










answered Jan 29 at 18:03









Jeff SchallerJeff Schaller

41.6k1056132




41.6k1056132












  • Excatly what i'm looking for, fd/2 is the error default channel and other created channel (if any). Also the /dev/null special case is helpfull

    – NeronLeVelu
    Jan 30 at 13:17

















  • Excatly what i'm looking for, fd/2 is the error default channel and other created channel (if any). Also the /dev/null special case is helpfull

    – NeronLeVelu
    Jan 30 at 13:17
















Excatly what i'm looking for, fd/2 is the error default channel and other created channel (if any). Also the /dev/null special case is helpfull

– NeronLeVelu
Jan 30 at 13:17





Excatly what i'm looking for, fd/2 is the error default channel and other created channel (if any). Also the /dev/null special case is helpfull

– NeronLeVelu
Jan 30 at 13:17













2














In general, you can't. Redirections don't appear as arguments to the running command. Even if they did, you wouldn't be able to tell where the script output goes in all cases. Consider these two:



bash -c 'somecmd > /dev/null; othercmd'


and



bash -c 'somecmd; othercmd' > /dev/null


In the first case, the output of somecmd is redirected to /dev/null, but in the second case, the output of the whole shell is redirected, including both somecmd and othercmd. Seeing the command line of somecmd in the second case wouldn't tell how the output is redirected.



That said, it appears Bash's DEBUG trap can be used for this.



$ trap 'export CMDLINE=$BASH_COMMAND' DEBUG
$ env 2>/dev/null |grep CMD
CMDLINE=env 2> /dev/null


The trap exports the command to be run as CMDLINE, which we can see is exported since it shows in the output of env. Note that the full pipeline is not shown, just the one command.




That said, in most cases there are better ways to deal with things than trying to second-guess the user's redirections. Many commands check if the output goes to a terminal and change their behavior based on that.



To check if stdout is a terminal, you can use [ -t 1 ]:



$ if [ -t 1 ]; then echo terminal; else echo not terminal; fi |cat
not terminal


This is most often used to disable some interactive functionality or extraneous output in case the output doesn't go to a terminal and hence, by assumption, to a user.




If just testing if a file descriptor points to a terminal isn't enough, it might be easiest to arrange to pass an additional argument to the program to tell it what mode to operate in. That is, instead of caring about redirections, have the program do one thing if started with someprog --mode=cron, another if started with someprog --mode=batch and run interactively if started without a --mode argument. (Make interactive or command line mode the default so that the user doesn't need to manually type --mode=commandline each time they run it by hand.)






share|improve this answer

























  • the test of terminal is not elligible because it is run from 1) comand line, 2) cron 3) external agent running a subshell (agent are not terminal session). This is the tricky point. I haven't thought about DEBUG, good point

    – NeronLeVelu
    Jan 29 at 12:43











  • bad luck, cannot have this info without previously trap, that is not possible ...

    – NeronLeVelu
    Jan 29 at 13:23






  • 1





    @NeronLeVelu, well, I didn't know (and still really don't know) what the actual use case was, so I mentioned testing for terminals since it's one common case. And yes, the DEBUG trap only works if set in the calling shell, and it might not be easy to use within, say, cron. (Though you could of course manually set the environment variable, but then you might just directly pass whatever information it is you're eventually interpreting from the redirections. Edited.)

    – ilkkachu
    Jan 29 at 13:27











  • that's exactly my problem. i check via a lsof but assuming the PID of the script and using a inode reference. Assuming lot of interpretation is not the most reliable method

    – NeronLeVelu
    Jan 29 at 14:42















2














In general, you can't. Redirections don't appear as arguments to the running command. Even if they did, you wouldn't be able to tell where the script output goes in all cases. Consider these two:



bash -c 'somecmd > /dev/null; othercmd'


and



bash -c 'somecmd; othercmd' > /dev/null


In the first case, the output of somecmd is redirected to /dev/null, but in the second case, the output of the whole shell is redirected, including both somecmd and othercmd. Seeing the command line of somecmd in the second case wouldn't tell how the output is redirected.



That said, it appears Bash's DEBUG trap can be used for this.



$ trap 'export CMDLINE=$BASH_COMMAND' DEBUG
$ env 2>/dev/null |grep CMD
CMDLINE=env 2> /dev/null


The trap exports the command to be run as CMDLINE, which we can see is exported since it shows in the output of env. Note that the full pipeline is not shown, just the one command.




That said, in most cases there are better ways to deal with things than trying to second-guess the user's redirections. Many commands check if the output goes to a terminal and change their behavior based on that.



To check if stdout is a terminal, you can use [ -t 1 ]:



$ if [ -t 1 ]; then echo terminal; else echo not terminal; fi |cat
not terminal


This is most often used to disable some interactive functionality or extraneous output in case the output doesn't go to a terminal and hence, by assumption, to a user.




If just testing if a file descriptor points to a terminal isn't enough, it might be easiest to arrange to pass an additional argument to the program to tell it what mode to operate in. That is, instead of caring about redirections, have the program do one thing if started with someprog --mode=cron, another if started with someprog --mode=batch and run interactively if started without a --mode argument. (Make interactive or command line mode the default so that the user doesn't need to manually type --mode=commandline each time they run it by hand.)






share|improve this answer

























  • the test of terminal is not elligible because it is run from 1) comand line, 2) cron 3) external agent running a subshell (agent are not terminal session). This is the tricky point. I haven't thought about DEBUG, good point

    – NeronLeVelu
    Jan 29 at 12:43











  • bad luck, cannot have this info without previously trap, that is not possible ...

    – NeronLeVelu
    Jan 29 at 13:23






  • 1





    @NeronLeVelu, well, I didn't know (and still really don't know) what the actual use case was, so I mentioned testing for terminals since it's one common case. And yes, the DEBUG trap only works if set in the calling shell, and it might not be easy to use within, say, cron. (Though you could of course manually set the environment variable, but then you might just directly pass whatever information it is you're eventually interpreting from the redirections. Edited.)

    – ilkkachu
    Jan 29 at 13:27











  • that's exactly my problem. i check via a lsof but assuming the PID of the script and using a inode reference. Assuming lot of interpretation is not the most reliable method

    – NeronLeVelu
    Jan 29 at 14:42













2












2








2







In general, you can't. Redirections don't appear as arguments to the running command. Even if they did, you wouldn't be able to tell where the script output goes in all cases. Consider these two:



bash -c 'somecmd > /dev/null; othercmd'


and



bash -c 'somecmd; othercmd' > /dev/null


In the first case, the output of somecmd is redirected to /dev/null, but in the second case, the output of the whole shell is redirected, including both somecmd and othercmd. Seeing the command line of somecmd in the second case wouldn't tell how the output is redirected.



That said, it appears Bash's DEBUG trap can be used for this.



$ trap 'export CMDLINE=$BASH_COMMAND' DEBUG
$ env 2>/dev/null |grep CMD
CMDLINE=env 2> /dev/null


The trap exports the command to be run as CMDLINE, which we can see is exported since it shows in the output of env. Note that the full pipeline is not shown, just the one command.




That said, in most cases there are better ways to deal with things than trying to second-guess the user's redirections. Many commands check if the output goes to a terminal and change their behavior based on that.



To check if stdout is a terminal, you can use [ -t 1 ]:



$ if [ -t 1 ]; then echo terminal; else echo not terminal; fi |cat
not terminal


This is most often used to disable some interactive functionality or extraneous output in case the output doesn't go to a terminal and hence, by assumption, to a user.




If just testing if a file descriptor points to a terminal isn't enough, it might be easiest to arrange to pass an additional argument to the program to tell it what mode to operate in. That is, instead of caring about redirections, have the program do one thing if started with someprog --mode=cron, another if started with someprog --mode=batch and run interactively if started without a --mode argument. (Make interactive or command line mode the default so that the user doesn't need to manually type --mode=commandline each time they run it by hand.)






share|improve this answer















In general, you can't. Redirections don't appear as arguments to the running command. Even if they did, you wouldn't be able to tell where the script output goes in all cases. Consider these two:



bash -c 'somecmd > /dev/null; othercmd'


and



bash -c 'somecmd; othercmd' > /dev/null


In the first case, the output of somecmd is redirected to /dev/null, but in the second case, the output of the whole shell is redirected, including both somecmd and othercmd. Seeing the command line of somecmd in the second case wouldn't tell how the output is redirected.



That said, it appears Bash's DEBUG trap can be used for this.



$ trap 'export CMDLINE=$BASH_COMMAND' DEBUG
$ env 2>/dev/null |grep CMD
CMDLINE=env 2> /dev/null


The trap exports the command to be run as CMDLINE, which we can see is exported since it shows in the output of env. Note that the full pipeline is not shown, just the one command.




That said, in most cases there are better ways to deal with things than trying to second-guess the user's redirections. Many commands check if the output goes to a terminal and change their behavior based on that.



To check if stdout is a terminal, you can use [ -t 1 ]:



$ if [ -t 1 ]; then echo terminal; else echo not terminal; fi |cat
not terminal


This is most often used to disable some interactive functionality or extraneous output in case the output doesn't go to a terminal and hence, by assumption, to a user.




If just testing if a file descriptor points to a terminal isn't enough, it might be easiest to arrange to pass an additional argument to the program to tell it what mode to operate in. That is, instead of caring about redirections, have the program do one thing if started with someprog --mode=cron, another if started with someprog --mode=batch and run interactively if started without a --mode argument. (Make interactive or command line mode the default so that the user doesn't need to manually type --mode=commandline each time they run it by hand.)







share|improve this answer














share|improve this answer



share|improve this answer








edited Jan 29 at 13:24

























answered Jan 29 at 10:52









ilkkachuilkkachu

59.1k892167




59.1k892167












  • the test of terminal is not elligible because it is run from 1) comand line, 2) cron 3) external agent running a subshell (agent are not terminal session). This is the tricky point. I haven't thought about DEBUG, good point

    – NeronLeVelu
    Jan 29 at 12:43











  • bad luck, cannot have this info without previously trap, that is not possible ...

    – NeronLeVelu
    Jan 29 at 13:23






  • 1





    @NeronLeVelu, well, I didn't know (and still really don't know) what the actual use case was, so I mentioned testing for terminals since it's one common case. And yes, the DEBUG trap only works if set in the calling shell, and it might not be easy to use within, say, cron. (Though you could of course manually set the environment variable, but then you might just directly pass whatever information it is you're eventually interpreting from the redirections. Edited.)

    – ilkkachu
    Jan 29 at 13:27











  • that's exactly my problem. i check via a lsof but assuming the PID of the script and using a inode reference. Assuming lot of interpretation is not the most reliable method

    – NeronLeVelu
    Jan 29 at 14:42

















  • the test of terminal is not elligible because it is run from 1) comand line, 2) cron 3) external agent running a subshell (agent are not terminal session). This is the tricky point. I haven't thought about DEBUG, good point

    – NeronLeVelu
    Jan 29 at 12:43











  • bad luck, cannot have this info without previously trap, that is not possible ...

    – NeronLeVelu
    Jan 29 at 13:23






  • 1





    @NeronLeVelu, well, I didn't know (and still really don't know) what the actual use case was, so I mentioned testing for terminals since it's one common case. And yes, the DEBUG trap only works if set in the calling shell, and it might not be easy to use within, say, cron. (Though you could of course manually set the environment variable, but then you might just directly pass whatever information it is you're eventually interpreting from the redirections. Edited.)

    – ilkkachu
    Jan 29 at 13:27











  • that's exactly my problem. i check via a lsof but assuming the PID of the script and using a inode reference. Assuming lot of interpretation is not the most reliable method

    – NeronLeVelu
    Jan 29 at 14:42
















the test of terminal is not elligible because it is run from 1) comand line, 2) cron 3) external agent running a subshell (agent are not terminal session). This is the tricky point. I haven't thought about DEBUG, good point

– NeronLeVelu
Jan 29 at 12:43





the test of terminal is not elligible because it is run from 1) comand line, 2) cron 3) external agent running a subshell (agent are not terminal session). This is the tricky point. I haven't thought about DEBUG, good point

– NeronLeVelu
Jan 29 at 12:43













bad luck, cannot have this info without previously trap, that is not possible ...

– NeronLeVelu
Jan 29 at 13:23





bad luck, cannot have this info without previously trap, that is not possible ...

– NeronLeVelu
Jan 29 at 13:23




1




1





@NeronLeVelu, well, I didn't know (and still really don't know) what the actual use case was, so I mentioned testing for terminals since it's one common case. And yes, the DEBUG trap only works if set in the calling shell, and it might not be easy to use within, say, cron. (Though you could of course manually set the environment variable, but then you might just directly pass whatever information it is you're eventually interpreting from the redirections. Edited.)

– ilkkachu
Jan 29 at 13:27





@NeronLeVelu, well, I didn't know (and still really don't know) what the actual use case was, so I mentioned testing for terminals since it's one common case. And yes, the DEBUG trap only works if set in the calling shell, and it might not be easy to use within, say, cron. (Though you could of course manually set the environment variable, but then you might just directly pass whatever information it is you're eventually interpreting from the redirections. Edited.)

– ilkkachu
Jan 29 at 13:27













that's exactly my problem. i check via a lsof but assuming the PID of the script and using a inode reference. Assuming lot of interpretation is not the most reliable method

– NeronLeVelu
Jan 29 at 14:42





that's exactly my problem. i check via a lsof but assuming the PID of the script and using a inode reference. Assuming lot of interpretation is not the most reliable method

– NeronLeVelu
Jan 29 at 14:42

















draft saved

draft discarded
















































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.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f497395%2fhow-could-i-know-inside-a-script-if-stdout-has-been-redirected-for-it%23new-answer', 'question_page');

);

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






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay