gammu-smsdrc

title: gammu-smsdrc(5)

summary: gammu-smsd(1) configuration file

text:
# gammu-smsdrc(5)

## NAME
gammu-smsdrc - gammu-smsd(1) configuration file

## DESCRIPTION
gammu-smsd reads configuration from a config file. It's location can be specified on command line, otherwise default path /etc/gammu-smsdrc is used.

This file use ini file syntax, see ini.

Configuration file of gammu-smsd consists of at least two sections - [gammu] and [smsd]. For gammu-smsd-sql you can also use [sql] and [tables].

The [gammu] section is configuration of a phone connection and is same as described in gammurc with the only exception that LogFile is ignored and common logging for gammu library and SMS daemon is used. However the LogFormat directive still configures how much messages gammu emits.

[smsd]

The [smsd] section configures SMS daemon itself, which are described in following subsections. First general parameters of SMS daemon are listed and then specific parameters for storage backends.

[include_numbers]

List of numbers from which accept messages, see Message filtering.

[exclude_numbers]

List of numbers from which reject messages, see Message filtering.

[include_smsc]

List of SMSC numbers from which accept messages, see Message filtering.

[exclude_smsc]

List of SMSC numbers from which reject messages, see Message filtering.

[sql]

Configure SQL queries used by gammu-smsd-sql, you usually don't have to modify them. SEE ALSO:

Configurable queries

[tables]

Configure SQL table names used by gammu-smsd-sql, you usually don't have to modify them. SEE ALSO:

Configurable tables

## GENERAL PARAMETERS OF SMS DAEMON
Service

SMSD service to use, one of following choices:

FILES

Stores messages in files, see gammu-smsd-files for details.

NULL

Does not store messages at all, see gammu-smsd-null for details.

SQL

Stores messages in SQL database, see gammu-smsd-sql for details, choose database type to use by Driver. New in version 1.28.93.

MYSQL

Deprecated since version 1.28.93: Use Service = SQL and Driver = native_mysql instead.

Compatibility option for older configuration files, stores messages in MySQL database, see gammu-smsd-mysql for details.

PGSQL

Deprecated since version 1.28.93: Use Service = SQL and Driver = native_pgsql instead.

Compatibility option for older configuration files, stores messages in PostgreSQL database, see gammu-smsd-pgsql for details.

DBI

Deprecated since version 1.28.93: Use Service = SQL and Driver = DBI driver instead.

Compatibility option for older configuration files, stores messages in any database supported by libdbi, see gammu-smsd-dbi for details.

NOTE:

Availability of backends depends on platform and compile time configuration.

PIN

PIN for SIM card. This is optional, but you should set it if your phone after power on requires PIN.

NetworkCode

Network personalisation password. This is optional, but some phones require it after power on.

PhoneCode

Phone lock password. This is optional, but some phones require it after power on.

LogFile

File where SMSD actions are being logged. You can also use special value syslog which will send all messages to syslog daemon. On Windows another special value eventlog exists, which will send logs to Windows Event Log. If you run SMSD as a system daemon (or service), it is recommended to use absolute path to log file as startup directory might be different than you expect.

Default is to provide no logging.

NOTE:

For logging to Windows Event Log, it is recommended to install Event Log source by invoking gammu-smsd -e (this is automatically done during installation of Gammu).

LogFacility

Facility to use on logging backends which support it (currently only syslog). One of following chouces:

- DAEMON (default)

- USER

- LOCAL0

- LOCAL1

- LOCAL2

- LOCAL3

- LOCAL4

- LOCAL5

- LOCAL6

- LOCAL7

New in version 1.30.91.

DebugLevel

Debug level for SMSD. The integer value should be sum of all flags you want to enable.

1

enables basic debugging information

2

enables logging of SQL queries of service backends

4

enables logging of gammu debug information

Generally to get as much debug information as possible, use 255.

Default is 0, what should mean no extra information.

CommTimeout

How many seconds should SMSD wait after there is no message in outbox before scanning it again. Default is 30.

SendTimeout

Shows how many seconds SMSD should wait for network answer during sending sms. If nothing happen during this time, sms will be resent. Default is 30.

MaxRetries

How many times will SMSD try to resend message if sending fails. This is tracked per message and currently supported only with SQL backends. Default is 1.

RetryTimeout

How long to wait before resending failed message (needs to be enabled by MaxRetries). Is used in update_retries.

Default is 600.

ReceiveFrequency

The number of seconds between testing for received SMSes, when the phone is busy sending SMSes. Normally a test for received SMSes is done every CommTimeout seconds and after each sent SMS. Default is 15.

StatusFrequency

The number of seconds between refreshing phone status (battery, signal) stored in shared memory and possibly in service backends. Use 0 to disable. You might want to increase this for higher throughput.

Default is 60.

LoopSleep

The number of seconds how long will SMSD sleep before checking for some activity. Please note that setting this to higher value than 1 will have effects to other time based configurations, because they will be effectively rounded to multiply of this value. Setting this to 0 disables sleeping. Please note this might cause Gammu to consume quite a lot of CPU power as it will effectively do busy loop.

This sleep is utilized only if the main loop (sending and receiving messages) takes less than defined time. For example if you set LoopSleep to 5 seconds and sending messages take 10 seconds, no sleep will be done in the iteration which is sending messages. Also the sleep time is lowered by the already processed time.

Default is 1.

MultipartTimeout

The number of seconds how long will SMSD wait for all parts of multipart message. If all parts won't arrive in time, parts will be processed as separate messages. Default is 600 (10 minutes).

CheckSecurity

Whether to check if phone wants to enter PIN. Default is 1 (enabled).

HangupCalls

New in version 1.34.0.

Whether to automatically hangup any incoming calls.

Default is 0 (disabled).

CheckBattery

Whether to check phone battery state periodically. Default is 1 (enabled).

CheckSignal

Whether to check signal level periodically. Default is 1 (enabled).

CheckNetwork

New in version 1.37.90.

Whether to check network status periodically.

If phone is reported to be not on the network, SMSD tries to power it on.

Default is 1 (enabled).

ResetFrequency

The number of seconds between performing a preventive soft reset in order to minimize the cases of hanging phones e.g. Nokia 5110 will sometimes freeze to a state when only after unmounting the battery the phone will be functional again. Default is 0 (not used).

HardResetFrequency

New in version 1.28.92.

WARNING:

For some phones hard reset means deleting all data in it. Use ResetFrequency instead, unless you know what you are doing.

The number of seconds between performing a preventive hard reset in order to minimize the cases of hanging phones.

Default is 0 (not used).

DeliveryReport

Whether delivery reports should be used, one of no, log, sms.

log

one line log entry,

sms

store in inbox as a received SMS

no

no delivery reports

Default is no.

DeliveryReportDelay

Delay in seconds how long is still delivery report considered valid. This depends on brokenness of your network (delivery report should have same timestamp as sent message). Increase this if delivery reports are not paired with sent messages. Default is 600 (10 minutes).

PhoneID

String with info about phone used for sending/receiving. This can be useful if you want to run several SMS daemons (see Multiple modems). When you set PhoneID, all messages (including injected ones) will be marked by this string (stored as SenderID in the database) and it allows more SMS daemons to share a single database.

SMSD daemon will in such case send outbox messages only with matching or empty SenderID.

This option has actually no effect with gammu-smsd-files.

SMSC

New in version 1.36.2.

SMSC number to use for sending messages if not specified in the message (see options of gammu-smsd-inject).

In most cases you don't need this settings as Gammu tries to read correct SMSC from phone, but sometimes this fails (try gammu getsmsc).

RunOnReceive

Executes a program after receiving message. This parameter is executed through shell, so you might need to escape some special characters and you can include any number of parameters. Additionally parameters with identifiers of received messages are appended to the command line. The identifiers depend on used service backend, typically it is ID of inserted row for database backends or file name for file based backends.

Gammu SMSD waits for the script to terminate. If you make some time consuming there, it will make SMSD not receive new messages. However to limit breakage from this situation, the waiting time is limited to two minutes. After this time SMSD will continue in normal operation and might execute your script again.

The process has available lot of information about received message in environment, check gammu-smsd-run for more details.

RunOnFailure

New in version 1.28.93.

Executes a program on failure.

This can be used to proactively react on some failures or to interactively detect failure of sending message.

The program will receive optional parameter, which can currently be either INIT (meaning failure during phone initialization) or message ID, which would indicate error while sending the message.

NOTE:

The environment with message (as is in RunOnReceive) is not passed to the command.

RunOnSent

New in version 1.36.4.

Executes a program after sending message.

The program will receive optional parameter a message ID and environment with message details as described in gammu-smsd-run.

RunOnIncomingCall

New in version 1.38.5.

Executes a program after cancelling incoming call.

The program will receive a parameter with a phone number of the call. This requires HangupCalls to be enabled.

IncludeNumbersFile

File with list of numbers which are accepted by SMSD. The file contains one number per line, blank lines are ignored. The file is read at startup and is reread only when configuration is being reread. See Message filtering for details.

ExcludeNumbersFile

File with list of numbers which are not accepted by SMSD. The file contains one number per line, blank lines are ignored. The file is read at startup and is reread only when configuration is being reread. See Message filtering for details.

IncludeSMSCFile

File with list of SMSC numbers which are accepted by SMSD. The file contains one number per line, blank lines are ignored. The file is read at startup and is reread only when configuration is being reread. See Message filtering for details.

ExcludeSMSCFile

File with list of SMSC numbers which are not accepted by SMSD. The file contains one number per line, blank lines are ignored. The file is read at startup and is reread only when configuration is being reread. See Message filtering for details.

BackendRetries

How many times will SMSD backend retry operation. The implementation on different backends is different, for database backends it generally means how many times it will try to reconnect to the server.

Default is 10.

Send

New in version 1.28.91.

Whether to enable sending of messages.

Default is True.

Receive

New in version 1.28.91.

Whether to enable receiving of messages.

Default is True.

## DATABASE BACKENDS OPTIONS
All DBI, ODBC, MYSQL and PGSQL backends (see gammu-smsd-mysql, gammu-smsd-odbc, gammu-smsd-pgsql, gammu-smsd-dbi for their documentation) supports same options for configuring connection to a database:

User

User name used for connection to a database.

Password

Password used for connection to a database.

Host

Database server address. It can also contain port or socket path after semicolon, for example localhost:/path/to/socket or 192.168.1.1:8000. For ODBC this is used as Data source name.

NOTE:

Some database servers differentiate usage of localhost (to use local socket) and 127.0.0.1 (to use locat TCP/IP connection). Please make sure your SMSD settings match the database server ones.

New in version 1.28.92.

PC

Deprecated since version 1.28.92: Please use Host instead.

Synonym for Host, kept for backwards compatibility.

Database

Name of database (or schema) to use and where SMSD can find it's tables. Please note that you should create tables in this database before using gammu-smsd. SQL files for creating needed tables are included in documentation for individual database backends: gammu-smsd-mysql, gammu-smsd-odbc, gammu-smsd-pgsql, gammu-smsd-dbi

SkipSMSCNumber

When you send sms from some SMS centers you can have delivery reports from other SMSC number. You can set here number of this SMSC used by you and Gammu will not check it's number during assigning reports to sent SMS.

Driver

SQL driver to use, Gammu supports several native drivers and generic interface using ODBC and DBI. Availability of the backends depends on compile time options. Available drivers:

odbc

Connects to the database using ODBC, see gammu-smsd-odbc.

native_mysql

Stores messages in MySQL database, see gammu-smsd-mysql for details.

native_pgsql

Stores messages in PostgreSQL database, see gammu-smsd-pgsql for details.

db2, firebird, freetds, ingres, msql, mysql, oracle, pgsql, sqlite, sqlite3

Stores messages using DBI library in given backend. You need to have installed appropriate DBI driver to make it work. See gammu-smsd-dbi for details.

SQL

SQL dialect to use. This is specially useful with gammu-smsd-odbc where SMSD does not know which server it is actually talking to. Possible values:

- mysql - MySQL

- pgsql - PostgreSQL

- sqlite - SQLite

- mssql - Microsoft SQL Server

- sybase - Sybase

- access - Microsoft Access

- oracle - Oracle

- odbc - Generic ODBC

New in version 1.28.93.

SEE ALSO:

You can also completely customize SQL queries used as described in SQL Queries.

DriversPath

Path, where DBI drivers are stored, this usually does not have to be set if you have properly installed drivers.

DBDir

Database directory for some (currently only sqlite) DBI drivers. Set here path where sqlite database files are stored.

### Files backend options
The FILES backend accepts following configuration options. See gammu-smsd-files for more detailed service backend description. Please note that all path should contain trailing path separator (/ on Unix systems):

InboxPath

Where the received SMSes are stored. Default is current directory.

OutboxPath

Where SMSes to be sent should be placed. Default is current directory.

SentSMSPath

Where the transmitted SMSes are placed, if same as OutboxPath transmitted messages are deleted. Default is to delete transmitted messages.

ErrorSMSPath

Where SMSes with error in transmission is placed. Default is same as SentSMSPath.

InboxFormat

The format in which the SMS will be stored: detail, unicode, standard.

detail

format used for message backup by gammu, see gammu-smsbackup.

unicode

message text stored in unicode (UTF-16)

standard

message text stored in system charset

The standard and unicode settings do not apply for 8-bit messages, which are always written raw as they are received with extension .bin.

Default is unicode.

NOTE:

In detail format, all message parts are stored into signle file, for all others each message part is saved separately.

OutboxFormat

The format in which messages created by gammu-smsd-inject will be stored, it accepts same values as InboxFormat. Default is detail if Gammu is compiled in with backup functions, unicode otherwise.

TransmitFormat

The format for transmitting the SMS: auto, unicode, 7bit. This option is used only if OutboxFormat is not set to detail. In such case encoding specified in the message is used (you can specify it to gammu-smsd-inject).

Default is auto.

## MESSAGE FILTERING
SMSD allows one to process only limited subset of incoming messages. You can define filters for sender number in [include_numbers] and [exclude_numbers] sections or using IncludeNumbersFile and ExcludeNumbersFile directives.

If [include_numbers] section exists, all values (keys are ignored) from it are used as allowed phone numbers and no other message is processed. On the other side, in [exclude_numbers] you can specify numbers which you want to skip.

Lists from both sources are merged together. If there is any number in include list, only include list is used and only messages in this list are being accepted. If include list is empty, exclude list can be used to ignore messages from some numbers. If both lists are empty, all messages are accepted.

Similar filtering rules can be used for SMSC number filtering, they just use different set of configuration options - [include_smsc] and [exclude_smsc] sections or IncludeSMSCFile and ExcludeSMSCFile directives.

## EXAMPLES
There is more complete example available in Gammu documentation. Please note that for simplicity following examples do not include [gammu] section, you can look into gammurc for some examples how it can look like.

### Files service
SMSD configuration file for FILES backend could look like:

```
[smsd]
Service = files
PIN = 1234
LogFile = syslog
InboxPath = /var/spool/sms/inbox/
OutboxPath = /var/spool/sms/outbox/
SentSMSPath = /var/spool/sms/sent/
ErrorSMSPath = /var/spool/sms/error/
```

### MySQL service
If you want to use MYSQL backend, you will need something like this:

```
[smsd]
Service = sql
Driver = native_mysql
PIN = 1234
LogFile = syslog
User = smsd
Password = smsd
PC = localhost
Database = smsd
```

### DBI service using SQLite
For gammu-smsd-dbi backend, in this particular case SQLite:

```
[smsd]
Service = sql
Driver = sqlite3
DBDir = /var/lib/sqlite3
Database = smsd.db
```

### ODBC service using MySQL
For gammu-smsd-odbc backend, in this particular case using DSN smsd server:

```
[smsd]
Service = sql
Driver = odbc
Host = smsd
```

The DSN definition (in ~/.odbc.ini on UNIX) for using MySQL server would look like:

```
[smsd]
Description         = MySQL
Driver              = MySQL
Server              = 127.0.0.1
Database            = smsd
Port                =
Socket              =
Option              =
Stmt                =
[smsdsuse]
Driver              = MySQL ODBC 3.51.27r695 Driver
DATABASE            = smsd
SERVER              = 127.0.0.1
```

### Numbers filtering
Process only messages from 123456 number:

```
[include_numbers]
number1 = 123456
```

Do not process messages from evil number 666:

```
[exclude_numbers]
number1 = 666
```

### Debugging
Enabling debugging:

```
[smsd]
debuglevel = 255
logfile = smsd.log
```

### Multiple modems
You can run any number of SMSD instances and they can even share same backend database. For routing the messages, you need to set different PhoneID for each instance and set SenderID column in outbox table.

Following example shows configuration for two modems, but you can have any number of SMSD instances. The only limitation is performance of your hardware, especially if all modems are connected using USB.

Configuration for first SMSD:

```
[gammu]
device = /dev/ttyACM0
connection = at
[smsd]
Service = sql
Driver = native_mysql
PIN = 1234
LogFile = syslog
User = smsd
Password = smsd
PC = localhost
Database = smsd
PhoneID = first
```

Configuration for second SMSD:

```
[gammu]
device = /dev/ttyACM1
connection = at
[smsd]
Service = sql
Driver = native_mysql
PIN = 1234
LogFile = syslog
User = smsd
Password = smsd
PC = localhost
Database = smsd
PhoneID = second
```

You can then start two separate instances of SMSD:

```
gammu-smsd -c /path/to/first-smsdrc
gammu-smsd -c /path/to/second-smsdrc
```

## AUTHOR
Michal Čihař <michal@cihar.com>

## COPYRIGHT
2009-2015, Michal Čihař <michal@cihar.com>


gammurc

package: gammu

title: gammurc(5)

summary: gammu(1) configuration file

text:
# gammurc(5)

## NAME
gammurc - gammu(1) configuration file

## SYNOPSIS
On Linux, MacOS X, BSD and other Unix-like systems, the config file is searched in following order:

1.

$XDG_CONFIG_HOME/gammu/config

2.

~/.config/gammu/config

3.

~/.gammurc

4.

/etc/gammurc

On Microsoft Windows:

1.

%PROFILE%\Application Data\gammurc

2.

.\gammurc

## DESCRIPTION
Gammu requires configuration to be able to properly talk to your phone. gammu reads configuration from a config file. It's location is determined on runtime, see above for search paths.

You can use gammu-config or gammu-detect to generate configuration file or start from Fully documented example.

For hints about configuring your phone, you can check Gammu Phone Database <https://wammu.eu/phones/> to see what user users experienced.

This file use ini file syntax, see ini.

Configuration file for gammu can contain several sections - [gammu], [gammu1], [gammuN], ... Each section configures one connection setup and in default mode gammu tries all of them in numerical order. You can also specify which configuration section to use by giving it's number ([gammu] has number 0) as a parameter to gammu and it will then use only this section.

[gammu]

This section is read by default unless you specify other on command line.

### Device connection parameters
Connection

Protocol which will be used to talk to your phone. For Nokia cables you want to use one of following:

fbus

serial FBUS connection

dlr3

DLR-3 and compatible cables

dku2

DKU-2 and compatible cables

dku5

DKU-5 and compatible cables

mbus

serial MBUS connection

If you use some non original cable, you might need to append -nodtr (eg. for ARK3116 based cables) or -nopower, but Gammu should be able to detect this automatically.

For non-Nokia phones connected using cable you generally want:

at

generic AT commands based connection

You can optionally specify speed of the connection, eg. at19200, but it is not needed for modern USB cables.

For IrDA connections use one of following:

irdaphonet

Phonet connection for Nokia phones.

irdaat

AT commands connection for most of phones (this is not supported on Linux).

irdaobex

OBEX (IrMC or file transfer) connection for most of phones.

irdagnapbus

GNapplet based connection for Symbian phones, see gnapplet.

For Bluetooth connection use one of following:

bluephonet

Phonet connection for Nokia phones.

bluefbus

FBUS connection for Nokia phones.

blueat

AT commands connection for most of phones.

blueobex

OBEX (IrMC or file transfer) connection for most of phones.

bluerfgnapbus

GNapplet based connection for Symbian phones, see gnapplet.

blues60

Connection to Series60 applet in S60 phones, see s60. New in version 1.29.90.

New in version 1.36.7: Gammu now supports connecting using proxy command.

You can also proxy the connection using shell command, for example to different host. This can be done using proxy connections:

proxyphonet

Phonet connection for Nokia phones.

proxyfbus

FBUS connection for Nokia phones.

proxyat

AT commands connection for most of phones.

proxyobex

OBEX (IrMC or file transfer) connection for most of phones.

proxygnapbus

GNapplet based connection for Symbian phones, see gnapplet.

proxys60

Connection to Series60 applet in S60 phones, see s60.

SEE ALSO:

faq-config

Device

New in version 1.27.95.

Device node or address of phone. It depends on used connection.

For cables or emulated serial ports, you enter device name (for example /dev/ttyS0, /dev/ttyACM0, /dev/ircomm0, /dev/rfcomm0 on Linux, /dev/cuad0 on FreeBSD or COM1: on Windows). The special exception are DKU-2 and DKU-5 cables on Windows, where the device is automatically detected from driver information and this parameters is ignored.

NOTE:

Some USB modems expose several interfaces, in such cases Gammu works best with "User" one, you can find more information on <http://www.dd-wrt.com/wiki/index.php/Mobile_Broadband>.

For USB connections (currently only fbususb and dku2 on Linux), you can specify to which USB device Gammu should connect. You can either provide vendor/product IDs or device address on USB:

```
Device = 0x1234:0x5678  # Match device by vendor and product id
Device = 0x1234:-1      # Match device by vendor id
Device = 1.10           # Match device by usb bus and device address
Device = 10             # Match device by usb device address
Device = serial:123456  # Match device by serial string
```

NOTE:

On Linux systems, you might lack permissions for some device nodes. You might need to be member of some group (eg. plugdev or dialout) or or add special udev rules to enable you access these devices as non-root. For Nokia phones you can put following file (also available in sources as contrib/udev/69-gammu-acl.rules) as /etc/udev/rules.d/69-gammu-acl.rules:

```
#
# udev rule to give users access to USB device to be used by Gammu
#
ACTION!="add|change", GOTO="gammu_acl_rules_end"
KERNEL!="ttyACM[0-9]*", GOTO="gammu_acl_rules_end"
SUBSYSTEM!="tty", GOTO="gammu_acl_rules_end"
# Nokia devices
ATTRS{manufacturer}=="Nokia", TAG+="uaccess"
# Example for Sony Ericsson J108i Cedar
# ATTRS{idVendor}=="0fce", ATTRS{idProduct}=="d14e", TAG+="uaccess"
LABEL="gammu_acl_rules_end"
```

In case your USB device appears as the serial port in the system (eg. /dev/ttyACM0 on Linux or COM5: on Windows), just use same setup as with serial port.

For Bluetooth connection you have to enter Bluetooth address of your phone (you can list Bluetooth devices in range on Linux using hcitool scan command). Optionally you can also force Gammu to use specified channel by including channel number after slash.

Before using Gammu, your device should be paired with computer or you should have set up automatic pairing.

For Proxy connections, you need to specify command which should be executed. It is supposed to pass bidirectional communication from Gammu to the device. This can happen for example over network.

For IrDA connections, this parameters is not used at all.

If IrDA does not work on Linux, you might need to bring up the interface and enable discovery (you need to run these commands as root):

```
ip l s dev irda0 up          # Enables irda0 device
sysctl net.irda.discovery=1  # Enables device discovery on IrDA
```

NOTE:

Native IrDA is not supported on Linux, you need to setup virtual serial port for it (eg. /dev/ircomm0) and use it same way as cable. This can be usually achieved by loading modules ircomm-tty and irtty-sir:

```
modprobe ircomm-tty
modprobe irtty-sir
```

SEE ALSO:

faq-config

Port

Deprecated since version 1.27.95: Please use Device instead.

Alias for Device, kept for backward compatibility.

Model

Do not use this parameter unless really needed! The only use case for this is when Gammu does not know your phone and misdetects it's features. The only special case for using model is to force special type of OBEX connection instead of letting Gammu try the best suited for selected operation:

obexfs

force using of file browsing service (file system support)

obexirmc

force using of IrMC service (contacts, calendar and notes support)

obexnone

none service chosen, this has only limited use for sending file (gammu sendfile command)

mobex

m-obex service for Samsung phones

Use_Locking

On Posix systems, you might want to lock serial device when it is being used using UUCP-style lock files. Enabling this option (setting to yes) will make Gammu honor these locks and create it on startup. On most distributions you need additional privileges to use locking (eg. you need to be member of uucp group). This option has no meaning on Windows.

### Connection options
SynchronizeTime

If you want to set time from computer to phone during starting connection.

StartInfo

This option allows one to set, that you want (setting yes) to see message on the phone screen or phone should enable light for a moment during starting connection. Phone will not beep during starting connection with this option. This works only with some Nokia phones.

### Debugging options
LogFile

Path to file where information about communication will be stored. NOTE:

For most debug levels (excluding errors) the log file is overwritten on each execution.

LogFormat

Determines what all will be logged to LogFile. Possible values are:

nothing

no debug level

text

transmission dump in text format

textall

all possible info in text format

textalldate

all possible info in text format, with time stamp

errors

errors in text format

errorsdate

errors in text format, with time stamp

binary

transmission dump in binary format

For debugging use either textalldate or textall, it contains all needed information to diagnose problems.

Features

Custom features for phone. This can be used as override when values coded in common/gsmphones.c are bad or missing. Consult include/gammu-info.h for possible values (all GSM_Feature values without leading F_ prefix). Please report correct values to Gammu authors.

### Locales and character set options
GammuCoding

Forces using specified codepage (for example 1250 will force CP-1250 or utf8 for UTF-8). This should not be needed, Gammu detects it according to your locales.

GammuLoc

Path to directory with localisation files (the directory should contain LANG/LC_MESSAGES/gammu.mo). If gammu is properly installed it should find these files automatically.

### Advanced options
Advanced options are used to alter default logic, when using these options the user is responsible for ensuring any settings are correct for the target device and that they produce the desired behaviour.

atgen_setCNMI

For configurations using the generic AT command protocol it is possible to override the default indicators used when a new SMS message is received. The value for the setting is a comma delimited list of single digits corresponding to the values for the AT+CNMI modem command. If a digit is not provided, or if the provided digit is outside of the acceptable range for the device the default value is used.

For example setting atgen_setcnmi = ,,2 would set the third parameter of the CNMI command to the value 2, leaving the rest of the parameters at default, and atgen_setcnmi = 1,,,1 would set the first and fourth parameters respectively.

### Other options
DataPath

Additional path where to search for data files. The default path is configured on build time (and defaults to /usr/share/data/gammu on Unix systems). Currently it is used only for searching files to upload to phone using gammu install.

## EXAMPLES
There is more complete example available in Gammu documentation, see gammu.

### Connection examples
Gammu configuration for Nokia phone using DLR-3 cable:

```
[gammu]
device = /dev/ttyACM0
connection = dlr3
```

Gammu configuration for Sony-Ericsson phone (or any other AT compatible phone) connected using USB cable:

```
[gammu]
device = /dev/ttyACM0
connection = at
```

Gammu configuration for Sony-Ericsson (or any other AT compatible phone) connected using bluetooth:

```
[gammu]
device = B0:0B:00:00:FA:CE
connection = blueat
```

Gammu configuration for phone which needs to manually adjust Bluetooth channel to use channel 42:

```
[gammu]
device = B0:0B:00:00:FA:CE/42
connection = blueat
```

### Working with multiple phones
Gammu can be configured for multiple phones (however only one connection is used at one time, you can choose which one to use with gammu -s parameter). Configuration for phones on three serial ports would look like following:

```
[gammu]
device = /dev/ttyS0
connection = at
[gammmu1]
device = /dev/ttyS1
connection = at
[gammmu2]
device = /dev/ttyS2
connection = at
```

### Connecting to remote phone
New in version 1.36.7.

You can connect using Gammu to phone running on different host. This can be achieved using proxy connection, which executes command to forward bi-directional communication with the phone.

```
[gammu]
device = ssh root@my.router /usr/local/bin/myscript /dev/ttyUSB0
connection = proxyat
```

You can find sample script which can be used on the remote side in contrib/proxy/gammu-backend.

### Fully documented example
You can find this sample file as docs/config/gammurc in Gammu sources.

```
; This is a sample ~/.gammurc file.
; In Unix/Linux  copy it into your home directory and name it .gammurc
;                or into /etc and name it gammurc
; In Win32       copy it into directory with Gammu.exe and name gammurc
; More about parameters later
; Anything behind ; or # is comment.
; -----------------------------------------------------------------------------
[gammu]
device = com8:
connection = irdaphonet
; Do not use model configuration unless you really need it
;model = 6110
;synchronizetime = yes
;logfile = gammulog
;logformat = textall
;use_locking = yes
;gammuloc = locfile
;startinfo = yes
;gammucoding = utf8
;usephonedb = yes
[gammu1]
device = com8:
;model = 6110
connection = fbusblue
;synchronizetime = yes
;logfile = gammulog
;logformat = textall
;use_locking = yes
;gammuloc = locfile
;startinfo = yes
;gammucoding = utf8
; Step 1. Please find required Connection parameter and look into assigned
; with it device type. With some Connection you must set concrete model
; ================================================================ cables =====
; New Nokia protocol for FBUS/DAU9P
;    Connection "fbus", device type serial
; New Nokia protocol for DLR3/DLR3P
;    Connection "fbusdlr3"/"dlr3", device type serial
; New Nokia protocol for DKU2 (and phone with USB converter on phone mainboard
;                              like 6230)
;    Connection "dku2phonet"/"dku2", device type dku2 on Windows
;    Connection "fbususb" on Linux
; New Nokia protocol for DKU5 (and phone without USB converter on phone
;                              mainboard like 5100)
;    Connection "dku5fbus"/"dku5", device type dku5
; New Nokia protocol for PL2303 USB cable (and phone without USB converter
;                                          on phone mainboard like 5100)
;    Connection "fbuspl2303", device type usb
; Old Nokia protocol for MBUS/DAU9P
;    Connection "mbus", device type serial
; Variants:
; You can modify a bit behaviour of connection using additional flags
; specified just after connection name like connection-variant.
; If you're using ARK3116 cable (or any other which does not like dtr
; handling), you might need -nodtr variant of connection, eg. dlr3-nodtr.
; If cable you use is not powered over DTR/RTS, try using -nopower variant of
; connection, eg. fbus-nopower.
; -----------------------------------------------------------------------------
; AT commands for DLR3, DKU5 or other AT compatible cable (8 bits, None
; parity, no flow control, 1 stop bit). Used with Nokia, Alcatel, Siemens, etc.
;    Connection "at19200"/"at115200"/.., device type serial
; AT commands for DKU2 cable
;    Connection "dku2at", device type dku2
; ============================================================== infrared =====
; Nokia protocol for infrared with Nokia 6110/6130/6150
;    Connection "fbusirda"/"infrared", device type serial
; Nokia protocol for infrared with other Nokia models
;    Connection "irdaphonet"/"irda", device type irda
; -----------------------------------------------------------------------------
; AT commands for infrared. Used with Nokia, Alcatel, Siemens, etc.
;    Connection "irdaat", device type irda
; -----------------------------------------------------------------------------
; OBEX for infrared
;    Connection "irdaobex", device type irda.
; ============================================================= Bluetooth =====
; Nokia protocol with serial device set in BT stack (WidComm, other) from
; adequate service and Nokia 6210
;    Connection "fbusblue", device type serial
; Nokia protocol with serial device set in BT stack (WidComm, other) from
; adequate service and other Nokia models
;    Connection "phonetblue", device type serial
; -----------------------------------------------------------------------------
; Nokia protocol for Bluetooth stack with Nokia 6210
;    Connection "bluerffbus", device type BT
; Nokia protocol for Bluetooth stack with DCT4 Nokia models, which don't inform
; about services correctly (6310, 6310i with firmware lower than 5.50, 8910,..)
;    Connection "bluerfphonet", device type BT
; Nokia protocol for Bluetooth stack with other DCT4 Nokia models
;    Connection "bluephonet", device type BT
; -----------------------------------------------------------------------------
; AT commands for Bluetooth stack and 6210 / DCT4 Nokia models, which don't
; inform about BT services correctly (6310, 6310i with firmware lower
; than 5.50, 8910,..)
;    Connection "bluerfat", device type BT
; AT commands for Bluetooth stack with other phones (Siemens, other Nokia,etc.)
;    Connection "blueat", device type BT
; -----------------------------------------------------------------------------
; OBEX for Bluetooth stack with DCT4 Nokia models, which don't inform about
; BT services correctly (6310, 6310i with firmware lower than 5.50, 8910,...)
;    Connection "bluerfobex", device type BT
; OBEX for Bluetooth stack with other phones (Siemens, other Nokia, etc.)
;    Connection "blueobex", device type BT.
; -----------------------------------------------------------------------------
;    Connection "bluerfgnapbus", device type BT, model "gnap"
;    Connection "irdagnapbus", device type irda, model "gnap"
; Step2. According to device type from Step1 and used OS set Port parameter
; -----------------------------------------------------------------------------
; Port type | "Port" parameter in Windows/DOS | "Port" parameter in Linux/Unix
; ----------|---------------------------------|--------------------------------
; serial    | "com*:"                         | "/dev/ttyS*"
;           | (example "com1:")               | (example "/dev/ttyS1")
;           |                                 | or "/dev/tts/**" (with DevFS)
;           |                                 | virtual serial ports like
;           |                                 | "/dev/ircomm*" or "/dev/rfcomm*"
; ----------|---------------------------------|--------------------------------
; irda      | ignored (can be empty)          | ignored (can be empty)
; ----------|---------------------------------|--------------------------------
; BT        | Bluetooth device address (example "00:11:22:33:44:55").
;           | Optionally you can also include channel after slash
;           | (example "00:11:22:33:44:55/12"). Can be also empty.
; ----------|---------------------------------|--------------------------------
; dku2      | ignored (can be empty)          | /dev/ttyUSB* or /dev/ttyACM*
; ----------|---------------------------------|--------------------------------
; dku5      | ignored (can be empty)          | connection with it not possible
; ----------|---------------------------------|--------------------------------
; usb       | connection with it not possible | "/dev/ttyUSB*"
; Step3. Set other config parameters
; -----------------------------------------------------------------------------
; Parameter name  | Description
; ----------------|------------------------------------------------------------
; Model           | Should not be used unless you have a good reason to do so.
;                 | If Gammu doesn't recognize your phone model, put it here.
;                 | Example values: "6110", "6150", "6210", "8210"
; SynchronizeTime | if you want to set time from computer to phone during
;                 | starting connection. Do not rather use this option when
;                 | when to reset phone during connection (in some phones need
;                 | to set time again after restart)
; GammuLoc        | name of localisation file
; StartInfo       | this option allows one to set, that you want (setting "yes")
;                 | to see message on the phone screen or phone should enable
;                 | light for a moment during starting connection. Phone
;                 | WON'T beep during starting connection with this option.
; GammuCoding     | forces using specified codepage (in win32 - for example
;                 | "1250" will force CP1250) or UTF8 (in Linux - "utf8")
; ----------------|------------------------------------------------------------
; Logfile         | Use, when want to have logfile from communication.
; Logformat       | What debug info and format should be used:
;                 |   "nothing" - no debug level (default)
;                 |   "text"    - transmission dump in text format
;                 |   "textall" - all possible info in text format
;                 |   "errors"  - errors in text format
;                 |   "binary"  - transmission dump in binary format
; ----------------|------------------------------------------------------------
; Features        | Custom features for phone. This can be used as override
;                 | when values coded in common/gsmphones.c are bad or
;                 | missing. Consult include/gammu-info.h for possible values
;                 | (all Feature values without leading F_ prefix).
;                 | Please report correct values to Gammu authors.
; ----------------|------------------------------------------------------------
; Use_Locking     | under Unix/Linux use "yes", if want to lock used device
;                 | to prevent using it by other applications. In win32 ignored
; vim: et ts=4 sw=4 sts=4 tw=78 spell spelllang=en_us
```

## AUTHOR
Michal Čihař <michal@cihar.com>

## COPYRIGHT
2009-2015, Michal Čihař <michal@cihar.com>


gcli

package: gcli

title: gcli(5)

summary: gcli configuration file formats

text:
# gcli(5)

## NAME
gcli — gcli configuration file formats

## DESCRIPTION
gcli has two different configuration files. A user configuration file that contains default values for gcli and a repository-local configuration that contains sensible default values for a given repository. The latter is meant to be checked into the repository and provide these default values to other users as well.

### User Configuration File
The user configuration file is located in ${XDG_CONFIG_HOME}/gcli/config. On most systems this equal to ${HOME}/.config/gcli/config.

The user configuration file contains definitions for accounts as well as sensible default values for things like an editor.

The file is structured in sections, each section has a name and consists of a collection of key-value pairs. E.g.:

```
section-name {
	key1 = value 1
	key2 = value 2
}
```

There must be a section named “defaults” which may contain the following keys:

editor

Path to a default editor. This might be overridden by the environment variable EDITOR.

pager

Name of the default pager when interactively displaying large output. May be overridden by the environment variable PAGER. If none of the above are specified, less(1) is used as a sane default pager.

github-default-account

Section name of a default GitHub account to use whenever the account is unspecified on the command line or in the environment. See GCLI_ACCOUNT in gcli(1).

gitlab-default-account

Section name of a default GitLab account to use whenever the account is unspecified on the command line or in the environment. See GCLI_ACCOUNT in gcli(1).

gitea-default-account

Section name of a default Gitea account to use whenever the account is unspecified on the command line or in the environment. See GCLI_ACCOUNT in gcli(1).

disable-spinner

Disable the progress spinner in the ui. gcli uses this when making requests. This can also be set, and overridden with the GCLI_NOSPINNER environment variable.

url-open-program

Name of a program in the PATH to open URLs with. Defaults to xdg-open which uses your default web browser. Note that the program name may not contain any arguments. If you need to pass any arguments to the program you must write a wrapper script.

All other sections define accounts for forges. Each of these account definitions have the account name as their section name and may have one or more of the following keys defined:

forge-type

The type of the forge. May be one of:

- github

- gitlab

- gitea

- bugzilla

api-base

(optional) Used to override the API base URL of the forge. This is useful for self-hosted instances. Depending on the “forge-type” the default values are: forge-type

default value

github

https://api.github.com

gitlab

https://gitlab.com/api/v4

gitea

https://codeberg.org/api/v1

bugzilla

https://bugs.freebsd.org/bugzilla

account

(optional) The username used to authenticate at the API.

token

(optional) A generated application token to use with this account. The gcli tutorial at https://herrhotzenplotz.de/gcli/tutorial has some documentation on how to generate thes tokens.

### Repository Local Configuration File
For repository-local configuration you can use a special configuration file. It contains definitions for gcli that are specific to the repository.

The Repository-local configuration file is located in the root directory of the repository and should be named .gcli.

It contains a list of key-value pairs. Allowed keys are:

pr.base

Name of a branch that the changes should be merged into by default. Usually this is one of master, main or trunk.

pr.upstream

Name of the upstream repository to submit the pull request to by default. This is a pair of the format “owner/repository”.

pr.inhibit-delete-source-branch

If defined and set to “yes” this will prevent the pull request source branch to get deleted when merging a pull request by default.

forge-type

When hosting on multiple forges this can be set to a type that will be used as a default when other overrides are unspecified. For possible values see the equivalent definition in User Configuration File.

## EXAMPLES

### User Configuration File
An example for the user configuration file consisting of both a GitHub and a GitLab account:

```
defaults {
	editor=/path/to/ganoooo/emacs
	pager=less
	github-default-account=herrhotzenplotz-gh
	gitlab-default-account=herrhotzenplotz-gitlab
}

herrhotzenplotz-gh {
	account=herrhotzenplotz
	token=foobar
	api-base=https://api.github.com
	forge-type=github
}

herrhotzenplotz-gl {
	account=herrhotzenplotz
	token=<valid gitlab api token>
	api-base=https://gitlab.com/api/v4
	forge-type=gitlab
}
```

Notice that this allows you to run gcli and force it to use a specific GitLab account. E.g.:

```
$ gcli -a herrhotzenplotz-gl issues -a
```

### Repository-Local Configuration file
The .gcli file for the gcli project itself looks like this:

```
pr.upstream=herrhotzenplotz/gcli
pr.base=trunk
pr.inhibit-delete-source-branch=yes
```

## SEE ALSO
git(1), gcli(1), less(1), xdg-open(1)

## AUTHORS
Nico Sonack aka. herrhotzenplotz <nsonack@herrhotzenplotz.de> and contributors.

## BUGS
Please report bugs via E-Mail to https://lists.sr.ht/~herrhotzenplotz/gcli-discuss.

Alternatively you can report them on any of the forges linked at https://sr.ht/~herrhotzenplotz/gcli. However, the preferred and quickest method is to use the mailing list.


gear-changelog-rules

package: gear

title: gear-changelog-rules(5)

summary: rule file for gear\-changelog

text:
# gear-changelog-rules(5)

## NAME
gear-changelog-rules - rule file for gear-changelog

## DESCRIPTION
The rule file specifies actions of gear-changelog(1) required to filter and format got commit messages. There are two types of directives: global and sectional. Global directives should be defined before any sections.

## FORMAT
A rule file consists of lines of the following format:

directive: <value>

Empty lines and lines beginning with “#” are ignored. Directive arguments are delimited by whitespace characters.

## GLOBAL DIRECTIVES
width: <number>

Set width of changelog messages. Default is 70 symbols.

## SECTION DIRECTIVES
group: <TEXT>

This directive begins a new section. It should contain a description for this group. This description will be used as a group message in the changelog.

regexp: <PATTERN>

Specifies the <PATTERN> on which a commit message can be attributed to this group. You can specify more than one directive of this kind.

filter: <SED-COMMAND>

Specify commands for sed(1) utility to transform each commit message before it will be written into changelog. You can specify more than one directive of this kind.

## FILES
.gear/changelog

The gear-changelog(1) expect to find rules, unless another name is specified by the --rules=filename option.

## EXAMPLES

```
[localhost]$ cat .gear/changelog <<EOF
group: gear-changelog utility changes
regexp: ^gear-changelog(-rules.5.in)?:
filter: s/^gear-changelog: //
filter: s/^gear-changelog-rules.5.in: /Documentation: /
group: gear-merge utility changes
regexp: ^gear-merge:
filter: s/^gear-merge: //
EOF
[localhost]$ gear-changelog
* Wed Jun 18 2008 Alexey Gladkov <legion@altlinux.org> 1.4.0-alt1
- gear-changelog utility changes:

  + Replace /bin/ash with /bin/sh.

  + Documentation: Fix typo.

  + Read first commit too.

  + Fix typo.
- gear-merge utility changes:

  + Fix spacing in help message.

  + Update copyrights.

  + More choices in interactive merge mode (thx Alexey I. Froloff).

  + Document --no-interactive option (thx Alexey I. Froloff).

  + Implement --stop option (thx Alexey I. Froloff).
```

## AUTHOR
This manual page written by Alexey Gladkov <legion@altlinux.org>.

Authors and contributors of the programs included in the gear package are listed in the manual pages for these programs.

## SEE ALSO
gear-changelog(1).


gear-import-rules

title: gear-import-rules(5)

summary: rule file for gear\-import

text:
# gear-import-rules(5)

## NAME
gear-import-rules - rule file for gear-import

## DESCRIPTION
The rule file specifies parser patterns for gear-import(1) required to parse archive filename.

## FORMAT
A rule file consists of lines of the following format:

directive: <value>

Empty lines and lines beginning with “#” are ignored.

## DIRECTIVES
pattern: <REGEXP>

Extended posix regexp that applies to archive filename (without path). If pattern matches, name and version are generated using regexp back-reference.

name: \<DIGIT>

Matches the DIGIT-th parenthesized subexpression that match name.

version: \<DIGIT>

Matches the DIGIT-th parenthesized subexpression that match version.

case-sense: yes

Makes `sed' match REGEXP in a case-sensitive manner.

replace-name: <sed-expression>

replace-version: <sed-expression>

Finally, if replace-name or replace-version directives defined, it applied to generated name of version as sed expression.

## EXAMPLES

```
pattern: ^([0-9_-]+[-_])?([a-z0-9.-]+)_([0-9][a-z0-9.-]+)$
name: \2
version: \3
replace-name: s/(-(bin|src)){0,}$//
replace-version: s/([-_](bin|src)){0,}$//
```

## AUTHOR
This manual page written by Alexey Gladkov <legion@altlinux.org>.

Authors and contributors of the programs included in the gear package are listed in the manual pages for these programs.

## SEE ALSO
gear-import(1).


gear-merge-rules

title: gear-merge-rules(5)

summary: rule file for gear\-merge

text:
# gear-merge-rules(5)

## NAME
gear-merge-rules - rule file for gear-merge

## DESCRIPTION
The rule file specifies actions of gear-merge(1) required to merge branches in the package repository.

## FORMAT
A rule file consists of lines of the following format:

directive: <from-branch> <to-branch> [arguments ...]

Empty lines and lines beginning with “#” are ignored. Directive arguments are delimited by whitespace characters.

## COMMON ARGUMENTS
squash

It is the same as git merge --squash. See git-merge(1).

strategy=<STRATEGY>

It is the same as git merge --strategy=<STRATEGY>.

## DIRECTIVES
merge: <from-branch> <to-branch> [options ...]

Call git-merge to merge the retrieved <from-branch> into the <to-branch> branch.

Valid options are:

message=<MESSAGE>

The commit message to be used for the merge commit.

gendiff: <from-branch> <to-branch> name=<FILENAME> [options ...]

Valid options are:

name=<FILENAME>

Write result to file <FILENAME>.

message=<MESSAGE>

The comment is added in the beginning of a diff.

unified=<N>

Generate diffs with <n> lines of context instead of the usual three. See git-diff(1).

## FILES
.gear/merge

The gear-merge(1) expect to find rules, unless another name is specified by the --rules=filename option.

## AUTHOR
This manual page written by Alexey Gladkov <legion@altlinux.org>.

Authors and contributors of the programs included in the gear package are listed in the manual pages for these programs.

## SEE ALSO
gear-merge(1).


gear-rules

title: gear-rules(5)

summary: rule file for gear

text:
# gear-rules(5)

## NAME
gear-rules - rule file for gear

## DESCRIPTION
The rule file specifies actions of gear(1) required to extract source files from the package repository.

## FORMAT
A rule file consists of 0 or more lines of the following format:

directive: arguments...

Empty lines and lines beginning with “#” are ignored. Directive arguments are delimited by whitespace characters. Whitespaces between the directive name and “:” are optional; whitespaces between “:” and the first argument are also optional. Arguments may contain special characters quoted using shell-alike quoting. There is no support for line continuation.

## PATHS
Unless specified otherwise, all paths used in the rule file are relative to the main tree, which is a subtree of the main commit specified by the -t option to gear(1). Paths are not allowed to contain “..”, and therefore can refer only to objects inside the main tree.

However, some directives can accept a tree_path, which can be either a plain path relative to the main tree, or a path with an explicit base tree specification:

base_tree:path_in_tree

The base_tree part can be in one of the following forms:

–

A single period character “.” specifies the main tree. In most cases just omitting the “base_tree:” part gives the same effect; adding “.:” explicitly is required only if the path_in_tree part itself contains the “:” character.

–

A full SHA-1 object name of a commit (40 hex characters) specifies the root tree of that commit. The specified commit must be an ancestor of the main commit.

–

A name of a tag listed in the tag list specifies the root tree of the commit pointed to by the specified tag (directly or indirectly through a chain of tag objects). The specified commit must be an ancestor of the main commit, and all tag objects in the chain must be stored in the tag directory.

The restrictions on references to other commits ensure that a correct git repository which contains the main commit also contains everything which is required to extract source files from the repository.

## KEYWORDS
Arguments of some directives can contain keywords in the @keyword@ format, which are replaced by real values before use. Values for keywords can be obtained from the main spec file or from other arguments of the same directive.

The following keywords are available in all directives which perform keyword replacement:

@name@

Package name extracted from spec file.

@version@

Package version extracted from spec file.

@release@

Package release extracted from spec file.

Other keywords are specific to each directive.

## DIRECTIVES
spec: path_to_file

Specify path of the main spec file within the main tree. This directive may be omitted if the main spec file is the only file in the main tree which matches the *.spec glob pattern; in this case gear(1) can find the spec file automatically.

tags: path_to_directory

Specify another path of the directory with the list of named tags and stored tag objects instead of .gear-tags and .gear/tags.

type: spec_type

Specify the type of the spec file instead of an unspecified default. This information is saved in the volume header of the output tar archive produced by gear(1).

copy: glob_pattern...

Copy files matching the specified glob patterns to the output directory, except files which match any of glob patterns specified by exclude directives. Every glob_pattern must match at least one file in the main tree.

Glob patterns specified in this directive may contain multiple directory components separated by “/”. Wildcards are interpreted only in the last component of the pattern.

gzip: glob_pattern...

bzip2: glob_pattern...

lzma: glob_pattern...

xz: glob_pattern...

zstd: glob_pattern...

Like copy, but additionally compress the copied files with gzip(1), bzip2(1), lzma(1), xz(1), or zstd(1), and add the appropriate suffix to the copied file name.

compress: type=TYPE [name=NAME] [options] -- glob_pattern...

Like copy, but can additionally compress the copied files with TYPE method.

type=TYPE

Specify compression method. Supported values are: copy, bzip2, gzip, lzma, xz, and zstd.

name=<NAME>

Specify destination file name in output directory. In this case glob_pattern should match only one file.

All methods except copy accept compress options.

copy?: glob_pattern...

gzip?: glob_pattern...

bzip2?: glob_pattern...

lzma?: glob_pattern...

xz?: glob_pattern...

zstd?: glob_pattern...

compress?: type=TYPE [name=NAME] [options] -- glob_pattern...

Like the corresponding directives without “?”, but unmatched patterns are ignored instead of causing errors.

exclude: glob_pattern...

Ignore files matching the specified glob patterns in all copy-like directives. Affects all directives in the rule file irrespective of the order. Specifying a glob pattern which does not match any files in the tree is not an error.

When copying files from subdirectories of the main tree, the whole path including the subdirectory name is matched against exclude patterns. The “/” characters in the path are not treated as special and can be matched by wildcards.

tar: tree_path [options...]

Create a tar(1) archive of the tree specified by tree_path. The specified tree must exist.

Valid options are:

spec=path_to_file

Use another file instead of the main spec file to define keyword values.

name=archive_name

Set name of the tar archive. The .tar suffix is added automatically unless another suffix is specified by the suffix option.

The default value of this option is @dir@-@version@, unless the path part of tree_path is “.”, in which case the default is @name@-@version@.

base=base_name

Add base_name as a leading path to all files in the generated archive. If this option is not specified, by default the archive name without the suffix (set by the name option) is used.

suffix=suffix

Add suffix to the archive file name instead of the default .tar suffix.

exclude=glob_pattern

All files matching the glob_pattern are excluded from the generated tar file. This option can be specified multiple times. The glob_pattern syntax is described in glob section of /usr/share/doc/git/user-manual.html.

Values of the name and base options and tree_path can contain keywords. In addition to the common keywords, the following keyword is supported:

@dir@

Expands to basename(path(tree_path)). Not allowed when path(tree_path) is “.” and must not be used in the path part of tree_path.

tar.gz: tree_path [options...]

tar.bz2: tree_path [options...]

tar.lzma: tree_path [options...]

tar.xz: tree_path [options...]

tar.zst: tree_path [options...]

Like tar, but additionally compress the generated tar archive with gzip(1), bzip2(1), lzma(1), xz(1), or zstd(1), and add the appropriate suffix to the archive file name (unless the suffix option is specified, which overrides both the .tar part and the suffix for the compression method).

zip: tree_path [options...]

Like tar, but create a zip(1) archive instead of tar(1) and add the .zip suffix to the archive file name instead of .tar.

tar?: tree_path [options...]

tar.gz?: tree_path [options...]

tar.bz2?: tree_path [options...]

tar.lzma?: tree_path [options...]

tar.xz?: tree_path [options...]

tar.zst?: tree_path [options...]

zip?: tree_path [options...]

Like the corresponding directives without “?”, but do not fail if the path specified in tree_path is not present in the tree. However, if tree_path specifies a non-default base tree, this tree still must be valid.

diff: old_tree_path new_tree_path [options...]

Create a diff in the unified format between trees specified by old_tree_path and new_tree_path. Both trees must exist.

Valid options are:

spec=path_to_file

Use another file instead of the main spec file to define keyword values.

name=diff_name

Set name of the generated diff file. The .patch suffix must be specified explicitly if required.

The default name is @new_dir@-@version@-@release@.patch, unless the path part of new_tree_path is “.”, in which case the default is @name@-@version@-@release@.patch.

exclude=glob_pattern

All files matching the glob_pattern are excluded from the generated tar file. This option can be specified multiple times. The glob_pattern syntax is described in glob section of /usr/share/doc/git/user-manual.html.

Value of the name option and the base tree components of old_tree_path and new_tree_path can contain keywords. In addition to the common keywords, the following keywords are supported:

@old_dir@

Expands to basename(path(old_tree_path)). Not allowed when path(old_tree_path) is “.”.

@new_dir@

Expands to basename(path(new_tree_path)). Not allowed when path(new_tree_path) is “.”.

diff.gz: old_tree_path new_tree_path [options...]

diff.bz2: old_tree_path new_tree_path [options...]

diff.lzma: old_tree_path new_tree_path [options...]

diff.xz: old_tree_path new_tree_path [options...]

diff.zst: old_tree_path new_tree_path [options...]

Like diff, but additionally compress the generated diff file with gzip(1), bzip2(1), lzma(1), xz(1), or zstd(1), and add the appropriate suffix to the diff file name.

diff?: old_tree_path new_tree_path [options...]

diff.gz?: old_tree_path new_tree_path [options...]

diff.bz2?: old_tree_path new_tree_path [options...]

diff.lzma?: old_tree_path new_tree_path [options...]

diff.xz?: old_tree_path new_tree_path [options...]

diff.zst?: old_tree_path new_tree_path [options...]

Like the corresponding directives without “?”, but do not fail if paths specified by old_tree_path or new_tree_path are not present in the tree. However, if old_tree_path or new_tree_path specify non-default base trees, these trees still must be valid.

specsubst: variables...

Specify whitespace-separated list of variables that should be substituted in specfile. Variable names may contain letters, digits and underscore characters. For each variable every occurrence of @variable@ in specfile is substituted with its value. Values for these variables are obtained from the tag object passed to gear(1), therefore a tag object is required when specsubst: directive is used.

## SPECSUBST TAG FORMAT
A tag object may contain definitions for variables to be substituted during specsubst: directive processing. These definitions have the following format:

X-gear-specsubst: variable=value

Values are treated literally, there is no support of quoting or line continuation.

## EXAMPLES

### Archive with modified sources
A simple rule file can contain just a single tar directive to archive everything in the tree:

```
tar: .
```

If the project has a separate upstream, adding @release@ to the archive name is recommended to make the name different from upstream:

```
tar: . name=@name@-@version@-@release@
```

### Archive with unmodified sources and patch with local modifications
If you prefer to create a tar archive with unmodified upstream sources and a separate patch with local modifications, you need to create a tag for the commit with upstream sources (or use the upstream tag if upstream also uses git), specify the tag name in the rule file and store this tag in the repository using gear-store-tags(1). In this case the default archive name used by the tar directive should be correct, unless the package name or version format is different from upstream.

Usually the tag name can be based on the package version:

```
tar: v@version@:.
diff: v@version@:. .
```

(other tag naming conventions may be used, like @name@-@version@ or plain @version@). However, if a prerelease version is packaged, parts like “preN” or “rcN” should not be included in the package version, therefore the rule file will need some modifications for such versions.

You may want to exclude .gear subdirectory and spec file from diff generation:

```
tar: v@version@:.
diff: v@version@:. . exclude=.gear/** exclude=*.spec
```

### Archive with unmodified sources and separate patch files
If you prefer to maintain patch files for local modifications instead of committing modified source files to the git repository, you can store unmodified upstream sources in a subdirectory of the main tree and put patch files directly into the main tree:

```
tar: package_name
copy: *.patch
```

This layout is used by gear-srpmimport(1). The gear-update(1) utility can be used to update sources stored in the git repository to a new upstream release.

If you don't like lots of patch files cluttering the main tree, you can move them into a subdirectory:

```
tar: package_name
copy: patches/*.patch
```

## FILES
.gear-rules, .gear/rules

The list of file names where gear(1), gear-commit(1), gear-create-tag(1), gear-srpmimport(1) and gear-store-tags(1) expect to find rules (first non-empty file from this list is used), unless another name is specified by the --rules=filename option.

## AUTHOR
This manual page written by Sergey Vlasov <vsu@altlinux.org>.

Authors and contributors of the programs included in the gear package are listed in the manual pages for these programs.

## SEE ALSO
gear(1), gear-srpmimport(1), gear-update(1), gear-store-tags(1).


genisoimagerc

package: genisoimage

title: genisoimagerc(5)

text:
# genisoimagerc(5)

## NAME
genisoimagerc - startup configuration file for genisoimage

## DESCRIPTION
genisoimage(1) searches for a configuration file in several places; it uses the first one it is able to open. First, if the GENISOIMAGERC environment variable is set, its value is used as the filename; likewise for the MKISOFSRC environment variable. Next, genisoimage looks for files named .genisoimagerc or .mkisofsrc, first in the current working directory, then in the user's home directory. Next, it looks for /etc/genisoimagerc. Finally, it looks for a .genisoimagerc in the same directory as genisoimage itself is stored.

The .genisoimagerc file contains lines of the form

TAG=value

where TAG is one of the settings defined below. The case of the tag is not significant. All settings have command-line equivalents; if the command-line parameter is specified, it takes priority over the configuration file.

Blank lines and lines beginning with `#' are ignored.

## CONFIGURATION SETTINGS
ABST

The abstract information, typically the name of a file on the disc containing an abstract. There is space for 37 characters. Equivalent to the -abstract command-line option.

APPI

The application identifier should describe the application that will be on the disc. There is space for 128 characters. Equivalent to the -A command-line option.

BIBL

The bibliographic information, often the name of a file on the disc containing a bibliography. There is space for 37 characters. Equivalent to the -biblio command-line option.

COPY

The copyright information, typically the name of a file on the disc containing the copyright notice. There is space for 37 characters. Equivalent to the -copyright command-line option.

HFS_TYPE

The default TYPE for Macintosh files. Must be exactly 4 characters. Equivalent to the -hfs-type command-line option. The default value is TEXT.

HFS_CREATOR

The default CREATOR for Macintosh files. Must be exactly 4 characters. Equivalent to the -hfs-creator command-line option. The default value is Unix.

PREP

This should describe the preparer of the CD-ROM, usually with a mailing address and phone number. There is space for 128 characters. Equivalent to the -p command-line option.

PUBL

This should describe the publisher of the CD-ROM, usually with a mailing address and phone number. There is space for 128 characters. Equivalent to the -publisher command-line option.

SYSI

The System Identifier. There is space for 32 characters. Equivalent to the -sysid command-line option.

VOLI

The Volume Identifier. There is space for 32 characters. Equivalent to the -V command-line option.

VOLS

The Volume Set Name. There is space for 128 characters. Equivalent to the -volset command-line option.

genisoimage can also be configured at compile time with defaults for many of these fields. See the file defaults.h.

## EXAMPLES
The following file

```
COPY=src/COPYING
SYSI=Multics 75
```

is equivalent to the genisoimage command-line parameters

-copyright src/COPYING -sysid "Multics 75"

## SEE ALSO
genisoimage(1).

## AUTHORS
See the genisoimage(1) manual page for credits for the genisoimage program and documentation.


geoclue

title: geoclue(5)

text:
# geoclue(5)

## NAME
geoclue.conf - geoclue configuration parameters

## SYNOPSIS
Main configuration file: /etc/geoclue/geoclue.conf

Overwriting parameters files: /etc/geoclue/conf.d

## DESCRIPTION

The main GeoClue configuration file 'geoclue.conf' specifies parameters that control the operation of geoclue. Parameters can be overwritten by placing configuration files in conf.d directory and applied in alphabetic order. Thus, a configuration file '90-config.conf' will overwrite parameters specified in another configuration file '50-config.conf' in the conf.d directory.

All configurations settings below are mandatory and the defaults are what you see before you edit them in geoclue.conf. If you want to keep the default values around, copy and comment out the appropriate line(s) before changing them.

Missing 'enable' key for a particular source in the main configuration file causes that source to be enabled by default. Adding 'enable' key setting to any further config file can overwrite this default.

## AGENT CONFIGURATION OPTIONS
[agent] is used to begin the agent configuration.

whitelist

Whitelist of desktop IDs (without .desktop part) of all agents we recognise, separated by a ';'.

whitelist=geoclue-demo-agent;gnome-shell;io.elementary.desktop.agent-geoclue2

[network-nmea]

Network NMEA source configuration options

enable=true

Fetch location from NMEA sources on local network?

nmea-socket=/var/run/gps-share.sock

Use a nmea unix socket as the data source. If not set, unix socket will not be used.

[3g]

3G source configuration options

enable=true

Enable 3G source

[cdma]

CDMA source configuration options

enable=true

Enable CDMA source

[modem-gps]

Modem GPS source configuration options

enable=true

Enable Modem-GPS source

[wifi]

WiFi source configuration options

enable=true

Enable WiFi source

url=https://location.services.mozilla.com/v1/geolocate?key=YOUR_KEY

URL to the WiFi geolocation service. If not set, defaults to Mozilla's Location Service with a hardcoded key. To use a custom key, uncomment this URL while changing YOUR_KEY to your MLS API key.

submit-data=false Submit data to Mozilla Location Service

If set to true, geoclue will automatically submit network data to Mozilla each time it gets a GPS lock.

submission-url=https://location.services.mozilla.com/v2/geosubmit?key=YOUR_KEY

URL to submission API of Mozilla Location Service

submission-nick=geoclue

A nickname to submit network data with. If empty, omitted from the submission. Otherwise, must be 2 to 32 characters long. Defaults to "geoclue".

[compass]

Compass configuration options

enable=true

Enable Compass

[static-source]

Static source configuration options.

This source reads location from "geolocation" file in /etc. While this file is constantly monitored for changes during geoclue operation, and the reported static location is updated accordingly, this source isn't meant for inputting a dynamically changing location to geoclue (please use the Network NMEA source for that).

enable=true

Enable the static source.

If you make use of this source, you probably should disable other location sources in geoclue.conf so they won't override the configured static location.

## APPLICATION CONFIGURATION OPTIONS
Having an entry here for an application with allowed=true means that geoclue will not ask agent to authorize the application. This is to ensure that applications with built-in authorization mechanism (e.g web browsers) do not have to be bound to agents.

If your application is denied access to location information and your operating system doesn't provide any mechanism to change that, it is likely a bug in your operation system (or geoclue). The solution is to report the issue with all details, rather than adding your application to this list.

Format:

[random-app]

Desktop ID of application without .desktop part allowed=true|false

Allowed access to location information?

system=true|false

Is application a system component?

users=

List of UIDs of all users for which this application is allowed location info access, separate by ';'. Keep it empty for allowing it for all users.

Examples:

[gnome-datetime-panel]

allowed=true

system=true

users= [gnome-color-panel]

allowed=true

system=true

users=

[org.gnome.Shell]

allowed=true

system=true

users=

[io.elementary.desktop.agent-geoclue2]

allowed=true

system=true

users=

[epiphany]

allowed=true

system=false

users=

[firefox]

allowed=true

system=false

users=

## STATIC LOCATION FILE

### Basic format:
The static location file in /etc (used by the static source) is a text file consisting of the following:

1

Latitude (floating point number; positive values mean north, negative south)

2

Longitude (floating point number; positive values mean east, negative west)

3

Altitude (floating point number; in meters)

4

Accuracy radius (floating point number; in meters)

These values need to be separated by newline characters.

### Additional format information:
•

The '#' character starts a comment, which continues until the end of the current line.

•

Leading and trailing white-space on each line is ignored.

•

Empty lines (or containing just white-space or a comment) are ignored.

### Example:

```
# Example static location file for a machine inside Statue of Liberty torch
40.6893129   # latitude
-74.0445531  # longitude
96           # altitude
1.83         # accuracy radius (the diameter of the torch is 12 feet)
```

### Notes:
For extra security, the static location file can be made readable just by the geoclue user:

```
# chown geoclue /etc/geolocation
# chmod 600 /etc/geolocation
```

## CLIENT LIST
Sending SIGUSR1 to a running geoclue process prints the current list of clients to the log.

## AUTHOR

```
Sachin Chand
```


discgrp

package: geomview

title: discgrp(5gv)

text:
# discgrp(5gv)

## NAME
discrete group file formats

## SYNOPSIS
An ascii file representation of a discrete geometric group.

## SUMMARY
This file format applies to a wide variety of groups encountered in topology and geometry. At the beginning of the file is the string DISCGRP, in conformity with other OOGL file formats (see oogl(5)). The remainder of the file is a series of parenthesized expressions.

The file format is based on an expandable set of key markers and values. A typical entry would be

```
(group  borromean )
```

where parentheses enclose the expression. The string 'group' is called the key marker. The remaining text contains a value, in this case a character string which is the name of the group. Key markers currently recognized and their values include:

```
group 	A name for this group.
comment An arbitrary comment [maximum length 256 bytes]
	 [must be enclosed in double quotes]
attribute One of a several keyword identifiers including:

        euclidean       is a euclidean group
	hyperbolic      is a hyperbolic group
	spherical       is a spherical group
	transposed      the matrices are transposed
	finite          this is a finite group
model	In the case that 'hyperbolic' is an attribute, and the dimension is
three, this keyword sets the model that is
expected for reading subsequent isometries, i.e., expects elements of
SL(2,C) if the model is upperhalfspace or conformalball and O(3,1,R) if it is
projective.
	projective	default
	upperhalfspace
	conformalball	[not currently implemented]
display These values set characteristics of the the display of the discrete
group.
	centercam	keeps the camera centered in central dirichlet domain.
	zcull		removes tiles which lie behind the camera.
	showcam		if centercam is set, displays camgeom, if provided (see below).
dimn    The dimension of the space.
ngens   Number of generators.
gens    List of generators.
nels    Number of group elements.
els     List of group elements.
wafile	Word acceptor file (in DEAGL format version 2.2)
camgeom An OOGL-format geometry description to represent the observer.
geom	An OOGL-format geometry description. Will replace the default Dirichlet domain computation.
```

String-matching of key markers and attribute values is case-insensitive.

Currently all matrices must be 4x4 real matrices. Hence the only valid dimensions are 2,3, or 4. The typical case is dimension 3 where there are projective models for hyperbolic, euclidean, and spherical geometry. Dimension 2 groups should leave the z-coordinate unchanged.

Matrices are considered transposed if they are considered to act on column vectors as in: M.v = v'. This is the usual mathematical convention convention. So, if you use this convention you must mark your matrices as being transposed.

Group elements are specified by an optional character string followed by a list of 16 real numbers. For the case of generators, the character string represents the name of that generator. Its main use is with the automatic group software: the name used here should match that of the generator in the word acceptor file. It should, for example, be a single character for the software to work reliably. For composite elements, the string is the word in the generators which describes this group element.

OOGL libraries expect discrete group files to use the '.dgp' suffix.

A file which describes the group of the three dimensional torus follows:

```
DISCGRP
(group 3torus )
(comment "  This is a test of the new discrete group library.  " )
(attribute Euclidean )
(display centercam )
(enumdepth 3 )		# look at all words of length 3 or less in generators
(enumdist 10.0 )	# and which don't move the origin more than 10.0
(dimn 3 )
(ngens 3 )
(gens
a

             1             0             0             0

             0             1             0             0

             0             0             1             0

             1             0          -0.1             1
b

             1             0             0             0

             0             1             0             0

             0             0             1             0

           0.1             1             0             1
c

             1             0             0             0

             0             1             0             0

             0             0             1             0

             0           0.2             1             1
)
(cpoint 0.000000 0.000000 0.000000 1.000000 )
(camgeom
{ = OFF
5 2 5
0 0 0
-0.1 0 0.5
0.1 0 0.5
0 -0.1 0.5
0 0.1 0.5
3	 0 1 2	200 200 0 .8
3	 0 3 4	0 200 200 .8
}
)
```

## FILES
Example group files are to be found in the OOGL release in ${GEOM}/data/groups, where e.g., GEOM = /u/gcg/ngrap. See also discgrp(3) and automata(1).

## AUTHORS
Charlie Gunn.

## BUGS
For dimension 2, the code should read and write 3 x 3 matrices.