have to set port every time in command line when trying to trigger any Perforce command - perforce

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.

Related

Where is the default .p4config file located?

I changed the P4PORT variable with the following command:
p4 configure set P4PORT=<local IPv4>:80
But now I am unable to connect to, or even start the perforce server. I was hoping that maybe someone would know where the default location for the .p4config file (I don't even think I know its proper name...) is so I can manually change the P4PORT value back to something that works.
p4 configure (server configurables persisted in the server db) is completely separate from P4CONFIG (client configurables persisted in a client-side text file).
If you've set P4PORT to an invalid value via p4 configure, you'll want to:
Check the log file (look for a file with log in its name in the P4ROOT directory) to confirm the error. I'm guessing you'll see an error about being unable to listen on that port.
Fix P4PORT via p4d -cset. (You don't want to mess around with db.config manually.)
Try again to restart the server, and start from step 1 if needed.
See p4d -h:
Configuration options:
-cshow
'-cset [server#]variable=value'
'-cunset [server#]variable'
This syntax provides a limited subset of the functionality of the
'p4 configure' command, and is useful for accessing the configuration
when the server is down. The '-cshow' flag displays the contents of
the db.config table, similar to 'p4 configure show allservers'.
The '-cset' and '-cunset' flags set or unset a configurable. When
using set or unset, enclose the entire expression in quotation marks,
and on Windows, use double quotation marks, not single ones.

Is there a way to change settings (e.g. color scheme) in a running tmux session triggered by a certain shell command (e.g. ssh)?

I just found out about the possibility of hooks in tmux. Since I'm still very new to the command line (and therefore not used to (say need time to) read through all relevant parts of a manpage) I just quickly wanted to ask here, if it is possible to use bash commands to trigger (e.g. when I use ssh, I want to change the color of my status bar). (Although I fear it is not possible).
If not, what could be a way to achieve what I want? Can I make an alias for the command in question and 'reload' a different .tmux.conf file (in a current session)?
Thanks for your help!
Edit:
For example:
I have two versions of a program where I source different environmental variables via aliases (say progVersionA and progVersionB).
When I have a tmux session running, I would like the current 'sourced' environment shown in the status bar (say "progVersionA"). And as soon as I switch to the other program the status bar should read "progVersionB". So, what I want is, that the status bar changes as soon as I run the alias progVersionB.

Unable to add files and directories to PATH

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).

Keeping track of history of commands of multiple sessions of ksh

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

GVim taking forever to load when connected to office network

When I load GVim from the Cygwin command line or when I'm not connected to the office network (mapped to U:/) it loads instantaneously. It takes a good minute or so to open when I'm on the network. What is going on here?
You probably need to set your $HOME directory to something other than U:/. Create a $HOME environment variable for Windows that points to My Documents or whatever and it won't try and use U:/. You may need to log-off/log-in to pick up the changes.
You should check what your $HOME directory is mapped to in each case. I bet that it is different depending on if you are connected to the network or not.
Do you have any custom .vimrc or other config files read at startup? If nothing else, vim will query your $HOME directory to look for such files. If your network is slow, it could cause your problem.
See ":help startup" inside vim for more details on the startup process.
It might also be a good idea to set the directory and backupdir options so they prefer a local directory. Something along the lines of
set backupdir^=C:/Temp
set directory^=C:/Temp//
The ^= syntax puts the directory at the start of the list of directories for each option. The trailing // for directory tells Vim to encode the full path to the file being edited in the swapfile's name. This allows for swapfiles to be created in one directory when editing multiple files with the same name, but different paths.

Resources