What does âexec 1>/var/opt/log/my_logs/MYPROG_`date '+%Y%m%d_%H%M%S'`.log 2>&1â do?
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgO9GURib1T8z7lCwjOGLQaGtrueEthgQ8LO42ZX8cOfTqDK4jvDDpKkLFwf2J49kYCMNW7d4ABih_XCb_2UXdq5fPJDkoyg7-8g_YfRUot-XnaXkNYycsNp7lA5_TW9td0FFpLQ2APzKcZ/s1600/1.jpg)
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYQ0N5W1qAOxLP7t7iOM6O6AzbZnkXUy16s7P_CWfOb5UbTQY_aDsc727chyphenhyphen5W4IppVNernMMQeaUFTB_rFzAd95_CDt-tnwN-nBx6JyUp2duGjPaL5-VgNO41AVsA_vu30EJcipdDG409/s400/Clash+Royale+CLAN+TAG%2523URR8PPP.png)
up vote
2
down vote
favorite
I'm trying to understand what the below piece of shell script is doing. I know that exec without any arguments redirect the output of the current shell but am not able to understand what the below command does:
exec 1>/var/opt/log/my_logs/MYPROG_`date '+%Y%m%d_%H%M%S'`.log 2>&1
command-line bash scripts execute-command
add a comment |Â
up vote
2
down vote
favorite
I'm trying to understand what the below piece of shell script is doing. I know that exec without any arguments redirect the output of the current shell but am not able to understand what the below command does:
exec 1>/var/opt/log/my_logs/MYPROG_`date '+%Y%m%d_%H%M%S'`.log 2>&1
command-line bash scripts execute-command
Those` s are most probably not supposed to be there. :) You didn't need to escape the
``s to keep them from being interpreted as inline code because you intented the text into a code block.... Seems like I'm one to talk...
â JoL
Apr 23 at 17:48
It's just the difficulties of the stackexchange formatting. But it's clear enough for practical purposes
â Sergiy Kolodyazhnyy
Apr 23 at 18:19
@JoL That's my mistake. When I edited the post, I changed the formatting in a way that caused the text to be shown literally, but I failed to remove the backslashes that had previously served to escape the backticks. Sorry about that and thanks for pointing it out -- I've fixed it.
â Eliah Kagan
Apr 23 at 21:10
This question needs a better title.
â Dennis Williamson
Apr 23 at 22:06
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I'm trying to understand what the below piece of shell script is doing. I know that exec without any arguments redirect the output of the current shell but am not able to understand what the below command does:
exec 1>/var/opt/log/my_logs/MYPROG_`date '+%Y%m%d_%H%M%S'`.log 2>&1
command-line bash scripts execute-command
I'm trying to understand what the below piece of shell script is doing. I know that exec without any arguments redirect the output of the current shell but am not able to understand what the below command does:
exec 1>/var/opt/log/my_logs/MYPROG_`date '+%Y%m%d_%H%M%S'`.log 2>&1
command-line bash scripts execute-command
edited Apr 23 at 21:08
Eliah Kagan
79.4k20221359
79.4k20221359
asked Apr 23 at 16:00
IA39
141
141
Those` s are most probably not supposed to be there. :) You didn't need to escape the
``s to keep them from being interpreted as inline code because you intented the text into a code block.... Seems like I'm one to talk...
â JoL
Apr 23 at 17:48
It's just the difficulties of the stackexchange formatting. But it's clear enough for practical purposes
â Sergiy Kolodyazhnyy
Apr 23 at 18:19
@JoL That's my mistake. When I edited the post, I changed the formatting in a way that caused the text to be shown literally, but I failed to remove the backslashes that had previously served to escape the backticks. Sorry about that and thanks for pointing it out -- I've fixed it.
â Eliah Kagan
Apr 23 at 21:10
This question needs a better title.
â Dennis Williamson
Apr 23 at 22:06
add a comment |Â
Those` s are most probably not supposed to be there. :) You didn't need to escape the
``s to keep them from being interpreted as inline code because you intented the text into a code block.... Seems like I'm one to talk...
â JoL
Apr 23 at 17:48
It's just the difficulties of the stackexchange formatting. But it's clear enough for practical purposes
â Sergiy Kolodyazhnyy
Apr 23 at 18:19
@JoL That's my mistake. When I edited the post, I changed the formatting in a way that caused the text to be shown literally, but I failed to remove the backslashes that had previously served to escape the backticks. Sorry about that and thanks for pointing it out -- I've fixed it.
â Eliah Kagan
Apr 23 at 21:10
This question needs a better title.
â Dennis Williamson
Apr 23 at 22:06
Those
` s are most probably not supposed to be there. :) You didn't need to escape the
``s to keep them from being interpreted as inline code because you intented the text into a code block.... Seems like I'm one to talk...â JoL
Apr 23 at 17:48
Those
` s are most probably not supposed to be there. :) You didn't need to escape the
``s to keep them from being interpreted as inline code because you intented the text into a code block.... Seems like I'm one to talk...â JoL
Apr 23 at 17:48
It's just the difficulties of the stackexchange formatting. But it's clear enough for practical purposes
â Sergiy Kolodyazhnyy
Apr 23 at 18:19
It's just the difficulties of the stackexchange formatting. But it's clear enough for practical purposes
â Sergiy Kolodyazhnyy
Apr 23 at 18:19
@JoL That's my mistake. When I edited the post, I changed the formatting in a way that caused the text to be shown literally, but I failed to remove the backslashes that had previously served to escape the backticks. Sorry about that and thanks for pointing it out -- I've fixed it.
â Eliah Kagan
Apr 23 at 21:10
@JoL That's my mistake. When I edited the post, I changed the formatting in a way that caused the text to be shown literally, but I failed to remove the backslashes that had previously served to escape the backticks. Sorry about that and thanks for pointing it out -- I've fixed it.
â Eliah Kagan
Apr 23 at 21:10
This question needs a better title.
â Dennis Williamson
Apr 23 at 22:06
This question needs a better title.
â Dennis Williamson
Apr 23 at 22:06
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
7
down vote
There's actually 4 important bits of information that are happening:
The
exec
built-in is used to redirect all output for command-line session to a fileThe
1><FILENAME>
tells the shell to redirectstdout
standard stream, i.e. normal non-error output of commands will go to<FILENAME>
. The>
will create if<FILENAME>
doesn't exist or truncate if<FILENAME>
already exists.The redirected filename is created via added backticks with
date '+%Y%m%d_%H%M%S'
command. Backticks are form of Command Substitution and are functionally equivalent to$(date '+%Y%m%d_%H%M%S')
form, and nowadays$(...)
is preferred for readability and because this form can be easily nested (i.e., have multiple levels). So output ofdate
with the specified format'+%Y%m%d_%H%M%S'
will create filename that is timestamped. If your command ran on 2018, July, 4th, 4:20:20 the output will be/var/opt/log/my_logs/MYPROG_20180704_042020.log
.2>&1
redirectsstderr
stream to that file also, it's a standard, POSIX compliant (which means Bourne-like shells other thanbash
understand it)form. This is functionally equivalent to&>
bash-specific syntax. The order of specified redirections in shell is important, hence why this appears after1>
redirection.
In conclusion, there should be no output from this command itself. It should only rewire two output streams of all successive commands to go into the file you specified.
Interestingly enough, with this command my bash 4.4
outputs everything to file, and that includes the prompt and anything I type (so here I had to type blindly echo hello world
and hit Ctrl+D to exit afterwards):
$ bash --posix
bash-4.4$ exec 1>./mylog_`date '+%Y%m%d_%H%M%S'`.log 2>&1
$ cat ./mylog_20180424_010800.log
bash-4.4$ echo hello world
hello world
bash-4.4$ exit
Doing that piece by piece, reveals that bash
outputs prompt to stderr
stream and surprisingly along with anything I type:
bash-4.4$ exec 1> ./mylog.txt
bash-4.4$ echo Hello World
bash-4.4$ cat ./mylog.txt
cat: ./mylog.txt: input file is output file
bash-4.4$ exec 2>&1
In case of ksh
same thing happens, but I can see what is being typed, only the prompt goes to file, i.e. stdin isn't redirected:
bash-4.4$ ksh
$ exec 1>./mylog 2>&1
echo hello askubuntu
bash-4.4$ cat ./mylog
$ hello askubuntu
$
bash-4.4$
So here we can kinda see that shells can choose to output the prompt PS1
also to one of the standard streams, so that gets included into a file.
1
Good answer. As we can see, thatexec
invocation is much more useful in a non-interactive script.
â glenn jackman
Apr 23 at 17:32
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
7
down vote
There's actually 4 important bits of information that are happening:
The
exec
built-in is used to redirect all output for command-line session to a fileThe
1><FILENAME>
tells the shell to redirectstdout
standard stream, i.e. normal non-error output of commands will go to<FILENAME>
. The>
will create if<FILENAME>
doesn't exist or truncate if<FILENAME>
already exists.The redirected filename is created via added backticks with
date '+%Y%m%d_%H%M%S'
command. Backticks are form of Command Substitution and are functionally equivalent to$(date '+%Y%m%d_%H%M%S')
form, and nowadays$(...)
is preferred for readability and because this form can be easily nested (i.e., have multiple levels). So output ofdate
with the specified format'+%Y%m%d_%H%M%S'
will create filename that is timestamped. If your command ran on 2018, July, 4th, 4:20:20 the output will be/var/opt/log/my_logs/MYPROG_20180704_042020.log
.2>&1
redirectsstderr
stream to that file also, it's a standard, POSIX compliant (which means Bourne-like shells other thanbash
understand it)form. This is functionally equivalent to&>
bash-specific syntax. The order of specified redirections in shell is important, hence why this appears after1>
redirection.
In conclusion, there should be no output from this command itself. It should only rewire two output streams of all successive commands to go into the file you specified.
Interestingly enough, with this command my bash 4.4
outputs everything to file, and that includes the prompt and anything I type (so here I had to type blindly echo hello world
and hit Ctrl+D to exit afterwards):
$ bash --posix
bash-4.4$ exec 1>./mylog_`date '+%Y%m%d_%H%M%S'`.log 2>&1
$ cat ./mylog_20180424_010800.log
bash-4.4$ echo hello world
hello world
bash-4.4$ exit
Doing that piece by piece, reveals that bash
outputs prompt to stderr
stream and surprisingly along with anything I type:
bash-4.4$ exec 1> ./mylog.txt
bash-4.4$ echo Hello World
bash-4.4$ cat ./mylog.txt
cat: ./mylog.txt: input file is output file
bash-4.4$ exec 2>&1
In case of ksh
same thing happens, but I can see what is being typed, only the prompt goes to file, i.e. stdin isn't redirected:
bash-4.4$ ksh
$ exec 1>./mylog 2>&1
echo hello askubuntu
bash-4.4$ cat ./mylog
$ hello askubuntu
$
bash-4.4$
So here we can kinda see that shells can choose to output the prompt PS1
also to one of the standard streams, so that gets included into a file.
1
Good answer. As we can see, thatexec
invocation is much more useful in a non-interactive script.
â glenn jackman
Apr 23 at 17:32
add a comment |Â
up vote
7
down vote
There's actually 4 important bits of information that are happening:
The
exec
built-in is used to redirect all output for command-line session to a fileThe
1><FILENAME>
tells the shell to redirectstdout
standard stream, i.e. normal non-error output of commands will go to<FILENAME>
. The>
will create if<FILENAME>
doesn't exist or truncate if<FILENAME>
already exists.The redirected filename is created via added backticks with
date '+%Y%m%d_%H%M%S'
command. Backticks are form of Command Substitution and are functionally equivalent to$(date '+%Y%m%d_%H%M%S')
form, and nowadays$(...)
is preferred for readability and because this form can be easily nested (i.e., have multiple levels). So output ofdate
with the specified format'+%Y%m%d_%H%M%S'
will create filename that is timestamped. If your command ran on 2018, July, 4th, 4:20:20 the output will be/var/opt/log/my_logs/MYPROG_20180704_042020.log
.2>&1
redirectsstderr
stream to that file also, it's a standard, POSIX compliant (which means Bourne-like shells other thanbash
understand it)form. This is functionally equivalent to&>
bash-specific syntax. The order of specified redirections in shell is important, hence why this appears after1>
redirection.
In conclusion, there should be no output from this command itself. It should only rewire two output streams of all successive commands to go into the file you specified.
Interestingly enough, with this command my bash 4.4
outputs everything to file, and that includes the prompt and anything I type (so here I had to type blindly echo hello world
and hit Ctrl+D to exit afterwards):
$ bash --posix
bash-4.4$ exec 1>./mylog_`date '+%Y%m%d_%H%M%S'`.log 2>&1
$ cat ./mylog_20180424_010800.log
bash-4.4$ echo hello world
hello world
bash-4.4$ exit
Doing that piece by piece, reveals that bash
outputs prompt to stderr
stream and surprisingly along with anything I type:
bash-4.4$ exec 1> ./mylog.txt
bash-4.4$ echo Hello World
bash-4.4$ cat ./mylog.txt
cat: ./mylog.txt: input file is output file
bash-4.4$ exec 2>&1
In case of ksh
same thing happens, but I can see what is being typed, only the prompt goes to file, i.e. stdin isn't redirected:
bash-4.4$ ksh
$ exec 1>./mylog 2>&1
echo hello askubuntu
bash-4.4$ cat ./mylog
$ hello askubuntu
$
bash-4.4$
So here we can kinda see that shells can choose to output the prompt PS1
also to one of the standard streams, so that gets included into a file.
1
Good answer. As we can see, thatexec
invocation is much more useful in a non-interactive script.
â glenn jackman
Apr 23 at 17:32
add a comment |Â
up vote
7
down vote
up vote
7
down vote
There's actually 4 important bits of information that are happening:
The
exec
built-in is used to redirect all output for command-line session to a fileThe
1><FILENAME>
tells the shell to redirectstdout
standard stream, i.e. normal non-error output of commands will go to<FILENAME>
. The>
will create if<FILENAME>
doesn't exist or truncate if<FILENAME>
already exists.The redirected filename is created via added backticks with
date '+%Y%m%d_%H%M%S'
command. Backticks are form of Command Substitution and are functionally equivalent to$(date '+%Y%m%d_%H%M%S')
form, and nowadays$(...)
is preferred for readability and because this form can be easily nested (i.e., have multiple levels). So output ofdate
with the specified format'+%Y%m%d_%H%M%S'
will create filename that is timestamped. If your command ran on 2018, July, 4th, 4:20:20 the output will be/var/opt/log/my_logs/MYPROG_20180704_042020.log
.2>&1
redirectsstderr
stream to that file also, it's a standard, POSIX compliant (which means Bourne-like shells other thanbash
understand it)form. This is functionally equivalent to&>
bash-specific syntax. The order of specified redirections in shell is important, hence why this appears after1>
redirection.
In conclusion, there should be no output from this command itself. It should only rewire two output streams of all successive commands to go into the file you specified.
Interestingly enough, with this command my bash 4.4
outputs everything to file, and that includes the prompt and anything I type (so here I had to type blindly echo hello world
and hit Ctrl+D to exit afterwards):
$ bash --posix
bash-4.4$ exec 1>./mylog_`date '+%Y%m%d_%H%M%S'`.log 2>&1
$ cat ./mylog_20180424_010800.log
bash-4.4$ echo hello world
hello world
bash-4.4$ exit
Doing that piece by piece, reveals that bash
outputs prompt to stderr
stream and surprisingly along with anything I type:
bash-4.4$ exec 1> ./mylog.txt
bash-4.4$ echo Hello World
bash-4.4$ cat ./mylog.txt
cat: ./mylog.txt: input file is output file
bash-4.4$ exec 2>&1
In case of ksh
same thing happens, but I can see what is being typed, only the prompt goes to file, i.e. stdin isn't redirected:
bash-4.4$ ksh
$ exec 1>./mylog 2>&1
echo hello askubuntu
bash-4.4$ cat ./mylog
$ hello askubuntu
$
bash-4.4$
So here we can kinda see that shells can choose to output the prompt PS1
also to one of the standard streams, so that gets included into a file.
There's actually 4 important bits of information that are happening:
The
exec
built-in is used to redirect all output for command-line session to a fileThe
1><FILENAME>
tells the shell to redirectstdout
standard stream, i.e. normal non-error output of commands will go to<FILENAME>
. The>
will create if<FILENAME>
doesn't exist or truncate if<FILENAME>
already exists.The redirected filename is created via added backticks with
date '+%Y%m%d_%H%M%S'
command. Backticks are form of Command Substitution and are functionally equivalent to$(date '+%Y%m%d_%H%M%S')
form, and nowadays$(...)
is preferred for readability and because this form can be easily nested (i.e., have multiple levels). So output ofdate
with the specified format'+%Y%m%d_%H%M%S'
will create filename that is timestamped. If your command ran on 2018, July, 4th, 4:20:20 the output will be/var/opt/log/my_logs/MYPROG_20180704_042020.log
.2>&1
redirectsstderr
stream to that file also, it's a standard, POSIX compliant (which means Bourne-like shells other thanbash
understand it)form. This is functionally equivalent to&>
bash-specific syntax. The order of specified redirections in shell is important, hence why this appears after1>
redirection.
In conclusion, there should be no output from this command itself. It should only rewire two output streams of all successive commands to go into the file you specified.
Interestingly enough, with this command my bash 4.4
outputs everything to file, and that includes the prompt and anything I type (so here I had to type blindly echo hello world
and hit Ctrl+D to exit afterwards):
$ bash --posix
bash-4.4$ exec 1>./mylog_`date '+%Y%m%d_%H%M%S'`.log 2>&1
$ cat ./mylog_20180424_010800.log
bash-4.4$ echo hello world
hello world
bash-4.4$ exit
Doing that piece by piece, reveals that bash
outputs prompt to stderr
stream and surprisingly along with anything I type:
bash-4.4$ exec 1> ./mylog.txt
bash-4.4$ echo Hello World
bash-4.4$ cat ./mylog.txt
cat: ./mylog.txt: input file is output file
bash-4.4$ exec 2>&1
In case of ksh
same thing happens, but I can see what is being typed, only the prompt goes to file, i.e. stdin isn't redirected:
bash-4.4$ ksh
$ exec 1>./mylog 2>&1
echo hello askubuntu
bash-4.4$ cat ./mylog
$ hello askubuntu
$
bash-4.4$
So here we can kinda see that shells can choose to output the prompt PS1
also to one of the standard streams, so that gets included into a file.
edited Apr 23 at 17:40
answered Apr 23 at 16:55
![](https://i.stack.imgur.com/U1Jy6.jpg?s=32&g=1)
![](https://i.stack.imgur.com/U1Jy6.jpg?s=32&g=1)
Sergiy Kolodyazhnyy
64.6k9129282
64.6k9129282
1
Good answer. As we can see, thatexec
invocation is much more useful in a non-interactive script.
â glenn jackman
Apr 23 at 17:32
add a comment |Â
1
Good answer. As we can see, thatexec
invocation is much more useful in a non-interactive script.
â glenn jackman
Apr 23 at 17:32
1
1
Good answer. As we can see, that
exec
invocation is much more useful in a non-interactive script.â glenn jackman
Apr 23 at 17:32
Good answer. As we can see, that
exec
invocation is much more useful in a non-interactive script.â glenn jackman
Apr 23 at 17:32
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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%2faskubuntu.com%2fquestions%2f1027510%2fwhat-does-exec-1-var-opt-log-my-logs-myprog-date-ymd-hms-log-21%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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
Those
` s are most probably not supposed to be there. :) You didn't need to escape the
``s to keep them from being interpreted as inline code because you intented the text into a code block.... Seems like I'm one to talk...â JoL
Apr 23 at 17:48
It's just the difficulties of the stackexchange formatting. But it's clear enough for practical purposes
â Sergiy Kolodyazhnyy
Apr 23 at 18:19
@JoL That's my mistake. When I edited the post, I changed the formatting in a way that caused the text to be shown literally, but I failed to remove the backslashes that had previously served to escape the backticks. Sorry about that and thanks for pointing it out -- I've fixed it.
â Eliah Kagan
Apr 23 at 21:10
This question needs a better title.
â Dennis Williamson
Apr 23 at 22:06