neulab/tldr huggingface dataset:
Optional arguments: -h, --help            show this help message and exit --auth_host_name AUTH_HOST_NAME Hostname when running a local web server. (default: localhost) --noauth_local_webserver Do not run a local web server. (default: False) --auth_host_port [AUTH_HOST_PORT [AUTH_HOST_PORT ...]] Port web server should listen on. (default: [8080, 8090]) --logging_level {DEBUG,INFO,WARNING,ERROR,CRITICAL} Set the logging level of detail. (default: ERROR) --version             show program's version number and exit --default-calendar DEFAULT_CALENDAR Optional default calendar to use if no --calendar options are given (default: []) --calendar CALENDAR   Which calendars to use (default: []) --refresh             Delete and refresh cached data (default: False) --client-id CLIENT_ID API client_id (default: 232867676714.apps.googleusercontent.com) --conky               Use Conky color codes (default: False) --nocache             Execute command without using cache (default: True) --locale LOCALE       System locale (default: ) --noincluderc         Whether to include ~/.gcalclirc when using configFolder (default: True) --lineart {fancy,unicode,ascii} Choose line art style for calendars: "fancy": for VTcodes, "unicode" for Unicode box drawing characters, "ascii" for old-school plusses, hyphens and pipes. (default: fancy) --config-folder CONFIG_FOLDER Optional directory to load/store all configuration information (default: None) --nocolor             Enable/Disable all color output (default: True) --client-secret CLIENT_SECRET API client_secret (default: 3tZSxItw6_VnZMezQwC8lUqy)
Encoding issues, wrongly printed characters, UnicodeEncodeError when using conky, in pipes or scripts" - Set an environment variable PYTHONIOENCODING=utf8 - Use a Unicode capable font like DejaVu Sans Mono - Set option --lineart=unicode or --lineart=ascii - Upgrade to Python3 No colors or garbage characters when using inside conky - Set option --conky
bash(1)
Report issues at https://github.com/insanum/gcalcli/issues
Eric Davis (edavis@insanum.com)
Brian Hartvigsen (brian.andrew@brianandjenny.com)
Joshua Crowgey (jcrowgey@uw.edu)
--single Only use a single connection instead of multiple. This simulates a typical file transfer.
MAKE(1)                           User Commands                          MAKE(1)
make - GNU make utility to maintain groups of programs
make [OPTION]... [TARGET]...
The make utility will determine automatically which pieces of a large program need to be recompiled, and issue the commands to recompile them. The manual describes the GNU implementation of make, which was written by Richard Stallman and Roland McGrath, and is currently maintained by Paul Smith.  Our examples show C programs, since they are very common, but you can use make with any programming language whose compiler can be run with a shell command.  In fact, make is not limited to programs.  You can use it to describe any task where some files must be updated automatically from others whenever the others change.
To prepare to use make, you must write a file called the makefile that describes the relationships among files in your program, and the states the commands for updating each file.  In a program, typically the executable file is updated from object files, which are in turn made by compiling source files.
Once a suitable makefile exists, each time you change some source files, this simple shell command:
suffices to perform all necessary recompilations.  The make program uses the makefile description and the last-modification times of the files to decide which of the files need to be updated.  For each of those files, it issues the commands recorded in the makefile.
make executes commands in the makefile to update one or more target names, where name is typically a program.  If no -f option is present, make will look for the makefiles GNUmakefile, makefile, and Makefile, in that order.
Normally you should call your makefile either makefile or Makefile.  (We recommend Makefile because it appears prominently near the beginning of a directory listing, right near other important files such as README.)  The first name checked, GNUmakefile, is not recommended for most makefiles. You should use this name if you have a makefile that is specific to GNU make, and will not be understood by other versions of make.  If makefile is '-', the standard input is read.
make updates a target if it depends on prerequisite files that have been modified since the target was last modified, or if the target does not exist.
-b, -m These options are ignored for compatibility with other versions of make.
-B, --always-make Unconditionally make all targets.
-C dir, --directory=dir Change to directory dir before reading the makefiles or doing anything else.  If multiple -C options are specified, each is interpreted relative to the previous one: -C / -C etc is equivalent to -C /etc.  This is typically used with recursive invocations of make.
-d   Print debugging information in addition to normal processing.  The debugging information says which files are being considered for remaking, which file-times are being compared and with what results, which files actually need to be remade, which implicit rules are considered and which are applied---everything interesting about how make decides what to do.
--debug[=FLAGS] Print debugging information in addition to normal processing.  If the FLAGS are omitted, then the behavior is the same as if -d was specified.  FLAGS may be a for all debugging output (same as using -d), b for basic debugging, v for more verbose basic debugging, i for showing implicit rules, j for details on invocation of commands, and m for debugging while remaking makefiles.  Use n to disable all previous debugging flags.
-e, --environment-overrides Give variables taken from the environment precedence over variables from makefiles.
-E string, --eval string Interpret string using the eval function, before parsing any makefiles.
-f file, --file=file, --makefile=FILE Use file as a makefile.
-i, --ignore-errors Ignore all errors in commands executed to remake files.
-I dir, --include-dir=dir Specifies a directory dir to search for included makefiles.  If several -I options are used to specify several directories, the directories are searched in the order specified.  Unlike the arguments to other flags of make, directories given with -I flags may come directly after the flag: -Idir is allowed, as well as -I dir.  This syntax is allowed for compatibility with the C preprocessor's -I flag.
-j [jobs], --jobs[=jobs] Specifies the number of jobs (commands) to run simultaneously.  If there is more than one -j option, the last one is effective.  If the -j option is given without an argument, make will not limit the number of jobs that can run simultaneously.
-k, --keep-going Continue as much as possible after an error.  While the target that failed, and those that depend on it, cannot be remade, the other dependencies of these targets can be processed all the same.
-l [load], --load-average[=load] Specifies that no new jobs (commands) should be started if there are others jobs running and the load average is at least load (a floating-point number).  With no argument, removes a previous load limit.
-L, --check-symlink-times Use the latest mtime between symlinks and target.
-n, --just-print, --dry-run, --recon Print the commands that would be executed, but do not execute them (except in certain circumstances).
-o file, --old-file=file, --assume-old=file Do not remake the file file even if it is older than its dependencies, and do not remake anything on account of changes in file.  Essentially the file is treated as very old and its rules are ignored.
-O[type], --output-sync[=type] When running multiple jobs in parallel with -j, ensure the output of each job is collected together rather than interspersed with output from other jobs.  If type is not specified or is target the output from the entire recipe for each target is grouped together.  If type is line the output from each command line within a recipe is grouped together.  If type is recurse output from an entire recursive make is grouped together.  If type is none output synchronization is disabled.
-p, --print-data-base Print the data base (rules and variable values) that results from reading the makefiles; then execute as usual or as otherwise specified.  This also prints the version information given by the -v switch (see below).  To print the data base without trying to remake any files, use make -p -f/dev/null.
-q, --question ``Question mode''.  Do not run any commands, or print anything; just return an exit status that is zero if the specified targets are already up to date, nonzero otherwise.
-r, --no-builtin-rules Eliminate use of the built-in implicit rules.  Also clear out the default list of suffixes for suffix rules.
-R, --no-builtin-variables Don't define any built-in variables.
-s, --silent, --quiet Silent operation; do not print the commands as they are executed.
--no-silent Cancel the effect of the -s option.
-S, --no-keep-going, --stop Cancel the effect of the -k option.
-t, --touch Touch files (mark them up to date without really changing them) instead of running their commands.  This is used to pretend that the commands were done, in order to fool future invocations of make.
--trace Information about the disposition of each target is printed (why the target is being rebuilt and what commands are run to rebuild it).
-v, --version Print the version of the make program plus a copyright, a list of authors and a notice that there is no warranty.
-w, --print-directory Print a message containing the working directory before and after other processing.  This may be useful for tracking down errors from complicated nests of recursive make commands.
--no-print-directory Turn off -w, even if it was turned on implicitly.
-W file, --what-if=file, --new-file=file, --assume-new=file Pretend that the target file has just been modified.  When used with the -n flag, this shows you what would happen if you were to modify that file.  Without -n, it is almost the same as running a touch command on the given file before running make, except that the modification time is changed only in the imagination of make.
--warn-undefined-variables Warn when an undefined variable is referenced.
GNU make exits with a status of zero if all makefiles were successfully parsed and no targets that were built failed.  A status of one will be returned if the -q flag was used and make determines that a target needs to be rebuilt.  A status of two will be returned if any errors were encountered.
The full documentation for make is maintained as a Texinfo manual.  If the info and make programs are properly installed at your site, the command
info make
See the chapter ``Problems and Bugs'' in The GNU Make Manual.
This manual page contributed by Dennis Morse of Stanford University. Further updates contributed by Mike Frysinger.  It has been reworked by Roland McGrath.  Maintained by Paul Smith.
Copyright Â© 1992-1993, 1996-2020 Free Software Foundation, Inc.  This file is part of GNU make.
GNU Make is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.
GNU Make is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program.  If not, see http://www.gnu.org/licenses/.
pdfinfo(1)                   General Commands Manual                  pdfinfo(1)
pdfinfo - Portable Document Format (PDF) document information extractor (version 3.03)
pdfinfo [options] [PDF-file]
Pdfinfo prints the contents of the ´Info' dictionary (plus some other useful information) from a Portable Document Format (PDF) file.
If PDF-file is ´-', it reads the PDF file from stdin.
The ´Info' dictionary contains the following values:
title subject keywords author creator producer creation date modification date
In addition, the following information is printed:
custom metadata (yes/no) metadata stream (yes/no) tagged (yes/no) userproperties (yes/no) suspects (yes/no) form (AcroForm / XFA / none) javascript (yes/no) page count encrypted flag (yes/no) print and copy permissions (if encrypted) page size file size linearized (yes/no) PDF version metadata (only if requested)
The options -listenc, -meta, -js, -struct, and -struct-text only print the requested information. The 'Info' dictionary and related data listed above is not printed. At most one of these five options may be used.
-f number Specifies the first page to examine.  If multiple pages are requested using the "-f" and "-l" options, the size of each requested page (and, optionally, the bounding boxes for each requested page) are printed.  Otherwise, only page one is examined.
-l number Specifies the last page to examine.
-box   Prints the page box bounding boxes: MediaBox, CropBox, BleedBox, TrimBox, and ArtBox.
-meta  Prints document-level metadata.  (This is the "Metadata" stream from the PDF file's Catalog object.)
-custom Prints custom and standard metadata.
-js    Prints all JavaScript in the PDF.
-struct Prints the logical document structure of a Tagged-PDF file.
-struct-text Print the textual content along with the document structure of a Tagged-PDF file.  Note that extracting text this way might be slow for big PDF files.  (Implies -struct.)
-url   Print all URLs in the PDF. Only the URL types supported by Poppler are listed.  Currently, this is limited to Annotations. Note: only URLs referenced by the PDF objects such as Link Annotations are listed. pdfinfo does not attempt to extract strings matching http://... from the text content.
-isodates Prints dates in ISO-8601 format (including the time zone).
-rawdates Prints the raw (undecoded) date strings, directly from the PDF file.
-dests Print a list of all named destinations. If a page range is specified using "-f" and "-l", only destinations in the page range are listed.
-listenc Lits the available encodings
The pdfinfo software and documentation are copyright 1996-2011 Glyph & Cog, LLC.
pdfdetach(1), pdffonts(1), pdfimages(1), pdftocairo(1), pdftohtml(1), pdftoppm(1), pdftops(1), pdftotext(1) pdfseparate(1), pdfsig(1), pdfunite(1)
Bundlewrap(1)                General Commands Manual               Bundlewrap(1)
bundlewrap - Decentralized configuration management system with Python
bundlewrap [-h] [-a] [-A] [-d] [-r DIRECTORY] [--version] {apply, debug, groups, hash, items, lock, metadata, nodes, plot, repo, run, stats, test, verify, zen} ...
BundleWrap fills the gap between complex deployments using Chef or Puppet and old school system administration over SSH. You do not need to know any Python in order to use Bundlewrap, but you can easily extend your bundles using Python.
While most other config management systems rely on a client-server architecture, BundleWrap works off a repository cloned to your local machine.
It then automates the process of SSHing into your servers and making sure everything is configured the way it's supposed to be. You won't have to install anything on managed servers.
-a, --add-host-keys set StrictHostKeyChecking=no instead of yes for SSH
-A, --adhoc-nodes treat unknown node names as adhoc 'virtual' nodes that receive configuration only through groups whose member_patterns match the node name given on the command line (which also has to be a resolvable hostname)
-d, --debug print debugging info (implies -v)
-r DIRECTORY, --repo-path DIRECTORY Look for repository at this path (defaults to current working directory)
SUBCOMMANDS: use 'bw <subcommand> --help' for more info
apply  Applies the configuration defined in your repository to your nodes
debug  Start an interactive Python shell for this repository
groups Lists groups in this repository (deprecated, use `bw nodes -a`)
hash   Shows a SHA1 hash that summarizes the entire configuration for this repo, node, group, or item.
items  List and preview items for a specific node
lock   Manage locks on nodes used to prevent collisions between BundleWrap users
metadata View a JSON representation of a node's metadata
nodes  List all nodes in this repository
plot   Generates DOT output that can be piped into `dot -Tsvg -ooutput.svg`.  The resulting output.svg can be viewed using most browsers.
repo   Various subcommands to manipulate your repository
run    Run a one-off command on a number of nodes
stats  Show some statistics about your repository
test   Test your repository for consistency (you can use this with a CI tool like Jenkins)
verify Inspect the health or 'correctness' of a node without changing it
Bundlewrap bug tracker: https://github.com/bundlewrap/bundlewrap/issues
This manual page was written by Jonathan Carter <jcarter@linux.com> Bundlewrap was written by Torsten Rehn <torsten@rehn.email>
ntpdate(1)                   General Commands Manual                  ntpdate(1)
ntpdate - set the date and time via NTP
ntpdate [-bBdoqsuv] [-a key] [-e authdelay] [-k keyfile] [-o version] [-p samples] [-t timeout] server [...]
ntpdate sets the local date and time by polling the Network Time Protocol (NTP) server(s) given as the server arguments to determine the correct time. It must be run as root on the local host. A number of samples are obtained from each of the servers specified and a subset of the NTP clock filter and selection algorithms are applied to select the best of these. Note that the accuracy and reliability of ntpdate depends on the number of servers, the number of polls each time it is run and the interval between runs.
ntpdate can be run manually as necessary to set the host clock, or it can be run from the host startup script to set the clock at boot time.  This is useful in some cases to set the clock initially before starting the NTP daemon ntpd. It is also possible to run ntpdate from a cron script. However, it is important to note that ntpdate with contrived cron scripts is no substitute for the NTP daemon, which uses sophisticated algorithms to maximize accuracy and reliability while minimizing resource use. Finally, since ntpdate does not discipline the host clock frequency as does ntpd, the accuracy using ntpdate is limited.
Time adjustments are made by ntpdate in one of two ways. If ntpdate determines the clock is in error more than 0.5 second it will simply step the time by calling the system settimeofday() routine. If the error is less than 0.5 seconds, it will slew the time by calling the system adjtime() routine. The latter technique is less disruptive and more accurate when the error is small, and works quite well when ntpdate is run by cron every hour or two.
ntpdate will decline to set the date if an NTP server daemon (e.g., ntpd) is running on the same host. When running ntpdate on a regular basis from cron as an alternative to running a daemon, doing so once every hour or two will result in precise enough timekeeping to avoid stepping the clock.
-a key Enable the authentication function and specify the key identifier to be used for authentication as the argument keyntpdate. The keys and key identifiers must match in both the client and server key files. The default is to disable the authentication function.
-B     Force the time to always be slewed using the adjtime() system call, even if the measured offset is greater than +-128 ms. The default is to step the time using settimeofday() if the offset is greater than +-128 ms. Note that, if the offset is much greater than +-128 ms in this case, that it can take a long time (hours) to slew the clock to the correct value. During this time. the host should not be used to synchronize clients.
-b     Force the time to be stepped using the settimeofday() system call, rather than slewed (default) using the adjtime() system call. This option should be used when called from a startup file at boot time.
-d     Enable the debugging mode, in which ntpdate will go through all the steps, but not adjust the local clock. Information useful for general debugging will also be printed.
-e authdelay Specify the processing delay to perform an authentication function as the value authdelay, in seconds and fraction (see ntpd for details). This number is usually small enough to be negligible for most purposes, though specifying a value may improve timekeeping on very slow CPU's.
-k keyfile Specify the path for the authentication key file as the string keyfile. The default is /etc/ntp.keys. This file should be in the format described in ntpd.
-o version Specify the NTP version for outgoint packets as the integer version, which can be 1 or 2. The default is 3. This allows ntpdate to be used with older NTP versions.
-p samples Specify the number of samples to be acquired from each server as the integer samples, with values from 1 to 8 inclusive. The default is 4.
-q     Query only - don't set the clock.
-s     Divert logging output from the standard output (default) to the system syslog facility. This is designed primarily for convenience of cron scripts.
-t timeout Specify the maximum time waiting for a server response as the value timeout, in seconds and fraction. The value is is rounded to a multiple of 0.2 seconds. The default is 1 second, a value suitable for polling across a LAN.
-u     Direct ntpdate to use an unprivileged port or outgoing packets. This is most useful when behind a firewall that blocks incoming traffic to privileged ports, and you want to synchronise with hosts beyond the firewall. Note that the -d option always uses unprivileged ports.
-v     Be verbose. This option will cause ntpdate's version identification string to be logged.
/etc/ntp.keys - encryption keys used by ntpdate.
The slew adjustment is actually 50% larger than the measured offset, since this (it is argued) will tend to keep a badly drifting clock more accurate. This is probably not a good idea and may cause a troubling hunt for some values of the kernel variables tick and tickadj.
David L. Mills (mills@udel.edu) This manpage converted from html to roff by Fabrizio Polacco <fpolacco@debian.org>
METEOR(4)                 BSD Kernel Interfaces Manual                 METEOR(4)
meteor â€” video capture driver interface
The meteor driver defined a video capture interface.  The meteor driver is no longer in the tree, but other devices support this interface so the interface portion is documented here.
Meteor Capture Modes The meteor capture driver has three modes of capture operation.
1.   Conventional read(2) interface.
This mode is the easiest and slowest to use.  This mode is great for capturing a single field at little programming cost.
In this mode, the user opens the device, sets the capture mode and size (see: METEORSETGEO ioctl(2) call), and uses the read(2) system call to load the data into a buffer.
meteor_read.c; read 400x300 RGB24 into a viewable PPM file
#include <sys/fcntl.h> #include <machine/ioctl_meteor.h>
extern int errno; #define ROWS 300 #define COLS 400 #define SIZE (ROWS * COLS * 4) main() { struct meteor_geomet geo; char buf[SIZE],b[4],header[16],*p; int i,o,c;
if ((i = open("/dev/meteor0", O_RDONLY)) < 0) { printf("open failed: %d\n", errno); exit(1); } /* set up the capture type and size */ geo.rows = ROWS; geo.columns = COLS; geo.frames = 1; geo.oformat = METEOR_GEO_RGB24 ;
if (ioctl(i, METEORSETGEO, &geo) < 0) { printf("ioctl failed: %d\n", errno); exit(1); }
c = METEOR_FMT_NTSC;
if (ioctl(i, METEORSFMT, &c) < 0) { printf("ioctl failed: %d\n", errno); exit(1); }
c = METEOR_INPUT_DEV0;
if (ioctl(i, METEORSINPUT, &c) < 0) { printf("ioctl failed: %d\n", errno); exit(1); }
if ((c=read(i, &buf[0], SIZE)) < SIZE) { printf("read failed %d %d %d\n", c, i, errno); close(i); exit(1); } close(i);
if ((o = open("rgb24.ppm", O_WRONLY | O_CREAT, 0644)) < 0) { printf("ppm open failed: %d\n", errno); exit(1); }
/* make PPM header and save to file */ strcpy(&header[0], "P6 400 300 255 "); header[2] = header[6]  = header[10] = header[14] = '\n'; write (o, &header[0], 15); /* save the RGB data to PPM file */ for (p = &buf[0]; p < &buf[SIZE]; ) { b[2] = *p++;            /* blue */ b[1] = *p++;            /* green */ b[0] = *p++;            /* red */ *p++;                   /* NULL byte */ write(o,&b[0], 3);      /* not very efficient */ } close(o); exit(0); }
2.   Memory mapped single capture or unsynchronized continuous capture.
The single capture mode is designed for conferencing tools such as nv. These tools need to control the starting of the image capture and also need several frames a second.  The continuous capture mode is designed for applications that want free-running data.
In this mode, the user opens the device, sets the capture mode and size (see: METEORSETGEO ioctl(2) call), mmap(2)s the frame buffer memory into the user process space, and issues either the single- capture or the continuous capture call (see: METEORCAPTUR ioctl(2) call) to load the data into the memory mapped buffer.
As explained in the METEORCAPTUR ioctl(2) call, the single frame capture ioctl(2) will block until the capture is complete, the continuous capture will return immediately.
meteor_mmap_single_continuous.c
#include <sys/types.h> #include <sys/mman.h> #include <sys/fcntl.h> #include <machine/ioctl_meteor.h>
extern int errno; #define ROWS 480 #define COLS 640 #define SIZE (ROWS * COLS * 2) main() { struct meteor_geomet geo; char buf[SIZE]; char *mmbuf; int i,c;
if ((i = open("/dev/meteor0", O_RDONLY)) < 0) { printf("open failed\n"); exit(1); }
geo.rows = ROWS; geo.columns = COLS; geo.frames = 1; geo.oformat = METEOR_GEO_RGB16 ;
mmbuf=(char *)mmap((caddr_t)0, SIZE, PROT_READ, MAP_SHARED, i, (off_t)0);
#ifdef SINGLE_MODE /* single frame capture */ c = METEOR_CAP_SINGLE ; ioctl(i, METEORCAPTUR, &c);     /* wait for the frame */
/* directly access the frame buffer array data in mmbuf */ #else /* continuous frame capture */ c = METEOR_CAP_CONTINOUS ; ioctl(i, METEORCAPTUR, &c);     /* returns immediately */
/* directly access the frame buffer array data in mmbuf */
c = METEOR_CAP_STOP_CONT ; ioctl(i, METEORCAPTUR, &c);     /* close will also stop capture */ #endif
close(i); exit(0); }
3.   Memory mapped, multi-frame ring buffer synchronize capture.
This continuous capture mode is synchronized with the application that processes up to 32 frames.  This gives the advantages of both single and continuous capture modes.
The kernel notifies the application of a new data by raising an application defined signal.  The driver also shares a structure with the application that allows them to communicate which frame has been written by the kernel and which frame has been read by the application.
The shared structure starts on the first page after your data.  The structure address can be found by calculation:
(number_rows * number_columns * pixel_depth + 4095) & 0xfffff000 or ((number_rows * number_columns * pixel_depth + 4095)/4096) * 4096
The shared structure is of type struct meteor_mem.  The two most important fields are called active and num_active_buf.  active is a bitmap of frames written by the kernel.  num_active_bufs is a count of frames marked in the active field.  When a frame is read in by the driver, the num_active_bufs count is tested, if this count is below the threshold of number of active frames (value in meteor_mem's hiwat variable), the bit representing frame number in the buffer is stored in the active variable, the num_active_bufs is incremented, the kernel then raises the specified signal to activate the user application. The user application's responsibility when getting the signal is to check the active bitmap to determine the lowest active frame, use the data as the application desires, clear the bitmap entry for that frame, and decrement the num_active_bufs.  If the threshold of number of active frames (hiwat) has been exceeded, no new frames or signal from the kernel will occur until the num_active_bufs is less than or equal to lowat.
The driver loads the frames in a round-robin fashion.  It is expected that the user removes them in the same order.  The driver does not check to see if the frame is already active.
The frame_size and number of frames in the buffer are also provided to the meteor_mem structure, but changing these fields in the application will not change the operation of the driver.
In programming for this mode, the user opens the device, sets the geometry, mmap(2)s the data/common control structure, then starts the continuous capture mode.  A special signal catcher is required to process the frames as they are read by the kernel.
When specifying the geometry (see: METEORSETGEO ioctl(2) call), it is important that the number of frames is set greater than 1.
skeleton_capture_n.c
#include <sys/types.h> #include <sys/mman.h> #include <sys/fcntl.h> #include <sys/signal.h> #include <machine/ioctl_meteor.h>
int video;  /* made global if you wish to stop capture in signal handler */ caddr_t data_frames; struct meteor_mem *common_mem; extern int errno;
#define FRAME_MAX
void usr2_catcher() { #ifdef SIGNAL_STOP struct meteor_capframe capframe;        /* for ioctl */ #endif char *frame;
/* find frame */ frame = (char *) (data_frames + sig_cnt * common_mem->frame_size) ;
/* add frame processing here */ /* deactivate frame */ common_mem->active &= ~(1 << (sig_cnt % 16)); common_mem->num_active_bufs--;
/* process next frame on next interrupt */ sig_cnt = ((sig_cnt+1) % FRAME_MAX);
#ifdef SIGNAL_STOP if (some_condition_requiring_stopping) { capframe.command=METEOR_CAP_STOP_FRAMES;
if (ioctl(i, METEORCAPFRM, &capframe) < 0) { printf("METEORCAPFRM failed %d\n", errno); exit(1); } } #endif }
main() { struct meteor_geomet geo; int height, width, depth, frames, size; struct meteor_capframe capframe;
if ((i = open("/dev/meteor0", O_RDONLY)) < 0) { printf("open failed\n"); exit(1); } printf("test %d %d\n", errno, i);
height = geo.rows = 120; width= geo.columns = 320; frames = geo.frames = FRAME_MAX; depth = 2;      /* 2 bytes per pixel for RGB*/
geo.oformat = METEOR_GEO_RGB16;
if (ioctl(i, METEORSETGEO, &geo) < 0) { printf("METEORSETGEO failed %d\n", errno); exit(1); }
size = ((width*height*depth*frames+4095)/4096)*4096; /* add one page after data for meteor_mem */ data_frames = mmap((caddr_t)0, size + 4096, PROT_READ | PROT_WRITE, MAP_SHARED, i, (off_t)0);
if (data_frames == (caddr_t) MAP_FAILED) return (0);
/* common_mem is located at page following data */ common_mem = (struct meteor_mem *) (y + size);
signal(SIGUSR2, usr2_catcher);  /* catch new frame message */
capframe.command=METEOR_CAP_N_FRAMES; capframe.signal=SIGUSR2; capframe.lowat=12;              /* must be < hiwat */ capframe.hiwat=14;              /* must be < FRAME_MAX */
/* start the sync capture */ if (ioctl(i, METEORCAPFRM, &capframe) < 0) { printf("METEORCAPFRM failed %d\n", errno); exit(1); }
/* this is the background working area, or you can sleep */
/* to stop capture */ capframe.command=METEOR_CAP_STOP_FRAMES;
if (ioctl(i, METEORCAPFRM, &capframe) < 0) { printf("METEORCAPFRM failed %d\n", errno); exit(1); } }
Meteor IOCTL Call and Parameters The meteor capture driver has ioctl(2) requests for capturing, reading card status, for setting and reading the geometry, and for setting and reading the attributes.
IT IS VERY IMPORTANT TO CHECK FOR ERRORS ON THESE RETURNING IOCTLs.  Errors indicate that something is very wrong with the ioctl(2) and the application should not attempt to proceed further with capturing.  The meteor capture driver still makes attempts to stop the next capture step if an error occurred in a previous step but was ignored by the application programmer.
1.   ioctl(2) requests METEORSETGEO and METEORGETGEO
METEORSETGEO and METEORGETGEO are used to set and read the input size, input device, and output format for frame capture.
These ioctl(2) routines use the meteor_geomet structure that has the following entries:
rows     number of rows (lines high) in output image
columns  number of pixels in a row (width) in output image
frames   number of frames in buffer.  Should be 1, unless using the multi-framed synchronous capture mode (METEORCAPFRM) which REQUIRES frames to be larger than 1.
Note: if rows, columns or frames is not changed, then the existing values are used.  The system defaults is 640x480x1.
oformat  you may choose one of the following output format:
METEOR_GEO_RGB16       (RGB 16 bits xrrrrrgg gggbbbbb default)
METEOR_GEO_RGB24       (RGB 24 bits packed in 32 bits: 00000000 rrrrrrrr gggggggg bbbbbbbb)
METEOR_GEO_YUV_PACKED  (4-2-2 YUV 16 bits packed byte format: u0 y0 v0 y1 u1 y2 v1 y3 ...)
METEOR_GEO_YUV_PLANER  (4-2-2 YUV 16 bits planer format: rows * columns bytes of y rows * column / 4 bytes of even u rows * column / 4 bytes of even v rows * column / 4 bytes of odd u rows * column / 4 bytes of odd v)
The METEORSETGEO ioctl(2) will fail if more than one entry from a category is selected.  It is highly recommended that a METEORSETGEO is done before capturing data because you cannot guarantee the initial mode the card.
The METEORSETGEO will also attempt to reallocate a new contiguous kernel buffer if the new geometry exceeds the old geometry.  On other hand, if the new geometry will fit in the existing buffer, the existing buffer is used.
If METEORSETGEO fails the ioctl(2) will return a value of -1 and the external variable errno will be set to:
[EINVAL]           invalid meteor_geomet structure pointer, rows, columns, frames were invalid.
[ENOMEM]           could not allocate the contiguous block.
2.   ioctl(2) requests METEORSFMT and METEORGFMT
METEORSFMT and METEORGFMT are used to set and read the camera input standard format.
Possible formats are:
METEOR_FMT_NTSC      NTSC (default mode) METEOR_FMT_PAL       PAL METEOR_FMT_SECAM     SECAM METEOR_FMT_AUTOMODE  Autodetect.
3.   ioctl(2) requests METEORSINPUT and METEORGINPUT
METEORSINPUT and METEORGINPUT are used to set and read the camera input device.  Using the DB9 connector on the Meteor card, 4 input devices can be connected and an input camera can be selected with this ioctl(2).
METEOR_INPUT_DEV0        (default if none specified) METEOR_INPUT_DEV_RCA     (same as METEOR_INPUT_DEV0) METEOR_INPUT_DEV1 METEOR_INPUT_DEV2 METEOR_INPUT_DEV_SVIDEO  (same as METEOR_INPUT_DEV2)
4.   ioctl(2) request METEORSTATUS
METEORSTATUS is used to read the status of the Meteor capture card and returns the following information:
METEOR_STATUS_ID_MASK    4 bit ID of the SAA7196 scaler chip.
METEOR_STATUS_DIR        0 = scaler uses internal source. 1 = scaler uses external data of expansion bus.
METEOR_STATUS_OEF        0 = even field detected. 1 = odd field detected.
METEOR_STATUS_SVP        VRAM Port state: 0 = inputs HFL and INCADDR inactive. 1 = inputs HFL and INCADDR active.
METEOR_STATUS_STTC       0 = TV horizontal time constant (slow). 1 = VCR horizontal time constant (fast).
METEOR_STATUS_HCLK       0 = Horizontal Phase Lock Loop locked. 1 = Horizontal Phase Lock Loop unlocked.
METEOR_STATUS_FIDT       0 = 50 Hz Field detected. 1 = 60 Hz Field detected.
METEOR_STATUS_ALTD       0 = no line alternating color burst detected. 1 = line alternating color burst detected (PAL/SECAM).
METEOR_STATUS_CODE       0 = no color information detected. 1 = color information detected.
5.   ioctl(2) request METEORCAPTUR
METEORCAPTUR is used to single frame capture or unsynchronized continuous capture.
The single frame capture ioctl(2) request will return only after a frame has been captured and transfered to the frame buffer.
The unsynchronized continuous capture will return immediately and data is directly deposited into the buffer when it is available.  Since this is unsynchronized, it is possible the data is being written by the kernel while being read by the application.
These ioctl(2) routines use the following settings:
METEOR_CAP_SINGLE     capture one frame METEOR_CAP_CONTINOUS  unsynchronized continuous capture METEOR_CAP_STOP_CONT  stop the unsynchronized continuous capture
If METEORCAPTUR fails the ioctl(2) will return a value of -1 and the external variable errno will be set to:
[EINVAL]           invalid capture command value
[ENXIO]            there is not internal buffer to hold the frame. This indicates the previous set geometry ioctl(2) failed.
[EIO]              card is already capturing.
6.   ioctl(2) request METEORCAPFRM
METEORCAPFRM is used for synchronous capture of multiple frames.
This ioctl(2) routine uses the meteor_capture structure that has the following entries:
command  possible values for command are:
METEOR_CAP_STOP_FRAMES  stop the capture; does not use the other variable in structure.
METEOR_CAP_N_FRAMES     start the capture using the other variables in the structure as inputs
signal   signal to send to application when a new frame has been captured.  This signal will only be raised if the captured frame is saved.
lowat    see below
hiwat    see below
When a new frame is completed, the driver checks the current unread frame count stored in shared variable (the shared variable is stored in the meteor_mem structure) num_active_buf; if the count is larger than hiwat, the driver will not store any new frames and will not send capture signal to the user application until the num_active_buf is lower than lowat.
If METEORCAPFRM fails the ioctl(2) will return a value of -1 and the external variable errno will be set to:
[EINVAL]           invalid meteor_geomet structure pointer or bad command.
7.   ioctl(2) requests METEORSCHCV and METEORGCHCV
METEORSCHCV and METEORGCHCV are used to set and get the chrominance gain control and effects the UV output amplitude.
If METEORSCHCV or METEORGCHCV fails the ioctl(2) will return a value of -1 and the external variable errno will be set to:
[EINVAL]           invalid unsigned char pointer.
8.   ioctl(2) requests METEORGHUE and METEORSHUE
METEORGHUE and METEORSHUE are used to get and set the hue.  The signed character has legal values are from +127 which represent +178.6 degrees to -128 which represents -180 degrees.
If METEORGHUE or METEORSHUE fails the ioctl(2) will return a value of -1 and the external variable errno will be set to:
[EINVAL]           invalid signed char pointer.
9.   ioctl(2) requests METEORSCOUNT and METEORGCOUNT
METEORGCOUNT is used to get the count of frame errors, DMA errors and count of the number of frames captured that have occurred since the device was opened.  METEORSCOUNT can be used to reinitialize the counters.
This ioctl(2) routines use the meteor_counts structure that has the following entries:
fifo_errors  number of FIFO errors since device was opened.
dma_errors   number of DMA errors since device was opened.
frame_count  number of frames captured since device was opened.
If METEORSCOUNT or METEORGCOUNT fails the ioctl(2) will return a value of -1 and the external variable errno will be set to:
[EINVAL]           invalid meteor_counts structure pointer.
Jim Lowe <james@miller.cs.uwm.edu>, Mark Tinguely <tinguely@plains.nodak.edu>
The meteor driver no longer works at all.
CSVCUT(1)                            csvkit                            CSVCUT(1)
csvcut - csvcut Documentation
Filters and truncates CSV files. Like the Unix “cut” command, but for tabular data:
usage: csvcut [-h] [-d DELIMITER] [-t] [-q QUOTECHAR] [-u {0,1,2,3}] [-b] [-p ESCAPECHAR] [-z FIELD_SIZE_LIMIT] [-e ENCODING] [-S] [-H] [-K SKIP_LINES] [-v] [-l] [--zero] [-V] [-n] [-c COLUMNS] [-C NOT_COLUMNS] [-x] [FILE]
Filter and truncate CSV files. Like the Unix "cut" command, but for tabular data.
optional arguments: -h, --help            show this help message and exit -n, --names           Display column names and indices from the input CSV and exit. -c COLUMNS, --columns COLUMNS A comma separated list of column indices, names or ranges to be extracted, e.g. "1,id,3-5". Defaults to all columns. -C NOT_COLUMNS, --not-columns NOT_COLUMNS A comma separated list of column indices, names or ranges to be excluded, e.g. "1,id,3-5". Defaults to no columns. -x, --delete-empty-rows After cutting, delete rows which are completely empty.
NOTE: csvcut does not implement row filtering, for this you should pipe data to csvgrep.
NOTE: If a data row is longer than the header row, its additional columns are truncated. Use csvclean first to fix such rows.
Print the indices and names of all columns:
csvcut -n examples/realdata/FY09_EDU_Recipients_by_State.csv 1: State Name 2: State Abbreviate 3: Code 4: Montgomery GI Bill-Active Duty 5: Montgomery GI Bill- Selective Reserve 6: Dependents' Educational Assistance 7: Reserve Educational Assistance Program 8: Post-Vietnam Era Veteran's Educational Assistance Program 9: TOTAL 10:
Print only the names of all columns, by removing the indices with the cut command:
csvcut -n examples/realdata/FY09_EDU_Recipients_by_State.csv | cut -c6- State Name State Abbreviate Code Montgomery GI Bill-Active Duty Montgomery GI Bill- Selective Reserve Dependents' Educational Assistance Reserve Educational Assistance Program Post-Vietnam Era Veteran's Educational Assistance Program TOTAL
Extract the first and third columns:
csvcut -c 1,3 examples/realdata/FY09_EDU_Recipients_by_State.csv
Extract columns named “TOTAL” and “State Name” (in that order):
csvcut -c TOTAL,"State Name" examples/realdata/FY09_EDU_Recipients_by_State.csv
Add line numbers to a file, making no other changes:
csvcut -l examples/realdata/FY09_EDU_Recipients_by_State.csv
Extract a column that may not exist in all files:
echo d, | csvjoin examples/dummy.csv - | csvcut -c d echo d, | csvjoin examples/join_no_header_row.csv - | csvcut -c d
Display a column’s unique values:
csvcut -c 1 examples/realdata/FY09_EDU_Recipients_by_State.csv | sed 1d | sort | uniq
csvcut -c 1 examples/realdata/FY09_EDU_Recipients_by_State.csv | csvsql --query 'SELECT DISTINCT("State Name") FROM stdin'
GIT-LFS(1)                   General Commands Manual                  GIT-LFS(1)
git-lfs - Work with large files in Git repositories
git lfs command [args]
Git LFS is a system for managing and versioning large files in association with a Git repository. Instead of storing the large files within the Git repository as blobs, Git LFS stores special "pointer files" in the repository, while storing the actual file contents on a Git LFS server. The contents of the large file are downloaded automatically when needed, for example when a Git branch containing the large file is checked out.
Git LFS works by using a "smudge" filter to look up the large file contents based on the pointer file, and a "clean" filter to create a new version of the pointer file when the large fileÂ´s contents change. It also uses a pre-push hook to upload the large file contents to the Git LFS server whenever a commit containing a new large file version is about to be pushed to the corresponding Git server.
Like Git, Git LFS commands are separated into high level ("porcelain") commands and low level ("plumbing") commands.
High level commands (porcelain) git-lfs-env(1) Display the Git LFS environment.
git-lfs-checkout(1) Populate working copy with real content from Git LFS files.
git-lfs-dedup(1) De-duplicate Git LFS files.
git-lfs-ext(1) Display Git LFS extension details.
git-lfs-fetch(1) Download Git LFS files from a remote.
git-lfs-fsck(1) Check Git LFS files for consistency.
git-lfs-install(1) Install Git LFS configuration.
git-lfs-lock(1) Set a file as "locked" on the Git LFS server.
git-lfs-locks(1) List currently "locked" files from the Git LFS server.
git-lfs-logs(1) Show errors from the Git LFS command.
git-lfs-ls-files(1) Show information about Git LFS files in the index and working tree.
git-lfs-migrate(1) Migrate history to or from Git LFS
git-lfs-prune(1) Delete old Git LFS files from local storage
git-lfs-pull(1) Fetch Git LFS changes from the remote & checkout any required working tree files.
git-lfs-push(1) Push queued large files to the Git LFS endpoint.
git-lfs-status(1) Show the status of Git LFS files in the working tree.
git-lfs-track(1) View or add Git LFS paths to Git attributes.
git-lfs-uninstall(1) Uninstall Git LFS by removing hooks and smudge/clean filter configuration.
git-lfs-unlock(1) Remove "locked" setting for a file on the Git LFS server.
git-lfs-untrack(1) Remove Git LFS paths from Git Attributes.
git-lfs-update(1) Update Git hooks for the current Git repository.
git-lfs-version(1) Report the version number.
Low level commands (plumbing) git-lfs-clean(1) Git clean filter that converts large files to pointers.
git-lfs-filter-process(1) Git process filter that converts between large files and pointers.
git-lfs-pointer(1) Build and compare pointers.
git-lfs-post-checkout(1) Git post-checkout hook implementation.
git-lfs-post-commit(1) Git post-commit hook implementation.
git-lfs-post-merge(1) Git post-merge hook implementation.
git-lfs-pre-push(1) Git pre-push hook implementation.
git-lfs-smudge(1) Git smudge filter that converts pointer in blobs to the actual content.
git-lfs-standalone-file(1) Git LFS standalone transfer adapter for file URLs (local paths).
To get started with Git LFS, the following commands can be used.
1.  Setup Git LFS on your system. You only have to do this once per repository per machine:
git lfs install
2.  Choose the type of files you want to track, for examples all ISO images, with git-lfs-track(1):
git lfs track "*.iso"
3.  The above stores this information in gitattributes(5) files, so that file need to be added to the repository:
4.  Commit, push and work with the files normally:
git add file.iso git commit -m "Add disk image" git push
DEBUILD(1)                   General Commands Manual                  DEBUILD(1)
debuild - build a Debian package
debuild [debuild options] [dpkg-buildpackage options] [--lintian-opts lintian options] debuild [debuild options] -- binary|binary-arch|binary-indep|clean ...
debuild creates all the files necessary for uploading a Debian package. It first runs dpkg-buildpackage, then runs lintian on the .changes file created (assuming that lintian is installed), and finally signs the appropriate files (using debsign(1) to do this instead of dpkg- buildpackage(1) itself; all relevant key-signing options are passed on). Signing will be skipped if the distribution is UNRELEASED, unless dpkg- buildpackage's --force-sign option is used.  Parameters can be passed to dpkg-buildpackage and lintian, where the parameters to the latter are indicated with the --lintian-opts option.  The allowable options in this case are --lintian and --no-lintian to force or skip the lintian step, respectively. The default is to run lintian.  There are also various options available for setting and preserving environment variables, as described below in the Environment Variables section.  In this method of running debuild, we also save a build log to the file ../<package>_<version>_<arch>.build.
An alternative way of using debuild is to use one or more of the parameters binary, binary-arch, binary-indep and clean, in which case debuild will attempt to gain root privileges and then run debian/rules with the given parameters.  A --rootcmd=gain-root-command or -rgain-root- command option may be used to specify a method of gaining root privileges.  The gain-root-command is likely to be one of fakeroot, sudo or super.  See below for further discussion of this point.  Again, the environment preservation options may be used.  In this case, debuild will also attempt to run dpkg-checkbuilddeps first; this can be explicitly requested or switched off using the options -D and -d respectively.  Note also that if either of these or a -r option is specified in the configuration file option DEBUILD_DPKG_BUILDPACKAGE_OPTS, then it will be recognised even in this method of invocation of debuild.
debuild also reads the devscripts configuration files as described below. This allows default options to be given.
Directory name checking In common with several other scripts in the devscripts package, debuild will climb the directory tree until it finds a debian/changelog file before attempting to build the package.  As a safeguard against stray files causing potential problems, it will examine the name of the parent directory once it finds the debian/changelog file, and check that the directory name corresponds to the package name.  Precisely how it does this is controlled by two configuration file variables DEVSCRIPTS_CHECK_DIRNAME_LEVEL and DEVSCRIPTS_CHECK_DIRNAME_REGEX, and their corresponding command-line options --check-dirname-level and --check-dirname-regex.
DEVSCRIPTS_CHECK_DIRNAME_LEVEL can take the following values:
0      Never check the directory name.
1      Only check the directory name if we have had to change directory in our search for debian/changelog.  This is the default behaviour.