neulab/tldr huggingface dataset:
--reversewrite Same as --reverse but will allow writes, if possible (configuration must have UniqueIV disabled).  Incompatible option : Per-File Initialization Vectors.
--extpass=program Specify an external program to use for getting the user password. When the external program is spawned, the environment variable "RootDir" will be set to contain the path to the root directory.  The program should print the password to standard output.
EncFS takes everything returned from the program to be the password, except for a trailing newline (\n) which will be removed.
For example, specifying --extpass=/usr/lib/ssh/ssh-askpass will cause EncFS to use ssh's password prompt program.
Note: EncFS reads at most 2k of data from the password program, and it removes any trailing newline.  Versions before 1.4.x accepted only 64 bytes of text.
-S, --stdinpass Read password from standard input, without prompting.  This may be useful for scripting encfs mounts.
Note that you should make sure the filesystem and mount points exist first.  Otherwise encfs will prompt for the filesystem creation options, which may interfere with your script.
--anykey Turn off key validation checking.  This allows EncFS to be used with secondary passwords.  This could be used to store a separate set of files in an encrypted filesystem.  EncFS ignores files which do not decode properly, so files created with separate passwords will only be visible when the filesystem is mounted with their associated password.
Note that if the primary password is changed (using encfsctl), the other passwords will not be usable unless the primary password is set back to what it was, as the other passwords rely on an invalid decoding of the volume key, which will not remain the same if the primary password is changed.
Warning: Use this option at your own risk.
--forcedecode This option only has an effect on filesystems which use MAC block headers.  By default, if a block is decoded and the stored MAC doesn't match what is calculated, then an IO error is returned to the application and the block is not returned.  However, by specifying --forcedecode, only an error will be logged and the data will still be returned to the application.  This may be useful for attempting to read corrupted files.
--require-macs If creating a new filesystem, this forces block authentication code headers to be enabled.  When mounting an existing filesystem, this causes encfs to exit if block authentication code headers are not enabled.
This can be used to improve security in case the ciphertext is vulnerable to tampering, by preventing an attacker from disabling MACs in the config file.
-i, --idle=MINUTES Enable automatic unmount of the filesystem after a period of inactivity.  The period is specified in minutes, so the shortest timeout period that can be requested is one minute.  EncFS will not automatically unmount if there are files open within the filesystem, even if they are open in read-only mode.  However simply having files open does not count as activity.
-m, --ondemand Mount the filesystem on-demand.  This currently only makes sense in combination with --idle and --extpass options.  When the filesystem becomes idle, instead of exiting, EncFS stops allowing access to the filesystem by internally dropping its reference to it.  If someone attempts to access the filesystem again, the extpass program is used to prompt the user for the password.  If this succeeds, then the filesystem becomes available again.
--delaymount Do not mount the filesystem when encfs starts; instead, delay mounting until first use. This option only makes sense with --ondemand.
-u, --unmount Unmounts the specified mountPoint.
--public Attempt to make encfs behave as a typical multi-user filesystem.  By default, all FUSE based filesystems are visible only to the user who mounted them.  No other users (including root) can view the filesystem contents.  The --public option does two things.  It adds the FUSE flags "allow_other" and "default_permission" when mounting the filesystem, which tells FUSE to allow other users to access the filesystem, and to use the ownership permissions provided by the filesystem.  Secondly, the --public flag changes how encfs's node creation functions work - as they will try and set ownership of new nodes based on the caller identification.
Warning: In order for this to work, encfs must be run as root -- otherwise it will not have the ability to change ownership of files. I recommend that you instead investigate if the fuse allow_other option can be used to do what you want before considering the use of --public.
--nocache Disable the kernel's cache of file attributes.  Setting this option makes EncFS pass "attr_timeout=0" and "entry_timeout=0" to FUSE. This makes sure that modifications to the backing file attributes that occour outside EncFS show up immediately in the EncFS mount. The internal EncFS data cache is also disabled. The main use case for --nocache is reverse mode.
--noattrcache Same as --nocache but for attributes only.
--nodatacache Same as --nocache but for data only.
--no-default-flags Encfs adds the FUSE flags "use_ino" and "default_permissions" by default, as of version 1.2.2, because that improves compatibility with some programs.  If for some reason you need to disable one or both of these flags, use the option --no-default-flags.
The following command lines produce the same result:
encfs raw crypt encfs --no-default-flags raw crypt -- -o use_ino,default_permissions
-o FUSE_ARG Pass through FUSE args to the underlying library.  This makes it easy to pass FUSE options when mounting EncFS via mount (and /etc/fstab). Eg:
mount encfs#/home/me-crypt /home/me -t fuse -o kernel_cache
Note that encfs arguments cannot be set this way.  If you need to set encfs arguments, create a wrapper, such as  encfs-reverse;
#!/bin/sh encfs --reverse "$@"
Then mount using the script path
mount encfs-reverse#/home/me /home/me-crypt -t fuse
-d, --fuse-debug Enables debugging within the FUSE library.  This should only be used if you suspect a problem within FUSE itself (not EncFS), as it generates a lot of low-level data and is not likely to be very helpful in general problem tracking.  Try verbose mode (-v) first, which gives a higher level view of what is happening within EncFS.
-H, --fuse-help Shows FUSE help.
--  The -- option tells EncFS to send any remaining arguments directly to FUSE.  In turn, FUSE passes the arguments to fusermount.  See the fusermount help page for information on available commands.
ENCFS6_CONFIG Which config file (typically named .encfs6.xml) to use.  By default, the config file is read from the encrypted directory.  Using this option allows to store the config file separated from the encrypted files.
Warning: If you lose the config file, the encrypted file contents are irrecoverably lost. It contains the master key encrypted with your password. Without the master key, recovery is impossible, even if you know the password.
Create a new encrypted filesystem.  Store the raw (encrypted) data in "~/.crypt" , and make the unencrypted data visible in "~/crypt".  Both directories are in the home directory in this example.  This example shows the full output of encfs as it asks the user if they wish to create the filesystem:
% encfs ~/.crypt ~/crypt Directory "/home/me/.crypt" does not exist, create (y,n)?y Directory "/home/me/crypt" does not exist, create (y,n)?y Creating new encrypted volume. Please choose from one of the following options: enter "x" for expert configuration mode, enter "p" for pre-configured paranoia mode, anything else, or an empty line will select standard mode. ?>
Standard configuration selected. Using cipher Blowfish, key size 160, block size 512 New Password: <password entered here> Verify: <password entered here>
The filesystem is now mounted and visible in ~/crypt.  If files are created there, they can be seen in encrypted form in ~/.crypt.  To unmount the filesystem, use fusermount with the -u (unmount) option:
% fusermount -u ~/crypt
Another example.  To mount the same filesystem, but have fusermount name the mount point '/dev/foo' (as shown in df and other tools which read /etc/mtab), and also request kernel-level caching of file data (which are both special arguments to fusermount):
% encfs ~/.crypt ~/crypt -- -n /dev/foo -c
Or, if you find strange behavior under some particular program when working in an encrypted filesystem, it may be helpful to run in verbose mode while reproducing the problem and send along the output with the problem report:
% encfs -v -f ~/.crypt ~/crypt 2> encfs-report.txt
In order to avoid leaking sensitive information through the debugging channels, all warnings and debug messages (as output in verbose mode) contain only encrypted filenames.  You can use the encfsctl program's decode function to decode filenames if desired.
EncFS is not a true filesystem.  It does not deal with any of the actual storage or maintenance of files.  It simply translates requests (encrypting or decrypting as necessary) and passes the requests through to the underlying host filesystem.  Therefore any limitations of the host filesystem will be inherited by EncFS (or possibly be further limited).
One such limitation is filename length.  If your underlying filesystem limits you to N characters in a filename, then EncFS will limit you to approximately 3*(N-2)/4.  For example if the host filesystem limits to 255 characters, then EncFS will be limited to 189 character filenames. This is because encrypted filenames are always longer than plaintext filenames.
When EncFS is given a root directory which does not contain an existing EncFS filesystem, it will give the option to create one.  Note that options can only be set at filesystem creation time.  There is no support for modifying a filesystem's options in-place.
If you want to upgrade a filesystem to use newer features, then you need to create a new filesystem and mount both the old filesystem and new filesystem at the same time and copy the old to the new.
Multiple instances of encfs can be run at the same time, including different versions of encfs, as long as they are compatible with the current FUSE module on your system.
A choice is provided for two pre-configured settings ('standard' and 'paranoia'), along with an expert configuration mode.
Standard mode uses the following settings: Cipher: AES Key Size: 192 bits PBKDF2 with 1/2 second runtime, 160 bit salt Filesystem Block Size: 1024 bytes Filename Encoding: Block encoding with IV chaining Unique initialization vector file headers File holes passed through
Paranoia mode uses the following settings: Cipher: AES Key Size: 256 bits PBKDF2 with 3 second runtime, 160 bit salt Filesystem Block Size: 1024 bytes Filename Encoding: Block encoding with IV chaining Unique initialization vector file headers Message Authentication Code block headers External IV Chaining File holes passed through
In the expert / manual configuration mode, each of the above options is configurable.  Here is a list of current options with some notes about what they mean:
Key Derivation Function As of version 1.5, EncFS now uses PBKDF2 as the default key derivation function.  The number of iterations in the keying function is selected based on wall clock time to generate the key.  In standard mode, a target time of 0.5 seconds is used, and in paranoia mode a target of 3.0 seconds is used.
On a 1.6Ghz AMD 64 system, roughly 64k iterations of the key derivation function can be handled in half a second.  The exact number of iterations to use is stored in the configuration file, as it is needed to remount the filesystem.
If an EncFS filesystem configuration from 1.4.x is modified with version 1.5 (such as when using encfsctl to change the password), then the new PBKDF2 function will be used and the filesystem will no longer be readable by older versions.
Cipher Which encryption algorithm to use.  The list is generated automatically based on what supported algorithms EncFS found in the encryption libraries.  When using a recent version of OpenSSL, Blowfish and AES are the typical options.
Blowfish is an 8 byte cipher - encoding 8 bytes at a time.  AES is a 16 byte cipher.
Cipher Key Size Many, if not all, of the supported ciphers support multiple key lengths.  There is not really much need to have enormous key lengths. Even 160 bits (the default) is probably overkill.
Filesystem Block Size This is the size (in bytes) that EncFS deals with at one time.  Each block gets its own initialization vector and is encoded in the cipher's cipher-block-chaining mode.  A partial block at the end of a file is encoded using a stream mode to avoid having to store the filesize somewhere.
Having larger block sizes reduces the overhead of EncFS a little, but it can also add overhead if your programs read small parts of files. In order to read a single byte from a file, the entire block that contains that byte must be read and decoded, so a large block size adds overhead to small requests.  With write calls it is even worse, as a block must be read and decoded, the change applied and the block encoded and written back out.
The default is 512 bytes as of version 1.0.  It was hard coded to 64 bytes in version 0.x, which was not as efficient as the current setting for general usage.
Filename Encoding New in 1.1. A choice is given between stream encoding of filename and block encoding.  The advantage of stream encoding is that the encoded filenames will be as short as possible.  If you have a filename with a single letter, it will be very short in the encoded form, where as block encoded filenames are always rounded up to the block size of the encryption cipher (8 bytes for Blowfish and 16 bytes for AES).
The advantage of block encoding mode is that filename lengths all come out as a multiple of the cipher block size.  This means that someone looking at your encrypted data can't tell as much about the length of your filenames.  It is on by default, as it takes a similar amount of time to using the stream cipher.  However stream cipher mode may be useful if you want shorter encrypted filenames for some reason.
Based on an underlying filesystem supporting a maximum of 255 characters in filenames, here is the maximum possible filename length depending on the choosen encoding scheme : stream (189), block (176), block32 (143). Note that we should rather talk about bytes, when filenames contain special (multi-bytes) characters.
Prior to version 1.1, only stream encoding was supported.
Filename Initialization Vector Chaining New in 1.1.  In previous versions of EncFS, each filename element in a path was encoded separately.  So if "foo" encoded to "XXX", then it would always encode that way (given the same encryption key), no matter if the path was "a/b/foo", or "aa/foo/cc", etc.  That meant it was possible for someone looking at the encrypted data to see if two files in different directories had the same name, even though they wouldn't know what that name decoded to.
With initialization vector chaining, each directory gets its own initialization vector.  So "a/foo" and "b/foo" will have completely different encoded names for "foo".  This features has almost no performance impact (for most operations), and so is the default in all modes.
Note: One significant performance exception is directory renames. Since the initialization vector for filename encoding depends on the directory path, any rename requires re-encoding every filename in the tree of the directory being changed.  If there are thousands of files, then EncFS will have to do thousands of renames.  It may also be possible that EncFS will come across a file that it can't decode or doesn't have permission to move during the rename operation, in which case it will attempt to undo any changes it made up to that point and the rename will fail.
Per-File Initialization Vectors New in 1.1.  In previous versions of EncFS, each file was encoded in the same way.  Each block in a file has always had its own initialization vector, but in a deterministic way, so that block N in one file was encoded in the same way as block N in another file. That made it possible for someone to tell if two files were identical (or parts of the file were identical) by comparing the encoded data.
With per-file initialization vectors, each file gets its own 64-bit random initialization vector, so that each file is encrypted in a different way.
Reverse mode derivates IV from inode number, it may then change for example when source files are copied from one FS to another.
External IV Chaining New in 1.1.3.  This option is closely related to Per-File Initialization Vectors and Filename Initialization Vector Chaining. Basically it extends the initialization vector chaining from filenames to the per-file initialization vector.
When this option is enabled, the per-file initialization vector is encoded using the initialization vector derived from the filename initialization vector chaining code.  This means that the data in a file becomes tied to the filename.  If an encrypted file is renamed outside of encfs, it will no longer be decodable within encfs.  Note that unless Block MAC headers are enabled, the decoding error will not be detected and will result in reading random looking data.
There is a cost associated with this.  When External IV Chaining is enabled, hard links will not be allowed within the filesystem, as there would be no way to properly decode two different filenames pointing to the same data.
Also, renaming a file requires modifying the file header.  So renames will only be allowed when the user has write access to the file.
Because of these limits, this option is disabled by default for standard mode (and enabled by default for paranoia mode).
This option may be incompatible with some cloud providers, as during a rename, file's content changes, but not its timestamp. Due to this, file's changes may no be correctly seen by cloud providers' sync programs. It is then not recommended for cloud usage.
Block MAC headers New to 1.1.  If this is enabled, every block in every file is stored along with a cryptographic checksum (Message Authentication Code). This makes it virtually impossible to modify a file without the change being detected by EncFS.  EncFS will refuse to read data which does not pass the checksum, and will log the error and return an IO error to the application.
This adds substantial overhead (default being 8 bytes per filesystem block), plus computational overhead, and is not enabled by default except in paranoia mode.
When this is not enabled and if EncFS is asked to read modified or corrupted data, it will have no way to verify that the decoded data is what was originally encoded.
File-hole pass-through Make encfs leave holes in files.  If a block is read as all zeros, it will be assumed to be a hole and will be left as 0's when read (not deciphered).  This is required if accessing encfs using the SMB protocol.
Enabled by default.  Can be disabled in expert mode.
Attacks The primary goal of EncFS is to protect data off-line.  That is, provide a convenient way of storing files in a way that will frustrate any attempt to read them if the files are later intercepted.
Some algorithms in EncFS are also meant to frustrate on-line attacks where an attacker is assumed to be able to modify the files.
The most intrusive attacks, where an attacker has complete control of the user's machine (and can therefore modify EncFS, or FUSE, or the kernel itself) are not guarded against.  Do not assume that encrypted files will protect your sensitive data if you enter your password into a compromised computer.  How you determine that the computer is safe to use is beyond the scope of this documentation.
That said, here are some example attacks and data gathering techniques on the filesystem contents along with the algorithms EncFS supports to thwart them:
Attack: modifying a few bytes of an encrypted file (without knowing what they will decode to). EncFS does not use any form of XOR encryption which would allow single bytes to be modified without affecting others.  Most modifications would affect dozens or more bytes.  Additionally, MAC Block headers can be used to identify any changes to files.
Attack: copying a random block of one file to a random block of another file. Each block has its own [deterministic] initialization vector.
Attack: copying block N to block N of another file. When the Per-File Initialization Vector support is enabled (default in 1.1.x filesystems), a copied block will not decode properly when copied to another file.
Attack: copying an entire file to another file. Can be prevented by enabling External IV Chaining mode.
Attack: determine if two filenames are the same by looking at encrypted names. Filename Initialization Vector chaining prevents this by giving each file a 64-bit initialization vector derived from its full path name.
Attack: compare if two files contain the same data. Per-File Initialization Vector support prevents this.
This library 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.  Please refer to the "COPYING" file distributed with EncFS for complete details.
EncFS was written by Valient Gough <vgough@pobox.com>.
Site : https://vgough.github.io/encfs/.
Support, bug reports... : https://github.com/vgough/encfs.
Mailing list : none.
Cygwin, Windows ports : https://github.com/vgough/encfs/wiki.
encfsctl(1)
TESSERACT(1)                                                        TESSERACT(1)
tesseract - command-line OCR engine
tesseract FILE OUTPUTBASE [OPTIONS]... [CONFIGFILE]...
tesseract(1) is a commercial quality OCR engine originally developed at HP between 1985 and 1995. In 1995, this engine was among the top 3 evaluated by UNLV. It was open-sourced by HP and UNLV in 2005, and has been developed at Google since then.
IN/OUT ARGUMENTS FILE The name of the input file. This can either be an image file or a text file.
Most image file formats (anything readable by Leptonica) are supported.
A text file lists the names of all input images (one image name per line). The results will be combined in a single file for each output file format (txt, pdf, hocr, xml).
If FILE is stdin or - then the standard input is used.
OUTPUTBASE The basename of the output file (to which the appropriate extension will be appended). By default the output will be a text file with .txt added to the basename unless there are one or more parameters set which explicitly specify the desired output.
If OUTPUTBASE is stdout or - then the standard output is used.
-c CONFIGVAR=VALUE Set value for parameter CONFIGVAR to VALUE. Multiple -c arguments are allowed.
--dpi N Specify the resolution N in DPI for the input image(s). A typical value for N is 300. Without this option, the resolution is read from the metadata included in the image. If an image does not include that information, Tesseract tries to guess it.
-l LANG, -l SCRIPT The language or script to use. If none is specified, eng (English) is assumed. Multiple languages may be specified, separated by plus characters. Tesseract uses 3-character ISO 639-2 language codes (see LANGUAGES AND SCRIPTS).
--psm N Set Tesseract to only run a subset of layout analysis and assume a certain form of image. The options for N are:
0 = Orientation and script detection (OSD) only. 1 = Automatic page segmentation with OSD. 2 = Automatic page segmentation, but no OSD, or OCR. (not implemented) 3 = Fully automatic page segmentation, but no OSD. (Default) 4 = Assume a single column of text of variable sizes. 5 = Assume a single uniform block of vertically aligned text. 6 = Assume a single uniform block of text. 7 = Treat the image as a single text line. 8 = Treat the image as a single word. 9 = Treat the image as a single word in a circle. 10 = Treat the image as a single character. 11 = Sparse text. Find as much text as possible in no particular order. 12 = Sparse text with OSD. 13 = Raw line. Treat the image as a single text line, bypassing hacks that are Tesseract-specific.
--oem N Specify OCR Engine mode. The options for N are:
0 = Original Tesseract only. 1 = Neural nets LSTM only. 2 = Tesseract + LSTM. 3 = Default, based on what is available.
--tessdata-dir PATH Specify the location of tessdata path.
--user-patterns FILE Specify the location of user patterns file.
--user-words FILE Specify the location of user words file.
CONFIGFILE The name of a config to use. The name can be a file in tessdata/configs or tessdata/tessconfigs, or an absolute or relative file path. A config is a plain text file which contains a list of parameters and their values, one per line, with a space separating parameter from value.
Interesting config files include:
•   alto — Output in ALTO format (OUTPUTBASE.xml).
•   hocr — Output in hOCR format (OUTPUTBASE.hocr).
•   pdf — Output PDF (OUTPUTBASE.pdf).
•   tsv — Output TSV (OUTPUTBASE.tsv).
•   txt — Output plain text (OUTPUTBASE.txt).
•   get.images — Write processed input images to file (tessinput.tif).
•   logfile — Redirect debug messages to file (tesseract.log).
•   lstm.train — Output files used by LSTM training (OUTPUTBASE.lstmf).
•   makebox — Write box file (OUTPUTBASE.box).
•   quiet — Redirect debug messages to /dev/null.
It is possible to select several config files, for example tesseract image.png demo alto hocr pdf txt will create four output files demo.alto, demo.hocr, demo.pdf and demo.txt with the OCR results.
Nota bene: The options -l LANG, -l SCRIPT and --psm N must occur before any CONFIGFILE.
-h, --help Show help message.
--help-extra Show extra help for advanced users.
--help-psm Show page segmentation modes.
--help-oem Show OCR Engine modes.
-v, --version Returns the current version of the tesseract(1) executable.
--list-langs List available languages for tesseract engine. Can be used with --tessdata-dir PATH.
--print-parameters Print tesseract parameters.
To recognize some text with Tesseract, it is normally necessary to specify the language(s) or script(s) of the text (unless it is English text which is supported by default) using -l LANG or -l SCRIPT.
Selecting a language automatically also selects the language specific character set and dictionary (word list).
Selecting a script typically selects all characters of that script which can be from different languages. The dictionary which is included also contains a mix from different languages. In most cases, a script also supports English. So it is possible to recognize a language that has not been specifically trained for by using traineddata for the script it is written in.
More than one language or script may be specified by using +. Example: tesseract myimage.png myimage -l eng+deu+fra.
https://github.com/tesseract-ocr/tessdata_fast provides fast language and script models which are also part of Linux distributions.
For Tesseract 4, tessdata_fast includes traineddata files for the following languages:
afr (Afrikaans), amh (Amharic), ara (Arabic), asm (Assamese), aze (Azerbaijani), aze_cyrl (Azerbaijani - Cyrilic), bel (Belarusian), ben (Bengali), bod (Tibetan), bos (Bosnian), bre (Breton), bul (Bulgarian), cat (Catalan; Valencian), ceb (Cebuano), ces (Czech), chi_sim (Chinese simplified), chi_tra (Chinese traditional), chr (Cherokee), cym (Welsh), dan (Danish), deu (German), dzo (Dzongkha), ell (Greek, Modern, 1453-), eng (English), enm (English, Middle, 1100-1500), epo (Esperanto), equ (Math / equation detection module), est (Estonian), eus (Basque), fas (Persian), fin (Finnish), fra (French), frk (Frankish), frm (French, Middle, ca.1400-1600), gle (Irish), glg (Galician), grc (Greek, Ancient, to 1453), guj (Gujarati), hat (Haitian; Haitian Creole), heb (Hebrew), hin (Hindi), hrv (Croatian), hun (Hungarian), iku (Inuktitut), ind (Indonesian), isl (Icelandic), ita (Italian), ita_old (Italian - Old), jav (Javanese), jpn (Japanese), kan (Kannada), kat (Georgian), kat_old (Georgian - Old), kaz (Kazakh), khm (Central Khmer), kir (Kirghiz; Kyrgyz), kmr (Kurdish Kurmanji), kor (Korean), kor_vert (Korean vertical), kur (Kurdish), lao (Lao), lat (Latin), lav (Latvian), lit (Lithuanian), ltz (Luxembourgish), mal (Malayalam), mar (Marathi), mkd (Macedonian), mlt (Maltese), mon (Mongolian), mri (Maori), msa (Malay), mya (Burmese), nep (Nepali), nld (Dutch; Flemish), nor (Norwegian), oci (Occitan post 1500), ori (Oriya), osd (Orientation and script detection module), pan (Panjabi; Punjabi), pol (Polish), por (Portuguese), pus (Pushto; Pashto), que (Quechua), ron (Romanian; Moldavian; Moldovan), rus (Russian), san (Sanskrit), sin (Sinhala; Sinhalese), slk (Slovak), slv (Slovenian), snd (Sindhi), spa (Spanish; Castilian), spa_old (Spanish; Castilian - Old), sqi (Albanian), srp (Serbian), srp_latn (Serbian - Latin), sun (Sundanese), swa (Swahili), swe (Swedish), syr (Syriac), tam (Tamil), tat (Tatar), tel (Telugu), tgk (Tajik), tgl (Tagalog), tha (Thai), tir (Tigrinya), ton (Tonga), tur (Turkish), uig (Uighur; Uyghur), ukr (Ukrainian), urd (Urdu), uzb (Uzbek), uzb_cyrl (Uzbek - Cyrilic), vie (Vietnamese), yid (Yiddish), yor (Yoruba)
To use a non-standard language pack named foo.traineddata, set the TESSDATA_PREFIX environment variable so the file can be found at TESSDATA_PREFIX/tessdata/foo.traineddata and give Tesseract the argument -l foo.
For Tesseract 4, tessdata_fast includes traineddata files for the following scripts:
Arabic, Armenian, Bengali, Canadian_Aboriginal, Cherokee, Cyrillic, Devanagari, Ethiopic, Fraktur, Georgian, Greek, Gujarati, Gurmukhi, HanS (Han simplified), HanS_vert (Han simplified, vertical), HanT (Han traditional), HanT_vert (Han traditional, vertical), Hangul, Hangul_vert (Hangul vertical), Hebrew, Japanese, Japanese_vert (Japanese vertical), Kannada, Khmer, Lao, Latin, Malayalam, Myanmar, Oriya (Odia), Sinhala, Syriac, Tamil, Telugu, Thaana, Thai, Tibetan, Vietnamese.
The same languages and scripts are available from https://github.com/tesseract-ocr/tessdata_best. tessdata_best provides slow language and script models. These models are needed for training. They also can give better OCR results, but the recognition takes much more time.
Both tessdata_fast and tessdata_best only support the LSTM OCR engine.
There is a third repository, https://github.com/tesseract-ocr/tessdata, with models which support both the Tesseract 3 legacy OCR engine and the Tesseract 4 LSTM OCR engine.
Tesseract config files consist of lines with parameter-value pairs (space separated). The parameters are documented as flags in the source code like the following one in tesseractclass.h:
STRING_VAR_H(tessedit_char_blacklist, "", "Blacklist of chars not to recognize");
These parameters may enable or disable various features of the engine, and may cause it to load (or not load) various data. For instance, let’s suppose you want to OCR in English, but suppress the normal dictionary and load an alternative word list and an alternative list of patterns — these two files are the most commonly used extra data files.
If your language pack is in /path/to/eng.traineddata and the hocr config is in /path/to/configs/hocr then create three new files:
/path/to/eng.user-words:
the quick brown fox jumped
/path/to/eng.user-patterns:
1-\d\d\d-GOOG-411 www.\n\\\*.com
/path/to/configs/bazaar:
load_system_dawg     F load_freq_dawg       F user_words_suffix    user-words user_patterns_suffix user-patterns
Now, if you pass the word bazaar as a CONFIGFILE to Tesseract, Tesseract will not bother loading the system dictionary nor the dictionary of frequent words and will load and use the eng.user-words and eng.user-patterns files you provided. The former is a simple word list, one per line. The format of the latter is documented in dict/trie.h on read_pattern_list().
TESSDATA_PREFIX If the TESSDATA_PREFIX is set to a path, then that path is used to find the tessdata directory with language and script recognition models and config files. Using --tessdata-dir PATH is the recommended alternative.
OMP_THREAD_LIMIT If the tesseract executable was built with multithreading support, it will normally use four CPU cores for the OCR process. While this can be faster for a single image, it gives bad performance if the host computer provides less than four CPU cores or if OCR is made for many images. Only a single CPU core is used with OMP_THREAD_LIMIT=1.
The engine was developed at Hewlett Packard Laboratories Bristol and at Hewlett Packard Co, Greeley Colorado between 1985 and 1994, with some more changes made in 1996 to port to Windows, and some C++izing in 1998. A lot of the code was written in C, and then some more was written in C++. The C++ code makes heavy use of a list system using macros. This predates STL, was portable before STL, and is more efficient than STL lists, but has the big negative that if you do get a segmentation violation, it is hard to debug.
Version 2.00 brought Unicode (UTF-8) support, six languages, and the ability to train Tesseract.
Tesseract was included in UNLV’s Fourth Annual Test of OCR Accuracy. See https://github.com/tesseract-ocr/docs/blob/master/AT-1995.pdf. Since Tesseract 2.00, scripts are now included to allow anyone to reproduce some of these tests. See https://github.com/tesseract-ocr/tesseract/wiki/TestingTesseract for more details.
Tesseract 3.00 added a number of new languages, including Chinese, Japanese, and Korean. It also introduced a new, single-file based system of managing language data.
Tesseract 3.02 added BiDirectional text support, the ability to recognize multiple languages in a single image, and improved layout analysis.
Tesseract 4 adds a new neural net (LSTM) based OCR engine which is focused on line recognition, but also still supports the legacy Tesseract OCR engine of Tesseract 3 which works by recognizing character patterns. Compatibility with Tesseract 3 is enabled by --oem 0. This also needs traineddata files which support the legacy engine, for example those from the tessdata repository (https://github.com/tesseract-ocr/tessdata).
For further details, see the release notes in the Tesseract wiki (https://github.com/tesseract-ocr/tesseract/wiki/ReleaseNotes).
Main web site: https://github.com/tesseract-ocr User forum: http://groups.google.com/group/tesseract-ocr Wiki: https://github.com/tesseract-ocr/tesseract/wiki Information on training: https://github.com/tesseract-ocr/tesseract/wiki/TrainingTesseract
ambiguous_words(1), cntraining(1), combine_tessdata(1), dawg2wordlist(1), shape_training(1), mftraining(1), unicharambigs(5), unicharset(5), unicharset_extractor(1), wordlist2dawg(1)
Tesseract development was led at Hewlett-Packard and Google by Ray Smith. The development team has included:
Ahmad Abdulkader, Chris Newton, Dan Johnson, Dar-Shyang Lee, David Eger, Eric Wiseblatt, Faisal Shafait, Hiroshi Takenaka, Joe Liu, Joern Wanke, Mark Seaman, Mickey Namiki, Nicholas Beato, Oded Fuhrmann, Phil Cheatle, Pingping Xiu, Pong Eksombatchai (Chantat), Ranjith Unnikrishnan, Raquel Romano, Ray Smith, Rika Antonova, Robert Moss, Samuel Charron, Sheelagh Lloyd, Shobhit Saxena, and Thomas Kielbus.
For a list of contributors see https://github.com/tesseract-ocr/tesseract/blob/master/AUTHORS.
TELNET(1)                         User Commands                        TELNET(1)
telnet - User interface to TELNET
telnet [OPTION...] [HOST [PORT]]
Login to remote system HOST (optionally, on service port PORT)
-4, --ipv4 use only IPv4
-6, --ipv6 use only IPv6
-8, --binary use an 8-bit data transmission
-a, --login attempt automatic login
-b, --bind=ADDRESS bind to specific local ADDRESS
-c, --no-rc do not read the user's .telnetrc file
-d, --debug turn on debugging
-e, --escape=CHAR use CHAR as an escape character
-E, --no-escape use no escape character
-K, --no-login do not automatically login to the remote system
-l, --user=USER attempt automatic login as USER
-L, --binary-output use an 8-bit data transmission for output only
-n, --trace=FILE record trace information into FILE
-r, --rlogin use a user-interface similar to rlogin
Written by many authors.
Report bugs to <bug-inetutils@gnu.org>.
telnetd(1)
The full documentation for telnet is maintained as a Texinfo manual.  If the info and telnet programs are properly installed at your site, the command
info telnet
DIFF(7)               BSD Miscellaneous Information Manual               DIFF(7)
diff — Comparing and Merging Files
Comparing and Merging Files
Overview Computer users often find occasion to ask how two files differ. Perhaps one file is a newer version of the other file. Or maybe the two files started out as identical copies but were changed by different people.
You can use the diff command to show differences between two files, or each corresponding file in two directories.  diff outputs differences between files line by line in any of several formats, selectable by command line options. This set of differences is often called a diff or patch.  For files that are identical, diff normally produces no output; for binary (non-text) files, diff normally reports only that they are different.
You can use the cmp command to show the byte and line numbers where two files differ.  cmp can also show all the bytes that differ between the two files, side by side.  A way to compare two files character by character is the Emacs command M-x compare-windows.  See Section.Dq Other Window , for more information on that command.
You can use the diff3 command to show differences among three files. When two people have made independent changes to a common original, diff3 can report the differences between the original and the two changed versions, and can produce a merged file that contains both persons' changes together with warnings about conflicts.
You can use the sdiff command to merge two files interactively.
You can use the set of differences produced by diff to distribute updates to text files (such as program source code) to other people. This method is especially useful when the differences are small compared to the complete files. Given diff output, you can use the patch program to update, or patch, a copy of the file. If you think of diff as subtracting one file from another to produce their difference, you can think of patch as adding the difference to one file to reproduce the other.
This manual first concentrates on making diffs, and later shows how to use diffs to update files.
GNU diff was written by Paul Eggert, Mike Haertel, David Hayes, Richard Stallman, and Len Tower. Wayne Davison designed and implemented the unified output format.  The basic algorithm is described by Eugene W. Myers in “An O(ND) Difference Algorithm and its Variations”, Algorithmica Vol. 1 No. 2, 1986, pp. 251--266; and in “A File Comparison Program”, Webb Miller and Eugene W. Myers, Software---Practice and Experience Vol. 15 No. 11, 1985, pp. 1025--1040. The algorithm was independently discovered as described by E. Ukkonen in “Algorithms for Approximate String Matching”, Information and Control Vol. 64, 1985, pp. 100--118. Unless the [--minimal] option is used, diff uses a heuristic by Paul Eggert that limits the cost to O(N^1.5 log N) at the price of producing suboptimal output for large inputs with many differences.  Related algorithms are surveyed by Alfred V. Aho in section 6.3 of “Algorithms for Finding Patterns in Strings”, Handbook of Theoretical Computer Science (Jan Van Leeuwen, ed.), Vol. A, Algorithms and Complexity, Elsevier/MIT Press, 1990, pp. 255--300.
GNU diff3 was written by Randy Smith. GNU sdiff was written by Thomas Lord. GNU cmp was written by Torbjörn Granlund and David MacKenzie.
GNU patch was written mainly by Larry Wall and Paul Eggert; several GNU enhancements were contributed by Wayne Davison and David MacKenzie. Parts of this manual are adapted from a manual page written by Larry Wall, with his permission.
What Comparison Means There are several ways to think about the differences between two files. One way to think of the differences is as a series of lines that were deleted from, inserted in, or changed in one file to produce the other file.  diff compares two files line by line, finds groups of lines that differ, and reports each group of differing lines. It can report the differing lines in several formats, which have different purposes.
GNU diff can show whether files are different without detailing the differences. It also provides ways to suppress certain kinds of differences that are not important to you. Most commonly, such differences are changes in the amount of white space between words or lines.  diff also provides ways to suppress differences in alphabetic case or in lines that match a regular expression that you provide. These options can accumulate; for example, you can ignore changes in both white space and alphabetic case.
Another way to think of the differences between two files is as a sequence of pairs of bytes that can be either identical or different.  cmp reports the differences between two files byte by byte, instead of line by line. As a result, it is often more useful than diff for comparing binary files. For text files, cmp is useful mainly when you want to know only whether two files are identical, or whether one file is a prefix of the other.
To illustrate the effect that considering changes byte by byte can have compared with considering them line by line, think of what happens if a single newline character is added to the beginning of a file. If that file is then compared with an otherwise identical file that lacks the newline at the beginning, diff will report that a blank line has been added to the file, while cmp will report that almost every byte of the two files differs.
diff3 normally compares three input files line by line, finds groups of lines that differ, and reports each group of differing lines. Its output is designed to make it easy to inspect two different sets of changes to the same file.
Hunks When comparing two files, diff finds sequences of lines common to both files, interspersed with groups of differing lines called hunks.  Comparing two identical files yields one sequence of common lines and no hunks, because no lines differ. Comparing two entirely different files yields no common lines and one large hunk that contains all lines of both files. In general, there are many ways to match up lines between two given files. diff tries to minimize the total hunk size by finding large sequences of common lines interspersed with small hunks of differing lines.
For example, suppose the file F contains the three lines a, b, c, and the file G contains the same three lines in reverse order c, b, a.  If diff finds the line c as common, then the command diff F G produces this output:
1,2d0 < a < b 3a2,3 > b > a
But if diff notices the common line b instead, it produces this output:
1c1 < a --- > c 3c3 < c --- > a
It is also possible to find a as the common line.  diff does not always find an optimal matching between the files; it takes shortcuts to run faster. But its output is usually close to the shortest possible. You can adjust this tradeoff with the [-d] or [--minimal] option (see Section “diff Performance”).
Suppressing Differences in Blank and Tab Spacing The [-E] or [--ignore-tab-expansion] option ignores the distinction between tabs and spaces on input. A tab is considered to be equivalent to the number of spaces to the next tab stop (see Section “Tabs”).
The [-b] or [--ignore-space-change] option is stronger. It ignores white space at line end, and considers all other sequences of one or more white space characters within a line to be equivalent. With this option, diff considers the following two lines to be equivalent, where $ denotes the line end:
Here lyeth  muche rychnesse  in lytell space.   -- John Heywood$ Here lyeth muche rychnesse in lytell space. -- John Heywood   $
The [-w] or [--ignore-all-space] option is stronger still. It ignores differences even if one line has white space where the other line has none. White space characters include tab, newline, vertical tab, form feed, carriage return, and space; some locales may define additional characters to be white space.  With this option, diff considers the following two lines to be equivalent, where $ denotes the line end and ^M denotes a carriage return:
Here lyeth  muche  rychnesse in lytell space.--  John Heywood$ He relyeth much erychnes  seinly tells pace.  --John Heywood   ^M$
Suppressing Differences Whose Lines Are All Blank The [-B] or [--ignore-blank-lines] option ignores changes that consist entirely of blank lines. With this option, for example, a file containing
1.  A point is that which has no part.
2.  A line is breadthless length. -- Euclid, The Elements, I is considered identical to a file containing
1.  A point is that which has no part. 2.  A line is breadthless length.
-- Euclid, The Elements, I
Normally this option affects only lines that are completely empty, but if you also specify the [-b] or [--ignore-space-change] option, or the [-w] or [--ignore-all-space] option, lines are also affected if they look empty but contain white space.  In other words, [-B] is equivalent to -I '^$' by default, but it is equivalent to [-I '^[[:space:]]*$'] if [-b] or [-w] is also specified.
Suppressing Differences Whose Lines All Match a Regular Expression To ignore insertions and deletions of lines that match a grep -style regular expression, use the [-I regexp] or [--ignore-matching-lines= regexp] option. You should escape regular expressions that contain shell metacharacters to prevent the shell from expanding them. For example, diff -I '^[[:digit:]]' ignores all changes to lines beginning with a digit.
However, [-I] only ignores the insertion or deletion of lines that contain the regular expression if every changed line in the hunk---every insertion and every deletion---matches the regular expression. In other words, for each nonignorable change, diff prints the complete set of changes in its vicinity, including the ignorable ones.
You can specify more than one regular expression for lines to ignore by using more than one [-I] option.  diff tries to match each line against each regular expression.
Suppressing Case Differences GNU diff can treat lower case letters as equivalent to their upper case counterparts, so that, for example, it considers Funky Stuff, funky STUFF, and fUNKy stuFf to all be the same. To request this, use the [-i] or [--ignore-case] option.
Summarizing Which Files Differ When you only want to find out whether files are different, and you don't care what the differences are, you can use the summary output format. In this format, instead of showing the differences between the files, diff simply reports whether files differ. The [-q] or [--brief] option selects this output format.
This format is especially useful when comparing the contents of two directories.  It is also much faster than doing the normal line by line comparisons, because diff can stop analyzing the files as soon as it knows that there are any differences.
You can also get a brief indication of whether two files differ by using cmp.  For files that are identical, cmp produces no output. When the files differ, by default, cmp outputs the byte and line number where the first difference occurs, or reports that one file is a prefix of the other. You can use the [-s], [--quiet], or [--silent] option to suppress that information, so that cmp produces no output and reports whether the files differ using only its exit status (see Section “Invoking cmp”).
Unlike diff, cmp cannot compare directories; it can only compare two files.
Binary Files and Forcing Text Comparisons If diff thinks that either of the two files it is comparing is binary (a non-text file), it normally treats that pair of files much as if the summary output format had been selected (see Section “Brief”), and reports only that the binary files are different. This is because line by line comparisons are usually not meaningful for binary files.
diff determines whether a file is text or binary by checking the first few bytes in the file; the exact number of bytes is system dependent, but it is typically several thousand. If every byte in that part of the file is non- null, diff considers the file to be text; otherwise it considers the file to be binary.