Can $PAGER contain spaces?
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I'm writing an application from which I want to run a user-specified pager. The standard way to do this seems to be to look at the PAGER environment variable.
I'm unclear as to whether this is a program name or a program name together with arguments. I tried to find standards mentioning this, but could not.
My gut feeling is that I should split on spaces and execute. Am I correct? I have come across various programs that assume environment variables like $PAGER and $EDITOR are program names without environment variables.
Perhaps I should execute with sh instead though?
Links
- This question discusses the source of various common environment variable
environment-variables standard
asked Nov 28 '17 at 22:58
Att Righ
574313
 |Â
show 1 more comment
up vote
1
down vote
favorite
I'm writing an application from which I want to run a user-specified pager. The standard way to do this seems to be to look at the PAGER environment variable.
I'm unclear as to whether this is a program name or a program name together with arguments. I tried to find standards mentioning this, but could not.
My gut feeling is that I should split on spaces and execute. Am I correct? I have come across various programs that assume environment variables like $PAGER and $EDITOR are program names without environment variables.
Perhaps I should execute with sh instead though?
Links
- This question discusses the source of various common environment variable
environment-variables standard
asked Nov 28 '17 at 22:58
Att Righ
574313
1
Run it through the shell. That way your users can't complain.
– PSkocik
Nov 28 '17 at 23:04
Probably a good idea. I don't want to spread lies if I shouldn't! The only slight complexity is that that I want to be able to kill it. I guess I could just kill the tree of processes though.
– Att Righ
Nov 28 '17 at 23:06
1
git log appears (from its strace output) to try to run it directly if there's no spaces in it and through /bin/sh otherwise. Anyway, you could launch it in a separate process group and then kill the process group.
– PSkocik
Nov 28 '17 at 23:13
1
Linking in unix.stackexchange.com/q/5383/117549
– Jeff Schaller
Nov 28 '17 at 23:42
1
Relating: unix.stackexchange.com/a/96231/117549
– Jeff Schaller
Nov 28 '17 at 23:45
 |Â
show 1 more comment
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I'm writing an application from which I want to run a user-specified pager. The standard way to do this seems to be to look at the PAGER environment variable.
I'm unclear as to whether this is a program name or a program name together with arguments. I tried to find standards mentioning this, but could not.
My gut feeling is that I should split on spaces and execute. Am I correct? I have come across various programs that assume environment variables like $PAGER and $EDITOR are program names without environment variables.
Perhaps I should execute with sh instead though?
Links
- This question discusses the source of various common environment variable
environment-variables standard
asked Nov 28 '17 at 22:58
Att Righ
574313
I'm writing an application from which I want to run a user-specified pager. The standard way to do this seems to be to look at the PAGER environment variable.
I'm unclear as to whether this is a program name or a program name together with arguments. I tried to find standards mentioning this, but could not.
My gut feeling is that I should split on spaces and execute. Am I correct? I have come across various programs that assume environment variables like $PAGER and $EDITOR are program names without environment variables.
Perhaps I should execute with sh instead though?
Links
- This question discusses the source of various common environment variable
environment-variables standard
asked Nov 28 '17 at 22:58
Att Righ
574313
edited Nov 28 '17 at 23:06
asked Nov 28 '17 at 22:58
Att Righ
574313
asked Nov 28 '17 at 22:58
Att Righ
574313
asked Nov 28 '17 at 22:58
Att Righ
574313
574313
1
Run it through the shell. That way your users can't complain.
– PSkocik
Nov 28 '17 at 23:04
Probably a good idea. I don't want to spread lies if I shouldn't! The only slight complexity is that that I want to be able to kill it. I guess I could just kill the tree of processes though.
– Att Righ
Nov 28 '17 at 23:06
1
git log appears (from its strace output) to try to run it directly if there's no spaces in it and through /bin/sh otherwise. Anyway, you could launch it in a separate process group and then kill the process group.
– PSkocik
Nov 28 '17 at 23:13
1
Linking in unix.stackexchange.com/q/5383/117549
– Jeff Schaller
Nov 28 '17 at 23:42
1
Relating: unix.stackexchange.com/a/96231/117549
– Jeff Schaller
Nov 28 '17 at 23:45
 |Â
show 1 more comment
1
Run it through the shell. That way your users can't complain.
– PSkocik
Nov 28 '17 at 23:04
Probably a good idea. I don't want to spread lies if I shouldn't! The only slight complexity is that that I want to be able to kill it. I guess I could just kill the tree of processes though.
– Att Righ
Nov 28 '17 at 23:06
1
git log appears (from its strace output) to try to run it directly if there's no spaces in it and through /bin/sh otherwise. Anyway, you could launch it in a separate process group and then kill the process group.
– PSkocik
Nov 28 '17 at 23:13
1
Linking in unix.stackexchange.com/q/5383/117549
– Jeff Schaller
Nov 28 '17 at 23:42
1
Relating: unix.stackexchange.com/a/96231/117549
– Jeff Schaller
Nov 28 '17 at 23:45
1
1
Run it through the shell. That way your users can't complain.
– PSkocik
Nov 28 '17 at 23:04
Run it through the shell. That way your users can't complain.
– PSkocik
Nov 28 '17 at 23:04
Probably a good idea. I don't want to spread lies if I shouldn't! The only slight complexity is that that I want to be able to kill it. I guess I could just kill the tree of processes though.
– Att Righ
Nov 28 '17 at 23:06
Probably a good idea. I don't want to spread lies if I shouldn't! The only slight complexity is that that I want to be able to kill it. I guess I could just kill the tree of processes though.
– Att Righ
Nov 28 '17 at 23:06
1
1
git log appears (from its strace output) to try to run it directly if there's no spaces in it and through /bin/sh otherwise. Anyway, you could launch it in a separate process group and then kill the process group.
– PSkocik
Nov 28 '17 at 23:13
git log appears (from its strace output) to try to run it directly if there's no spaces in it and through /bin/sh otherwise. Anyway, you could launch it in a separate process group and then kill the process group.
– PSkocik
Nov 28 '17 at 23:13
1
1
Linking in unix.stackexchange.com/q/5383/117549
– Jeff Schaller
Nov 28 '17 at 23:42
Linking in unix.stackexchange.com/q/5383/117549
– Jeff Schaller
Nov 28 '17 at 23:42
1
1
Relating: unix.stackexchange.com/a/96231/117549
– Jeff Schaller
Nov 28 '17 at 23:45
Relating: unix.stackexchange.com/a/96231/117549
– Jeff Schaller
Nov 28 '17 at 23:45
 |Â
show 1 more comment
1 Answer
1
active
oldest
votes
up vote
3
down vote
accepted
My gut feeling is that I should split on spaces and execute.
Good instincts. You're calling exec(3); it's up to you how to interpret the environment variables you support. By supporting options, you save the user the trouble of writing a script to tuck them into a single $PAGER name.
A good example to follow might be man(1). On my system, it supports MANPAGER, which says,
If MANPAGER is set, its value is used as the name of the program
to use to display the man page. If not, then PAGER is used. If
that has no value either, /usr/bin/less -is is used.
That at least implies that PAGER can contain options. You might experiment with yours to see. I bet it does.
I don't think Posix addresses the question of how environment variables that denote utilities are interpreted. I think the best you have is common examples of prior art.
As to whether or not to pass it though "the" shell, I'd say No, unless you want to take advantage of shell variable expansion, and document it. It's simpler and more predictable to keep the shell out of it.
answered Nov 29 '17 at 1:16
James K. Lowden
1,27469
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
My gut feeling is that I should split on spaces and execute.
Good instincts. You're calling exec(3); it's up to you how to interpret the environment variables you support. By supporting options, you save the user the trouble of writing a script to tuck them into a single $PAGER name.
A good example to follow might be man(1). On my system, it supports MANPAGER, which says,
If MANPAGER is set, its value is used as the name of the program
to use to display the man page. If not, then PAGER is used. If
that has no value either, /usr/bin/less -is is used.
That at least implies that PAGER can contain options. You might experiment with yours to see. I bet it does.
I don't think Posix addresses the question of how environment variables that denote utilities are interpreted. I think the best you have is common examples of prior art.
As to whether or not to pass it though "the" shell, I'd say No, unless you want to take advantage of shell variable expansion, and document it. It's simpler and more predictable to keep the shell out of it.
answered Nov 29 '17 at 1:16
James K. Lowden
1,27469
add a comment |Â
up vote
3
down vote
accepted
My gut feeling is that I should split on spaces and execute.
Good instincts. You're calling exec(3); it's up to you how to interpret the environment variables you support. By supporting options, you save the user the trouble of writing a script to tuck them into a single $PAGER name.
A good example to follow might be man(1). On my system, it supports MANPAGER, which says,
If MANPAGER is set, its value is used as the name of the program
to use to display the man page. If not, then PAGER is used. If
that has no value either, /usr/bin/less -is is used.
That at least implies that PAGER can contain options. You might experiment with yours to see. I bet it does.
I don't think Posix addresses the question of how environment variables that denote utilities are interpreted. I think the best you have is common examples of prior art.
As to whether or not to pass it though "the" shell, I'd say No, unless you want to take advantage of shell variable expansion, and document it. It's simpler and more predictable to keep the shell out of it.
answered Nov 29 '17 at 1:16
James K. Lowden
1,27469
add a comment |Â
up vote
3
down vote
accepted
up vote
3
down vote
accepted
My gut feeling is that I should split on spaces and execute.
Good instincts. You're calling exec(3); it's up to you how to interpret the environment variables you support. By supporting options, you save the user the trouble of writing a script to tuck them into a single $PAGER name.
A good example to follow might be man(1). On my system, it supports MANPAGER, which says,
If MANPAGER is set, its value is used as the name of the program
to use to display the man page. If not, then PAGER is used. If
that has no value either, /usr/bin/less -is is used.
That at least implies that PAGER can contain options. You might experiment with yours to see. I bet it does.
I don't think Posix addresses the question of how environment variables that denote utilities are interpreted. I think the best you have is common examples of prior art.
As to whether or not to pass it though "the" shell, I'd say No, unless you want to take advantage of shell variable expansion, and document it. It's simpler and more predictable to keep the shell out of it.
answered Nov 29 '17 at 1:16
James K. Lowden
1,27469
My gut feeling is that I should split on spaces and execute.
Good instincts. You're calling exec(3); it's up to you how to interpret the environment variables you support. By supporting options, you save the user the trouble of writing a script to tuck them into a single $PAGER name.
A good example to follow might be man(1). On my system, it supports MANPAGER, which says,
If MANPAGER is set, its value is used as the name of the program
to use to display the man page. If not, then PAGER is used. If
that has no value either, /usr/bin/less -is is used.
That at least implies that PAGER can contain options. You might experiment with yours to see. I bet it does.
I don't think Posix addresses the question of how environment variables that denote utilities are interpreted. I think the best you have is common examples of prior art.
As to whether or not to pass it though "the" shell, I'd say No, unless you want to take advantage of shell variable expansion, and document it. It's simpler and more predictable to keep the shell out of it.
answered Nov 29 '17 at 1:16
James K. Lowden
1,27469
answered Nov 29 '17 at 1:16
James K. Lowden
1,27469
answered Nov 29 '17 at 1:16
James K. Lowden
1,27469
answered Nov 29 '17 at 1:16
James K. Lowden
1,27469
1,27469
add a comment |Â
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%2f407614%2fcan-pager-contain-spaces%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
1
Run it through the shell. That way your users can't complain.
– PSkocik
Nov 28 '17 at 23:04
Probably a good idea. I don't want to spread lies if I shouldn't! The only slight complexity is that that I want to be able to kill it. I guess I could just kill the tree of processes though.
– Att Righ
Nov 28 '17 at 23:06
1
git log appears (from its strace output) to try to run it directly if there's no spaces in it and through /bin/sh otherwise. Anyway, you could launch it in a separate process group and then kill the process group.
– PSkocik
Nov 28 '17 at 23:13
1
Linking in unix.stackexchange.com/q/5383/117549
– Jeff Schaller
Nov 28 '17 at 23:42
1
Relating: unix.stackexchange.com/a/96231/117549
– Jeff Schaller
Nov 28 '17 at 23:45