Add BASHPID to history?
5
I often have multiple sessions running at any given time. This sometimes leads to issues when trying to reconstruct work using history. As a result, I was thinking it would be useful to include the $BASHPID somehow so that I could sort by shell and then time. My naive attempt at this was to try
export HISTTIMEFORMAT="$BASHPID %Y %m %d - %H:%M:%S| "
But all this does is add the current shell's $BASHPID to the output of 'history'.
A search for HISTTIMEFORMAT and $BASHPID returned nothing. ANy suggestions on how to get this kind of behavior?
bash command-history
asked Jul 3 '17 at 20:55
mikemtnbikesmikemtnbikes
1403
|
show 2 more comments
5
I often have multiple sessions running at any given time. This sometimes leads to issues when trying to reconstruct work using history. As a result, I was thinking it would be useful to include the $BASHPID somehow so that I could sort by shell and then time. My naive attempt at this was to try
export HISTTIMEFORMAT="$BASHPID %Y %m %d - %H:%M:%S| "
But all this does is add the current shell's $BASHPID to the output of 'history'.
A search for HISTTIMEFORMAT and $BASHPID returned nothing. ANy suggestions on how to get this kind of behavior?
bash command-history
asked Jul 3 '17 at 20:55
mikemtnbikesmikemtnbikes
1403
How about adding tty?
– Rui F Ribeiro
Jul 3 '17 at 20:59
@RuiFRibeiro could you be more explicit?
– mikemtnbikes
Jul 3 '17 at 21:03
if running multiple windows in a graphical shell, tty is also useful to keep an idea of what is done in several screens; or to keep a notion of what is being done by different remote users when root is being (ab)used.man tty
– Rui F Ribeiro
Jul 3 '17 at 21:09
@RuiFRibeiro Yes, but I don't see how that information can be stored in the .bash_history file.
– mikemtnbikes
Jul 3 '17 at 21:27
Indeed, the more I understand the more I think I'll have to have multiple history files (one for each BASHPID 'cause that's more granular than tty) and then somehow process them together to make the default .bash_history file.
– mikemtnbikes
Jul 3 '17 at 21:27
|
show 2 more comments
5
5
5
0
I often have multiple sessions running at any given time. This sometimes leads to issues when trying to reconstruct work using history. As a result, I was thinking it would be useful to include the $BASHPID somehow so that I could sort by shell and then time. My naive attempt at this was to try
export HISTTIMEFORMAT="$BASHPID %Y %m %d - %H:%M:%S| "
But all this does is add the current shell's $BASHPID to the output of 'history'.
A search for HISTTIMEFORMAT and $BASHPID returned nothing. ANy suggestions on how to get this kind of behavior?
bash command-history
asked Jul 3 '17 at 20:55
mikemtnbikesmikemtnbikes
1403
I often have multiple sessions running at any given time. This sometimes leads to issues when trying to reconstruct work using history. As a result, I was thinking it would be useful to include the $BASHPID somehow so that I could sort by shell and then time. My naive attempt at this was to try
export HISTTIMEFORMAT="$BASHPID %Y %m %d - %H:%M:%S| "
But all this does is add the current shell's $BASHPID to the output of 'history'.
A search for HISTTIMEFORMAT and $BASHPID returned nothing. ANy suggestions on how to get this kind of behavior?
bash command-history
bash command-history
asked Jul 3 '17 at 20:55
mikemtnbikesmikemtnbikes
1403
asked Jul 3 '17 at 20:55
mikemtnbikesmikemtnbikes
1403
asked Jul 3 '17 at 20:55
mikemtnbikesmikemtnbikes
1403
asked Jul 3 '17 at 20:55
mikemtnbikesmikemtnbikes
1403
asked Jul 3 '17 at 20:55
mikemtnbikesmikemtnbikes
1403
1403
How about adding tty?
– Rui F Ribeiro
Jul 3 '17 at 20:59
@RuiFRibeiro could you be more explicit?
– mikemtnbikes
Jul 3 '17 at 21:03
if running multiple windows in a graphical shell, tty is also useful to keep an idea of what is done in several screens; or to keep a notion of what is being done by different remote users when root is being (ab)used.man tty
– Rui F Ribeiro
Jul 3 '17 at 21:09
@RuiFRibeiro Yes, but I don't see how that information can be stored in the .bash_history file.
– mikemtnbikes
Jul 3 '17 at 21:27
Indeed, the more I understand the more I think I'll have to have multiple history files (one for each BASHPID 'cause that's more granular than tty) and then somehow process them together to make the default .bash_history file.
– mikemtnbikes
Jul 3 '17 at 21:27
|
show 2 more comments
How about adding tty?
– Rui F Ribeiro
Jul 3 '17 at 20:59
@RuiFRibeiro could you be more explicit?
– mikemtnbikes
Jul 3 '17 at 21:03
if running multiple windows in a graphical shell, tty is also useful to keep an idea of what is done in several screens; or to keep a notion of what is being done by different remote users when root is being (ab)used.man tty
– Rui F Ribeiro
Jul 3 '17 at 21:09
@RuiFRibeiro Yes, but I don't see how that information can be stored in the .bash_history file.
– mikemtnbikes
Jul 3 '17 at 21:27
Indeed, the more I understand the more I think I'll have to have multiple history files (one for each BASHPID 'cause that's more granular than tty) and then somehow process them together to make the default .bash_history file.
– mikemtnbikes
Jul 3 '17 at 21:27
How about adding tty?
– Rui F Ribeiro
Jul 3 '17 at 20:59
How about adding tty?
– Rui F Ribeiro
Jul 3 '17 at 20:59
@RuiFRibeiro could you be more explicit?
– mikemtnbikes
Jul 3 '17 at 21:03
@RuiFRibeiro could you be more explicit?
– mikemtnbikes
Jul 3 '17 at 21:03
if running multiple windows in a graphical shell, tty is also useful to keep an idea of what is done in several screens; or to keep a notion of what is being done by different remote users when root is being (ab)used.
man tty– Rui F Ribeiro
Jul 3 '17 at 21:09
if running multiple windows in a graphical shell, tty is also useful to keep an idea of what is done in several screens; or to keep a notion of what is being done by different remote users when root is being (ab)used.
man tty– Rui F Ribeiro
Jul 3 '17 at 21:09
@RuiFRibeiro Yes, but I don't see how that information can be stored in the .bash_history file.
– mikemtnbikes
Jul 3 '17 at 21:27
@RuiFRibeiro Yes, but I don't see how that information can be stored in the .bash_history file.
– mikemtnbikes
Jul 3 '17 at 21:27
Indeed, the more I understand the more I think I'll have to have multiple history files (one for each BASHPID 'cause that's more granular than tty) and then somehow process them together to make the default .bash_history file.
– mikemtnbikes
Jul 3 '17 at 21:27
Indeed, the more I understand the more I think I'll have to have multiple history files (one for each BASHPID 'cause that's more granular than tty) and then somehow process them together to make the default .bash_history file.
– mikemtnbikes
Jul 3 '17 at 21:27
|
show 2 more comments
2 Answers
2
active
oldest
votes
4
My strategy is to add to /etc/bash.bashrc the following line:
readonly PROMPT_COMMAND='history -a >(logger -t "cmdline $USER[$PWD] $SSH_TTY $SSH_CONNECTION")'
Then in /etc/rsyslog.conf:
*.* @syslogserver:514
I prefer this approach than logging to a single file, as:
- files are rotated (i.e. do not grow too much)
- the user does not delete the history
- it creates a remote log trail resistant to tampering/hacking of a server
- The rotation log in the remote syslog server can be changed to keep some months of logging
- syslog-ng allows you to have separe file logs per logging IP address
- it is all in a central point, and you do not need to be entering multiple serves to understand what is happening
- when the remote bash session is aborted, the local history is lost, and it is not lost with this method
- also when several sessions are opened by the same user, once again all the commands do not get in history, and I get them with this method.
answered Jul 4 '17 at 8:00
Rui F RibeiroRui F Ribeiro
41.4k1481140
Thanks for the help. I understand now that the process substitution>(…)is treated as the filename used to append the history to, thus: storing it.
– Arrow
Jul 5 '17 at 18:28
To really improve security you need to also set as read onlyHISTCONTROL. If the option ignorespace, a command that start with an space will not be logged. And keep HISTIGNORE empty to prevent that some commands are not stored.
– Arrow
Jul 6 '17 at 0:12
Also, if someone executes the commandnano shtest, that is what will be logged, only a perfectly innocuousnanoeditor, but inside the file, a simpleexec sh, orexec badprogramwill allow an user to avoid detection.
– Arrow
Jul 6 '17 at 0:25
And, also, as the logging takes place after a command has returned to the shell (not before), the process may take actions to change the name of the process or some other mischief.
– Arrow
Jul 6 '17 at 0:28
1
Indeed it is not full proof ; it is just another tool.
– Rui F Ribeiro
Jul 6 '17 at 13:24
|
show 1 more comment
2
You need something like "bash eternal history".
There is a good description in here to get it working.
That solution is still lacking the PID, which could be added with the ideas from here.
Mainly:
export HISTTIMEFORMAT="%s "
PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND ; }"'
echo $$ $USER "$(history 1)" >> ~/.bash_eternal_history'
Which is using the $PROMPT_COMMAND to generate a:
$PID $USER $LAST_COMMAND
output per command executed.
answered Jul 3 '17 at 22:52
ArrowArrow
2,490218
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
});
}
});
draft saved
draft discarded
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%2f375067%2fadd-bashpid-to-history%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
4
My strategy is to add to /etc/bash.bashrc the following line:
readonly PROMPT_COMMAND='history -a >(logger -t "cmdline $USER[$PWD] $SSH_TTY $SSH_CONNECTION")'
Then in /etc/rsyslog.conf:
*.* @syslogserver:514
I prefer this approach than logging to a single file, as:
- files are rotated (i.e. do not grow too much)
- the user does not delete the history
- it creates a remote log trail resistant to tampering/hacking of a server
- The rotation log in the remote syslog server can be changed to keep some months of logging
- syslog-ng allows you to have separe file logs per logging IP address
- it is all in a central point, and you do not need to be entering multiple serves to understand what is happening
- when the remote bash session is aborted, the local history is lost, and it is not lost with this method
- also when several sessions are opened by the same user, once again all the commands do not get in history, and I get them with this method.
answered Jul 4 '17 at 8:00
Rui F RibeiroRui F Ribeiro
41.4k1481140
Thanks for the help. I understand now that the process substitution>(…)is treated as the filename used to append the history to, thus: storing it.
– Arrow
Jul 5 '17 at 18:28
To really improve security you need to also set as read onlyHISTCONTROL. If the option ignorespace, a command that start with an space will not be logged. And keep HISTIGNORE empty to prevent that some commands are not stored.
– Arrow
Jul 6 '17 at 0:12
Also, if someone executes the commandnano shtest, that is what will be logged, only a perfectly innocuousnanoeditor, but inside the file, a simpleexec sh, orexec badprogramwill allow an user to avoid detection.
– Arrow
Jul 6 '17 at 0:25
And, also, as the logging takes place after a command has returned to the shell (not before), the process may take actions to change the name of the process or some other mischief.
– Arrow
Jul 6 '17 at 0:28
1
Indeed it is not full proof ; it is just another tool.
– Rui F Ribeiro
Jul 6 '17 at 13:24
|
show 1 more comment
4
My strategy is to add to /etc/bash.bashrc the following line:
readonly PROMPT_COMMAND='history -a >(logger -t "cmdline $USER[$PWD] $SSH_TTY $SSH_CONNECTION")'
Then in /etc/rsyslog.conf:
*.* @syslogserver:514
I prefer this approach than logging to a single file, as:
- files are rotated (i.e. do not grow too much)
- the user does not delete the history
- it creates a remote log trail resistant to tampering/hacking of a server
- The rotation log in the remote syslog server can be changed to keep some months of logging
- syslog-ng allows you to have separe file logs per logging IP address
- it is all in a central point, and you do not need to be entering multiple serves to understand what is happening
- when the remote bash session is aborted, the local history is lost, and it is not lost with this method
- also when several sessions are opened by the same user, once again all the commands do not get in history, and I get them with this method.
answered Jul 4 '17 at 8:00
Rui F RibeiroRui F Ribeiro
41.4k1481140
Thanks for the help. I understand now that the process substitution>(…)is treated as the filename used to append the history to, thus: storing it.
– Arrow
Jul 5 '17 at 18:28
To really improve security you need to also set as read onlyHISTCONTROL. If the option ignorespace, a command that start with an space will not be logged. And keep HISTIGNORE empty to prevent that some commands are not stored.
– Arrow
Jul 6 '17 at 0:12
Also, if someone executes the commandnano shtest, that is what will be logged, only a perfectly innocuousnanoeditor, but inside the file, a simpleexec sh, orexec badprogramwill allow an user to avoid detection.
– Arrow
Jul 6 '17 at 0:25
And, also, as the logging takes place after a command has returned to the shell (not before), the process may take actions to change the name of the process or some other mischief.
– Arrow
Jul 6 '17 at 0:28
1
Indeed it is not full proof ; it is just another tool.
– Rui F Ribeiro
Jul 6 '17 at 13:24
|
show 1 more comment
4
4
4
My strategy is to add to /etc/bash.bashrc the following line:
readonly PROMPT_COMMAND='history -a >(logger -t "cmdline $USER[$PWD] $SSH_TTY $SSH_CONNECTION")'
Then in /etc/rsyslog.conf:
*.* @syslogserver:514
I prefer this approach than logging to a single file, as:
- files are rotated (i.e. do not grow too much)
- the user does not delete the history
- it creates a remote log trail resistant to tampering/hacking of a server
- The rotation log in the remote syslog server can be changed to keep some months of logging
- syslog-ng allows you to have separe file logs per logging IP address
- it is all in a central point, and you do not need to be entering multiple serves to understand what is happening
- when the remote bash session is aborted, the local history is lost, and it is not lost with this method
- also when several sessions are opened by the same user, once again all the commands do not get in history, and I get them with this method.
answered Jul 4 '17 at 8:00
Rui F RibeiroRui F Ribeiro
41.4k1481140
My strategy is to add to /etc/bash.bashrc the following line:
readonly PROMPT_COMMAND='history -a >(logger -t "cmdline $USER[$PWD] $SSH_TTY $SSH_CONNECTION")'
Then in /etc/rsyslog.conf:
*.* @syslogserver:514
I prefer this approach than logging to a single file, as:
- files are rotated (i.e. do not grow too much)
- the user does not delete the history
- it creates a remote log trail resistant to tampering/hacking of a server
- The rotation log in the remote syslog server can be changed to keep some months of logging
- syslog-ng allows you to have separe file logs per logging IP address
- it is all in a central point, and you do not need to be entering multiple serves to understand what is happening
- when the remote bash session is aborted, the local history is lost, and it is not lost with this method
- also when several sessions are opened by the same user, once again all the commands do not get in history, and I get them with this method.
answered Jul 4 '17 at 8:00
Rui F RibeiroRui F Ribeiro
41.4k1481140
edited 8 hours ago
answered Jul 4 '17 at 8:00
Rui F RibeiroRui F Ribeiro
41.4k1481140
answered Jul 4 '17 at 8:00
Rui F RibeiroRui F Ribeiro
41.4k1481140
answered Jul 4 '17 at 8:00
Rui F RibeiroRui F Ribeiro
41.4k1481140
41.4k1481140
Thanks for the help. I understand now that the process substitution>(…)is treated as the filename used to append the history to, thus: storing it.
– Arrow
Jul 5 '17 at 18:28
To really improve security you need to also set as read onlyHISTCONTROL. If the option ignorespace, a command that start with an space will not be logged. And keep HISTIGNORE empty to prevent that some commands are not stored.
– Arrow
Jul 6 '17 at 0:12
Also, if someone executes the commandnano shtest, that is what will be logged, only a perfectly innocuousnanoeditor, but inside the file, a simpleexec sh, orexec badprogramwill allow an user to avoid detection.
– Arrow
Jul 6 '17 at 0:25
And, also, as the logging takes place after a command has returned to the shell (not before), the process may take actions to change the name of the process or some other mischief.
– Arrow
Jul 6 '17 at 0:28
1
Indeed it is not full proof ; it is just another tool.
– Rui F Ribeiro
Jul 6 '17 at 13:24
|
show 1 more comment
Thanks for the help. I understand now that the process substitution>(…)is treated as the filename used to append the history to, thus: storing it.
– Arrow
Jul 5 '17 at 18:28
To really improve security you need to also set as read onlyHISTCONTROL. If the option ignorespace, a command that start with an space will not be logged. And keep HISTIGNORE empty to prevent that some commands are not stored.
– Arrow
Jul 6 '17 at 0:12
Also, if someone executes the commandnano shtest, that is what will be logged, only a perfectly innocuousnanoeditor, but inside the file, a simpleexec sh, orexec badprogramwill allow an user to avoid detection.
– Arrow
Jul 6 '17 at 0:25
And, also, as the logging takes place after a command has returned to the shell (not before), the process may take actions to change the name of the process or some other mischief.
– Arrow
Jul 6 '17 at 0:28
1
Indeed it is not full proof ; it is just another tool.
– Rui F Ribeiro
Jul 6 '17 at 13:24
Thanks for the help. I understand now that the process substitution
>(…) is treated as the filename used to append the history to, thus: storing it.– Arrow
Jul 5 '17 at 18:28
Thanks for the help. I understand now that the process substitution
>(…) is treated as the filename used to append the history to, thus: storing it.– Arrow
Jul 5 '17 at 18:28
To really improve security you need to also set as read only
HISTCONTROL. If the option ignorespace, a command that start with an space will not be logged. And keep HISTIGNORE empty to prevent that some commands are not stored.– Arrow
Jul 6 '17 at 0:12
To really improve security you need to also set as read only
HISTCONTROL. If the option ignorespace, a command that start with an space will not be logged. And keep HISTIGNORE empty to prevent that some commands are not stored.– Arrow
Jul 6 '17 at 0:12
Also, if someone executes the command
nano shtest, that is what will be logged, only a perfectly innocuous nano editor, but inside the file, a simple exec sh, or exec badprogram will allow an user to avoid detection.– Arrow
Jul 6 '17 at 0:25
Also, if someone executes the command
nano shtest, that is what will be logged, only a perfectly innocuous nano editor, but inside the file, a simple exec sh, or exec badprogram will allow an user to avoid detection.– Arrow
Jul 6 '17 at 0:25
And, also, as the logging takes place after a command has returned to the shell (not before), the process may take actions to change the name of the process or some other mischief.
– Arrow
Jul 6 '17 at 0:28
And, also, as the logging takes place after a command has returned to the shell (not before), the process may take actions to change the name of the process or some other mischief.
– Arrow
Jul 6 '17 at 0:28
1
1
Indeed it is not full proof ; it is just another tool.
– Rui F Ribeiro
Jul 6 '17 at 13:24
Indeed it is not full proof ; it is just another tool.
– Rui F Ribeiro
Jul 6 '17 at 13:24
|
show 1 more comment
2
You need something like "bash eternal history".
There is a good description in here to get it working.
That solution is still lacking the PID, which could be added with the ideas from here.
Mainly:
export HISTTIMEFORMAT="%s "
PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND ; }"'
echo $$ $USER "$(history 1)" >> ~/.bash_eternal_history'
Which is using the $PROMPT_COMMAND to generate a:
$PID $USER $LAST_COMMAND
output per command executed.
answered Jul 3 '17 at 22:52
ArrowArrow
2,490218
add a comment |
2
You need something like "bash eternal history".
There is a good description in here to get it working.
That solution is still lacking the PID, which could be added with the ideas from here.
Mainly:
export HISTTIMEFORMAT="%s "
PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND ; }"'
echo $$ $USER "$(history 1)" >> ~/.bash_eternal_history'
Which is using the $PROMPT_COMMAND to generate a:
$PID $USER $LAST_COMMAND
output per command executed.
answered Jul 3 '17 at 22:52
ArrowArrow
2,490218
add a comment |
2
2
2
You need something like "bash eternal history".
There is a good description in here to get it working.
That solution is still lacking the PID, which could be added with the ideas from here.
Mainly:
export HISTTIMEFORMAT="%s "
PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND ; }"'
echo $$ $USER "$(history 1)" >> ~/.bash_eternal_history'
Which is using the $PROMPT_COMMAND to generate a:
$PID $USER $LAST_COMMAND
output per command executed.
answered Jul 3 '17 at 22:52
ArrowArrow
2,490218
You need something like "bash eternal history".
There is a good description in here to get it working.
That solution is still lacking the PID, which could be added with the ideas from here.
Mainly:
export HISTTIMEFORMAT="%s "
PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND ; }"'
echo $$ $USER "$(history 1)" >> ~/.bash_eternal_history'
Which is using the $PROMPT_COMMAND to generate a:
$PID $USER $LAST_COMMAND
output per command executed.
answered Jul 3 '17 at 22:52
ArrowArrow
2,490218
answered Jul 3 '17 at 22:52
ArrowArrow
2,490218
answered Jul 3 '17 at 22:52
ArrowArrow
2,490218
answered Jul 3 '17 at 22:52
ArrowArrow
2,490218
2,490218
add a comment |
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
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%2f375067%2fadd-bashpid-to-history%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
How about adding tty?
– Rui F Ribeiro
Jul 3 '17 at 20:59
@RuiFRibeiro could you be more explicit?
– mikemtnbikes
Jul 3 '17 at 21:03
if running multiple windows in a graphical shell, tty is also useful to keep an idea of what is done in several screens; or to keep a notion of what is being done by different remote users when root is being (ab)used.
man tty– Rui F Ribeiro
Jul 3 '17 at 21:09
@RuiFRibeiro Yes, but I don't see how that information can be stored in the .bash_history file.
– mikemtnbikes
Jul 3 '17 at 21:27
Indeed, the more I understand the more I think I'll have to have multiple history files (one for each BASHPID 'cause that's more granular than tty) and then somehow process them together to make the default .bash_history file.
– mikemtnbikes
Jul 3 '17 at 21:27