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
Related
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 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.
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 have a program, let's call it exampleProg, in my /opt directory, and I want to run it from any directory, rather than just:
/opt/radFolder/exampleProg
This should be a simple task, I've done it several times before on different computers. I've searched around, and found instructions ranging from:
edit .bash
edit .bashrc
edit .profile (Another stackoverflow answer said that, while this worked at one time, it no longer functions.)
edit /etc/environment/
with PATH="$HOME/bin:$PATH:/opt/radFolder/:" or just adding the /opt/radFolder bit.
Yet none of them seem to work. The problem that I'm running into is that there doesn't seem to be a yet there doesn't seem to be a universally agreed-upon solution. I've tried so many that I think one of my changes has prevented the appropriate one from taking effect. Would someone help me put this to rest once and for all? Many thanks in advance.
I'm running ubuntu 14.04 LTS x64.
First, understand that writing things to those files does not mean everything is instantaneously, and globally, changed. In fact, nothing is changed until the file is sourced (via . or source), and even then, the environment changes apply only to the current shell (and subsequent created children, if export is used).
INVOCATION, near the top of man bash, spells out which files are automatically sourced when. To summarize:
~/.bashrc is read for new non-login, interactive shells, e.g., when you open a GUI terminal. On many systems, this file by default in turn sources /etc/bashrc.
/etc/profile, ~/.bash_profile, and ~/.profile are read by interactive login shells.
Adding to ~/.bashrc should be effective, but it will only work for subsequently invoked, interactive, non-login shells (and their children, if $PATH is exported). However, since it's prone to being sourced repeatedly, using it to add to an existing variable (as with $PATH) can produce repeated concatenations (see here).
An issue with the second category, .profile, is that if you use a GUI login, the display manager may not source it, but it logs you in, meaning, you never invoke a login shell and hence none of those is ever sourced. If this is the case, sourcing them from ~/.xsession should work (this has a system wide correlate in /etc/X11).
After I make changes in .bash_rc or .bash_profile, when I start GNU screen, it doesn't recognize those changes.
I can
source ~/.bash_profile
and it works for the current screen window I have open, but I have to do that for every screen window I have open.
How do I get screen to read my latest changes in my bash configuration?
If you want screen to always treat your shell as a login shell, and source the same files that would be read if just started a new shell normally, add the following to ~/.screenrc (or maybe ~/.byobu/.screenrc, as pointed out in the comment):
shell -$SHELL
This way, you don't need to manually tell it to source your files each time you start a new screen. Though you would have to if you just made changes and wanted those changes to be reflected in your current screen.
The documentation for this (and lots of other screen details) can be found here. Basically, shell is a command to screen telling it to run the following when it needs to create a new shell. $SHELL is the usual variable holding the path to your preferred shell. And the dash - in front of $SHELL indicates that it should be run as a login shell (which will typically mean it sources your ~/.bash_profile, etc.).
It's worth pointing out, however, that screen defaults to just inheriting most environment variables from the shell where you start screen; and a login sub-shell may alter some environment variables in unexpected ways. I ran into a situation where elements of my $PATH were basically permuted. I solved the problem thanks to this particularly excellent answer on superuser.
You may notice the source command available. It's important to note that this sources a file of screen commands, rather than shell commands. Other relevant (screen) commands include eval and exec.
You have to do it in each screen that you have open since they are all different shells. If you need the change every time a new shell is opened, I suggest you put the changes in ~/.bashrc instead.
Apparently, you can send a command to all windows at once using this syntax:
C-a :
at "#" stuff "source ~/.bash_profile^M"