p4 changelist cheatsheet

A changelist in Perforce is identified by an unique number and contains a list of modified files and a description (among other things). When you inform Perforce that you have created a file, deleted a file or modified a file, such changed files are by default added to a default changelist that has no changelist number.

To create a changelist by grabbing the files in the current default changelist:

$ p4 change

This opens your default editor to a temporary text file showing an empty description and the list of files from the default changelist. You have to use the editor and provide a description. If you do not want some of the files to be in the changelist you are creating, you can delete those lines in the editor. Once you save the file, the changelist is created with a unique number identifying it. After this command ends, p4 prints out its changelist number, say 123456.

Note that this command moves all the files in the default changelist to the new changelist you created. That is, unless you removed a few of them while creating the changelist.

To view all the details of an existing changelist 123456:

$ p4 change -o 123456

To add a new file to an existing changelist 123456:

$ p4 reopen -c 123456 joe/foobar.cpp

Description

To view the description of a changelist:

$ p4 describe 123456

To edit the description of an existing changelist 123456:

$ p4 change -u 123456

Shelve

To shelve the files from a changelist 123456:

$ p4 shelve -c 123456

To list the files in a shelved changelist 123456:

$ p4 describe -s -S 123456

To update a shelved changelist 123456 with newly updated files from disk:

$ p4 shelve -f -c 123456

To update a shelved file with a particular changed file from disk:

$ p4 shelve -f -c 123456 foobar.cpp

To delete the shelved files of a changelist:

$ p4 shelve -d -c 123456

To delete a few files from a shelved changelist 123456:

$ p4 shelve -d -c 123456 joe/foo.cpp joe/foo.h

Unshelve

To unshelve the files that were shelved from a changelist 123456 back to the same changelist:

$ p4 unshelve -s 123456 -c 123456

To unshelve the files that were shelved from a changelist 123456 back to a different changelist 789012:

$ p4 unshelve -s 123456 -c 789012

To unshelve the files that were shelved from a changelist 123456 back to the default changelist:

$ p4 unshelve -s 123456

Submit

To create a changelist from the default changelist and submit it to your branch in the depot:

$ p4 submit

To submit a changelist 123456 to your branch in the depot:

$ p4 submit -c 123456

Scanner in use error

Problem

I connected a HP DeskJet 2130 printer-scanner to my Windows 10 computer and installed its driver. I opened the HP Printer Assistant application and tried to scan a page and got this error:

The scanner is currently in use. Please wait until your previous task is complete and then try scanning again.

The error would not go away even if I restarted Windows or restarted the printer-scanner.

Solution

This error is extremely misleading because the scanner was not in use. After some trial and error I figured out the real cause of the error: the door to load the printer cartridge was open. I closed that, restarted Windows and restarted the device. I was able to scan without a problem after that.

How to mount remote directory on Windows using SSHFS-Win

sshfs makes it convenient to mount a directory from a remote Linux computer on a local Linux computer. SSHFS-Win makes it easy to mount a directory from a remote Linux computer on your local Windows computer.

Install the latest stable installer of WinFSP from here.
Install the latest stable installer of SSHFS-Win from here.
Open File Explorer, right-click on This PC and choose Map network drive. Choose a drive to mount at and in the Folder field enter:

\\sshfs\yourRemoteLogin@remoteComputer

Windows will ask for your password at the remote computer. After that the home directory from your remote computer will be mounted at the Windows drive you chose. I found that I had full read-write access to the files mounted from remote.

Tried with: SSHFS-Win 2.7.17334 and WinFSP 1.2.17346

How to edit remote files using Remote VSCode

Visual Studio Code is a great editor for local files. Remote VSCode is an extension that enables editing files on remote systems in your local VSCode. Note that you will need to specify individual files on the remote computer and they will appear in your local VSCode. You cannot open a remote folder and expect all of the code there to be indexed for code browsing with this method.

Install rmate on the remote computer. rmate has been ported from its original Ruby implementation to Python, Bash and other languages. I like to use rmate-python. Installing it is easy:

$ sudo pip3 install rmate

On your local VSCode, install the Remote VSCode extension from here.
Open Preferences → Settings and in the User Settings window, add the following settings:

//-------- Remote VSCode configuration --------

// Port number to use for connection.
"remote.port": 52698,

// Launch the server on start up.
"remote.onstartup": true

// Address to listen on.
"remote.host": "127.0.0.1"

// If set to true, error for remote.port already in use won't be shown anymore.
"remote.dontShowPortAlreadyInUseError": false

Restart VSCode and run the command Remote: Start server by pressing F1.
SSH to your remote machine with port tunneling:

$ ssh -R 52698:127.0.0.1:52698 yourlogin@remotecomputer

Once you are SSHed into the remote computer, run this command there:

$ rmate -p 52698 file/you/want/to/edit

The file will appear in your local VSCode for editing. The remote file will be updated with any changes you make locally after you save the file.

Tried with: Visual Studio Code 1.22.2 and Remote VSCode 1.1.0

How to convert Unix and Windows paths in Cygwin

Cygwin uses Unix paths. It can be sometimes confusing to figure out where in the Windows filesystem a Cygwin path is actually referring to. This is precisely why Cygwin ships with the cygpath tool.

To print the Windows path of a Cygwin Unix path:

$ cygwin -w /some/unix/path
C:\cygwin64\some\unix\path

To print the Windows path of a Cygwin Unix path in a DOS-compatible path format:

$ cygwin -d /some/unix/path

To find out how a Windows path can be accessed inside Cygwin as an Unix path:

$ cygwin -u "C:\Windows"
/cygdrive/c/Windows

How to specify number of bits in a byte

In C and C++ code, I sometimes need to specify the number of bits in a byte. For example, when creating a bitset object. In old architectures, the number of bits that make a byte has varied, from 1 to 48 bits. But for all practical purposes today, 8 bits make a byte. However, I am not comfortable using the magic number 8 in my code or creating a new constant variable with that value whenever I need it.

Thankfully, the C and C++ standards have a constant for that: CHAR_BIT. It is defined in limits.h and climits. It is guaranteed to be set to the number of bits in a byte on the architecture you are running on.

How to use clipboard for Vim in VSCode

Visual Studio Code has a decent Vim extension. I use it by default and sometimes wish I could yank to and paste from the system clipboard. Thankfully, this feature is available in the Vim extension, but turned off by default.

To turn on this feature, set the vim.useSytemClipboard setting to true. You may need to restart VSCode for it to take effect.

Note that you can yank text to the clipboard of your OS and also paste from it into VSCode using Vim.

Tried with: Vim extension for Visual Studio Code 0.11.5 and Visual Studio Code 1.22.2

How to debug make using remake

In big projects that use Make, it can be hard to examine how a make build is working and to diagnose a build problem. Imagine my joy when I finally discovered ReMake. This is a debugger, you heard it right, built off a version of GNU Make. It essentially allows you to step through a make build just like you would step through a program using GDB and examine state at any point in time.

Installing remake is easy on Ubuntu:

$ sudo apt install remake

Using remake is as easy as replacing your make command with it:

$ remake
$ remake some_target

If you want a verbose output of what is happening with your build use -x option:

$ remake -x

To actually debug a build with its debugger:

$ remake -X

The debugger jumps and waits at the line with the target that it needs to execute first. Use the help command to get a list of commands that you can use. They are all similar to GDB: step to step into, next to execute next line, print to print values of make variables (this is a lifesaver!) and so on.

Tried with: remake 3.82 and Ubuntu 16.04

How to list environment variables used by program

Problem

Many programs fail or behave mysteriously because they are looking for or reading environment variables that you may not be aware of. It would be very useful if you could see what environment variables they are probing for.

Solution

If the program is using the getenv standard library call, then you can list all those calls, the environment variable requested for and what value was returned using ltrace:

$ ltrace -e getenv ./your_program

You will be surprised how many environment variables you had no idea about are probed by common programs that you use. I find this usage to be immensely useful in increasing my understanding of any program I use.

How to use ltrace

ltrace is an immensely useful tool to know what a program is doing. It displays the library calls made by a program that you execute. Just like strace, it will display the function called, list its input arguments and also display the return value from the function. Note that only calls made to dynamically linked libraries are reported. Not those to libraries that have been statically linked into the executable.

Installing ltrace is easy:

$ sudo apt install ltrace

Provide a program as argument when you invoke it:

$ ltrace ./foobar
$ ltrace touch

Note that it writes its output to stderr.

To redirect output of ltrace to a file:

$ ltrace -o foobar.log ./foobar

To filter and display only calls to a certain library function:

$ ltrace -e foobar_function_name ./foobar
$ ltrace -e malloc ./foobar

Note that you need to specify the exact name of the function. You can also use some method name and library name globs and regular expressions. For more info, please see the manual.

Tried with: ltrace 0.7.3

Description

Shelve

Unshelve

Submit

Share this:

Like this:

Problem

Solution

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Problem

Solution

Share this:

Like this:

Share this:

Like this: