neulab/tldr huggingface dataset:
A frequent problem when attempting to get client certificates working is that a web client complains it has no certificates or gives an empty list to choose from. This is normally because the server is not sending the clients certificate authority in its "acceptable CA list" when it requests a certificate. By using s_client the CA list can be viewed and checked. However, some servers only request client authentication after a specific URL is requested. To obtain the list in this case it is necessary to use the -prexit option and send an HTTP request for an appropriate page.
If a certificate is specified on the command line using the -cert option it will not be used unless the server specifically requests a client certificate. Therefore, merely including a client certificate on the command line is no guarantee that the certificate works.
If there are problems verifying a server certificate then the -showcerts option can be used to show all the certificates sent by the server.
The s_client utility is a test tool and is designed to continue the handshake after any certificate verification errors. As a result it will accept any certificate chain (trusted or not) sent by the peer. None test applications should not do this as it makes them vulnerable to a MITM attack. This behaviour can be changed by with the -verify_return_error option: any verify errors are then returned aborting the handshake.
The -bind option may be useful if the server or a firewall requires connections to come from some particular address and or port.
Because this program has a lot of options and also because some of the techniques used are rather old, the C source of s_client is rather hard to read and not a model of how things should be done.  A typical SSL client program would be much simpler.
The -prexit option is a bit of a hack. We should really report information whenever a session is renegotiated.
SSL_CONF_cmd(3), sess_id(1), s_server(1), ciphers(1), SSL_CTX_set_max_send_fragment(3), SSL_CTX_set_split_send_fragment(3), SSL_CTX_set_max_pipelines(3)
The -no_alt_chains option was added in OpenSSL 1.1.0.  The -name option was added in OpenSSL 1.1.1.
gh-pr-create - Create a pull request
gh pr create [flags]
Create a pull request on GitHub.
When the current branch isn't fully pushed to a git remote, a prompt will ask where to push the branch and offer an option to fork the base repository. Use --head to explicitly skip any forking or pushing behavior.
A prompt will also ask for the title and the body of the pull request. Use --title and --body to skip this, or use --fill to autofill these values from git commits.
Link an issue to the pull request by referencing the issue in the body of the pull request. If the body text mentions Fixes #123 or Closes #123, the referenced issue will automatically get closed when the pull request gets merged.
By default, users with write access to the base repository can push new commits to the head branch of the pull request. Disable this with --no- maintainer-edit.
-B, --base=""      The branch into which you want your code merged
-b, --body=""      Body for the pull request
-F, --body-file=""      Read body text from file
-d, --draft[=false]      Mark pull request as a draft
-f, --fill[=false]      Do not prompt for title/body and just use commit info
-H, --head=""      The branch that contains commits for your pull request (default: current branch)
-m, --milestone=""      Add the pull request to a milestone by name
--no-maintainer-edit[=false]      Disable maintainer's ability to modify pull request
-p, --project=[]      Add the pull request to projects by name
-r, --reviewer=[]      Request reviews from people or teams by their handle
-t, --title=""      Title for the pull request
-w, --web[=false]      Open the web browser to create a pull request
$ gh pr create --title "The bug is fixed" --body "Everything works again" $ gh pr create --reviewer monalisa,hubot  --reviewer myorg/team-name $ gh pr create --project "Roadmap" $ gh pr create --base develop --head monalisa:feature
DEBOOTSTRAP(8)               Debian GNU/Linux manual              DEBOOTSTRAP(8)
debootstrap - Bootstrap a basic Debian system
debootstrap [OPTION...]  SUITE TARGET [MIRROR [SCRIPT]]
debootstrap [OPTION...]  --second-stage
debootstrap bootstraps a basic Debian system of SUITE into TARGET from MIRROR by running SCRIPT.  MIRROR can be an http:// or https:// URL, a file:/// URL, or an ssh:/// URL.
The SUITE may be a release code name (eg, sid, stretch, jessie) or a symbolic name (eg, unstable, testing, stable, oldstable)
Notice that file:/ URLs are translated to file:/// (correct scheme as described in RFC1738 for local filenames), and file:// will not work. ssh://USER@HOST/PATH URLs are retrieved using scp; use of ssh-agent or similar is strongly recommended.
Debootstrap can be used to install Debian in a system without using an installation disk but can also be used to run a different Debian flavor in a chroot environment.  This way you can create a full (minimal) Debian installation which can be used for testing purposes (see the EXAMPLES section).  If you are looking for a chroot system to build packages please take a look at pbuilder.
--arch=ARCH Set the target architecture (use if dpkg isn't installed).  See also --foreign.
--include=alpha,beta Comma separated list of packages which will be added to download and extract lists.
--exclude=alpha,beta Comma separated list of packages which will be removed from download and extract lists.  WARNING: you can and probably will exclude essential packages, be careful using this option.
--extra-suites=alpha,beta Also use packages from the listed suites of the archive.
--components=alpha,beta Use packages from the listed components of the archive.
--no-resolve-deps By default, debootstrap will attempt to automatically resolve any missing dependencies, warning if any are found.  Note that this is not a complete dependency resolve in the sense of dpkg or apt, and that it is far better to specify the entire base system than rely on this option.  With this option set, this behaviour is disabled.
--log-extra-deps If you want to record additional dependencies when resolving package dependencies, set this option to track them through debootstrap.log.
--variant=minbase|buildd|fakechroot Name of the bootstrap script variant to use.  Currently, the variants supported are minbase, which only includes required packages and apt; buildd, which installs the build-essential packages and fakechroot, which installs the packages without root privileges.  The default, with no --variant=X argument, is to create a base Debian installation with all packages of priority required and important, including apt.
--merged-usr Create /{bin,sbin,lib}/ symlinks pointing to their counterparts in /usr/.  (Default for most variants.)
--no-merged-usr Do not create /{bin,sbin,lib}/ symlinks pointing to their counterparts in /usr/.  (Default for the buildd variant on suites older than bookworm.)
--keyring=KEYRING Override the default keyring for the distribution being bootstrapped, and use KEYRING to check signatures of retrieved Release files.
--no-check-gpg Disables checking gpg signatures of retrieved Release files.
--force-check-gpg Forces checking Release file signatures, disabling automatic fallback to HTTPS in case of a missing keyring. Incompatible with the previous option.
--verbose Produce more info about downloading.
--print-debs Print the packages to be installed, and exit.  Note that an empty or non-existing TARGET directory must be specified so that debootstrap can download Packages files to determine which packages should be installed, and to resolve dependencies. The TARGET directory will be deleted unless --keep-debootstrap-dir is specified.
--download-only Download packages, but don't perform installation.
--foreign Do the initial unpack phase of bootstrapping only, for example if the target architecture does not match the host architecture.  A copy of debootstrap sufficient for completing the bootstrap process will be installed as /debootstrap/debootstrap in the target filesystem.  You can run it with the --second-stage option to complete the bootstrapping process.
--second-stage Complete the bootstrapping process.  Other arguments are generally not needed.
--second-stage-target=DIR Run second stage in a subdirectory instead of root. (can be used to create a foreign chroot) (requires --second-stage)
--keep-debootstrap-dir Don't delete the /debootstrap directory in the target after completing the installation.
--cache-dir=DIR Cache .deb files under directory. It should be an absolute path.
--unpack-tarball=FILE Acquire .debs from gzipped tarball FILE (specified with absolute path) instead of downloading via HTTP(S).
--make-tarball=FILE Instead of bootstrapping, make a gzipped tarball (written to FILE) of the downloaded packages.  The resulting tarball may be passed to a later --unpack-tarball.  Note that an empty or non-existing TARGET directory must be specified so that debootstrap can download packages to prepare the tarball. The TARGET directory will be deleted unless --keep-debootstrap-dir is specified.
--debian-installer Used for internal purposes by the debian-installer
--extractor=TYPE Override automatic .deb extractor selection to TYPE.  Supported extractors are: dpkg-deb and ar.
--no-check-certificate Do not check certificate against certificate authorities
--certificate=FILE Use the client certificate stored in file (PEM)
--private-key=FILE Read the private key from file
--inrelease-path Determine the path to the InRelease file of the suite relative to the normal position of an InRelease file
To setup a stretch system:
debootstrap stretch ./stretch-chroot http://deb.debian.org/debian
debootstrap stretch ./stretch-chroot file:///LOCAL_MIRROR/debian
Full process to create a complete Debian installation of sid (unstable) in a chroot:
main # debootstrap sid sid-root http://deb.debian.org/debian/ [ ... watch it download the whole system ] main # echo "proc sid-root/proc proc defaults 0 0" >> /etc/fstab main # mount proc sid-root/proc -t proc main # echo "sysfs sid-root/sys sysfs defaults 0 0" >> /etc/fstab main # mount sysfs sid-root/sys -t sysfs main # cp /etc/hosts sid-root/etc/hosts main # chroot sid-root /bin/bash
debootstrap was written by Anthony Towns <ajt@debian.org>.  This manpage was written by Matt Kraai <kraai@debian.org>.
GLANCES(1)                           Glances                          GLANCES(1)
glances - An eye on your system
glances [OPTIONS]
glances is a cross-platform curses-based monitoring tool which aims to present a maximum of information in a minimum of space, ideally to fit in a classical 80x24 terminal or higher to have additional information. It can adapt dynamically the displayed information depending on the terminal size. It can also work in client/server mode.  Remote monitoring could be done via terminal or web interface.
glances is written in Python and uses the psutil library to get information from your system.
COMMAND-LINE OPTIONS -h, --help show this help message and exit
-V, --version show program’s version number and exit
-d, --debug enable debug mode
-C CONF_FILE, --config CONF_FILE path to the configuration file
--modules-list display modules (plugins & exports) list and exit
--disable-plugin PLUGIN disable PLUGIN (comma separated list)
--enable-plugin PLUGIN enable PLUGIN (comma separated list)
--stdout PLUGINS_STATS display stats to stdout (comma separated list of plugins/plugins.attribute)
--export EXPORT enable EXPORT module (comma separated list)
--export-csv-file EXPORT_CSV_FILE file path for CSV exporter
--export-json-file EXPORT_JSON_FILE file path for JSON exporter
--disable-process disable process module (reduce Glances CPU consumption)
--disable-webui disable the Web UI (only the RESTful API will respond)
--light, --enable-light light mode for Curses UI (disable all but top menu)
-0, --disable-irix task’s CPU usage will be divided by the total number of CPUs
-1, --percpu start Glances in per CPU mode
-2, --disable-left-sidebar disable network, disk I/O, FS and sensors modules
-3, --disable-quicklook disable quick look module
-4, --full-quicklook disable all but quick look and load
-5, --disable-top disable top menu (QuickLook, CPU, MEM, SWAP and LOAD)
-6, --meangpu start Glances in mean GPU mode
--enable-history enable the history mode
--disable-bold disable bold mode in the terminal
--disable-bg disable background colors in the terminal
--enable-process-extended enable extended stats on top process
-c CLIENT, --client CLIENT connect to a Glances server by IPv4/IPv6 address, hostname or hostname:port
-s, --server run Glances in server mode
--browser start the client browser (list of servers)
--disable-autodiscover disable autodiscover feature
-p PORT, --port PORT define the client/server TCP port [default: 61209]
-B BIND_ADDRESS, --bind BIND_ADDRESS bind server to the given IPv4/IPv6 address or hostname
--username define a client/server username
--password define a client/server password
--snmp-community SNMP_COMMUNITY SNMP community
--snmp-port SNMP_PORT SNMP port
--snmp-version SNMP_VERSION SNMP version (1, 2c or 3)
--snmp-user SNMP_USER SNMP username (only for SNMPv3)
--snmp-auth SNMP_AUTH SNMP authentication key (only for SNMPv3)
--snmp-force force SNMP mode
-t TIME, --time TIME set refresh time in seconds [default: 3 sec]
-w, --webserver run Glances in web server mode (bottle lib needed)
--cached-time CACHED_TIME set the server cache time [default: 1 sec]
open-web-browser try to open the Web UI in the default Web browser
-q, --quiet do not display the curses interface
-f PROCESS_FILTER, --process-filter PROCESS_FILTER set the process filter pattern (regular expression)
--process-short-name force short name for processes name
--hide-kernel-threads hide kernel threads in process list (not available on Windows)
-b, --byte display network rate in byte per second
--diskio-show-ramfs show RAM FS in the DiskIO plugin
--diskio-iops show I/O per second in the DiskIO plugin
--fahrenheit display temperature in Fahrenheit (default is Celsius)
--fs-free-space display FS free space instead of used
--theme-white optimize display colors for white background
--disable-check-update disable online Glances version ckeck
The following commands (key pressed) are supported while in Glances:
ENTER  Set the process filter
NOTE: On macOS please use CTRL-H to delete filter.
Filter is a regular expression pattern:
• gnome: matches all processes starting with the gnome string
• .*gnome.*: matches all processes containing the gnome string
a      Sort process list automatically
• If CPU >70%, sort processes by CPU usage
• If MEM >70%, sort processes by MEM usage
• If CPU iowait >60%, sort processes by I/O read and write
A      Enable/disable Application Monitoring Process
b      Switch between bit/s or Byte/s for network I/O
B      View disk I/O counters per second
c      Sort processes by CPU usage
C      Enable/disable cloud stats
d      Show/hide disk I/O stats
D      Enable/disable Docker stats
e      Enable/disable top extended stats
E      Erase current process filter
f      Show/hide file system and folder monitoring stats
F      Switch between file system used and free space
g      Generate graphs for current history
G      Enable/disable GPU stats
h      Show/hide the help screen
i      Sort processes by I/O rate
I      Show/hide IP module
k      Kill selected process
K      Show/hide TCP connections
l      Show/hide log messages
m      Sort processes by MEM usage
M      Reset processes summary min/max
n      Show/hide network stats
N      Show/hide current time
p      Sort processes by name
P      Enable/Disable ports stats
q|ESC|CTRL-C Quit the current Glances session
Q      Show/hide IRQ module
r      Reset history
R      Show/hide RAID plugin
s      Show/hide sensors stats
S      Enable/disable spark lines
t      Sort process by CPU times (TIME+)
T      View network I/O as combination
u      Sort processes by USER
U      View cumulative network I/O
w      Delete finished warning log messages
W      Show/hide Wifi module
x      Delete finished warning and critical log messages
z      Show/hide processes stats
0      Enable/disable Irix/Solaris mode
Task’s CPU usage will be divided by the total number of CPUs
1      Switch between global CPU and per-CPU stats
2      Enable/disable left sidebar
3      Enable/disable the quick look module
4      Enable/disable all but quick look and load module
5      Enable/disable top menu (QuickLook, CPU, MEM, SWAP and LOAD)
6      Enable/disable mean GPU mode
9      Switch UI theme between black and white
/      Switch between process command line or command name
F5     Refresh stats in curses user interface
LEFT   Navigation leff through process sort
RIGHT  Navigation right through process sort
UP     Up in the processes list
DOWN   Down in the processes list
In the Glances client browser (accessible through the --browser command line argument):
ENTER  Run the selected server
UP     Up in the servers list
DOWN   Down in the servers list
q|ESC  Quit Glances
No configuration file is mandatory to use Glances.
Furthermore a configuration file is needed to access more settings.
NOTE: A template is available in the /usr{,/local}/share/doc/glances (Unix-like) directory or directly on GitHub.
You can put your own glances.conf file in the following locations:
┌─────────────┬───────────────────────────────┐ │Linux, SunOS │ ~/.config/glances/,           │ │             │ /etc/glances/,                │ │             │ /usr/share/docs/glances/      │ ├─────────────┼───────────────────────────────┤ │*BSD         │ ~/.config/glances/,           │ │             │ /usr/local/etc/glances/,      │ │             │ /usr/share/docs/glances/      │ ├─────────────┼───────────────────────────────┤ │macOS        │ ~/Library/Application         │ │             │ Support/glances/,             │ │             │ /usr/local/etc/glances/,      │ │             │ /usr/share/docs/glances/      │ ├─────────────┼───────────────────────────────┤ │Windows      │ %APPDATA%\glancesglances.conf │ └─────────────┴───────────────────────────────┘
• On Windows XP, %APPDATA% is: C:\Documents and Settings\<USERNAME>\Application Data.
• On Windows Vista and later: C:\Users\<USERNAME>\AppData\Roaming.
User-specific options override system-wide options and options given on the command line override either.
Glances reads configuration files in the ini syntax.
A first section (called global) is available:
[global] # Refresh rate (default is a minimum of 2 seconds) # Can be overwrite by the -t <sec> option # It is also possible to overwrite it in each plugin sections refresh=2 # Does Glances should check if a newer version is available on PyPI ? check_update=false # History size (maximum number of values) # Default is 28800: 1 day with 1 point every 3 seconds history_size=28800
Each plugin, export module and application monitoring process (AMP) can have a section. Below an example for the CPU plugin:
[cpu] disable=False refresh=3 user_careful=50 user_warning=70 user_critical=90 iowait_careful=50 iowait_warning=70 iowait_critical=90 system_careful=50 system_warning=70 system_critical=90 steal_careful=50 steal_warning=70 steal_critical=90
an InfluxDB export module:
[influxdb] # Configuration for the --export influxdb option # https://influxdb.com/ host=localhost port=8086 user=root password=root db=glances prefix=localhost #tags=foo:bar,spam:eggs
or a Nginx AMP:
[amp_nginx] # Nginx status page should be enable (https://easyengine.io/tutorials/nginx/status-page/) enable=true regex=\/usr\/sbin\/nginx refresh=60 one_line=false status_url=http://localhost/nginx_status
With Glances 3.0 or higher it is also possible to use dynamic configuration value using system command. For example, if you to set the prefix of an InfluxDB export to the current hostname, use:
[influxdb] ... prefix=`hostname`
Or if you want to add the Operating System name as a tag:
[influxdb] ... tags=system:`uname -a`
Glances logs all of its internal messages to a log file.
DEBUG messages can been logged using the -d option on the command line.
The location of the Glances depends of your operating system. You could displayed the Glances log file full path using the``glances -V`` command line.
The file is automatically rotate when the size is higher than 1 MB.
If you want to use another system path or change the log message, you can use your own logger configuration. First of all, you have to create a glances.json file with, for example, the following content (JSON format):
{ "version": 1, "disable_existing_loggers": "False", "root": { "level": "INFO", "handlers": ["file", "console"] }, "formatters": { "standard": { "format": "%(asctime)s -- %(levelname)s -- %(message)s" }, "short": { "format": "%(levelname)s: %(message)s" }, "free": { "format": "%(message)s" } }, "handlers": { "file": { "level": "DEBUG", "class": "logging.handlers.RotatingFileHandler", "formatter": "standard", "filename": "/var/tmp/glances.log" }, "console": { "level": "CRITICAL", "class": "logging.StreamHandler", "formatter": "free" } }, "loggers": { "debug": { "handlers": ["file", "console"], "level": "DEBUG" }, "verbose": { "handlers": ["file", "console"], "level": "INFO" }, "standard": { "handlers": ["file"], "level": "INFO" }, "requests": { "handlers": ["file", "console"], "level": "ERROR" }, "elasticsearch": { "handlers": ["file", "console"], "level": "ERROR" }, "elasticsearch.trace": { "handlers": ["file", "console"], "level": "ERROR" } } }
and start Glances using the following command line:
LOG_CFG=<path>/glances.json glances
NOTE: Replace <path> by the folder where your glances.json file is hosted.
Monitor local machine (standalone mode): $ glances
Monitor local machine with the web interface (Web UI), run the following command line: $ glances -w
and open a Web browser with the returned URL
Monitor local machine and export stats to a CSV file: $ glances –export csv –export-csv-file /tmp/glances.csv
Monitor local machine and export stats to a InfluxDB server with 5s refresh time (also possible to export to OpenTSDB, Cassandra, Statsd, ElasticSearch, RabbitMQ and Riemann): $ glances -t 5 –export influxdb
It is also possible to export stats to multiple endpoints: $ glances -t 5 –export influxdb,statsd,csv
Start a Glances server (server mode): $ glances -s
Connect Glances to a Glances server (client mode): $ glances -c <ip_server>
Connect to a Glances server and export stats to a StatsD server: $ glances -c <ip_server> –export statsd
Start the client browser (browser mode): $ glances –browser
Nicolas Hennion aka Nicolargo <contact@nicolargo.com>
2021, Nicolas Hennion
PO4A(1p)                           Po4a Tools                           PO4A(1p)
po4a - update both the PO files and translated documents in one shot
po4a [options] config_file
po4a (PO for anything) eases the maintenance of documentation translation using the classical gettext tools. The main feature of po4a is that it decouples the translation of content from its document structure.  Please refer to the page po4a(7) for a gentle introduction to this project.
When you run the po4a program for the first time, with only a configuration file and the documents to translate (called master documents), it produces a POT file (also called translation template) that contains all of the translatable strings in the document in a form that eases the work of translators.
Those POT files can either be translated with a specific editor such as the GNOME Translation Editor, KDE's Lokalize or poedit, or they can be integrated in an online localization platform such as weblate or pootle. The translation result is a set of PO files, one per language.
When you run the po4a program with both the master documents and the PO files, it produces the translated documents by injecting the content's translation (found in the PO files) into the structure of the original master document.
If the master documents changed in the meanwhile, po4a will update the PO and POT files accordingly, so that the translators can easily detect the modifications and update their work. Depending on your settings, po4a will discard the partially translated documents, or produce a document mixing English (for the new or modified paragraphs) and the target language (for paragraphs where translation is already in the PO file).
By default, the translated documents are produced when at least 80% of their content is translated (see the --keep option below).  Discarding translations as soon as they are not 100% may be discouraging for the translators, while showing "translations" that are too incomplete may be troubling for the end users.
Graphical overview master documents ---+---->-------->---------+ (doc authoring)    |                       | V   (po4a executions)   >-----+--> translations |                       |     | existing PO files -->--> updated PO files >-+     | ^                            |               | |                            V               | +----------<---------<-------+               ^ (manual translation process)                | | addendum -->--------------------------------------+
The master documents are authored by the documentation writers. Any changes are automatically reflected by po4a in the PO files, that are then updated by the translators. All changes to the PO files (either manual or by po4a) are automatically reflected in translated documents. You can mimic this behavior using the po4a-updatepo(1) and po4a-translate(1) scripts in makefiles, but this quickly becomes bothersome and repetitive (see po4a(7)). It is highly recommended to use the po4a program in your build process.
-k, --keep Minimal threshold for translation percentage to keep (i.e. write) the resulting file (default: 80). I.e. by default, files have to be translated at least at 80% to be written on disk.
-M, --master-charset Charset of the files containing the documents to translate. Note that all master documents must use the same charset.
-L, --localized-charset Charset of the files containing the localized documents. Note that all translated documents will use the same charset.
-A, --addendum-charset Charset of the addenda. Note that all the addenda should be in the same charset.
-q, --quiet Decrease the verbosity of the program.
-o, --option Extra option(s) to pass to the format plugin. See the documentation of each plugin for more information about the valid options and their meanings. For example, you could pass '-o tablecells' to the AsciiDoc parser, while the text parser would accept '-o tabs=split'.
-f, --force Always generate the POT and PO files, even if po4a considers it is not necessary.
The default behavior (when --force is not specified) is the following:
If the POT file already exists, it is regenerated if a master document or the configuration file is more recent (unless --no-update is provided).  The POT file is also written in a temporary document and po4a verifies that the changes are really needed.
Also, a translation is regenerated only if its master document, the PO file, one of its addenda or the configuration file is more recent.  To avoid trying to regenerate translations which do not pass the threshold test (see --keep), a file with the .po4a-stamp extension can be created (see --stamp).
If a master document includes files, you should use the --force flag because the modification time of these included files are not taken into account.
The PO files are always re-generated based on the POT with msgmerge -U.
--stamp Tells po4a to create stamp files when a translation is not generated because it does not reach the threshold. These stamp files are named according to the expected translated document, with the .po4a-stamp extension.
Note: This only activates the creation of the .po4a-stamp files. The stamp files are always used if they exist, and they are removed with --rm-translations or when the file is finally translated.
--no-translations Do not generate the translated documents, only update the POT and PO files.
--no-update Do not change the POT and PO files, only the translation may be updated.
--keep-translations Keeps the existing translation files even if the translation doesn't meet the threshold specified by --keep.  This option does not create new translation files with few content, but it will save existing translations which decay because of changes to the master files.
WARNING: This flag changes the po4a behavior in a rather drastic way: your translated files will not get updated at all until the translation improves. Only use this flag if you prefer shipping an outdated translated documentation rather than only shipping an accurate untranslated documentation.
--rm-translations Remove the translated files (implies --no-translations).
--no-backups This flag does nothing since 0.41, and may be removed in later releases.
--rm-backups This flag does nothing since 0.41, and may be removed in later releases.
--translate-only translated-file Translate only the specified file.  It may be useful to speed up processing if a configuration file contains a lot of files.  Note that this option does not update PO and POT files.  This option can be used multiple times.
--variable var=value Define a variable that will be expanded in the po4a configuration file.  Every occurrence of $(var) will be replaced by value.  This option can be used multiple times.
--srcdir SRCDIR Set the base directory for all input documents specified in the po4a configuration file.
If both destdir and srcdir are specified, input files are searched in the following directories, in order: destdir, the current directory and srcdir. Output files are written to destdir if specified, or to the current directory.
--destdir DESTDIR Set the base directory for all the output documents specified in the po4a configuration file (see --srcdir above).
Options modifying the POT header --porefs type Specify the reference format. Argument type can be one of never to not produce any reference, file to only specify the file without the line number, counter to replace line number by an increasing counter, and full to include complete references (default: full).
--wrap-po no|newlines|number (default: 76) Specify how the po file should be wrapped. This gives the choice between either files that are nicely wrapped but could lead to git conflicts, or files that are easier to handle automatically, but harder to read for humans.
Historically, the gettext suite has reformatted the po files at the 77th column for cosmetics. This option specifies the behavior of po4a. If set to a numerical value, po4a will wrap the po file after this column and after newlines in the content. If set to newlines, po4a will only split the msgid and msgstr after newlines in the content. If set to no, po4a will not wrap the po file at all.  The reference comments are always wrapped by the gettext tools that we use internally.
Note that this option has no impact on how the msgid and msgstr are wrapped, ie on how newlines are added to the content of these strings.
--master-language Language of the source files containing the documents to translate. Note that all master documents must use the same language.
Options to modify the PO files --msgmerge-opt options Extra options for msgmerge(1).
Note: $lang will be extended to the current language.
--no-previous This option removes --previous from the options passed to msgmerge. This permits to support versions of gettext earlier than 0.16.
--previous This option adds --previous to the options passed to msgmerge.  It requires gettext 0.16 or later, and is activated by default.
po4a expects a configuration file as argument. This file must contain the following elements:
•   The path to the PO files and the list of languages existing in the project;
•   Optionally, some global options and so-called configuration aliases that are used as templates to configure individual master files;
•   The list of each master file to translate, along with specific parameters.
All lines contain a command between square braces, followed by its parameters.  Comments begin with the char '#' and run until the end of the line. You can escape the end of line to spread a command over several lines.
Some full examples are presented on this page, while other examples can be found in the "t/cfg" directory of the source distribution.
Finding the PO and POT files The simplest solution is to explicitly give the path to POT and PO files, as follows:
[po4a_paths] man/po/project.pot de:man/po/de.po fr:man/po/fr.po
This specifies the path to the POT file first, and then the paths to the German and French PO files.
The same information can be written as follows to reduce the risk of copy/paste errors:
[po4a_langs] fr de [po4a_paths] man/po/project.pot $lang:man/po/$lang.po
The $lang component is automatically expanded using the provided languages list, reducing the risk of copy/paste error when a new language is added.
You can further compact the same information by only providing the path to the directory containing your translation project, as follows.
[po_directory] man/po/
The provided directory must contain a set of PO files, each named XX.po with "XX" the ISO 639-1 of the language used in this file. The directory must also contain a single POT file, with the ".pot" file extension. For the first run, this file can be empty but it must exist (po4a cannot guess the name to use before the extension).
Note that you must choose only one between "po_directory" and "po4a_paths". The first one ("po_directory") is more compact, further reduces the risk of copy/paste error, but forces you to use the expected project structure and file names. The second one ("po4a_paths"), is more explicit, probably more readable, and advised when you setup your first project with po4a.
Centralized or split PO files?
By default, po4a produces one single PO file per target language, containing the whole content of your translation project. As your project grows, the size of these files may become problematic. When using weblate, it is possible to specify priorities for each translation segment (i.e., msgid) so that the important ones get translated first. Still, some translation teams prefer to split the content in several files.
To have one PO file per master file, you simply have to use the string $master in the name of your PO files on the "[po4a_paths]" line, as follows.
[po4a_paths] doc/$master/$master.pot $lang:doc/$master/$lang.po
If there are name conflicts because several files have the same filename, the name of the master file can be specified by adding a "master:file="name option:
[po4a_langs] de fr ja [po4a_paths] l10n/po/$master.pot $lang:l10n/po/$master.$lang.po [type: xml] foo/gui.xml $lang:foo/gui.$lang.xml master:file=foo-gui [type: xml] bar/gui.xml $lang:bar/gui.$lang.xml master:file=bar-gui
In split mode, po4a builds a temporary compendium during the PO update, to share the translations between all the PO files. If two PO files have different translations for the same string, po4a will mark this string as fuzzy and will submit both translations in all the PO files containing this string. When unfuzzied by the translator, the translation is automatically used in every PO files.
Specifying the documents to translate You must also list the documents that should be translated. For each master file, you must specify the format parser to use, the location of the translated document to produce, and optionally some configuration. Here is an example:
[type: sgml] doc/my_stuff.sgml fr:doc/fr/mon_truc.sgml \ de:doc/de/mein_kram.sgml [type: man] script fr:doc/fr/script.1 de:doc/de/script.1 [type: docbook] doc/script.xml fr:doc/fr/script.xml \ de:doc/de/script.xml
But again, these complex lines are difficult to read and modify, e.g. when adding a new language. It is much simpler to reorganize things using the $lang template as follows:
[type: sgml]    doc/my_stuff.sgml $lang:doc/$lang/my_stuff.sgml [type: man]     script.1          $lang:po/$lang/script.1 [type: docbook] doc/script.xml    $lang:doc/$lang/script.xml
Specifying options There is two types of options: po4a options are default values to the po4a command line options while format options are used to change the behavior of the format parsers. As a po4a options, you could for example specify in your configuration file that the default value of the --keep command line parameter is 50% instead of 80%. Format options are documented on the specific page of each parsing module, e.g. Locale::Po4a::Xml(3pm). You could for example pass nostrip to the XML parser to not strip the spaces around the extracted strings.
You can pass these options for a specific master file, or even for a specific translation of that file, using "opt:" and "opt_XX:" for the "XX" language.  In the following example, the nostrip option is passed to the XML parser (for all languages), while the threshold will be reduced to 0% for the French translation (that is thus always kept).
[type:xml] toto.xml $lang:toto.$lang.xml opt:"-o nostrip" opt_fr:"--keep 0"
In any case, these configuration chunks must be located at the end of the line.  The declaration of files must come first, then the addendum if any (see below), and then only the options. The grouping of configuration chunks is not very important, since elements are internally concatenated as strings. The following examples are all equivalent:
[type:xml] toto.xml $lang:toto.$lang.xml opt:"--keep 20" opt:"-o nostrip" opt_fr:"--keep 0" [type:xml] toto.xml $lang:toto.$lang.xml opt:"--keep 20 -o nostrip" opt_fr:"--keep 0" [type:xml] toto.xml $lang:toto.$lang.xml opt:--keep opt:20 opt:-o opt:nostrip opt_fr:--keep opt_fr:0
Note that language specific options are not used when building the POT file. It is for example impossible to pass nostrip to the parser only when building the French translation, because the same POT file is used to update every languages. So the only options that can be language- specific are the ones that are used when producing the translation, as the "--keep" option.
Configuration aliases
To pass the same options to several files, the best is to define a type alias as follows. In the next example, "--keep 0" is passed to every Italian translation using this "test" type, that is an extension of the "man" type.
[po4a_alias:test] man opt_it:"--keep 0" [type: test] man/page.1 $lang:man/$lang/page.1
You can also extend an existing type reusing the same name for the alias as follows. This is not interpreted as as an erroneous recursive definition.
[po4a_alias:man] man opt_it:"--keep 0" [type: man] man/page.1 $lang:man/$lang/page.1
Global default options
You can also use "[options]" lines to define options that must be used for all files, regardless of their type.
[options] --keep 20 --option nostrip
As with the command line options, you can abbreviate the parameters passed in the configuration file:
[options] -k 20 -o nostrip
Option priorities
The options of every sources are concatenated, ensuring that the default values can easily be overridden by more specific options. The order is as follows:
•   "[options]" lines provide default values that can be overridden by any other source.
•   Type aliases are then used. Language specific settings override the ones applicable to all languages.
•   Settings that are specific to a given master file override both the default ones and the ones coming from the type alias. In this case also, language specific settings override the global ones.
•   Finally, parameters provided on the po4a command line override any settings from the configuration file.
Here is an example showing how to quote the spaces and quotes:
[options] --master-charset UTF-8
[po4a_alias:man] man opt:"-o \"mdoc=NAME,SEE ALSO\"" [type:man] t-05-config/test02_man.1 $lang:tmp/test02_man.$lang.1 \ opt:"-k 75" opt_it:"-L UTF-8" opt_fr:--verbose
Addendum: Adding extra content in the translation If you want to add an extra section to the translation, for example to give credit to the translator, then you need to define an addendum to the line defining your master file. Please refer to the page po4a(7) for more details on the syntax of addendum files.
[type: pod] script fr:doc/fr/script.1 \ add_fr:doc/l10n/script.fr.add
You can also use language templates as follow:
[type: pod] script $lang:doc/$lang/script.1 \ add_$lang:doc/l10n/script.$lang.add
If an addendum fails to apply, the translation is discarded.
Modifiers for the addendum declaration
Addendum modifiers can simplify the configuration file in the case where not all languages provide an addendum, or when the list of addenda changes from one language to the other. The modifier is a single char located before the file name.
? Include addendum_path if this file does exist, otherwise do nothing.
@ addendum_path is not a regular addendum but a file containing a list of addenda, one by line.  Each addendum may be preceded by modifiers.
! addendum_path is discarded, it is not loaded and will not be loaded by any further addendum specification.
The following includes an addendum in any language, but if only it exists. No error is reported if the addendum does not exist.
[type: pod] script $lang:doc/$lang/script.1  add_$lang:?doc/l10n/script.$lang.add
The following includes a list of addendum for every language:
[type: pod] script $lang:doc/$lang/script.1  add_$lang:@doc/l10n/script.$lang.add
Filtering the translated strings Sometimes, you want to hide some strings from the translation process. To that extend, you can give a "pot_in" parameter to your master file to specify the name of the file to use instead of the real master when building the POT file. Here is an example:
[type:docbook] book.xml          \ pot_in:book-filtered.xml \ $lang:book.$lang.xml
With this setting, the strings to translate will be extracted from the book-filtered.xml (that must be produced before calling po4a) while the translated files will be built from book.xml. As a result, any string that is part of book.xml but not in book-filtered.xml will not be included in the PO files, preventing the translators from providing a translation for them. So these strings will be left unmodified when producing the translated documents.  This naturally decreases the level of translation, so you may need the "--keep" option to ensure that the document is produced anyway.
CONFIGURATION EXAMPLE TODO: Is this section really useful?
Let's assume you maintain a program named foo which has a man page man/foo.1 which naturally is maintained in English only. Now you as the upstream or downstream maintainer want to create and maintain the translation.  First you need to create the POT file necessary to send to translators using po4a-gettextize(1).
So for our case we would call
cd man && po4a-gettextize -f man -m foo.1 -p foo.pot
You would then send this file to the appropriate language lists or offer it for download somewhere on your website.
Now let's assume you received three translations before your next release: de.po (including an addendum de.add), sv.po and pt.po.  Since you don't want to change your Makefile(s) whenever a new translation arrives you can use po4a with an appropriate configuration file in your Makefile.  Let's call it po4a.cfg. In our example it would look like the following:
[po_directory] man/po4a/po/
[type: man] man/foo.1 $lang:man/translated/$lang/foo.1 \ add_$lang:?man/po4a/add_$lang/$lang.add opt:"-k 80"
In this example we assume that your generated man pages (and all PO and addenda files) should be stored in man/translated/$lang/ (respectively in man/po4a/po/ and man/po4a/add_$lang/) below the current directory. In our example the man/po4a/po/ directory would include de.po, pt.po and sv.po, and the man/po4a/add_de/ directory would include de.add.
Note the use of the modifier ? as only the German translation (de.po) is accompanied by an addendum.
To actually build the translated man pages you would then (once!) add the following line in the build target of the appropriate Makefile:
po4a po4a.cfg
Once this is set up you don't need to touch the Makefile when a new translation arrives, i.e. if the French team sends you fr.po and fr.add then you simply drop them respectively in man/po4a/po/ and man/po4a/add_fr/ and the next time the program is built the French translation is automatically build as well in man/translated/fr/.
Note that you still need an appropriate target to install localized manual pages with English ones.
Finally if you do not store generated files into your version control system, you will need a line in your clean target as well: -rm -rf man/translated
po4a-gettextize(1), po4a-normalize(1), po4a-translate(1), po4a-updatepo(1), po4a(7).
Denis Barbier <barbier@linuxfr.org> Nicolas François <nicolas.francois@centraliens.net> Martin Quinson (mquinson#debian.org)
Copyright 2002-2020 by SPI, inc.
PPROF(1)                             Google                             PPROF(1)
pprof - manual page for pprof (part of gperftools)
pprof [options] <program> <profile>
Prints specified cpu- or heap-profile
--cum  Sort by cumulative data
--base=<base> Subtract <base> from <profile> before display
Reporting Granularity: --addresses Report at address level
--lines Report at source line level
--functions Report at function level [default]
--files Report at source file level
Output type: --text Generate text report [default]
--gv   Generate Postscript and display
--list=<regexp> Generate source listing of matching routines
--disasm=<regexp> Generate disassembly of matching routines
--dot  Generate DOT file to stdout
--ps   Generate Postscript to stdout
--pdf  Generate PDF to stdout
--gif  Generate GIF to stdout
Heap-Profile Options: --inuse_space Display in-use (mega)bytes [default]
--inuse_objects Display in-use objects
--alloc_space Display allocated (mega)bytes
--alloc_objects Display allocated objects
--show_bytes Display space in bytes
--drop_negative Ignore negaive differences
Call-graph Options: --nodecount=<n> Show at most so many nodes [default=80]
--nodefraction=<f> Hide nodes below <f>*total [default=.005]
--edgefraction=<f> Hide edges below <f>*total [default=.001]
--focus=<regexp> Focus on nodes matching <regexp>
--ignore=<regexp> Ignore nodes matching <regexp>
--scale=<n> Set GV scaling [default=0]
pprof /bin/ls ls.prof
Outputs one line per procedure
pprof --gv /bin/ls ls.prof
Displays annotated call-graph via 'gv'
pprof --gv --focus=Mutex /bin/ls ls.prof
Restricts to code paths including a .*Mutex.* entry
pprof --gv --focus=Mutex --ignore=string /bin/ls ls.prof
Code paths including Mutex but not string
pprof --list=getdir /bin/ls ls.prof
Dissassembly (with per-line annotations) for getdir()
pprof --disasm=getdir /bin/ls ls.prof
Dissassembly (with per-PC annotations) for getdir()
Copyright Â© 2005 Google Inc.
Further documentation for pprof is maintained as a web page called cpu_profiler.html and is likely installed at one of the following locations:
/usr/share/gperftools/cpu_profiler.html /usr/local/share/gperftools/cpu_profiler.html
cewl(1)                    custom word list generator                    cewl(1)
cewl - custom word list generator
cewl [OPTION] ... URL
CeWL (Custom Word List generator) is a ruby app which spiders a given URL, up to a specified depth, and returns a list of words which can then be used for password crackers such as John the Ripper. Optionally, CeWL can follow external links.
CeWL can also create a list of email addresses found in mailto links. These email addresses can be used as usernames in brute force actions.
CeWL is pronounced "cool".
-h, --help Show help.
-k, --keep Keep the downloaded file.
-d <x>,--depth <x> Depth to spider to, default 2.  -m, --min_word_length Minimum word length, default 3.
-o, --offsite Let the spider visit other sites.
-w, --write Write the output to the file.
-u, --ua <agent> User agent to send.
-n, --no-words Don't output the wordlist.
--with-numbers Accept words with numbers in as well as just letters.
-a, --meta Include meta data.
--meta_file file Output file for meta data.
-e, --email Include email addresses.
--email_file <file> Output file for email addresses.  --meta-temp-dir <dir> The temporary directory used by exiftool when parsing files, default /tmp.
-c, --count Show the count for each word found.
-v, --verbose Verbose.
--debug Extra debug information.
--auth_type Digest or basic.
--auth_user Authentication username.
--auth_pass Authentication password.
--proxy_host Proxy host.
--proxy_port Proxy port, default 8080.
--proxy_username Username for proxy, if required.
--proxy_password Password for proxy, if required.
--header, -H In format name:value - can pass multiple.
<url>  The site to spider.
Someone has reported that the spider misses some pages which are have querystrings on them. This issue isn't confirmed.
fab-cewl(1)
The CeWL was written by Robin Wood <robin@digi.ninja>.