What does bashrc PS1 check [ “$PS1” = “\s-\v\$ ” ] mean?
In /etc/bashrc file in Fedora/Red Hat I see following line:
[ "$PS1" = "\s-\v\$ " ] && PS1="[u@h W]\$ "
What is the check being done in [ "$PS1" = "\s-\v\$ " ] and why is PS1 set only if the test succeeds?
bash bashrc
add a comment |
In /etc/bashrc file in Fedora/Red Hat I see following line:
[ "$PS1" = "\s-\v\$ " ] && PS1="[u@h W]\$ "
What is the check being done in [ "$PS1" = "\s-\v\$ " ] and why is PS1 set only if the test succeeds?
bash bashrc
add a comment |
In /etc/bashrc file in Fedora/Red Hat I see following line:
[ "$PS1" = "\s-\v\$ " ] && PS1="[u@h W]\$ "
What is the check being done in [ "$PS1" = "\s-\v\$ " ] and why is PS1 set only if the test succeeds?
bash bashrc
In /etc/bashrc file in Fedora/Red Hat I see following line:
[ "$PS1" = "\s-\v\$ " ] && PS1="[u@h W]\$ "
What is the check being done in [ "$PS1" = "\s-\v\$ " ] and why is PS1 set only if the test succeeds?
bash bashrc
bash bashrc
asked Aug 10 '17 at 10:01
AkilanAkilan
1515
1515
add a comment |
add a comment |
5 Answers
5
active
oldest
votes
(I debated whether to make this an answer since it's such a swag but here ya go...)
Just a theory but the first form (e.g. bash-3.2.1$) looks like the prompt I often see when logged in as root or other "non-user" account . The second, overriding form (e.g. [joeblow@myhost /tmp]$) is more user-centric. So maybe this is to detect when going from a system account to user account...then, and only then, change to a more appropriate prompt. Otherwise assume someone would want to preserve the current prompt.
add a comment |
The check being done is a string comparison =. It's comparing the value of $PS1 to the string s-v$, where the backslashes need to be escaped in the string so that they get compared to actual backslashes instead of attempting to escape the following character.
The && syntax is the part that sets PS1 only if the preceding test succeeds.
The overall logic here is apparently to update PS1 only if it was previously set to a specific value.
I understand that it is string comparison and && being used as a test. My question rather was about significance of that string and "why is PS1 set only if the test succeeds".
– Akilan
Aug 10 '17 at 11:45
The poster already acknowledged that && was testing for the success of the previous command and so the answer doesn't give the required response,
– Raman Sailopal
Aug 10 '17 at 12:52
I think you'd have to ask the maintainers of that file to ask why it is set that way.
– Jeff Schaller
Aug 10 '17 at 22:49
add a comment |
s-v$␣ is the default prompt string, the one Bash sets when starting interactively with PS1 unset. It shows the basename of the shell process (usually bash or sh), the version and a dollar sign, e.g. bash-4.4$. (Or a # instead of $ if running as root.)
The idea of appears to be to set a more useful prompt, but not if some other startup file has already set it.
The backslashes are doubled in "\s-\v\$ " since within a double-quoted string x has a special meaning for some values of x. \ unambiguously represents a literal backslash. (Though for some reason they haven't done that on the assignment side).
Using single quoted strings would make the backslashes a bit easier to read:
[ "$PS1" = 's-v$ ' ] && PS1='[u@h W]$ '
add a comment |
I believe the comparison is checking to see if the shell is an interactive session. s-v$ as a $PS1 var evaluates to bash-5.0$ on my machine. See the differences here:
Jonathans-Air:~ lirum$ bash
bash-5.0$ echo "$PS1"
s-v$
bash-5.0$ exit
exit
Jonathans-Air:~ lirum$ echo "$PS1"
h:W u$
New contributor
Lirum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Bash unsetsPS1completely if the shell is non-interactive, so testing it against a non-empty string value doesn't really help there. Testing for empty$PS1is done in some places, e.g. Debian's/etc/bash.bashrchas[ -z "$PS1" ] && returnto exit if the shell is non-interactive.
– ilkkachu
1 hour ago
add a comment |
It's an awkward way to check if PS1 is bash's default, or if it was customized by the user in ~/.bashrc (or in any of the /etc/profile, /etc/profile.d/* or ~/.bash_profile files in the case of a login shell).
In the former case, PS1 will be set to the ugly and annoying [user@host /long/path/to/hell]$; in the latter case, it will be left as is.
Notice that on RedHat /etc/bashrc is sourced explicitly from the default ~/.bashrc and ~/.bash_profile installed from /etc/skel; do not confuse /etc/bashrc with /etc/bash.bashrc which is sourced before ~/.bashrc on some systems (eg. Debian).
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%2f385181%2fwhat-does-bashrc-ps1-check-ps1-s-v-mean%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
(I debated whether to make this an answer since it's such a swag but here ya go...)
Just a theory but the first form (e.g. bash-3.2.1$) looks like the prompt I often see when logged in as root or other "non-user" account . The second, overriding form (e.g. [joeblow@myhost /tmp]$) is more user-centric. So maybe this is to detect when going from a system account to user account...then, and only then, change to a more appropriate prompt. Otherwise assume someone would want to preserve the current prompt.
add a comment |
(I debated whether to make this an answer since it's such a swag but here ya go...)
Just a theory but the first form (e.g. bash-3.2.1$) looks like the prompt I often see when logged in as root or other "non-user" account . The second, overriding form (e.g. [joeblow@myhost /tmp]$) is more user-centric. So maybe this is to detect when going from a system account to user account...then, and only then, change to a more appropriate prompt. Otherwise assume someone would want to preserve the current prompt.
add a comment |
(I debated whether to make this an answer since it's such a swag but here ya go...)
Just a theory but the first form (e.g. bash-3.2.1$) looks like the prompt I often see when logged in as root or other "non-user" account . The second, overriding form (e.g. [joeblow@myhost /tmp]$) is more user-centric. So maybe this is to detect when going from a system account to user account...then, and only then, change to a more appropriate prompt. Otherwise assume someone would want to preserve the current prompt.
(I debated whether to make this an answer since it's such a swag but here ya go...)
Just a theory but the first form (e.g. bash-3.2.1$) looks like the prompt I often see when logged in as root or other "non-user" account . The second, overriding form (e.g. [joeblow@myhost /tmp]$) is more user-centric. So maybe this is to detect when going from a system account to user account...then, and only then, change to a more appropriate prompt. Otherwise assume someone would want to preserve the current prompt.
edited Aug 10 '17 at 14:17
answered Aug 10 '17 at 14:12
B LayerB Layer
4,0641625
4,0641625
add a comment |
add a comment |
The check being done is a string comparison =. It's comparing the value of $PS1 to the string s-v$, where the backslashes need to be escaped in the string so that they get compared to actual backslashes instead of attempting to escape the following character.
The && syntax is the part that sets PS1 only if the preceding test succeeds.
The overall logic here is apparently to update PS1 only if it was previously set to a specific value.
I understand that it is string comparison and && being used as a test. My question rather was about significance of that string and "why is PS1 set only if the test succeeds".
– Akilan
Aug 10 '17 at 11:45
The poster already acknowledged that && was testing for the success of the previous command and so the answer doesn't give the required response,
– Raman Sailopal
Aug 10 '17 at 12:52
I think you'd have to ask the maintainers of that file to ask why it is set that way.
– Jeff Schaller
Aug 10 '17 at 22:49
add a comment |
The check being done is a string comparison =. It's comparing the value of $PS1 to the string s-v$, where the backslashes need to be escaped in the string so that they get compared to actual backslashes instead of attempting to escape the following character.
The && syntax is the part that sets PS1 only if the preceding test succeeds.
The overall logic here is apparently to update PS1 only if it was previously set to a specific value.
I understand that it is string comparison and && being used as a test. My question rather was about significance of that string and "why is PS1 set only if the test succeeds".
– Akilan
Aug 10 '17 at 11:45
The poster already acknowledged that && was testing for the success of the previous command and so the answer doesn't give the required response,
– Raman Sailopal
Aug 10 '17 at 12:52
I think you'd have to ask the maintainers of that file to ask why it is set that way.
– Jeff Schaller
Aug 10 '17 at 22:49
add a comment |
The check being done is a string comparison =. It's comparing the value of $PS1 to the string s-v$, where the backslashes need to be escaped in the string so that they get compared to actual backslashes instead of attempting to escape the following character.
The && syntax is the part that sets PS1 only if the preceding test succeeds.
The overall logic here is apparently to update PS1 only if it was previously set to a specific value.
The check being done is a string comparison =. It's comparing the value of $PS1 to the string s-v$, where the backslashes need to be escaped in the string so that they get compared to actual backslashes instead of attempting to escape the following character.
The && syntax is the part that sets PS1 only if the preceding test succeeds.
The overall logic here is apparently to update PS1 only if it was previously set to a specific value.
answered Aug 10 '17 at 11:16
Jeff SchallerJeff Schaller
43.4k1160140
43.4k1160140
I understand that it is string comparison and && being used as a test. My question rather was about significance of that string and "why is PS1 set only if the test succeeds".
– Akilan
Aug 10 '17 at 11:45
The poster already acknowledged that && was testing for the success of the previous command and so the answer doesn't give the required response,
– Raman Sailopal
Aug 10 '17 at 12:52
I think you'd have to ask the maintainers of that file to ask why it is set that way.
– Jeff Schaller
Aug 10 '17 at 22:49
add a comment |
I understand that it is string comparison and && being used as a test. My question rather was about significance of that string and "why is PS1 set only if the test succeeds".
– Akilan
Aug 10 '17 at 11:45
The poster already acknowledged that && was testing for the success of the previous command and so the answer doesn't give the required response,
– Raman Sailopal
Aug 10 '17 at 12:52
I think you'd have to ask the maintainers of that file to ask why it is set that way.
– Jeff Schaller
Aug 10 '17 at 22:49
I understand that it is string comparison and && being used as a test. My question rather was about significance of that string and "why is PS1 set only if the test succeeds".
– Akilan
Aug 10 '17 at 11:45
I understand that it is string comparison and && being used as a test. My question rather was about significance of that string and "why is PS1 set only if the test succeeds".
– Akilan
Aug 10 '17 at 11:45
The poster already acknowledged that && was testing for the success of the previous command and so the answer doesn't give the required response,
– Raman Sailopal
Aug 10 '17 at 12:52
The poster already acknowledged that && was testing for the success of the previous command and so the answer doesn't give the required response,
– Raman Sailopal
Aug 10 '17 at 12:52
I think you'd have to ask the maintainers of that file to ask why it is set that way.
– Jeff Schaller
Aug 10 '17 at 22:49
I think you'd have to ask the maintainers of that file to ask why it is set that way.
– Jeff Schaller
Aug 10 '17 at 22:49
add a comment |
s-v$␣ is the default prompt string, the one Bash sets when starting interactively with PS1 unset. It shows the basename of the shell process (usually bash or sh), the version and a dollar sign, e.g. bash-4.4$. (Or a # instead of $ if running as root.)
The idea of appears to be to set a more useful prompt, but not if some other startup file has already set it.
The backslashes are doubled in "\s-\v\$ " since within a double-quoted string x has a special meaning for some values of x. \ unambiguously represents a literal backslash. (Though for some reason they haven't done that on the assignment side).
Using single quoted strings would make the backslashes a bit easier to read:
[ "$PS1" = 's-v$ ' ] && PS1='[u@h W]$ '
add a comment |
s-v$␣ is the default prompt string, the one Bash sets when starting interactively with PS1 unset. It shows the basename of the shell process (usually bash or sh), the version and a dollar sign, e.g. bash-4.4$. (Or a # instead of $ if running as root.)
The idea of appears to be to set a more useful prompt, but not if some other startup file has already set it.
The backslashes are doubled in "\s-\v\$ " since within a double-quoted string x has a special meaning for some values of x. \ unambiguously represents a literal backslash. (Though for some reason they haven't done that on the assignment side).
Using single quoted strings would make the backslashes a bit easier to read:
[ "$PS1" = 's-v$ ' ] && PS1='[u@h W]$ '
add a comment |
s-v$␣ is the default prompt string, the one Bash sets when starting interactively with PS1 unset. It shows the basename of the shell process (usually bash or sh), the version and a dollar sign, e.g. bash-4.4$. (Or a # instead of $ if running as root.)
The idea of appears to be to set a more useful prompt, but not if some other startup file has already set it.
The backslashes are doubled in "\s-\v\$ " since within a double-quoted string x has a special meaning for some values of x. \ unambiguously represents a literal backslash. (Though for some reason they haven't done that on the assignment side).
Using single quoted strings would make the backslashes a bit easier to read:
[ "$PS1" = 's-v$ ' ] && PS1='[u@h W]$ '
s-v$␣ is the default prompt string, the one Bash sets when starting interactively with PS1 unset. It shows the basename of the shell process (usually bash or sh), the version and a dollar sign, e.g. bash-4.4$. (Or a # instead of $ if running as root.)
The idea of appears to be to set a more useful prompt, but not if some other startup file has already set it.
The backslashes are doubled in "\s-\v\$ " since within a double-quoted string x has a special meaning for some values of x. \ unambiguously represents a literal backslash. (Though for some reason they haven't done that on the assignment side).
Using single quoted strings would make the backslashes a bit easier to read:
[ "$PS1" = 's-v$ ' ] && PS1='[u@h W]$ '
answered 1 hour ago
ilkkachuilkkachu
61.5k10100177
61.5k10100177
add a comment |
add a comment |
I believe the comparison is checking to see if the shell is an interactive session. s-v$ as a $PS1 var evaluates to bash-5.0$ on my machine. See the differences here:
Jonathans-Air:~ lirum$ bash
bash-5.0$ echo "$PS1"
s-v$
bash-5.0$ exit
exit
Jonathans-Air:~ lirum$ echo "$PS1"
h:W u$
New contributor
Lirum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Bash unsetsPS1completely if the shell is non-interactive, so testing it against a non-empty string value doesn't really help there. Testing for empty$PS1is done in some places, e.g. Debian's/etc/bash.bashrchas[ -z "$PS1" ] && returnto exit if the shell is non-interactive.
– ilkkachu
1 hour ago
add a comment |
I believe the comparison is checking to see if the shell is an interactive session. s-v$ as a $PS1 var evaluates to bash-5.0$ on my machine. See the differences here:
Jonathans-Air:~ lirum$ bash
bash-5.0$ echo "$PS1"
s-v$
bash-5.0$ exit
exit
Jonathans-Air:~ lirum$ echo "$PS1"
h:W u$
New contributor
Lirum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Bash unsetsPS1completely if the shell is non-interactive, so testing it against a non-empty string value doesn't really help there. Testing for empty$PS1is done in some places, e.g. Debian's/etc/bash.bashrchas[ -z "$PS1" ] && returnto exit if the shell is non-interactive.
– ilkkachu
1 hour ago
add a comment |
I believe the comparison is checking to see if the shell is an interactive session. s-v$ as a $PS1 var evaluates to bash-5.0$ on my machine. See the differences here:
Jonathans-Air:~ lirum$ bash
bash-5.0$ echo "$PS1"
s-v$
bash-5.0$ exit
exit
Jonathans-Air:~ lirum$ echo "$PS1"
h:W u$
New contributor
Lirum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I believe the comparison is checking to see if the shell is an interactive session. s-v$ as a $PS1 var evaluates to bash-5.0$ on my machine. See the differences here:
Jonathans-Air:~ lirum$ bash
bash-5.0$ echo "$PS1"
s-v$
bash-5.0$ exit
exit
Jonathans-Air:~ lirum$ echo "$PS1"
h:W u$
New contributor
Lirum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Lirum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 3 hours ago
LirumLirum
11
11
New contributor
Lirum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Lirum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Lirum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Bash unsetsPS1completely if the shell is non-interactive, so testing it against a non-empty string value doesn't really help there. Testing for empty$PS1is done in some places, e.g. Debian's/etc/bash.bashrchas[ -z "$PS1" ] && returnto exit if the shell is non-interactive.
– ilkkachu
1 hour ago
add a comment |
Bash unsetsPS1completely if the shell is non-interactive, so testing it against a non-empty string value doesn't really help there. Testing for empty$PS1is done in some places, e.g. Debian's/etc/bash.bashrchas[ -z "$PS1" ] && returnto exit if the shell is non-interactive.
– ilkkachu
1 hour ago
Bash unsets
PS1 completely if the shell is non-interactive, so testing it against a non-empty string value doesn't really help there. Testing for empty $PS1 is done in some places, e.g. Debian's /etc/bash.bashrc has [ -z "$PS1" ] && return to exit if the shell is non-interactive.– ilkkachu
1 hour ago
Bash unsets
PS1 completely if the shell is non-interactive, so testing it against a non-empty string value doesn't really help there. Testing for empty $PS1 is done in some places, e.g. Debian's /etc/bash.bashrc has [ -z "$PS1" ] && return to exit if the shell is non-interactive.– ilkkachu
1 hour ago
add a comment |
It's an awkward way to check if PS1 is bash's default, or if it was customized by the user in ~/.bashrc (or in any of the /etc/profile, /etc/profile.d/* or ~/.bash_profile files in the case of a login shell).
In the former case, PS1 will be set to the ugly and annoying [user@host /long/path/to/hell]$; in the latter case, it will be left as is.
Notice that on RedHat /etc/bashrc is sourced explicitly from the default ~/.bashrc and ~/.bash_profile installed from /etc/skel; do not confuse /etc/bashrc with /etc/bash.bashrc which is sourced before ~/.bashrc on some systems (eg. Debian).
add a comment |
It's an awkward way to check if PS1 is bash's default, or if it was customized by the user in ~/.bashrc (or in any of the /etc/profile, /etc/profile.d/* or ~/.bash_profile files in the case of a login shell).
In the former case, PS1 will be set to the ugly and annoying [user@host /long/path/to/hell]$; in the latter case, it will be left as is.
Notice that on RedHat /etc/bashrc is sourced explicitly from the default ~/.bashrc and ~/.bash_profile installed from /etc/skel; do not confuse /etc/bashrc with /etc/bash.bashrc which is sourced before ~/.bashrc on some systems (eg. Debian).
add a comment |
It's an awkward way to check if PS1 is bash's default, or if it was customized by the user in ~/.bashrc (or in any of the /etc/profile, /etc/profile.d/* or ~/.bash_profile files in the case of a login shell).
In the former case, PS1 will be set to the ugly and annoying [user@host /long/path/to/hell]$; in the latter case, it will be left as is.
Notice that on RedHat /etc/bashrc is sourced explicitly from the default ~/.bashrc and ~/.bash_profile installed from /etc/skel; do not confuse /etc/bashrc with /etc/bash.bashrc which is sourced before ~/.bashrc on some systems (eg. Debian).
It's an awkward way to check if PS1 is bash's default, or if it was customized by the user in ~/.bashrc (or in any of the /etc/profile, /etc/profile.d/* or ~/.bash_profile files in the case of a login shell).
In the former case, PS1 will be set to the ugly and annoying [user@host /long/path/to/hell]$; in the latter case, it will be left as is.
Notice that on RedHat /etc/bashrc is sourced explicitly from the default ~/.bashrc and ~/.bash_profile installed from /etc/skel; do not confuse /etc/bashrc with /etc/bash.bashrc which is sourced before ~/.bashrc on some systems (eg. Debian).
edited 42 mins ago
answered 1 hour ago
mosvymosvy
8,2371732
8,2371732
add a comment |
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%2f385181%2fwhat-does-bashrc-ps1-check-ps1-s-v-mean%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