neulab/tldr huggingface dataset:
If your .env file is located in a different path or has a different name you may set the PIPENV_DOTENV_LOCATION environment variable:
$ PIPENV_DOTENV_LOCATION=/path/to/.env pipenv shell
☤ Configuration With Environment Variables pipenv comes with a handful of options that can be enabled via shell environment variables. To activate them, simply create the variable in your shell and pipenv will detect it.
• PIPENV_DEFAULT_PYTHON_VERSION — Use this version of Python when creating new virtual environments, by default (e.g. 3.6).
• PIPENV_SHELL_FANCY — Always use fancy mode when invoking pipenv shell.
• PIPENV_VENV_IN_PROJECT — If set, use .venv in your project directory instead of the global virtualenv manager pew.
• PIPENV_COLORBLIND — Disable terminal colors, for some reason.
• PIPENV_NOSPIN — Disable terminal spinner, for cleaner logs. Automatically set in CI environments.
• PIPENV_MAX_DEPTH — Set to an integer for the maximum number of directories to recursively search for a Pipfile.
• PIPENV_TIMEOUT — Set to an integer for the max number of seconds Pipenv will wait for virtualenv creation to complete.  Defaults to 120 seconds.
• PIPENV_IGNORE_VIRTUALENVS — Set to disable automatically using an activated virtualenv over the current project's own virtual environment.
Also note that pip itself supports environment variables, if you need additional customization.
$ PIP_INSTALL_OPTION="-- -DCMAKE_BUILD_TYPE=Release" pipenv install -e .
☤ Custom Virtual Environment Location Pipenv's underlying pew dependency will automatically honor the WORKON_HOME environment variable, if you have it set — so you can tell pipenv to store your virtual environments wherever you want, e.g.:
export WORKON_HOME=~/.venvs
In addition, you can also have Pipenv stick the virtualenv in project/.venv by setting the PIPENV_VENV_IN_PROJECT environment variable.
☤ Testing Projects Pipenv is being used in projects like Requests for declaring development dependencies and running the test suite.
We've currently tested deployments with both Travis-CI and tox with success.
Travis CI An example Travis CI setup can be found in Requests. The project uses a Makefile to define common functions such as its init and tests commands. Here is a stripped down example .travis.yml:
language: python python: - "2.6" - "2.7" - "3.3" - "3.4" - "3.5" - "3.6" - "3.7dev"
# command to install dependencies install: "make"
# command to run tests script: - make test
and the corresponding Makefile:
init: pip install pipenv pipenv install --dev
test: pipenv run py.test tests
Tox Automation Project Alternatively, you can configure a tox.ini like the one below for both local and external testing:
[tox] envlist = flake8-py3, py26, py27, py33, py34, py35, py36, pypy
[testenv] passenv=HOME deps = pipenv commands= pipenv install --dev pipenv run py.test tests
[testenv:flake8-py3] passenv=HOME basepython = python3.4 commands= {[testenv]deps} pipenv install --dev pipenv run flake8 --version pipenv run flake8 setup.py docs project test
NOTE: With Pipenv's default configuration, you'll need to use tox's passenv parameter to pass your shell's HOME variable.
☤ Shell Completion To enable completion in fish, add this to your config:
eval (pipenv --completion)
Magic shell completions are now enabled!
☤ Working with Platform-Provided Python Components It's reasonably common for platform specific Python bindings for operating system interfaces to only be available through the system package manager, and hence unavailable for installation into virtual environments with pip. In these cases, the virtual environment can be created with access to the system site-packages directory:
$ pipenv --three --site-packages
To ensure that all pip-installable components actually are installed into the virtual environment and system packages are only used for interfaces that don't participate in Python-level dependency resolution at all, use the PIP_IGNORE_INSTALLED setting:
$ PIP_IGNORE_INSTALLED=1 pipenv install --dev
☤ PIPENV USAGE • genindex
• modindex
• search
Kenneth Reitz
2017. A <a href="http://kennethreitz.com/pages/open- projects.html">Kenneth Reitz</a> Project
GIT-STAGE(1)                       Git Manual                       GIT-STAGE(1)
git-stage - Add file contents to the staging area
git stage args...
This is a synonym for git-add(1). Please refer to the documentation of that command.
UPX(1)                                                                    UPX(1)
upx - compress or expand executable files
upx [ command ] [ options ] filename...
The Ultimate Packer for eXecutables Copyright (c) 1996-2020 Markus Oberhumer, Laszlo Molnar & John Reiser https://upx.github.io
UPX is a portable, extendable, high-performance executable packer for several different executable formats. It achieves an excellent compression ratio and offers *very* fast decompression. Your executables suffer no memory overhead or other drawbacks for most of the formats supported, because of in-place decompression.
While you may use UPX freely for both non-commercial and commercial executables (for details see the file LICENSE), we would highly appreciate if you credit UPX and ourselves in the documentation, possibly including a reference to the UPX home page. Thanks.
[ Using UPX in non-OpenSource applications without proper credits is considered not politically correct ;-) ]
UPX comes with ABSOLUTELY NO WARRANTY; for details see the file LICENSE.
This is the first production quality release, and we plan that future 1.xx releases will be backward compatible with this version.
Please report all problems or suggestions to the authors. Thanks.
UPX is a versatile executable packer with the following features:
- excellent compression ratio: compresses better than zip/gzip, use UPX to decrease the size of your distribution !
- very fast decompression: about 10 MiB/sec on an ancient Pentium 133, about 200 MiB/sec on an Athlon XP 2000+.
- no memory overhead for your compressed executables for most of the supported formats
- safe: you can list, test and unpack your executables Also, a checksum of both the compressed and uncompressed file is maintained internally.
- universal: UPX can pack a number of executable formats: * atari/tos * bvmlinuz/386    [bootable Linux kernel] * djgpp2/coff * dos/com * dos/exe * dos/sys * linux/386 * linux/elf386 * linux/sh386 * ps1/exe * rtm32/pe * tmt/adam * vmlinuz/386     [bootable Linux kernel] * vmlinux/386 * watcom/le (supporting DOS4G, PMODE/W, DOS32a and CauseWay) * win32/pe (exe and dll) * win64/pe (exe and dll) * arm/pe (exe and dll) * linux/elfamd64 * linux/elfppc32 * mach/elfppc32
- portable: UPX is written in portable endian-neutral C++
- extendable: because of the class layout it's very easy to support new executable formats or add new compression algorithms
- free: UPX can be distributed and used freely. And from version 0.99 the full source code of UPX is released under the GNU General Public License (GPL) !
You probably understand now why we call UPX the "ultimate" executable packer.
Compress This is the default operation, eg. upx yourfile.exe will compress the file specified on the command line.
Decompress All UPX supported file formats can be unpacked using the -d switch, eg. upx -d yourfile.exe will uncompress the file you've just compressed.
Test The -t command tests the integrity of the compressed and uncompressed data, eg. upx -t yourfile.exe check whether your file can be safely decompressed. Note, that this command doesn't check the whole file, only the part that will be uncompressed during program execution. This means that you should not use this command instead of a virus checker.
List The -l command prints out some information about the compressed files specified on the command line as parameters, eg upx -l yourfile.exe shows the compressed / uncompressed size and the compression ratio of yourfile.exe.
-q: be quiet, suppress warnings
-q -q (or -qq): be very quiet, suppress errors
-q -q -q (or -qqq): produce no output at all
--help: prints the help
--version: print the version of UPX
--exact: when compressing, require to be able to get a byte-identical file after decompression with option -d. [NOTE: this is work in progress and is not supported for all formats yet. If you do care, as a workaround you can compress and then decompress your program a first time - any further compress-decompress steps should then yield byte-identical results as compared to the first decompressed version.]
[ ...to be written... - type `upx --help' for now ]
COMPRESSION LEVELS & TUNING UPX offers ten different compression levels from -1 to -9, and --best. The default compression level is -8 for files smaller than 512 KiB, and -7 otherwise.
•   Compression levels 1, 2 and 3 are pretty fast.
•   Compression levels 4, 5 and 6 achieve a good time/ratio performance.
•   Compression levels 7, 8 and 9 favor compression ratio over speed.
•   Compression level --best may take a long time.
Note that compression level --best can be somewhat slow for large files, but you definitely should use it when releasing a final version of your program.
Quick info for achieving the best compression ratio:
•   Try upx --brute myfile.exe or even upx --ultra-brute myfile.exe.
•   Try if --overlay=strip works.
•   For win32/pe programs there's --strip-relocs=0. See notes below.
Info: An "overlay" means auxiliary data attached after the logical end of an executable, and it often contains application specific data (this is a common practice to avoid an extra data file, though it would be better to use resource sections).
UPX handles overlays like many other executable packers do: it simply copies the overlay after the compressed image. This works with some files, but doesn't work with others, depending on how an application actually accesses this overlayed data.
--overlay=copy    Copy any extra data attached to the file. [DEFAULT]
--overlay=strip   Strip any overlay from the program instead of copying it. Be warned, this may make the compressed program crash or otherwise unusable.
--overlay=skip    Refuse to compress any program which has an overlay.
The environment variable UPX can hold a set of default options for UPX. These options are interpreted first and can be overwritten by explicit command line parameters.  For example:
for DOS/Windows:   set UPX=-9 --compress-icons#0 for sh/ksh/zsh:    UPX="-9 --compress-icons=0"; export UPX for csh/tcsh:      setenv UPX "-9 --compress-icons=0"
Under DOS/Windows you must use '#' instead of '=' when setting the environment variable because of a COMMAND.COM limitation.
Not all of the options are valid in the environment variable - UPX will tell you.
You can explicitly use the --no-env option to ignore the environment variable.
NOTES FOR ATARI/TOS This is the executable format used by the Atari ST/TT, a Motorola 68000 based personal computer which was popular in the late '80s. Support of this format is only because of nostalgic feelings of one of the authors and serves no practical purpose :-).  See http://www.freemint.de for more info.
Packed programs will be byte-identical to the original after uncompression.  All debug information will be stripped, though.
Extra options available for this executable format:
--all-methods       Compress the program several times, using all available compression methods. This may improve the compression ratio in some cases, but usually the default method gives the best results anyway.
NOTES FOR BVMLINUZ/I386 Same as vmlinuz/i386.
NOTES FOR DOS/COM Obviously UPX won't work with executables that want to read data from themselves (like some commandline utilities that ship with Win95/98/ME).
Compressed programs only work on a 286+.
Packed programs will be byte-identical to the original after uncompression.
Maximum uncompressed size: ~65100 bytes.
--8086              Create an executable that works on any 8086 CPU.
--all-filters       Compress the program several times, using all available preprocessing filters. This may improve the compression ratio in some cases, but usually the default filter gives the best results anyway.
NOTES FOR DOS/EXE dos/exe stands for all "normal" 16-bit DOS executables.
Obviously UPX won't work with executables that want to read data from themselves (like some command line utilities that ship with Win95/98/ME).
--no-reloc          Use no relocation records in the exe header.
NOTES FOR DOS/SYS Compressed programs only work on a 286+.
Maximum uncompressed size: ~65350 bytes.
NOTES FOR DJGPP2/COFF First of all, it is recommended to use UPX *instead* of strip. strip has the very bad habit of replacing your stub with its own (outdated) version.  Additionally UPX corrects a bug/feature in strip v2.8.x: it will fix the 4 KiB alignment of the stub.
UPX includes the full functionality of stubify. This means it will automatically stubify your COFF files. Use the option --coff to disable this functionality (see below).
UPX automatically handles Allegro packfiles.
The DLM format (a rather exotic shared library extension) is not supported.
Packed programs will be byte-identical to the original after uncompression.  All debug information and trailing garbage will be stripped, though.
--coff              Produce COFF output instead of EXE. By default UPX keeps your current stub.
NOTES FOR LINUX [general] Introduction
Linux/386 support in UPX consists of 3 different executable formats, one optimized for ELF executables ("linux/elf386"), one optimized for shell scripts ("linux/sh386"), and one generic format ("linux/386").
We will start with a general discussion first, but please also read the relevant docs for each of the individual formats.
Also, there is special support for bootable kernels - see the description of the vmlinuz/386 format.
General user's overview
Running a compressed executable program trades less space on a ``permanent'' storage medium (such as a hard disk, floppy disk, CD-ROM, flash memory, EPROM, etc.) for more space in one or more ``temporary'' storage media (such as RAM, swap space, /tmp, etc.). Running a compressed executable also requires some additional CPU cycles to generate the compressed executable in the first place, and to decompress it at each invocation.
How much space is traded?  It depends on the executable, but many programs save 30% to 50% of permanent disk space.  How much CPU overhead is there?  Again, it depends on the executable, but decompression speed generally is at least many megabytes per second, and frequently is limited by the speed of the underlying disk or network I/O.
Depending on the statistics of usage and access, and the relative speeds of CPU, RAM, swap space, /tmp, and file system storage, then invoking and running a compressed executable can be faster than directly running the corresponding uncompressed program. The operating system might perform fewer expensive I/O operations to invoke the compressed program.  Paging to or from swap space or /tmp might be faster than paging from the general file system. ``Medium-sized'' programs which access about 1/3 to 1/2 of their stored program bytes can do particularly well with compression. Small programs tend not to benefit as much because the absolute savings is less.  Big programs tend not to benefit proportionally because each invocation may use only a small fraction of the program, yet UPX decompresses the entire program before invoking it. But in environments where disk or flash memory storage is limited, then compression may win anyway.
Currently, executables compressed by UPX do not share RAM at runtime in the way that executables mapped from a file system do.  As a result, if the same program is run simultaneously by more than one process, then using the compressed version will require more RAM and/or swap space.  So, shell programs (bash, csh, etc.)  and ``make'' might not be good candidates for compression.
UPX recognizes three executable formats for Linux: Linux/elf386, Linux/sh386, and Linux/386.  Linux/386 is the most generic format; it accommodates any file that can be executed.  At runtime, the UPX decompression stub re-creates in /tmp a copy of the original file, and then the copy is (re-)executed with the same arguments. ELF binary executables prefer the Linux/elf386 format by default, because UPX decompresses them directly into RAM, uses only one exec, does not use space in /tmp, and does not use /proc. Shell scripts where the underlying shell accepts a ``-c'' argument can use the Linux/sh386 format.  UPX decompresses the shell script into low memory, then maps the shell and passes the entire text of the script as an argument with a leading ``-c''.
General benefits:
- UPX can compress all executables, be it AOUT, ELF, libc4, libc5, libc6, Shell/Perl/Python/... scripts, standalone Java .class binaries, or whatever... All scripts and programs will work just as before.
- Compressed programs are completely self-contained. No need for any external program.
- UPX keeps your original program untouched. This means that after decompression you will have a byte-identical version, and you can use UPX as a file compressor just like gzip. [ Note that UPX maintains a checksum of the file internally, so it is indeed a reliable alternative. ]
- As the stub only uses syscalls and isn't linked against libc it should run under any Linux configuration that can run ELF binaries.
- For the same reason compressed executables should run under FreeBSD and other systems which can run Linux binaries. [ Please send feedback on this topic ]
General drawbacks:
- It is not advisable to compress programs which usually have many instances running (like `sh' or `make') because the common segments of compressed programs won't be shared any longer between different processes.
- `ldd' and `size' won't show anything useful because all they see is the statically linked stub.  Since version 0.82 the section headers are stripped from the UPX stub and `size' doesn't even recognize the file format.  The file patches/patch-elfcode.h has a patch to fix this bug in `size' and other programs which use GNU BFD.
General notes:
- As UPX leaves your original program untouched it is advantageous to strip it before compression.
- If you compress a script you will lose platform independence - this could be a problem if you are using NFS mounted disks.
- Compression of suid, guid and sticky-bit programs is rejected because of possible security implications.
- For the same reason there is no sense in making any compressed program suid.
- Obviously UPX won't work with executables that want to read data from themselves. E.g., this might be a problem for Perl scripts which access their __DATA__ lines.
- In case of internal errors the stub will abort with exitcode 127. Typical reasons for this to happen are that the program has somehow been modified after compression. Running `strace -o strace.log compressed_file' will tell you more.
NOTES FOR LINUX/ELF386 Please read the general Linux description first.
The linux/elf386 format decompresses directly into RAM, uses only one exec, does not use space in /tmp, and does not use /proc.
Linux/elf386 is automatically selected for Linux ELF executables.
How it works:
For ELF executables, UPX decompresses directly to memory, simulating the mapping that the operating system kernel uses during exec(), including the PT_INTERP program interpreter (if any). The brk() is set by a special PT_LOAD segment in the compressed executable itself.  UPX then wipes the stack clean except for arguments, environment variables, and Elf_auxv entries (this is required by bugs in the startup code of /lib/ld-linux.so as of May 2000), and transfers control to the program interpreter or the e_entry address of the original executable.
The UPX stub is about 1700 bytes long, partly written in assembler and only uses kernel syscalls. It is not linked against any libc.
Specific drawbacks:
- For linux/elf386 and linux/sh386 formats, you will be relying on RAM and swap space to hold all of the decompressed program during the lifetime of the process.  If you already use most of your swap space, then you may run out.  A system that is "out of memory" can become fragile.  Many programs do not react gracefully when malloc() returns 0.  With newer Linux kernels, the kernel may decide to kill some processes to regain memory, and you may not like the kernel's choice of which to kill.  Running /usr/bin/top is one way to check on the usage of swap space.
NOTES FOR LINUX/SH386 Please read the general Linux description first.
Shell scripts where the underling shell accepts a ``-c'' argument can use the Linux/sh386 format.  UPX decompresses the shell script into low memory, then maps the shell and passes the entire text of the script as an argument with a leading ``-c''.  It does not use space in /tmp, and does not use /proc.
Linux/sh386 is automatically selected for shell scripts that use a known shell.
For shell script executables (files beginning with "#!/" or "#! /") where the shell is known to accept "-c <command>", UPX decompresses the file into low memory, then maps the shell (and its PT_INTERP), and passes control to the shell with the entire decompressed file as the argument after "-c".  Known shells are sh, ash, bash, bsh, csh, ksh, tcsh, pdksh.  Restriction: UPX cannot use this method for shell scripts which use the one optional string argument after the shell name in the script (example: "#! /bin/sh option3\n".)
NOTES FOR LINUX/386 Please read the general Linux description first.
The generic linux/386 format decompresses to /tmp and needs /proc file system support. It starts the decompressed program via the execve() syscall.
Linux/386 is only selected if the specialized linux/elf386 and linux/sh386 won't recognize a file.
For files which are not ELF and not a script for a known "-c" shell, UPX uses kernel execve(), which first requires decompressing to a temporary file in the file system.  Interestingly - because of the good memory management of the Linux kernel - this often does not introduce a noticeable delay, and in fact there will be no disk access at all if you have enough free memory as the entire process takes places within the file system buffers.
A compressed executable consists of the UPX stub and an overlay which contains the original program in a compressed form.
The UPX stub is a statically linked ELF executable and does the following at program startup:
1) decompress the overlay to a temporary location in /tmp 2) open the temporary file for reading 3) try to delete the temporary file and start (execve) the uncompressed program in /tmp using /proc/<pid>/fd/X as attained by step 2) 4) if that fails, fork off a subprocess to clean up and start the program in /tmp in the meantime
- You need additional free disk space for the uncompressed program in your /tmp directory. This program is deleted immediately after decompression, but you still need it for the full execution time of the program.
- You must have /proc file system support as the stub wants to open /proc/<pid>/exe and needs /proc/<pid>/fd/X. This also means that you cannot compress programs that are used during the boot sequence before /proc is mounted.
- Utilities like `top' will display numerical values in the process name field. This is because Linux computes the process name from the first argument of the last execve syscall (which is typically something like /proc/<pid>/fd/3).
- Because of temporary decompression to disk the decompression speed is not as fast as with the other executable formats. Still, I can see no noticeable delay when starting programs like my ~3 MiB emacs (which is less than 1 MiB when compressed :-).
--force-execve      Force the use of the generic linux/386 "execve" format, i.e. do not try the linux/elf386 and linux/sh386 formats.
NOTES FOR PS1/EXE This is the executable format used by the Sony PlayStation (PSone), a Mips R3000 based gaming console which is popular since the late '90s. Support of this format is very similar to the Atari one, because of nostalgic feelings of one of the authors.
Packed programs will be byte-identical to the original after uncompression, until further notice.
Maximum uncompressed size: ~1.89 / ~7.60 MiB.
- UPX creates as default a suitable executable for CD-Mastering and console transfer. For a CD-Master main executable you could also try the special option "--boot-only" as described below. It has been reported that upx packed executables are fully compatible with the Sony PlayStation 2 (PS2, PStwo) and Sony PlayStation Portable (PSP) in Sony PlayStation (PSone) emulation mode.
- Normally the packed files use the same memory areas like the uncompressed versions, so they will not override other memory areas while unpacking. If this isn't possible UPX will abort showing a 'packed data overlap' error. With the "--force" option UPX will relocate the loading address for the packed file, but this isn't a real problem if it is a single or the main executable.
--8-bit             Uses 8 bit size compression [default: 32 bit]
--8mib-ram          PSone has 8 MiB ram available [default: 2 MiB]
--boot-only         This format is for main exes and CD-Mastering only ! It may slightly improve the compression ratio, decompression routines are faster than default ones. But it cannot be used for console transfer !
--no-align          This option disables CD mode 2 data sector format alignment. May slightly improves the compression ratio, but the compressed executable will not boot from a CD. Use it for console transfer only !
NOTES FOR RTM32/PE and ARM/PE Same as win32/pe.
NOTES FOR TMT/ADAM This format is used by the TMT Pascal compiler - see http://www.tmt.com/ .
NOTES FOR VMLINUZ/386 The vmlinuz/386 and bvmlinuz/386 formats take a gzip-compressed bootable Linux kernel image ("vmlinuz", "zImage", "bzImage"), gzip-decompress it and re-compress it with the UPX compression method.
vmlinuz/386 is completely unrelated to the other Linux executable formats, and it does not share any of their drawbacks.
- Be sure that "vmlinuz/386" or "bvmlinuz/386" is displayed during compression - otherwise a wrong executable format may have been used, and the kernel won't boot.
- Better compression (but note that the kernel was already compressed, so the improvement is not as large as with other formats). Still, the bytes saved may be essential for special needs like boot disks.
For example, this is what I get for my 2.2.16 kernel: 1589708  vmlinux 641073  bzImage        [original] 560755  bzImage.upx    [compressed by "upx -9"]
- Much faster decompression at kernel boot time (but kernel decompression speed is not really an issue these days).
Drawbacks:
NOTES FOR WATCOM/LE UPX has been successfully tested with the following extenders: DOS4G, DOS4GW, PMODE/W, DOS32a, CauseWay. The WDOS/X extender is partly supported (for details see the file bugs BUGS).
DLLs and the LX format are not supported.
--le                Produce an unbound LE output instead of keeping the current stub.
NOTES FOR WIN32/PE The PE support in UPX is quite stable now, but probably there are still some incompatibilities with some files.
Because of the way UPX (and other packers for this format) works, you can see increased memory usage of your compressed files because the whole program is loaded into memory at startup.  If you start several instances of huge compressed programs you're wasting memory because the common segments of the program won't get shared across the instances.  On the other hand if you're compressing only smaller programs, or running only one instance of larger programs, then this penalty is smaller, but it's still there.
If you're running executables from network, then compressed programs will load faster, and require less bandwidth during execution.
DLLs are supported. But UPX compressed DLLs can not share common data and code when they got used by multiple applications. So compressing msvcrt.dll is a waste of memory, but compressing the dll plugins of a particular application may be a better idea.
Screensavers are supported, with the restriction that the filename must end with ".scr" (as screensavers are handled slightly different than normal exe files).
UPX compressed PE files have some minor memory overhead (usually in the 10 - 30 KiB range) which can be seen by specifying the "-i" command line switch during compression.
--compress-exports=0 Don't compress the export section. Use this if you plan to run the compressed program under Wine. --compress-exports=1 Compress the export section. [DEFAULT] Compression of the export section can improve the compression ratio quite a bit but may not work with all programs (like winword.exe). UPX never compresses the export section of a DLL regardless of this option.
--compress-icons=0  Don't compress any icons. --compress-icons=1  Compress all but the first icon. --compress-icons=2  Compress all icons which are not in the first icon directory. [DEFAULT] --compress-icons=3  Compress all icons.
--compress-resources=0  Don't compress any resources at all.
--keep-resource=list Don't compress resources specified by the list. The members of the list are separated by commas. A list member has the following format: I<type[/name]>. I<Type> is the type of the resource. Standard types must be specified as decimal numbers, user types can be specified by decimal IDs or strings. I<Name> is the identifier of the resource. It can be a decimal number or a string. For example:
--keep-resource=2/MYBITMAP,5,6/12345
UPX won't compress the named bitmap resource "MYBITMAP", it leaves every dialog (5) resource uncompressed, and it won't touch the string table resource with identifier 12345.
--force             Force compression even when there is an unexpected value in a header field. Use with care.
--strip-relocs=0    Don't strip relocation records. --strip-relocs=1    Strip relocation records. [DEFAULT] This option only works on executables with base address greater or equal to 0x400000. Usually the compressed files becomes smaller, but some files may become larger. Note that the resulting file will not work under Windows 3.x (Win32s). UPX never strips relocations from a DLL regardless of this option.
UPX's diagnostics are intended to be self-explanatory.
Please report all bugs immediately to the authors.
Markus F.X.J. Oberhumer <markus@oberhumer.com> http://www.oberhumer.com
Laszlo Molnar <ezerotven+github@gmail.com>
John F. Reiser <jreiser@BitWagon.com>
Jens Medoch <jssg@users.sourceforge.net>
Copyright (C) 1996-2020 Markus Franz Xaver Johannes Oberhumer
Copyright (C) 1996-2020 Laszlo Molnar
Copyright (C) 2000-2020 John F. Reiser
Copyright (C) 2002-2020 Jens Medoch
This program may be used freely, and you are welcome to redistribute it under certain conditions.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the UPX License Agreement for more details.
You should have received a copy of the UPX License Agreement along with this program; see the file LICENSE. If not, visit the UPX home page.
MKSWAP(8)                     System Administration                    MKSWAP(8)
mkswap - set up a Linux swap area
mkswap [options] device [size]
mkswap sets up a Linux swap area on a device or in a file.
The device argument will usually be a disk partition (something like /dev/sdb7) but can also be a file. The Linux kernel does not look at partition IDs, but many installation scripts will assume that partitions of hex type 82 (LINUX_SWAP) are meant to be swap partitions. (Warning: Solaris also uses this type. Be careful not to kill your Solaris partitions.)
The size parameter is superfluous but retained for backwards compatibility. (It specifies the desired size of the swap area in 1024-byte blocks. mkswap will use the entire partition or file if it is omitted. Specifying it is unwise - a typo may destroy your disk.)
After creating the swap area, you need the swapon command to start using it. Usually swap areas are listed in /etc/fstab so that they can be taken into use at boot time by a swapon -a command in some boot script.
The swap header does not touch the first block. A boot loader or disk label can be there, but it is not a recommended setup. The recommended setup is to use a separate partition for a Linux swap area.
mkswap, like many others mkfs-like utils, erases the first partition block to make any previous filesystem invisible.
However, mkswap refuses to erase the first block on a device with a disk label (SUN, BSD, ...).
-c, --check Check the device (if it is a block device) for bad blocks before creating the swap area. If any bad blocks are found, the count is printed.
-f, --force Go ahead even if the command is stupid. This allows the creation of a swap area larger than the file or partition it resides on.
Also, without this option, mkswap will refuse to erase the first block on a device with a partition table.
-L, --label label Specify a label for the device, to allow swapon by label.
--lock[=mode] Use exclusive BSD lock for device or file it operates. The optional argument mode can be yes, no (or 1 and 0) or nonblock. If the mode argument is omitted, it defaults to "yes". This option overwrites environment variable $LOCK_BLOCK_DEVICE. The default is not to use any lock at all, but it’s recommended to avoid collisions with udevd or other tools.
-p, --pagesize size Specify the page size (in bytes) to use. This option is usually unnecessary; mkswap reads the size from the kernel.
-U, --uuid UUID Specify the UUID to use. The default is to generate a UUID.
-v, --swapversion 1 Specify the swap-space version. (This option is currently pointless, as the old -v 0 option has become obsolete and now only -v 1 is supported. The kernel has not supported v0 swap-space format since 2.5.22 (June 2002). The new version v1 is supported since 2.1.117 (August 1998).)
--verbose Verbose execution. With this option mkswap will output more details about detected problems during swap area set up.
LOCK_BLOCK_DEVICE=<mode> use exclusive BSD lock. The mode is "1" or "0". See --lock for more details.
The maximum useful size of a swap area depends on the architecture and the kernel version.
The maximum number of the pages that is possible to address by swap area header is 4294967295 (32-bit unsigned int). The remaining space on the swap device is ignored.
Presently, Linux allows 32 swap areas. The areas in use can be seen in the file /proc/swaps.
mkswap refuses areas smaller than 10 pages.
If you don’t know the page size that your machine uses, you may be able to look it up with cat /proc/cpuinfo (or you may not - the contents of this file depend on architecture and kernel version).
To set up a swap file, it is necessary to create that file before initializing it with mkswap, e.g. using a command like
# dd if=/dev/zero of=swapfile bs=1MiB count=$((8*1024))
to create 8GiB swapfile.
Please read notes from swapon(8) about the swap file use restrictions (holes, preallocation and copy-on-write issues).
fdisk(8), swapon(8)
The mkswap command is part of the util-linux package which can be downloaded from Linux Kernel Archive <https://www.kernel.org/pub/linux/utils/util-linux/>.
INKVIEW(1)                   Inkview Commands Manual                  INKVIEW(1)
Inkview - an SVG viewer and slideshow program.
"inkview [options] [filename ...]"
options:
-h, --help -V, --version
-f, --fullscreen -r, --recursive -t, --timer=NUMBER -s, --scale=NUMBER -p, --preload
Inkview is an Scalable Vector Graphics (SVG) viewer that can also be used for slideshows or presentations. One or more FILES or FOLDERS can be specified on the command-line for opening. Inkview will display all SVG files in the given order. Folders will be expanded to a list of contained SVG files.
You can also launch Inkview without any command-line arguments, which will bring up a file chooser that allows to select files and folders via a graphical user interface.
-?, --help Show help options
-V, --version Print Inkview version and build date (this is usually matches the Inkscape version).
-f, --fullscreen Launch Inkview in fullscreen mode.
-r, --recursive Search folders specified on the command line recursively for SVG files.  This means all SVG files in all subfolders of the specified folder will be opened.
-t, --timer=NUMBER Change to the next image every NUMBER seconds
-s, --scale=NUMBER Show image scaled by a factor of NUMBER instead of using the file's native size.
-p, --preload Preloads all SVG files. Inkview still needs to render images upon showing, however this option ensures all SVG files are already parsed and loaded into memory. This option can also be used to verify if all files can be opened properly, without having to cycle through all files manually.
•       Left, Page Up, or Backspace: show previous image
•       Right, Page Down, or Space: show next image
•       Up, or Home: go to first image
•       Down, or End: go to last image
•       Return: show control window
•       F11: toggle fullscreen mode
•       Escape or Q: quit
Open two SVG files for viewing:
inkview file1.svg file2.svg
Open all SVG files in the examples folder shipped with Inkscape:
inkview B</usr/share>/inkscape/examples
Launch a fullscreen slideshow that automatically changes to the next image every 5 seconds:
inkview --fullscreen --timer=5 [files/folders ...]
<http://www.inkscape.org/>
See inkscape(1)
Copyright (C) 1999-2020 by Authors.
Inkscape is free software; you can redistribute it and/or modify it under the terms of the GPL version 3 or later.
SL(6)                             Games Manual                             SL(6)
sl - display animations aimed to correct users who accidentally enter sl instead of ls.
sl [ -alFe ]
sl Displays animations aimed to correct users who accidentally enter sl instead of ls.  SL stands for Steam Locomotive.
-a     An accident seems to happen. You'll feel pity for people who cry for help.
-l     shows little one.
-F     It flies.
-e     Allow interrupt by Ctrl+C.
ls(1)
It rarely shows contents of current directory.
sl was written by Toyoda Masashi <toyoda@is.titech.ac.jp>. This manual page was written by Brian Ristuccia <brianr@debian.org> and Kenshi Muto <kmuto@debian.org> for the Debian GNU/Linux system but may be used by others under the same license as sl itself.
GIT-RM(1)                          Git Manual                          GIT-RM(1)
git-rm - Remove files from the working tree and from the index
git rm [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--pathspec-from-file=<file> [--pathspec-file-nul]] [--] [<pathspec>...]
Remove files matching pathspec from the index, or from the working tree and the index. git rm will not remove a file from just your working directory. (There is no option to remove a file only from the working tree and yet keep it in the index; use /bin/rm if you want to do that.) The files being removed have to be identical to the tip of the branch, and no updates to their contents can be staged in the index, though that default behavior can be overridden with the -f option. When --cached is given, the staged content has to match either the tip of the branch or the file on disk, allowing the file to be removed from just the index. When sparse-checkouts are in use (see git-sparse-checkout(1)), git rm will only remove paths within the sparse-checkout patterns.
<pathspec>... Files to remove. A leading directory name (e.g.  dir to remove dir/file1 and dir/file2) can be given to remove all files in the directory, and recursively all sub-directories, but this requires the -r option to be explicitly given.
The command removes only the paths that are known to Git.
File globbing matches across directory boundaries. Thus, given two directories d and d2, there is a difference between using git rm 'd*' and git rm 'd/*', as the former will also remove all of directory d2.
-f, --force Override the up-to-date check.
-n, --dry-run Don’t actually remove any file(s). Instead, just show if they exist in the index and would otherwise be removed by the command.
-r Allow recursive removal when a leading directory name is given.
-- This option can be used to separate command-line options from the list of files, (useful when filenames might be mistaken for command-line options).
--cached Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left alone.
--ignore-unmatch Exit with a zero status even if no files matched.
--sparse Allow updating index entries outside of the sparse-checkout cone. Normally, git rm refuses to update index entries whose paths do not fit within the sparse-checkout cone. See git-sparse-checkout(1) for more.
-q, --quiet git rm normally outputs one line (in the form of an rm command) for each file removed. This option suppresses that output.
There is no option for git rm to remove from the index only the paths that have disappeared from the filesystem. However, depending on the use case, there are several ways that can be done.
Using “git commit -a” If you intend that your next commit should record all modifications of tracked files in the working tree and record all removals of files that have been removed from the working tree with rm (as opposed to git rm), use git commit -a, as it will automatically notice and record all removals. You can also have a similar effect without committing by using git add -u.
Using “git add -A” When accepting a new code drop for a vendor branch, you probably want to record both the removal of paths and additions of new paths as well as modifications of existing paths.
Typically you would first remove all tracked files from the working tree using this command:
git ls-files -z | xargs -0 rm -f
and then untar the new code in the working tree. Alternately you could rsync the changes into the working tree.
After that, the easiest way to record all removals, additions, and modifications in the working tree is:
See git-add(1).
Other ways If all you really want to do is to remove from the index the files that are no longer present in the working tree (perhaps because your working tree is dirty so that you cannot use git commit -a), use the following command:
git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached
Only submodules using a gitfile (which means they were cloned with a Git version 1.7.8 or newer) will be removed from the work tree, as their repository lives inside the .git directory of the superproject. If a submodule (or one of those nested inside it) still uses a .git directory, git rm will move the submodules git directory into the superprojects git directory to protect the submodule’s history. If it exists the submodule.<name> section in the gitmodules(5) file will also be removed and that file will be staged (unless --cached or -n are used).
A submodule is considered up to date when the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren’t ignored are present in the submodules work tree. Ignored files are deemed expendable and won’t stop a submodule’s work tree from being removed.
If you only want to remove the local checkout of a submodule from your work tree without committing the removal, use git-submodule(1) deinit instead. Also see gitsubmodules(7) for details on submodule removal.
git rm Documentation/\*.txt Removes all *.txt files from the index that are under the Documentation directory and any of its subdirectories.
Note that the asterisk * is quoted from the shell in this example; this lets Git, and not the shell, expand the pathnames of files and subdirectories under the Documentation/ directory.
git rm -f git-*.sh Because this example lets the shell expand the asterisk (i.e. you are listing the files explicitly), it does not remove subdir/git-foo.sh.
Each time a superproject update removes a populated submodule (e.g. when switching between commits before and after the removal) a stale submodule checkout will remain in the old location. Removing the old directory is only safe when it uses a gitfile, as otherwise the history of the submodule will be deleted too. This step will be obsolete when recursive submodule update has been implemented.
git-add(1)
jhat(1)                      General Commands Manual                     jhat(1)
Name jhat - Java Heap Analysis Tool
jhat [ options ] <heap-dump-file>
options Options, if used, should follow immediately after the command name.
heap-dump-file Java binary heap dump file to be browsed. For a dump file that contains multiple heap dumps, you may specify which dump in the file by appending "#<number> to the file name, i.e. "foo.hprof#3".
The jhat command parses a java heap dump file and launches a webserver. jhat enables you to browse heap dumps using your favorite webbrowser. jhat supports pre-designed queries (such as 'show all instances of a known class "Foo"') as well as OQL (Object Query Language) - a SQL-like query language to query heap dumps. Help on OQL is available from the OQL help page shown by jhat. With the default port, OQL help is available at http://localhost:7000/oqlhelp/
There are several ways to generate a java heap dump:
o Use jmap(1) -dump option to obtain a heap dump at runtime;
o Use jconsole(1) option to obtain a heap dump via HotSpotDiagnosticMXBean @ http://docs.oracle.com/javase/7/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html at runtime;
o Heap dump will be generated when OutOfMemoryError is thrown by specifying -XX:+HeapDumpOnOutOfMemoryError VM option;
o Use hprof @ https://docs.oracle.com/javase/7/docs/technotes/samples/hprof.html.
NOTE: This tool is experimental and may not be available in future versions of the JDK.
-stack false/true Turn off tracking object allocation call stack. Note that if allocation site information is not available in the heap dump, you have to set this flag to false. Default is true.
-refs false/true Turn off tracking of references to objects. Default is true. By default, back pointers (objects pointing to a given object a.k.a referrers or in-coming references) are calculated for all objects in the heap.
-port port-number Set the port for the jhat's HTTP server. Default is 7000.
-exclude exclude-file Specify a file that lists data members that should be excluded from the "reachable objects" query. For example, if the file lists java.lang.String.value, then, whenever list of objects reachable from a specific object "o" are calculated, reference paths involving java.lang.String.value field will not considered.
-baseline baseline-dump-file Specify a baseline heap dump. Objects in both heap dumps with the same object ID will be marked as not being "new". Other objects will be marked as "new". This is useful while comparing two different heap dumps.
-debug int Set debug level for this tool. 0 means no debug output. Set higher values for more verbose modes.
-version Report version number and exit.
-h Output help message and exit.
-help Output help message and exit.
-J<flag> Pass <flag> to the Java virtual machine on which jhat is run. For example, -J-Xmx512m to use a maximum heap size of 512MB.
o jmap(1)
o jconsole(1)
o hprof - Heap and CPU profiling tool @ https://docs.oracle.com/javase/7/docs/technotes/samples/hprof.html.
GCAL(1)                      General Commands Manual                     GCAL(1)
Gcal - a program for calculating and printing calendars.
gcal [[Option...] [%Date] [@File...]] [Command]
Gcal is a program similar the standard calendar programs BSD-`cal' and `calendar'.
Gcal displays hybrid and proleptic Julian and Gregorian calendar sheets, respectively, for one month, three months or a whole year.  It also displays eternal holiday lists for many countries around the globe, and features a very powerful creation of fixed date lists that can be used for reminding purposes.  Gcal can calculate various astronomical data and times of the Sun and the Moon for at pleasure any location, precisely enough for most civil purposes.  Gcal supports some other calendar systems, for example the Chinese and Japanese calendar, the Hebrew calendar and the civil Islamic calendar, too.
If Gcal is started without any options or commands, a calendar of the current month is displayed.
If the calendar of a definite year is wanted, the year must be fully specified, e.g.:  gcal 94 displays a year calendar of the year 94, not of the year 1994.
If two arguments are given in the command part, the first argument denotes the month and the second argument denotes the year. In case any illegal commands are given running Gcal , the program will use internal defaults.
You obtain more program information if you start Gcal as follows: gcal -h gcal -? gcal --help
gcal -hh gcal -?? gcal --long-help[=ARG]|[=?] gcal --usage[=ARG]|[=?] A Hypertext file gcal.info containing detailed online information should be available, which you can inspect using your GNU Infobrowser.