How could I know inside a script if stdout has been redirected for it?
Clash Royale CLAN TAG#URR8PPP
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
add a comment |
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
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
add a comment |
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
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
shell io-redirection ksh aix
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
add a comment |
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
add a comment |
2 Answers
2
active
oldest
votes
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
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
add a comment |
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.)
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, theDEBUG
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
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%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
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
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
add a comment |
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
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
add a comment |
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
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
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
add a comment |
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
add a comment |
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.)
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, theDEBUG
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
add a comment |
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.)
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, theDEBUG
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
add a comment |
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.)
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.)
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, theDEBUG
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
add a comment |
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, theDEBUG
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
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%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
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
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