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
- To view the description of a changelist:
$ p4 describe 123456
- To edit the description of an existing changelist 123456:
$ p4 change -u 123456
- 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
- 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
- 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
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.
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.
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:
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
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
//-------- Remote VSCode configuration --------
// Port number to use for connection.
// Launch the server on start up.
// Address to listen on.
// If set to true, error for remote.port already in use won't be shown anymore.
$ 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
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
- 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"
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.
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
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 some_target
- If you want a verbose output of what is happening with your build use
$ 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
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.
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.
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