I know that the history can be seen by just running the command 'history' but I am wondering where else commands may be stored.
You can check the location of the (only) history file of your shell using echo $HISTFILE. Most likely, this is what you are looking for.
Single commands may store additional information. For example, sudo may store the commands executed as root in the system log. If you run the mysql CLI, it would store its history (by default) in ~/.mysql_history.
By default it's stored in ~/.bash_history
Command history is a shell-specific feature stored on a per-user basis. The history command displays what the current instance has in memory.
The history command takes options -r, -w, and -a to read from, write to, or append to (respectively) a default history file, which is ~/.bash_history or the name stored in the HISTFILE variable.
Generally speaking, though, the shell could be configured to read and write history to an arbitrary file; there's no way to know where history could be stored without being familiar with a particular user's shell configuration files or scripts.
Related
On my development machine, I have a number of different environments, each of which maintaining an own history file with a dedicated name. This is a customer requirement which I can not change.
If I have activated one of these environments, a 'history' command will always list the contents of the current environments history-file which is ok.
However, if I want to look up something in the history of another environment, I can only do this by opening a new shell and loading the respective environment. But what I want to do is to tell 'history' from which file it should read it's input without opening a new session and loading the environment in question.
Just 'grep'ing the alternative history-file is not a satisfying option as I want the entire output (e.g. timestamps) to be formatted properly.
The question is: How can I point 'history' to process an alternative file? Trying with
$ HISTFILE=/path/to/other-histfile history
didn't help, nor did
$ export HISTFILE=/path/to/other-histfile; history
I could write a perl script to do produce the oputput I want. But perhaps there is a way to do this out of the box?
EDIT: An environment is activated by a script which sources all settings which are relevant for the history processing.
useEnv() is an alias which basically looks like this:
useEnv()
{
export HISTFILE=/some/directory/.bash_history.$ENVNAME
PROMPT_COMMAND="history -a; $PROMPT_COMMAND"
export HISTCONTROL=ignoreboth
}
EDIT, SOLUTION: KamilCuk had the solution which works for me, see his answer below. Here is my summary:
You can write an alias or a script which first clears [-c] the history list (but leaves $HISTFILE untouched), and then reads [-r] the alternative history file.
Upon the next history call the content of the alternative file is displayed.
Then, clear the history again and read back $HISTFILE
like so:
$ history -c -r /path/to/otherfile; history; history -c -r $HISTFILE
HISTFILE is the file where the command history is saved (and read on startup, and also it's the default for history command when no filename argument is given, but mostly it's for saving).
Clear current history list and then read another history file to the current history list:
history -c
history -r /path/to/other-histfile
You might want to modify HISTFILE too, so it does not get saved.
EDIT
The answer to my question is actually obvious, I simply forgot about the meaning of the EXPORT keyword. I still drop the explanation here, just in case.
So in a few words, when opening a terminal with Ctrl-Alt T a new shell is created, which is a child of the shell created at loggin. As explained here, the loggin shell is initialized by reading /etc/profile, and as explained here and more specifically here elements of the environment are transmitted to child processes, notably variables prefixed with the EXPORT keyword.
I am trying to understand what is the mechanism under which the PATH is set under linux when opening a new (virtual) terminal.
I know one can change the PATH in several files (e.g. system : /etc/{profile, bash.bashrc, ... } or user: ~/{.profile, .bash_login, .bashrc... }, some of which are read at login, the others when opening new (virtual) terminals.
According to my tests, it seems the "profile" files are read at startup (when the user logs in), which registers some startup values for variables such as PATH. Then, each time a terminal is opened these startup values are provided to other script (e.g. bashrc) for further configuration, resulting in something like : PATH_IN_TERMINAL=$BASHRC_ADDONS:$PATH_FROM_PROFILE
Notably, ~/.profile won't normally be read after login. Changing this file won't have any effect in the current session and the PATH_FROM_PROFILE part of the PATH will remain the same until one logs in again (after logout or through ssh connection for instance).
Am I correct ? And if so, where can I find a doc on the subject ?
Thanks
This is the best explanation I have found on the subject: Startup Files
The simple explanation, in most common situations is:
Upon initial login to host, read /etc/profile followed by the first of
~/.bash_profile, ~/.bash_login or ~/.profile. ~/.profile is
supported by multiple shells, so is preferred.
When Bash starts, but not immediately after login, read ~/.bashrc.
So, profile files are intended to run upon login and should be used to print initial messages (e.g. Security Warning, Message of the Day), check mail, and configure settings/variables that rarely change. Either system-wide (quotas, MOTD, etc.), or user-specific (timezone, locale, terminal, etc.).
.bashrc files are intended for individual users to customize their interactive experience. e.g. defining aliases, setting prompts, adding to PATH, etc.
I almost always add source ~/.bashrc to the end of my .profile file so that my shell is always customized to my requirements, even immediately after login.
NOTE: The above only applies to interactive shells (e.g. running on a terminal). None of these files are read if bash is run non-interactively (e.g. via cron). In those cases, you should create a different file containing required variables and specify that via the BASH_ENV environment file.
I'm new to Perforce, need to work in command line, i'm so confused why all the commands on the tutorial websites all write like $p4 command, but I have to add the port every time when try to trigger that command, for an example, for $p4 sync, i have to type $p4 -p myhost:myport sync every time even after I logged in, if i missed the host and port, like if i just typing $p4 sync, the program will just hang in there... anyone can provide some suggestions?
There are a couple ways to make myhost:1666 the default. These are, in the order of decreasing precedence:
command-line options (like -p myhost:1666)
the P4CONFIG file
environment variables (%P4PORT%)
on Windows, the registry (use p4 set P4PORT=myhost:1666 to set it)
See the docs here.
In your case, I guess the registry (if on Windows) or the env. var. (if on Linux) is the best option.
Type:
p4 set P4PORT=myhost:myport
From that point on, "myhost:myport" will be used as the P4PORT when you run commands.
If you use multiple workspaces/servers, P4CONFIG files make it easy to have different sets of settings (based on your working directory), but for a single value, "p4 set" is a nice persistent one-shot method.
I am trying to save my directory specific command line history. AKA, when I am in a directory called Happy, and I arrow up, I don't want to see all of my past command line history, I only want to see the history that was done in the specific Happy directory.
I also want all of this to get saved to a file so that I can access it later. Perhaps save it to files organized by directory, or by date, I don't know what would be best. Does anyone have anything like this set up?
Thank you!
It sounds like you could use this script on GitHub. Excerpt from README:
Per-Directory-History
Per directory history for zsh, as well as global history, and the
ability to toggle between them with ^G.
This is a implementation of per directory history for zsh, some
implementations of which exist in bash. It also implements
a per-directory-history-toggle-history function to change from using
the directory history to using the global history. In both cases the
history is always saved to both the global history and the directory
history, so the toggle state will not effect the saved histories.
Being able to switch between global and directory histories on the
fly is a novel feature as far as I am aware.
This is a standalone repository for the script, however it is also
included in oh-my-zsh as a plugin.
I am using multiple sessions of ksh on a linux machine. On one terminal when I do history, I only see history of commands typed on that terminal.
When I log out all sessions, I want to make sure that history of commands typed on all the terminal get appended on one file say .bash_history. Is it possible?
Even when I don't log out, are all these commands dynamically get appended to this history file?
I am wary of losing my commands like when someone helps me do something, I want to make sure that I can refer to that command later on.
How do I set the size of .bash_history file
Thanks,
HISTSIZE will set the size of your history, default is 512; HISTFILE should be set to the name of your history file, default is ~/.sh_history.
I suppose you could set HISTFILE to ~/.bash_history, but that might be confusing later on.
From what I can see of the docs on ksh, it should be merging your history from multiple invocations. Try opening three separate sessions and issuing a distinct different command on each then logging out. Open a new instance of your term and view your history file - are they all there?
Tested out ok under ksh on Mac OS X