neulab/tldr huggingface dataset:
Examples, open an interactive session: cabal v2-repl for the default component in the package in the current directory cabal v2-repl pkgname for the default component in the package named 'pkgname' cabal v2-repl ./pkgfoo for the default component in the package in the ./pkgfoo directory cabal v2-repl cname for the component named 'cname' cabal v2-repl pkgname:cname for the component 'cname' in the package 'pkgname'
cabal v2-repl --build-depends lens add the latest version of the library 'lens' to the default component (or no componentif there is no project present) cabal v2-repl --build-depends "lens >= 4.15 && < 4.18" add a version (constrained between 4.15 and 4.18) of the library 'lens' to the default component (or no component if there is no project present) Note: this command is part of the new project-based system (aka nix-style local builds). These features are currently in beta. Please see http://cabal.readthedocs.io/en/latest/nix-local-build-overview.html for details and advice on what you can expect to work. If you encounter problems please file issues at https://github.com/haskell/cabal/issues and if you have any time to get involved and help with testing, fixing bugs etc then that is very much appreciated.
Usage: cabal freeze [FLAGS]
The project configuration is frozen so that it will be reproducible in future.
The precise dependency configuration for the project is written to the specified). This file extends the configuration from the 'cabal.project' file and thus is used as the project configuration for all other commands (such as
The freeze file can be kept in source control. To make small adjustments it may be edited manually, or to make bigger changes you may wish to delete the file and re-freeze. For more control, one approach is to try variations using once you have a satisfactory solution to freeze it using the 'freeze' command with the same set of flags.
cabal new-freeze
Usage: cabal new-freeze [FLAGS]
The freeze file can be kept in source control. To make small adjustments it may be edited manually, or to make bigger changes you may wish to delete the file and re-freeze. For more control, one approach is to try variations using once you have a satisfactory solution to freeze it using the 'new-freeze' command with the same set of flags.
cabal v2-freeze
Usage: cabal v2-freeze [FLAGS]
The freeze file can be kept in source control. To make small adjustments it may be edited manually, or to make bigger changes you may wish to delete the file and re-freeze. For more control, one approach is to try variations using once you have a satisfactory solution to freeze it using the 'v2-freeze' command with the same set of flags.
Examples: cabal v2-freeze Freeze the configuration of the current project
cabal v2-build --dry-run --constraint="aeson < 1" Check what a solution with the given constraints would look like cabal v2-freeze --constraint="aeson < 1" Freeze a solution using the given constraints
cabal haddock
Usage: cabal haddock [FLAGS] TARGET
Build Haddock documentation for the specified packages within the project.
Any package in the project can be specified. If no package is specified, the default is to build the documentation for the package in the current directory. The default behaviour is to build documentation for the exposed modules of the library component (if any). This can be changed with the
Currently, documentation for dependencies is NOT built. This behavior may change in future.
Additional configuration flags can be specified on the command line and these extend the project configuration from the 'cabal.project',
cabal new-haddock
Usage: cabal new-haddock [FLAGS] TARGET
cabal v2-haddock
Usage: cabal v2-haddock [FLAGS] TARGET
Examples: cabal v2-haddock pkgname    Build documentation for the package named pkgname
Usage: cabal install [TARGETS] [FLAGS]
Installs one or more packages. This is done by installing them in the store and symlinking/copying the executables in the directory specified by the --installdir flag (`~/.cabal/bin/` by default). If you want the installed executables to be available globally, make sure that the PATH environment variable contains that directory.
If TARGET is a library, it will be added to the global environment. When doing this, cabal will try to build a plan that includes all the previously installed libraries. This is currently not implemented.
--lib Install libraries rather than executables from the target package.
-z, --ignore-project Ignore local project configuration
--package-env, --env ENV Set the environment file that may be modified.
--overwrite-policy always|never How to handle already existing symlinks.
--install-method copy|symlink How to install the executables.
--installdir DIR Where to install (by symlinking or copying) the executables in.
cabal new-install
Usage: cabal new-install [TARGETS] [FLAGS]
cabal v2-install
Usage: cabal v2-install [TARGETS] [FLAGS]
Examples: cabal v2-install Install the package in the current directory cabal v2-install pkgname Install the package named pkgname (fetching it from hackage if necessary) cabal v2-install ./pkgfoo Install the package in the ./pkgfoo directory Note: this command is part of the new project-based system (aka nix-style local builds). These features are currently in beta. Please see http://cabal.readthedocs.io/en/latest/nix-local-build-overview.html for details and advice on what you can expect to work. If you encounter problems please file issues at https://github.com/haskell/cabal/issues and if you have any time to get involved and help with testing, fixing bugs etc then that is very much appreciated.
cabal run
Usage: cabal run [TARGET] [FLAGS] [-- EXECUTABLE_FLAGS]
Runs the specified executable-like component (an executable, a test, or a benchmark), first ensuring it is up to date.
Any executable-like component in any package in the project can be specified.  A package can be specified if contains just one executable- like. The default is to use the package in the current directory if it contains just one executable-like.
Extra arguments can be passed to the program, but use '--' to separate arguments for the program from arguments for cabal. The executable is run in an environment where it can find its data files inplace in the build tree.
cabal new-run
Usage: cabal new-run [TARGET] [FLAGS] [-- EXECUTABLE_FLAGS]
cabal v2-run
Usage: cabal v2-run [TARGET] [FLAGS] [-- EXECUTABLE_FLAGS]
Examples: cabal v2-run Run the executable-like in the package in the current directory cabal v2-run foo-tool Run the named executable-like (in any package in the project) cabal v2-run pkgfoo:foo-tool Run the executable-like 'foo-tool' in the package 'pkgfoo' cabal v2-run foo -O2 -- dothing --fooflag Build with '-O2' and run the program, passing it extra arguments.
Usage: cabal test [TARGETS] [FLAGS]
Runs the specified test-suites, first ensuring they are up to date.
Any test-suite in any package in the project can be specified. A package can be specified in which case all the test-suites in the package are run. The default is to run all the test-suites in the package in the current directory.
To pass command-line arguments to a test suite, see the run command.
cabal new-test
Usage: cabal new-test [TARGETS] [FLAGS]
To pass command-line arguments to a test suite, see the new-run command.
cabal v2-test
Usage: cabal v2-test [TARGETS] [FLAGS]
To pass command-line arguments to a test suite, see the v2-run command.
Examples: cabal v2-test Run all the test-suites in the package in the current directory cabal v2-test pkgname Run all the test-suites in the package named pkgname cabal v2-test cname Run the test-suite named cname cabal v2-test cname --enable-coverage Run the test-suite built with code coverage (including local libs used)
cabal bench
Usage: cabal bench [TARGETS] [FLAGS]
Runs the specified benchmarks, first ensuring they are up to date.
Any benchmark in any package in the project can be specified. A package can be specified in which case all the benchmarks in the package are run. The default is to run all the benchmarks in the package in the current directory.
cabal new-bench
Usage: cabal new-bench [TARGETS] [FLAGS]
cabal v2-bench
Usage: cabal v2-bench [TARGETS] [FLAGS]
Examples: cabal v2-bench Run all the benchmarks in the package in the current directory cabal v2-bench pkgname Run all the benchmarks in the package named pkgname cabal v2-bench cname Run the benchmark named cname cabal v2-bench cname -O2 Run the benchmark built with '-O2' (including local libs used)
cabal exec
Usage: cabal exec [FLAGS] [--] COMMAND [--] [ARGS]
During development it is often useful to run build tasks and perform one- off program executions to experiment with the behavior of build tools. It is convenient to run these tools in the same way cabal itself would. The `cabal exec` command provides a way to do so.
Compiler tools will be configured to see the same subset of the store that builds would see. The PATH is modified to make all executables in the dependency tree available (provided they have been built already). Commands are also rewritten in the way cabal itself would. For example, `cabal exec ghc` will consult the configuration to choose an appropriate version of ghc and to include any ghc-specific flags requested.
cabal new-exec
Usage: cabal new-exec [FLAGS] [--] COMMAND [--] [ARGS]
During development it is often useful to run build tasks and perform one- off program executions to experiment with the behavior of build tools. It is convenient to run these tools in the same way cabal itself would. The `cabal new-exec` command provides a way to do so.
Compiler tools will be configured to see the same subset of the store that builds would see. The PATH is modified to make all executables in the dependency tree available (provided they have been built already). Commands are also rewritten in the way cabal itself would. For example, `cabal new-exec ghc` will consult the configuration to choose an appropriate version of ghc and to include any ghc-specific flags requested.
cabal v2-exec
Usage: cabal v2-exec [FLAGS] [--] COMMAND [--] [ARGS]
During development it is often useful to run build tasks and perform one- off program executions to experiment with the behavior of build tools. It is convenient to run these tools in the same way cabal itself would. The `cabal v2-exec` command provides a way to do so.
Compiler tools will be configured to see the same subset of the store that builds would see. The PATH is modified to make all executables in the dependency tree available (provided they have been built already). Commands are also rewritten in the way cabal itself would. For example, `cabal v2-exec ghc` will consult the configuration to choose an appropriate version of ghc and to include any ghc-specific flags requested.
cabal clean
Usage: cabal new-clean [FLAGS]
Removes all temporary files created during the building process (.hi, .o, preprocessed sources, etc.) and also empties out the local caches (by default).
-s, --save-config Save configuration, only remove build artifacts
cabal new-clean
cabal v2-clean
cabal sdist
Usage: cabal sdist [FLAGS] [PACKAGES]
Generates tarballs of project packages suitable for upload to Hackage.
-l, --list-only Just list the sources, do not make a tarball
-z, --null-sep Separate the source files with NUL bytes rather than newlines.
-o, --output-dir, --outputdir PATH Choose the output directory of this command. '-' sends all output to stdout
cabal new-sdist
Usage: cabal new-sdist [FLAGS] [PACKAGES]
cabal v2-sdist
Usage: cabal v2-sdist [FLAGS] [PACKAGES]
cabal v1-configure
Usage: cabal v1-configure [FLAGS]
Configure how the package is built by setting package (and other) flags.
The configuration affects several other commands, including v1-build, v1-test, v1-bench, v1-run, v1-repl.
The flags --with-PROG and --PROG-option(s) can be used with the following programs: alex ar c2hs cpphs doctest gcc ghc ghc-pkg ghcjs ghcjs-pkg greencard haddock happy haskell-suite haskell-suite-pkg hmake hpc hsc2hs hscolour jhc ld pkg-config runghc strip tar uhc
Examples: cabal v1-configure Configure with defaults; cabal v1-configure --enable-tests -fcustomflag Configure building package including tests, with some package-specific flag.
The v1-configure command is a part of the legacy v1 style of cabal usage.
It is a legacy feature and will be removed in a future release of cabal- install. Please file a bug if you cannot replicate a working v1- use case with the nix-style commands.
For more information, see: https://cabal.readthedocs.io/en/latest/nix- local-build-overview.html
cabal v1-update
Usage: cabal v1-update [FLAGS]
Relevant global configuration keys: remote-repo remote-repo-cache local-repo
The v1-update command is a part of the legacy v1 style of cabal usage.
--index-state STATE Update the source package index to its state as it existed at a previous time. Accepts unix-timestamps (e.g. '@1474732068'), ISO8601 UTC timestamps (e.g. '2016-09-24T17:47:48Z'), or 'HEAD' (default: 'HEAD').
cabal v1-build
Usage: cabal v1-build [FLAGS] or: cabal v1-build COMPONENTS [FLAGS]
Components encompass executables, tests, and benchmarks.
Affected by configuration options, see `v1-configure`.
Examples: cabal v1-build               All the components in the package cabal v1-build foo           A component (i.e. lib, exe, test suite)
The v1-build command is a part of the legacy v1 style of cabal usage.
--only Don't reinstall add-source dependencies (sandbox-only)
cabal v1-repl
Usage: cabal v1-repl [COMPONENT] [FLAGS]
If the current directory contains no package, ignores COMPONENT parameters and opens an interactive interpreter session; if a sandbox is present, its package database will be used.
Otherwise, (re)configures with the given or default flags, and loads the interpreter with the relevant modules. For executables, tests and benchmarks, loads the main module (and its dependencies); for libraries all exposed/other modules.
The default component is the library itself, or the executable if that is the only component.
Support for loading specific modules is planned but not implemented yet. For certain scenarios, `cabal v1-exec -- ghci :l Foo` may be used instead. Note that `v1-exec` will not (re)configure and you will have to specify the location of other modules, if required.
Examples: cabal v1-repl               The first component in the package cabal v1-repl foo           A named component (i.e. lib, exe, test suite) cabal v1-repl --ghc-options="-lstdc++"  Specifying flags for interpreter
The v1-repl command is a part of the legacy v1 style of cabal usage.
--reload Used from within an interpreter to update files.
cabal v1-freeze
Calculates a valid set of dependencies and their exact versions. If successful, saves the result to the file `cabal.config`.
The package versions specified in `cabal.config` will be used for any future installs.
An existing `cabal.config` is ignored and overwritten.
The v1-freeze command is a part of the legacy v1 style of cabal usage.
--dry-run Do not freeze anything, only print what would be frozen
--enable-tests --disable-tests freezing of the dependencies of any tests suites in the package description file.
--enable-benchmarks --disable-benchmarks freezing of the dependencies of any benchmarks suites in the package description file.
cabal v1-haddock
Usage: cabal v1-haddock [FLAGS] or: cabal v1-haddock COMPONENTS [FLAGS]
Requires the program haddock, version 2.x.
The v1-haddock command is a part of the legacy v1 style of cabal usage.
--keep-temp-files Keep temporary files
--hoogle Generate a hoogle database
--html Generate HTML documentation (the default)
--html-location URL Location of HTML documentation for pre-requisite packages
--for-hackage Collection of flags to generate documentation suitable for upload to hackage
--executables Run haddock for Executables targets
--tests Run haddock for Test Suite targets
--benchmarks Run haddock for Benchmark targets
--foreign-libraries Run haddock for Foreign Library targets
--all Run haddock for all targets
--internal Run haddock for internal modules and include all symbols
--css PATH Use PATH as the haddock stylesheet
--hyperlink-source, --hyperlink-sources, --hyperlinked-source Hyperlink the documentation to the source code
--quickjump Generate an index for interactive documentation navigation
--hscolour-css PATH Use PATH as the HsColour stylesheet
--contents-location URL Bake URL in as the location for the contents page
cabal v1-install
Usage: cabal v1-install [FLAGS] or: cabal v1-install [FLAGS] PACKAGES
Installs one or more packages. By default, the installed package will be registered in the user's package database or, if a sandbox is present in the current directory, inside the sandbox.
If PACKAGES are specified, downloads and installs those packages. Otherwise, install the package in the current directory (and/or its dependencies) (there must be exactly one .cabal file in the current directory).
When using a sandbox, the flags for `v1-install` only affect the current command and have no effect on future commands. (To achieve that, `v1-configure` must be used.)  In contrast, without a sandbox, the flags to `v1-install` are saved and affect future commands such as `v1-build` and `v1-repl`. See the help for `v1-configure` for a list of commands being affected.
Installed executables will by default (and without a sandbox) be put into `~/.cabal/bin/`. If you want installed executable to be available globally, make sure that the PATH environment variable contains that directory.  When using a sandbox, executables will be put into `$SANDBOX/bin/` (by default: `./.cabal-sandbox/bin/`).
When specifying --bindir, consider also specifying --datadir; this way the sandbox can be deleted and the executable should continue working as long as bindir and datadir are left untouched.
Examples: cabal v1-install                     Package in the current directory cabal v1-install foo                 Package from the hackage server cabal v1-install foo-1.0             Specific version of a package cabal v1-install 'foo < 2'           Constrained package version cabal v1-install haddock --bindir=$HOME/hask-bin/ --datadir=$HOME/hask- data/ Change installation destination
The v1-install command is a part of the legacy v1 style of cabal usage.
cabal v1-run
Usage: cabal v1-run [FLAGS] [EXECUTABLE] [-- EXECUTABLE_FLAGS]
Builds and then runs the specified executable. If no executable is specified, but the package contains just one executable, that one is built and executed.
Use `cabal v1-test --show-details=streaming` to run a test-suite and get its full output.
Examples: cabal v1-run Run the only executable in the current package; cabal v1-run foo -- --fooflag Works similar to `./foo --fooflag`.
The v1-run command is a part of the legacy v1 style of cabal usage.
cabal v1-test
Usage: cabal v1-test [FLAGS] or: cabal v1-test TESTCOMPONENTS [FLAGS]
If necessary (re)configures with `--enable-tests` flag and builds the test suite.
Remember that the tests' dependencies must be installed if there are additional ones; e.g. with `cabal v1-install --only-dependencies --enable-tests`.
By defining UserHooks in a custom Setup.hs, the package can define actions to be executed before and after running tests.
The v1-test command is a part of the legacy v1 style of cabal usage.
--log TEMPLATE Log all test suite results to file (name template can use $pkgid, $compiler, $os, $arch, $test-suite, $result)
--machine-log TEMPLATE Produce a machine-readable log file (name template can use $pkgid, $compiler, $os, $arch, $result)
--show-details FILTER
--keep-tix-files keep .tix files for HPC between test runs
--fail-when-no-test-suites Exit with failure when no test suites are found.
cabal v1-bench
Usage: cabal v1-bench [FLAGS] or: cabal v1-bench BENCHCOMPONENTS [FLAGS]
If necessary (re)configures with `--enable-benchmarks` flag and builds the benchmarks.
Remember that the benchmarks' dependencies must be installed if there are additional ones; e.g. with `cabal v1-install --only-dependencies --enable-benchmarks`.
By defining UserHooks in a custom Setup.hs, the package can define actions to be executed before and after running benchmarks.
The v1-bench command is a part of the legacy v1 style of cabal usage.
cabal v1-exec
Usage: cabal v1-exec [FLAGS] [--] COMMAND [--] [ARGS]
A directly invoked GHC will not automatically be aware of any sandboxes: the GHC_PACKAGE_PATH environment variable controls what GHC uses. `cabal v1-exec` can be used to modify this variable: COMMAND will be executed in a modified environment and thereby uses the sandbox package database.
If there is no sandbox, behaves as identity (executing COMMAND).
Note that other cabal commands change the environment variable appropriately already, so there is no need to wrap those in `cabal v1-exec`. But with `cabal v1-exec`, the user has more control and can, for example, execute custom scripts which indirectly execute GHC.
Note that `cabal v1-repl` is different from `cabal v1-exec -- ghci` as the latter will not forward any additional flags being defined in the local package to ghci.
See `cabal sandbox`.
Examples: cabal v1-exec -- ghci -Wall Start a repl session with sandbox packages and all warnings; cabal v1-exec gitit -- -f gitit.cnf Give gitit access to the sandbox packages, and pass it a flag; cabal v1-exec runghc Foo.hs Execute runghc on Foo.hs with runghc configured to use the sandbox package database (if a sandbox is being used).
The v1-exec command is a part of the legacy v1 style of cabal usage.
cabal v1-clean
Usage: cabal v1-clean [FLAGS]
Removes .hi, .o, preprocessed sources, etc.
The v1-clean command is a part of the legacy v1 style of cabal usage.
-s, --save-configure Do not remove the configuration file (dist/setup-config) during cleaning.  Saves need to reconfigure.
cabal v1-sdist
Usage: cabal v1-sdist [FLAGS]
The v1-sdist command is a part of the legacy v1 style of cabal usage.
--list-sources FILE Just write a list of the package's sources to a file
--snapshot Produce a snapshot source distribution
--output-directory DIR Generate a source distribution in the given directory, without creating a tarball
cabal v1-doctest
Usage: cabal v1-doctest [FLAGS]
Requires the program doctest, version 0.12.
The v1-doctest command is a part of the legacy v1 style of cabal usage.
cabal v1-copy
Usage: cabal v1-copy [FLAGS] or: cabal v1-copy COMPONENTS [FLAGS]
Components encompass executables and libraries. Does not call register, and allows a prefix at install time. Without the --destdir flag, configure determines location.
Examples: cabal v1-copy               All the components in the package cabal v1-copy foo           A component (i.e. lib, exe, test suite) The v1-copy command is a part of the legacy v1 style of cabal usage.
--destdir DIR directory to copy files to, prepended to installation directories
--target-package-db DATABASE package database to copy files into. Required when using ${pkgroot} prefix.
cabal v1-register
Usage: cabal v1-register [FLAGS]
The v1-register command is a part of the legacy v1 style of cabal usage.
--user upon registration, register this package in the user's local package database
--global (default)upon registration, register this package in the system-wide package database
--inplace register the package in the build location, so it can be used without being installed
--gen-script instead of registering, generate a script to register later
--gen-pkg-config [PKG] instead of registering, generate a package registration file/directory
--print-ipid print the installed package ID calculated for this package
cabal v1-reconfigure
Usage: cabal v1-reconfigure [FLAGS]
Run `configure` with the most recently used flags, or append FLAGS to the most recently used configuration. Accepts the same flags as `cabal v1-configure'.  If the package has never been configured, the default flags are used.
Examples: cabal v1-reconfigure Configure with the most recently used flags. cabal v1-reconfigure -w PATH Reconfigure with the most recently used flags, but use the compiler at PATH.
The v1-reconfigure command is a part of the legacy v1 style of cabal usage.
cabal v1-sandbox
Usage: cabal v1-sandbox init          [FLAGS] or: cabal v1-sandbox delete        [FLAGS] or: cabal v1-sandbox add-source    [FLAGS] PATHS or: cabal v1-sandbox delete-source [FLAGS] PATHS or: cabal v1-sandbox list-sources  [FLAGS] or: cabal v1-sandbox hc-pkg        [FLAGS] [--] COMMAND [--] [ARGS]
Sandboxes are isolated package databases that can be used to prevent dependency conflicts that arise when many different packages are installed in the same database (i.e. the user's database in the home directory).
A sandbox in the current directory (created by `v1-sandbox init`) will be used instead of the user's database for commands such as `v1-install` and `v1-build`. Note that (a directly invoked) GHC will not automatically be aware of sandboxes; only if called via appropriate cabal commands, e.g. `v1-repl`, `v1-build`, `v1-exec`.
Currently, cabal will not search for a sandbox in folders above the current one, so cabal will not see the sandbox if you are in a subfolder of a sandbox.
Subcommands:
init: Initialize a sandbox in the current directory. An existing package database will not be modified, but settings (such as the location of the database) can be modified this way.
delete: Remove the sandbox; deleting all the packages installed inside.
add-source: Make one or more local packages available in the sandbox. PATHS may be relative or absolute. Typical usecase is when you need to make a (temporary) modification to a dependency: You download the package into a different directory, make the modification, and add that directory to the sandbox with `add-source`.
Unless given `--snapshot`, any add-source'd dependency that was modified since the last build will be re-installed automatically.
delete-source: Remove an add-source dependency; however, this will not delete the package(s) that have been installed in the sandbox from this dependency. You can either unregister the package(s) via `cabal v1-sandbox hc-pkg unregister` or re-create the sandbox (`v1-sandbox delete; v1-sandbox init`).
list-sources: List the directories of local packages made available via `cabal v1-sandbox add-source`.
hc-pkg: Similar to `ghc-pkg`, but for the sandbox package database. Can be used to list specific/all packages that are installed in the sandbox. For subcommands, see the help for ghc-pkg. Affected by the compiler version specified by `v1-configure`.
Relevant global configuration keys: require-sandbox ignore-sandbox
Examples: Set up a sandbox with one local dependency, located at ../foo: cabal v1-sandbox init cabal v1-sandbox add-source ../foo cabal v1-install --only-dependencies Reset the sandbox: cabal v1-sandbox delete cabal v1-sandbox init cabal v1-install --only-dependencies List the packages in the sandbox: cabal v1-sandbox hc-pkg list Unregister the `broken` package from the sandbox: cabal v1-sandbox hc-pkg -- --force unregister broken
The v1-sandbox command is a part of the legacy v1 style of cabal usage.
--snapshot Take a snapshot instead of creating a link (only applies to 'add-source')
--sandbox DIR Sandbox location (default: './.cabal-sandbox').
~/.cabal/config The defaults that can be overridden with command-line options.
~/.cabal/world A list of all packages whose installation has been explicitly requested.
To browse the list of known issues or report a new one please see https://github.com/haskell/cabal/labels/cabal-install.
TBL(1)                       General Commands Manual                      TBL(1)
tbl - format tables for troff
tbl [-Cv] [file ...]
This manual page describes the GNU version of tbl, which is part of the groff document formatting system.  tbl compiles descriptions of tables embedded within troff input files into commands that are understood by troff.  Normally, it should be invoked using the -t option of groff.  It is highly compatible with Unix tbl.  The output generated by GNU tbl cannot be processed with Unix troff; it must be processed with GNU troff. If no files are given on the command line or a filename of - is given, the standard input is read.
-C     Enable compatibility mode to recognize .TS and .TE even when followed by a character other than space or newline.  Leader characters (\a) are handled as interpreted.
-v     Print the version number.
tbl expects to find table descriptions wrapped in the .TS (table start) and .TE (table end) macros.  Within each such table sections, another table can be defined by using the request .T& before the final command .TE.  Each table definition has the following structure:
Global options This is optional.  This table part can use several of these options distributed in 1 or more lines.  The global option part must always be finished by a semi-colon ; .
Table format specification This part must be given, it is not optional.  It determines the number of columns (cells) of the table.  Moreover each cell is classified by being central, left adjusted, or numerical, etc. This specification can have several lines, but must be finished by a dot .  at the end of the last line.  After each cell definition, column specifiers can be appended, but that's optional.
Cells are separated by a tab character by default.  That can be changed by the global option tab(c), where c is an arbitrary character.
The easiest table definition is. .TS c c c . This is   centered Well,     this also .TE By using c c c, each cell in the whole table will be centered.  The separating character is here the default tab.
This     is    centered Well,   this     also
This definition is identical to .TS tab(@); ccc. This@is@centered Well,@this@also .TE Here, the separating tab character is changed to the letter @.
Moreover a title can be added and the centering directions can be changed to many other formats: .TS tab(@); c s s l c n . Title left@centers@123 another@number@75 .TE The result is
Title left      centers   123 another   number     75 Here l means left-justified, and n means numerical, which is here right-justified.
Global options The line immediately following the .TS macro may contain any of the following global options (ignoring the case of characters – Unix tbl only accepts options with all characters lowercase or all characters uppercase), separated by spaces, tabs, or commas:
allbox Enclose each item of the table in a box.
box    Enclose the table in a box.
center Center the table (default is left-justified).  The alternative keyword name centre is also recognized (this is a GNU tbl extension).
decimalpoint(c) Set the character to be recognized as the decimal point in numeric columns (GNU tbl only).
delim(xy) Use x and y as start and end delimiters for eqn(1).
doublebox Enclose the table in a double box.
doubleframe Same as doublebox (GNU tbl only).
expand Make the table as wide as the current line length (providing a column separation factor).  Ignored if one or more ‘x’ column specifiers are used (see below).
In case the sum of the column widths is larger than the current line length, the column separation factor is set to zero; such tables extend into the right margin, and there is no column separation at all.
frame  Same as box (GNU tbl only).
linesize(n) Set lines or rules (e.g. from box) in n-point type.
nokeep Don't use diversions to prevent page breaks (GNU tbl only). Normally tbl attempts to prevent undesirable breaks in boxed tables by using diversions.  This can sometimes interact badly with macro packages' own use of diversions—when footnotes, for example, are used.
nospaces Ignore leading and trailing spaces in data items (GNU tbl only).
nowarn Turn off warnings related to tables exceeding the current line width (GNU tbl only).
tab(x) Use the character x instead of a tab to separate items in a line of input data.
The global options must end with a semicolon.  There might be whitespace between an option and its argument in parentheses.
Table format specification After global options come lines describing the format of each line of the table.  Each such format line describes one line of the table itself, except that the last format line (which you must end with a period) describes all remaining lines of the table.  A single-key character describes each column of each line of the table.  Key characters can be separated by spaces or tabs.  You may run format specifications for multiple lines together on the same line by separating them with commas.
You may follow each key character with specifiers that determine the font and point size of the corresponding item, that determine column width, inter-column spacing, etc.
The longest format line defines the number of columns in the table; missing format descriptors at the end of format lines are assumed to be L.  Extra columns in the data (which have no corresponding format entry) are ignored.
The available key characters are:
a,A    Center longest line in this column and then left-justifies all other lines in this column with respect to that centered line. The idea is to use such alphabetic subcolumns (hence the name of the key character) in combination with L; they are called subcolumns because A items are indented by 1n relative to L entries.  Example:
.TS tab(;); ln,an. item one;1 subitem two;2 subitem three;3 .T& ln,an. item eleven;11 subitem twentytwo;22 subitem thirtythree;33 .TE
item one                 1 subitem two             2 subitem three           3 item eleven             11 subitem twentytwo      22 subitem thirtythree    33
c,C    Center item within the column.
l,L    Left-justify item within the column.
n,N    Numerically justify item in the column: Units positions of numbers are aligned vertically.  If there is one or more dots adjacent to a digit, use the rightmost one for vertical alignment.  If there is no dot, use the rightmost digit for vertical alignment; otherwise, center the item within the column.  Alignment can be forced to a certain position using ‘\&’; if there is one or more instances of this special (non-printing) character present within the data, use the leftmost one for alignment.  Example:
.TS n. 1 1.5 1.5.3 abcde a\&bcde .TE
1 1.5 1.5.3 abcde abcde
If numerical entries are combined with L or R entries – this can happen if the table format is changed with .T& – center the widest number (of the data entered under the N specifier regime) relative to the widest L or R entry, preserving the alignment of all numerical entries.  Contrary to A type entries, there is no extra indentation.
Using equations (to be processed with eqn) within columns which use the N specifier is problematic in most cases due to tbl's algorithm for finding the vertical alignment, as described above. Using the global delim option, however, it is possible to make tbl ignore the data within eqn delimiters for that purpose.
r,R    Right-justify item within the column.
s,S    Span previous item on the left into this column.  Not allowed for the first column.
^      Span down entry from previous row in this column.  Not allowed for the first row.
_,-    Replace this entry with a horizontal line.  Note that ‘_’ and ‘-’ can be used for table fields only, not for column separator lines.
=      Replace this entry with a double horizontal line.  Note that ‘=’ can be used for table fields only, not for column separator lines.
|      The corresponding column becomes a vertical rule (if two of these are adjacent, a double vertical rule).
A vertical bar to the left of the first key letter or to the right of the last one produces a line at the edge of the table.
To change the data format within a table, use the .T& command (at the start of a line).  It is followed by format and data lines (but no global options) similar to the .TS request.
Column specifiers Here are the specifiers that can appear in suffixes to column key letters (in any order):
b,B    Short form of fB (make affected entries bold).
d,D    Start an item that vertically spans rows, using the ‘^’ column specifier or ‘\^’ data item, at the bottom of its range rather than vertically centering it (GNU tbl only).  Example:
.TS tab(;) allbox; l l l ld r ^ l rd. 0000;foobar T{ 1111 .br 2222 T};foo r; T{ 3333 .br 4444 T};bar \^;\^ .TE
┌─────┬────────┐ │0000 │ foobar │ ├─────┼────────┤ │1111 │        │ │2222 │        │ ├─────┤        │ │   r │ foo    │ ├─────┼────────┤ │3333 │        │ │4444 │    bar │ └─────┴────────┘ e,E    Make equally-spaced columns.  All columns marked with this specifier get the same width; this happens after the affected column widths have been computed (this means that the largest width value rules).
f,F    Either of these specifiers may be followed by a font name (either one or two characters long), font number (a single digit), or long name in parentheses (the last form is a GNU tbl extension).  A one-letter font name must be separated by one or more blanks from whatever follows.
i,I    Short form of fI (make affected entries italic).
m,M    This is a GNU tbl extension.  Either of these specifiers may be followed by a macro name (either one or two characters long), or long name in parentheses.  A one-letter macro name must be separated by one or more blanks from whatever follows.  The macro which name can be specified here must be defined before creating the table.  It is called just before the table's cell text is output.  As implemented currently, this macro is only called if block input is used, that is, text between ‘T{’ and ‘T}’.  The macro should contain only simple troff requests to change the text block formatting, like text adjustment, hyphenation, size, or font.  The macro is called after other cell modifications like b, f or v are output.  Thus the macro can overwrite other modification specifiers.
p,P    Followed by a number, this does a point size change for the affected fields.  If signed, the current point size is incremented or decremented (using a signed number instead of a signed digit is a GNU tbl extension).  A point size specifier followed by a column separation number must be separated by one or more blanks.
t,T    Start an item vertically spanning rows at the top of its range rather than vertically centering it.
u,U    Move the corresponding column up one half-line.
v,V    Followed by a number, this indicates the vertical line spacing to be used in a multi-line table entry.  If signed, the current vertical line spacing is incremented or decremented (using a signed number instead of a signed digit is a GNU tbl extension). A vertical line spacing specifier followed by a column separation number must be separated by one or more blanks.  No effect if the corresponding table entry isn't a text block.
w,W    Minimum column width value.  Must be followed either by a troff(1) width expression in parentheses or a unitless integer.  If no unit is given, en units are used.  Also used as the default line length for included text blocks.  If used multiple times to specify the width for a particular column, the last entry takes effect.
x,X    An expanded column.  After computing all column widths without an x specifier, use the remaining line width for this column.  If there is more than one expanded column, distribute the remaining horizontal space evenly among the affected columns (this is a GNU extension).  This feature has the same effect as specifying a minimum column width.
z,Z    Ignore the corresponding column for width-calculation purposes, this is, don't use the fields but only the specifiers of this column to compute its width.
A number suffix on a key character is interpreted as a column separation in en units (multiplied in proportion if the expand option is on – in case of overfull tables this might be zero).  Default separation is 3n.
The column specifier x is mutually exclusive with e and w (but e is not mutually exclusive with w); if specified multiple times for a particular column, the last entry takes effect: x unsets both e and w, while either e or w overrides x.
Table data The format lines are followed by lines containing the actual data for the table, followed finally by .TE.  Within such data lines, items are normally separated by tab characters (or the character specified with the tab option).  Long input lines can be broken across multiple lines if the last character on the line is ‘\’ (which vanishes after concatenation).
Note that tbl computes the column widths line by line, applying \w on each entry which isn't a text block.  As a consequence, constructions like
.TS c,l. \s[20]MM MMMM .TE
fail; you must either say
.TS cp20,lp20. MM MMMM .TE
.TS c,l. \s[20]MM \s[20]MMMM .TE
A dot starting a line, followed by anything but a digit is handled as a troff command, passed through without changes.  The table position is unchanged in this case.
If a data line consists of only ‘_’ or ‘=’, a single or double line, respectively, is drawn across the table at that point; if a single item in a data line consists of only ‘_’ or ‘=’, then that item is replaced by a single or double line, joining its neighbours.  If a data item consists only of ‘\_’ or ‘\=’, a single or double line, respectively, is drawn across the field at that point which does not join its neighbours.
A data item consisting only of ‘\Rx’ (‘x’ any character) is replaced by repetitions of character ‘x’ as wide as the column (not joining its neighbours).
A data item consisting only of ‘\^’ indicates that the field immediately above spans downward over this row.
Text blocks A text block can be used to enter data as a single entry which would be too long as a simple string between tabs.  It is started with ‘T{’ and closed with ‘T}’.  The former must end a line, and the latter must start a line, probably followed by other data columns (separated with tabs or the character given with the tab global option).
By default, the text block is formatted with the settings which were active before entering the table, possibly overridden by the m, v, and w tbl specifiers.  For example, to make all text blocks ragged-right, insert .na right before the starting .TS (and .ad after the table).
If either ‘w’ or ‘x’ specifiers are not given for all columns of a text block span, the default length of the text block (to be more precise, the line length used to process the text block diversion) is computed as L×C/(N+1), where ‘L’ is the current line length, ‘C’ the number of columns spanned by the text block, and ‘N’ the total number of columns in the table.  Note, however, that the actual diversion width as returned in register \n[dl] is used eventually as the text block width.  If necessary, you can also control the text block width with a direct insertion of a .ll request right after ‘T{’.
Miscellaneous The number register \n[TW] holds the table width; it can't be used within the table itself but is defined right before calling .TE so that this macro can make use of it.
tbl also defines a macro .T# which produces the bottom and side lines of a boxed table.  While tbl does call this macro itself at the end of the table, it can be used by macro packages to create boxes for multi-page tables by calling it within the page footer.  An example of this is shown by the -ms macros which provide this functionality if a table starts with .TS H instead of the standard call to the .TS macro.
tbl(1) should always be called before eqn(1) (groff(1) automatically takes care of the correct order of preprocessors).
There is no limit on the number of columns in a table, nor any limit on the number of text blocks.  All the lines of a table are considered in deciding column widths, not just the first 200.  Table continuation (.T&) lines are not restricted to the first 200 lines.
Numeric and alphabetic items may appear in the same column.
Numeric and alphabetic items may span horizontally.
tbl uses register, string, macro and diversion names beginning with the digit 3.  When using tbl you should avoid using any names beginning with a 3.
Since tbl defines its own macros (right before each table) it is necessary to use an ‘end-of-macro’ macro.  Additionally, the escape character has to be switched off.  Here an example.
.eo .de ATABLE .. .TS allbox tab(;); cl. \$1;\$2 .TE ... .ec .ATABLE A table .ATABLE Another table .ATABLE And "another one"
Note, however, that not all features of tbl can be wrapped into a macro because tbl sees the input earlier than troff.  For example, number formatting with vertically aligned decimal points fails if those numbers are passed on as macro parameters because decimal point alignment is handled by tbl itself: It only sees ‘\$1’, ‘\$2’, etc., and therefore can't recognize the decimal point.
You should use .TS H/.TH in conjunction with a supporting macro package for all multi-page boxed tables.  If there is no header that you wish to appear at the top of each page of the table, place the .TH line immediately after the format section.  Do not enclose a multi-page table within keep/release macros, or divert it in any other way.
A text block within a table must be able to fit on one page.
The bp request cannot be used to force a page-break in a multi-page table.  Instead, define BP as follows
.de BP .  ie '\\n(.z'' .bp \\$1 .  el \!.BP \\$1 ..
and use BP instead of bp.
Using \a directly in a table to get leaders does not work (except in compatibility mode).  This is correct behaviour: \a is an uninterpreted leader.  To get leaders use a real leader, either by using a control A or like this:
.ds a \a .TS tab(;); lw(1i) l. A\*a;B .TE
A leading and/or trailing ‘|’ in a format line, such as
|l r|.
gives output which has a 1n space between the resulting bordering vertical rule and the content of the adjacent column, as in
.TS tab(#); |l r|. left column#right column .TE
If it is desired to have zero space (so that the rule touches the content), this can be achieved by introducing extra “dummy” columns, with no content and zero separation, before and/or after, as in
.TS tab(#); r0|l r0|l. #left column#right column# .TE
The resulting “dummy” columns are invisible and have zero width; note that such columns usually don't work with TTY devices.
Lesk, M.E.: "TBL – A Program to Format Tables".  For copyright reasons it cannot be included in the groff distribution, but copies can be found with a title search on the World Wide Web.
groff(1), troff(1)
LRZTAR.1(1)            User Contributed Perl Documentation           LRZTAR.1(1)
lrztar - Directory wrapper for lrzip
lrztar [options] DIRECTORY lrztar -d [options] DIRECTORY.tar.lrz lrzuntar [options] DIRECTORY.tar.lrz
lrztar is a wrapper for compressing and decompressing whole directories with lrzip(1) to corresponding file "DIRECTORY.tar.lrz". lrzuntar is identical to "lrztar -d".  lrztar takes the same options as lrzip.
See lrzip(1).
lrzip.conf(5), lrzuntar(1), lrzip(1), lrunzip(1), lrzcat(1), lrz(1), bzip2(1), gzip(1), lzop(1), rzip(1), zip(1)
Program was written by Con Kolivas.
This manual page was written by Jari Aalto <jari.aalto@cante.net> (but may be used by others). Released under license GNU GPL version 2 or (at your option) any later version. For more information about license, visit <http://www.gnu.org/copyleft/gpl.html>.
man(1)                           gcalcli Manual                           man(1)
gcalcli - interact with a Google Calendar
gcalcli [options] command [command args or options]
gcalcli is a Python application that allows you to access your Google Calendar(s) from a command line. It's easy to get your agenda, search for events, add new events, delete events, edit events, and even import those annoying ICS/vCal invites from Microsoft Exchange and/or other sources. Additionally, gcalcli can be used as a reminder service and execute any application you want when an event is coming up.
gcalcli [-h] [--auth_host_name AUTH_HOST_NAME] [--noauth_local_webserver] [--auth_host_port [AUTH_HOST_PORT [AUTH_HOST_PORT ...]]] [--logging_level {DEBUG,INFO,WARNING,ERROR,CRITICAL}] [--version] [--default-calendar DEFAULT_CALENDAR] [--calendar CALENDAR] [--refresh] [--client-id CLIENT_ID] [--conky] [--nocache] [--locale LOCALE] [--noincluderc] [--lineart {fancy,unicode,ascii}] [--config-folder CONFIG_FOLDER] [--nocolor] [--client-secret CLIENT_SECRET] {list,search,edit,delete,agenda,calw,calm,quick,add,import,remind} ...
Positional arguments: {list,search,edit,delete,agenda,calw,calm,quick,add,import,remind} Invoking a subcommand with --help prints subcommand usage. list                list available calendars edit                edit calendar events agenda              get an agenda for a time period calw                get a week-based agenda in calendar format calm                get a month agenda in calendar format quick               quick-add an event to a calendar add                 add a detailed event to the calendar import              import an ics/vcal file to a calendar remind              execute command if event occurs within <mins> time