https://wiki.archlinux.org/api.php?action=feedcontributions&user=Rnabioullin&feedformat=atomArchWiki - User contributions [en]2024-03-29T10:28:07ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=List_of_applications/Other&diff=210986List of applications/Other2012-06-23T03:10:32Z<p>Rnabioullin: /* Others */ added finance section</p>
<hr />
<div><noinclude><br />
[[Category:Applications]]<br />
[[it:Common Applications/Other]]<br />
[[zh-CN:Common Applications/Other]]<br />
{{Common Applications navigation}}<br />
</noinclude><br />
== Others ==<br />
=== Note Taking Organizers ===<br />
{{Merge|Common Applications#Time Management}}<br />
<br />
==== Console ====<br />
* {{App|hnb|A program to organize many kinds of data in one place|http://hnb.sourceforge.net/|{{AUR|hnb}}}}<br />
* {{App|todo.txt|Manages your Todo list from the command line|http://ginatrapani.github.com/todo.txt-cli/|{{AUR|todotxt}}}}<br />
* {{App|[[Wikipedia:Taskwarrior|Taskwarrior]]|Another cli todo list application with support for lua customization and more|http://taskwarrior.org/|{{Pkg|task}}}}<br />
* {{App|doneyet|Doneyet is an ncurses based hierarchical todo list manager written in C++|https://code.google.com/p/doneyet/|{{AUR|doneyet}}}}<br />
* {{App|tudu|ncurses-based hierarchical todo list manager with vim-like keybindings|http://code.meskio.net/tudu/|{{AUR|tudu}}}}<br />
<br />
==== Graphical ====<br />
* {{App|Cherrytree|A hierarchical note taking application|http://giuspen.com/cherrytree/|{{Pkg|cherrytree}}}}<br />
* {{App|Glista|Simple GTK+ to-do list manager with notes support|http://prematureoptimization.org/glista/|{{AUR|glista}}}}<br />
* {{App|[[Wikipedia:Gnote|Gnote]]|Gnote is an experimental port of Tomboy to C++|http://live.gnome.org/Gnote|{{Pkg|gnote}}}}<br />
* {{App|KeepNote|A cross-platform GTK note-taking app with rich text formatting|http://keepnote.org|{{Pkg|keepnote}}}}<br />
* {{App|[[Wikipedia:Tomboy (software)|Tomboy]]|desktop note-taking application for Linux and Unix|http://projects.gnome.org/tomboy/|{{Pkg|tomboy}}}}<br />
* {{App|[[Wikipedia:org-mode|org-mode]]|An [[Emacs]] Mode for Notes, Project Planning, and Authoring|http://orgmode.org|{{AUR|emacs-org-mode}}}}<br />
* {{App|[[zim]]|WYSIWYG text editor that aims at bringing the concept of a wiki to the desktop|http://zim-wiki.org/|{{Pkg|zim}}}}<br />
* {{App|NoteCase|portable hierarchical note manager, coded in C++ using the GTK+ toolkit|http://notecase.sourceforge.net|{{AUR|notecase}}}}<br />
<br />
=== Time Management ===<br />
==== Console ====<br />
* {{App|Calcurse|A text-based curses calendar and scheduling system|http://calcurse.org/|{{Pkg|calcurse}}}}<br />
* {{App|Pal|A very lightweight calendar with both interactive and non-interactive interfaces|http://palcal.sourceforge.net/|{{AUR|pal}}}}<br />
* {{App|Remind|A highly sophisticated text-based calendaring and notification system|http://roaringpenguin.com/products/remind|{{Pkg|remind}}}}<br />
* {{App|When|simple personal calendar program|http://lightandmatter.com/when/when.html|{{Pkg|when}}}}<br />
* {{App|Wyrd|curses front-end to Remind|http://pessimization.com/software/wyrd/|{{Pkg|wyrd}}}}<br />
<br />
==== Graphical ====<br />
* {{App|etm|Event and Task Manager. A "Getting Things Done" approach handling events, tasks, activities, reminders and projects|http://duke.edu/~dgraham/ETM/|{{AUR|etm}}}}<br />
* {{App|korganizer|A KDE-based calendar and scheduling program |http://www.kde.org/applications/office/korganizer/|{{Pkg|kdepim-korganizer}}}}<br />
* {{App|wxRemind|A Python text and graphical frontend to Remind|http://duke.edu/~dgraham/wxRemind/|{{AUR|wxremind}}}}<br />
* {{App|Lightning|Mozilla Thunderbird calendar and task extenstion|http://www.mozilla.org/projects/calendar/lightning/|{{AUR|lightning}}}}<br />
* {{App|taskcoach|simple open source todo manager to manage personal tasks and todo lists|http://taskcoach.org|{{AUR|taskcoach}}}}<br />
* {{App|Orage|GTK+ calendar and task manager often seen integrated with Xfce|http://www.xfce.org/projects|{{Pkg|orage}}}}<br />
* {{App|Osmo|GTK+ personal organizer, which includes calendar, tasks manager and address book modules|http://clayo.org/osmo/|{{Pkg|osmo}}}}<br />
* {{App|Rachota|portable time tracker for personal projects|http://rachota.sourceforge.net/|{{AUR|rachota}}}}<br />
* {{App|tasks|simple to do list application that uses libecal|http://pimlico-project.org/tasks.html|{{Pkg|tasks}}}}<br />
* {{App|tkremind|A sophisticated calendar and alarm program.|http://www.roaringpenguin.com/products/remind|{{Pkg|remind}}}}<br />
<br />
=== Translation and Localisation ===<br />
* {{App|[[Wikipedia:Lokalize|Lokalize]]|standard [[KDE]] tool for software translation|http://userbase.kde.org/Lokalize|{{Pkg|kdesdk-lokalize}}}}<br />
<br />
* {{App|[[Wikipedia:Virtaal|Virtaal]]|editor for translation of both software and other text, based on Translate Toolkit.<br />
:* Supported formats: Gettext (.po and .mo), XLIFF (.xlf), TMX, TBX, WordFast TM (.txt), Qt Linguist (.ts), Qt Phrase Book (.qph), OmegaT glossary (.tab and .utf8), ...<br />
:* Shows suggestions from Apertium, Google Translate, Microsoft Translator, Moses, http://open-tran.eu, Translation Memories or TM servers<br />
|http://translate.sourceforge.net/wiki/virtaal|{{AUR|virtaal}}}}<br />
<br />
* {{App|[[Wikipedia:Poedit|Poedit]]|simple Gettext/po-file translation tool|http://poedit.net|{{Pkg|poedit}}}}<br />
<br />
* {{App|[[Wikipedia:Moses (machine translation)|Moses]]|statistical machine translation tool (language data not included)|http://statmt.org/moses|{{AUR?|Moses}}}}<br />
<br />
* {{App|[[Wikipedia:OmegaT|OmegaT]]|"the translation memory tool", a general translators tool which contains a lot of translation memory features<br />
:* Supported formats: html, MS Office 2007 XML, OpenDocument format, XLIFF/Okapi, MediaWiki, plain text, TMX, ...<br />
:* Shows suggestions from Google Translate<br />
|http://omegat.org|{{AUR|omegat}}}}<br />
<br />
* {{App|[[Wikipedia:Apertium|Apertium]]|free and open source rule-based machine translation platform. All released language data is available<br />
:* Supported formats: html, MS Office 2007 XML, OpenDocument format, TMX, some MediaWiki support, ... (use Pology or Virtaal for po-files)<br />
:* See [http://wiki.apertium.org the wiki] for supported languages<br />
|http://apertium.org/|{{AUR|apertium}}}}<br />
<br />
* {{App|pology|set of Python tools for dealing with Gettext/po-files. See the [http://techbase.kde.org/Localization/Tools/Pology#About home page] for simple installation instructions.<br />
:* May be used to translate po-files with Apertium, see http://wiki.apertium.org/wiki/Translating_gettext for instructions.<br />
|http://techbase.kde.org/Localization/Tools/Pology|{{AUR|pology}}}}<br />
<br />
=== Work environment ===<br />
Default installation of Arch does not contain any Desktop Environment and therefore forces users to choose one themselves. Most Arch boxes run some X11 Window Manager and/or Desktop Environment but precedents of doing everyday tasks in bare console are also present (proofs?).<br />
<br />
==== Desktop environments ====<br />
{{Wikipedia|Comparison of X Window System desktop environments}}<br />
<br />
{{Box||See the main article: [[Desktop Environment#List of desktop environments]]|#E5E5FF|#FCFCFC}}<br />
<br />
==== Window managers ====<br />
===== Console =====<br />
* {{App|dvtm|performs [[dwm]]-style window management in console|http://brain-dump.org/projects/dvtm/|{{Pkg|dvtm}}}}<br />
<br />
===== Graphical =====<br />
{{Wikipedia|Comparison of X window managers}}<br />
<br />
{{Box||See the main article: [[Window Manager#List of window managers]]|#E5E5FF|#FCFCFC}}<br />
<br />
==== Support applications ====<br />
===== Login managers =====<br />
<br />
{{Box||See the main article: [[Display Manager#List of display managers]]|#E5E5FF|#FCFCFC}}<br />
<br />
===== Terminal multiplexers etc =====<br />
* {{App|[[screen]]|Full-screen window manager that multiplexes a physical terminal|https://gnu.org/s/screen/|{{Pkg|screen}}}}<br />
* {{App|[[Wikipedia:Tmux|Tmux]]|BSD-licensed terminal multiplexer|http://tmux.sourceforge.net/|{{Pkg|tmux}}}}<br />
* {{App|dtach|program that emulates the detach feature of [[screen]]|http://dtach.sourceforge.net/|{{Pkg|dtach}}}}<br />
<br />
=== System Monitoring ===<br />
* {{App|adesklet-systemmonitor|modular stackable system monitors for adesklets|http://adesklets.sourceforge.net/desklets.html|{{AUR|adesklet-systemmonitor}}}}<br />
* {{App|[[Conky]]|lightweight, scriptable system monitor|http://conky.sourceforge.net/|{{Pkg|conky}}}}<br />
* {{App|[[Wikipedia:GKrellM|GKrellM]]|simple, flexible system monitor package for GTK2; many plug-ins are available on AUR|http://members.dslextreme.com/users/billw/gkrellm/gkrellm.html|{{Pkg|gkrellm}}}}<br />
* {{App|[[Wikipedia:Htop|Htop]]|simple, ncurses interactive process viewer|http://htop.sourceforge.net/|{{Pkg|htop}}}}<br />
* {{App|LXTask|lightweight task manager for [[LXDE]]|http://wiki.lxde.org/en/LXTask|{{Pkg|lxtask}}}}<br />
<br />
=== Terminal emulators ===<br />
{{Wikipedia|List of terminal emulators}}<br />
<br />
Power users use terminal emulators quite often, so unsurprisingly lots of X11 terminal emulators exist. Most of them emulate Xterm that emulates VT102, which emulates typewriter, so you will have to read [[Wikipedia:Terminal emulator|Wikipedia article]] and [https://google.com/search?q=linux+terminal+emulators other sources] to master these things. Some of listed emulators have "quake"-like sequences in names or refer to Quake terminals. If you have not played Quake (really?) or did not pay enough attention to it's terminals &ndash; those have no border and are hidden from the desktop until a key is pressed.<br />
<br />
* {{App|[[Xterm]]|It is doubtful that you would need more functionality than present in the Xterm, but be ready to tune it a bit to get nice look and working copy-paste|http://invisible-island.net/xterm/|{{Pkg|xterm}}}}<br />
* {{App|[[Wikipedia:aterm|aterm]]|An xterm replacement with transparency support|http://aterm.sourceforge.net/|{{Pkg|aterm}}}}<br />
* {{App|[[Wikipedia:Konsole|Konsole]]|[[KDE]]'s default terminal|http://konsole.kde.org/|{{Pkg|kdebase-konsole}}}}<br />
* {{App|[[Wikipedia:Yakuake|Yakuake]]|drop-down terminal emulator based on KDE Konsole technology|http://extragear.kde.org/apps/yakuake/|{{Pkg|yakuake}}}}<br />
* {{App|[[LilyTerm]]|A light and easy to use libvte based X Terminal Emulator|http://lilyterm.luna.com.tw/|{{Pkg|lilyterm}}}}<br />
* {{App|[[Wikipedia:Rxvt|rxvt]]|popular replacement for the xterm|http://rxvt.sourceforge.net/|{{Pkg|rxvt}}}}<br />
* {{App|[[urxvt]]|A highly extendable unicode enabled rxvt-clone terminal emulator featuring tabbing, url launching, quake-style dropdown, pseudo-transparency, and is extensible with perl|http://software.schmorp.de/pkg/rxvt-unicode|{{Pkg|rxvt-unicode}}}}<br />
* {{App|[[Wikipedia:mrxvt|mrxvt]]|tabbed X terminal emulator based on rxvt code|http://materm.sourceforge.net/index.html|{{AUR|mrxvt}}}}<br />
* {{App|Eterm ([[Enlightenment]])|emulator, derived from rxvt|http://eterm.org|{{AUR|eterm}}}}<br />
* {{App|[[Stjerm]]|is a GTK+-based drop-down terminal emulator. Stjerm sets itself apart from similar programs by providing a minimalistic interface combined with a small file size, lightweight memory usage and easy integration with composite window managers such as Compiz. |https://code.google.com/p/stjerm-terminal-emulator/|{{AUR|stjerm}}}}<br />
* {{App|[[Wikipedia:Terminator (terminal emulator)|Terminator]]|terminal emulator supporting multiple resizable terminal panes|http://tenshu.net/p/terminator.html|{{Pkg|terminator}}}}<br />
* {{App|[[Wikipedia:Tilda (software)|Tilda]]|A Linux terminal taking after the likeness of many classic terminals from first person shooter games, Quake, Doom and Half-Life|http://sourceforge.net/projects/tilda/files/|{{Pkg|tilda}}}}<br />
* {{App|Termit|simple terminal emulator, extensible via Lua. Includes tabs, bookmarks, and the ability to switch encodings|https://wiki.github.com/nonstop/termit/|{{AUR|termit}}}}<br />
<br />
==== VTE-based ====<br />
[http://developer.gnome.org/vte/unstable/ Terminal Vidget], developed during early Gnome days, gave birth to many terminals with similar capabilities:<br />
* {{App|ROXTerm|A tabbed, VTE-based terminal emulator with a small footprint|http://rox.sourceforge.net|{{Pkg|roxterm}}}}<br />
* {{App|Sakura|A terminal emulator based on GTK+ and VTE|http://www.pleyades.net/david/projects/sakura|{{Pkg|sakura}}}}<br />
* {{App|mt|written as nice light-er-weight replacement for sakura (the binary is one third the size), keeping most of the functionality, except settings are defined during compilation, and removes some stupid features|https://github.com/mutantturkey/mt/|{{AUR|mt-git}}}}<br />
* {{App|lxterminal|VTE-based terminal emulator and c part of the LXDE DE.|http://lxde.org/|{{Pkg|lxterminal}}}}<br />
* {{App|[[Wikipedia:GNOME Terminal|GNOME Terminal]]|[[GNOME]] default (standalone) terminal with support for Unicode and pseudo-transparency|http://invisible-island.net/xterm/xterm.faq.html#bug_gnometerm|{{Pkg|gnome-terminal}}}}<br />
* {{App|[[guake]]|drop-down terminal for Gnome Desktop Environment|http://guake.org/|{{AUR|guake-git}}}}<br />
* {{App|[[Wikipedia:Terminal (Xfce)|Terminal]]|Xfce default terminal with support for a colorized prompt and a tabbed interface|http://docs.xfce.org/apps/terminal/start|{{Pkg|terminal}}}}<br />
* {{App|evilvte|name apparently is a reference to [[evilwm]], although the two projects do not appear to be related|http://calno.com/evilvte/|{{AUR|evilvte}}}}<br />
<br />
=== Text editors ===<br />
{{Wikipedia|Comparison of text editors}}<br />
<br />
==== Console ====<br />
* {{App|[[Emacs|GNU Emacs]]|The somewhat intimidating but famously extensible text editor with hundreds of tricks and add-ons|https://gnu.org/s/emacs|{{Pkg|emacs}}}}<br />
* {{App|[[Wikipedia:JED (text editor)|JED]]|text editor that makes extensive use of the [[Wikipedia:S-Lang (programming library)|S-Lang library]].|http://jedsoft.org/jed/|{{AUR|jed}}}}<br />
* {{App|[[Joe]]|Joe's Own Editor|http://joe-editor.sourceforge.net/|{{AUR|joe}}}}<br />
* {{App|[[nano]]|A console text editor based on pico with on-screen key binding help|http://nano-editor.org/|{{Pkg|nano}}}}<br />
* {{App|[[Vim]]|Vi IMproved|http://www.vim.org/|{{Pkg|vim}}}}<br />
* {{App|[[Wikipedia:ed (text editor)|ed]]|Ed is the standard text editor|https://gnu.org/s/ed/|{{Pkg|ed}}}}<br />
* {{App|[[Wikipedia:Zile (editor)|Zile]]|Lightweight Emacs clone|https://gnu.org/s/zile/|{{Pkg|zile}}}}<br />
* {{App|dex|dextrous text editor, a lightweight text editor.|https://github.com/tihirvon/dex|{{AUR|dex-editor-git}}}}<br />
<br />
==== Graphical ====<br />
* {{App|[[Wikipedia:Acme (text editor)|Acme]]|A minimalist and flexible programming environment by Rob Pike|http://acme.cat-v.org|{{Pkg|plan9port}}}}<br />
* {{App|[[Beaver]]|An Early AdVanced EditoR|http://beaver-editor.sourceforge.net/|{{Pkg|beaver}}}}<br />
* {{App|[[Wikipedia:Bluefish (text editor)|Bluefish]]|GTK editor/IDE with an MDI interface, syntax highlighting and support for Python plugins|http://bluefish.openoffice.nl/|{{Pkg|bluefish}}}}<br />
* {{App|cssed|GTK2 based Cascading Style Sheets (CSS) editor|http://cssed.sourceforge.net/|{{AUR|cssed}}}}<br />
* {{App|Edile|A PyGTK code/scripting editor implemented in one file|https://code.google.com/p/edile/|{{AUR|edile}}}}<br />
* {{App|[[Wikipedia:Geany|Geany]]|A text editor using the GTK+ 2 toolkit with basic features of an integrated development environment|https://geany.org|{{Pkg|geany}}}}<br />
* {{App|[[Wikipedia:Gedit|Gedit]]|Part of the GNOME desktop, but has minimal dependencies: a GTK2 editor with syntax highlighting, automatic indentation, matching brackets, etc., and a number of add-ons to increase functionality|http://projects.gnome.org/gedit/|{{Pkg|gedit}}}}<br />
* {{App|[[gVim]]|Vi IMproved|http://vim.org/|{{Pkg|gvim}}}}<br />
* {{App|[[Wikipedia:Kate|Kate]]|The KDE Advanced Text Editor. A full-featured programmer's editor, with MDI and a filesystem browser|http://kate-editor.org/|{{Pkg|kdesdk-kate}}}}<br />
* {{App|[[Wikipedia:KWrite|KWrite]] (part of the KDE desktop)|lightweight text editor with syntax highlighting.|http://kde.org/applications/utilities/kwrite/|{{Pkg|kdebase-kwrite}}}}<br />
* {{App|[[Wikipedia:Leafpad|Leafpad]]|A notepad clone for GTK+ 2.x that emphasizes simplicity|http://tarot.freeshell.org/leafpad/|{{Pkg|leafpad}}}}<br />
* {{App|medit|medit is a programming and around-programming text editor|http://mooedit.sourceforge.net/|{{Pkg|medit}}}}<br />
* {{App|[[Wikipedia:PyRoom|PyRoom]]|great distractionless PyGTK text editor, a clone of the infamous WriteRoom|http://pyroom.org/|{{AUR|pyroom}}}}<br />
* {{App|[[Wikipedia:Sam (text editor)|Sam]]|graphical text editor by Rob Pike (still used by Ken Thompson and others)|http://sam.cat-v.org|{{Pkg|plan9port}} or {{Pkg|9base}}}}<br />
* {{App|[[Wikipedia:Scite|Scite]]|generally useful editor with facilities for building and running programs|http://scintilla.org/SciTE.html|{{Pkg|scite}}}}<br />
* {{App|Tea|QT based feature rich text editor|http://tea-editor.sourceforge.net/|{{Pkg|tea}}}}<br />
<br />
=== Application Launchers ===<br />
{{Stub}}<br />
<br />
{{Wikipedia|Comparison of desktop application launchers}}<br />
<br />
* {{App|Adeskbar|easy, simple, unobtrusive application launcher for Openbox|https://launchpad.net/adeskbar|{{AUR|adeskbar}}}}<br />
* {{App|Fehlstart|small application launcher written in c99|https://gitorious.org/fehlstart|{{AUR|fehlstart-git}}}}<br />
<br />
=== Amateur radio ===<br />
{{Wikipedia|List of software-defined radios}}<br />
{{Box||See the main article: [[Amateur Radio#Software list]]|#E5E5FF|#FCFCFC}}<br />
<br />
=== Finance ===<br />
{{Stub}}<br />
* {{App|esniper|simple, lightweight tool for [[Wikipedia:Auction_sniping|sniping]] ebay auctions|http://esniper.sourceforge.net/|{{AUR|esniper}}}}<br />
* {{App|[[Wikipedia:GnuCash|GnuCash]]|personal and small-business financial-accounting software|http://www.gnucash.org/|{{Pkg|gnucash}}}}</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Arch_User_Repository&diff=202528Arch User Repository2012-05-22T17:00:49Z<p>Rnabioullin: /* Sharing packages */ broadened heading</p>
<hr />
<div>[[Category:Arch User Repository]]<br />
[[Category:Package development]]<br />
[[Category:Package management]]<br />
[[tr:Arch_Kullanıcı_Deposu]]<br />
{{i18n|Arch User Repository}}<br />
[[fr:AUR]]<br />
{{Article summary start}}<br />
{{Article summary text|The Arch User Repository is a collection of user-submitted [[PKGBUILD]]s that supplement software available from the [[official repositories]]. This article describes how to build ''unsupported'' software packages from the AUR.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Package management overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|AUR Helpers}}<br />
{{Article summary wiki|AUR Trusted User Guidelines}}<br />
{{Article summary heading|Resources}}<br />
{{Article summary link|AUR Web Interface|https://aur.archlinux.org}}<br />
{{Article summary link|AUR Mailing List|http://www.archlinux.org/mailman/listinfo/aur-general}}<br />
{{Article summary end}}<br />
<br />
The Arch User Repository (AUR) is a community-driven repository for Arch users. It contains package descriptions (PKGBUILDs) that allow you to compile a package from source with [[makepkg]] and then install it via [[pacman]]. The AUR was created to organize and share new packages from the community and to help expedite popular packages' inclusion into the [[#.5Bcommunity.5D|[community]]] repository. This document explains how users can access and utilize the AUR.<br />
<br />
A good number of new packages that enter the official repositories start in the AUR. In the AUR, users are able to contribute their own package builds (PKGBUILD and related files). The AUR community has the ability to vote for or against packages in the AUR. If a package becomes popular enough -- provided it has a compatible license and good packaging technique -- it may be entered into the [community] repository (directly accessible by [[pacman]] or [[ABS|abs]]).<br />
<br />
==Getting started==<br />
Users can search and download PKGBUILDs from the [https://aur.archlinux.org AUR Web Interface]. These PKGBUILDs can be built into installable packages using [[makepkg]], then installed using pacman. <br />
<br />
* Install {{Grp|base-devel}} ({{ic|pacman -S base-devel}}), because members of this group are not explicitly required by AUR packages which may not build without them (more info in [https://bbs.archlinux.org/viewtopic.php?pid=632355 this thread]).<br />
* Read the remainder of this article for more info and a short tutorial on installing AUR packages.<br />
* Visit the [https://aur.archlinux.org AUR Web Interface] to inform yourself on updates and happenings. There you will also find statistics and an up-to-date list of newest available packages available in AUR.<br />
* Glance over the [[#FAQ]] for answers to the most common questions.<br />
* You may wish to adjust {{ic|/etc/makepkg.conf}} to better optimize for your processor prior to building packages from the AUR. A significant improvement in compile times can be realized on systems with multi-core processors by adjusting the MAKEFLAGS variable. Users can also enable hardware-specific optimizations in GCC via the CFLAGS variable. See [[makepkg.conf]] for more information.<br />
<br />
==History==<br />
The following items are listed for historical purposes only. They have since been superseded by the AUR and are no longer available.<br />
<br />
At the beginning, there was {{ic|<nowiki>ftp://ftp.archlinux.org/incoming</nowiki>}}, and people contributed by simply uploading the PKGBUILD, the needed supplementary files, and the built package itself to the server. The package and associated files remained there until a [[Package Maintainer]] saw the program and adopted it.<br />
<br />
Then the Trusted User Repositories were born. Certain individuals in the community were allowed to host their own repositories for anyone to use. The AUR expanded on this basis, with the aim of making it both more flexible and more usable. In fact, the AUR maintainers are still referred to as TUs (Trusted Users).<br />
<br />
==Searching==<br />
The AUR web interface can be found [https://aur.archlinux.org/ here], and an interface suitable for accessing the AUR from a script (for example) can be found [https://aur.archlinux.org/rpc.php here]<br />
<br />
Queries search package names and descriptions via a MySQL LIKE comparison. This allows for more flexible search criteria (e.g. try searching for 'tool%like%grep' instead of 'tool like grep'). If you need to search for a description that contains '%', escape it with '\%'.<br />
<br />
==Installing packages==<br />
Installing packages from the AUR is a relatively simple process. Essentially:<br />
# Acquire the tarball which contains the PKGBUILD and possibly other required files<br />
# Extract the tarball (preferably in a folder set aside just for builds from the AUR)<br />
# Run '''makepkg''' in the directory where the files are saved ("makepkg -s" will auto-resolve dependencies with pacman)<br />
# Install the resulting package with '''pacman''':<br />
<br />
# pacman -U /path/to/pkg.tar.xz<br />
<br />
[[AUR Helpers]] add seamless access to the AUR. They vary in their features, but can ease in searching, fetching, building, and installing from PKGBUILDs found in the AUR. All of these scripts can be found in the AUR.<br />
<br />
{{Note|There is not and will never be an ''official'' mechanism for installing build material from the AUR. All users should be familiar with the build process.}}<br />
<br />
What follows is a detailed example of installation of a package called "foo".<br />
<br />
===Prerequisites===<br />
First ensure that the necessary tools are installed. The package group "base-devel" should be sufficient; it includes ''make'' and other tools needed for compiling from source.<br />
<br />
{{Warning|Packages in the AUR assume "base-devel" is installed, and will not list members of this group as dependencies even if the package cannot be built without them. Please ensure this group is installed before complaining about failed builds.}}<br />
<br />
# pacman -S base-devel<br />
<br />
Next choose an appropriate build directory. A build directory is simply a directory where the package will be made or "built" and can be any directory. Examples of commonly used directories are:<br />
<br />
~/builds<br />
<br />
or if using ABS (the [[Arch Build System]]):<br />
<br />
/var/abs/local<br />
<br />
For more information on ABS read the [[Arch Build System]] article. The example will use {{ic|~/builds}} as the build directory.<br />
<br />
===Acquire build files===<br />
Locate the package in the AUR. This is done using the search feature (text field at the top of the [https://aur.archlinux.org/ AUR home page]). Clicking the application's name in the search list brings up an information page on the package. Read through the description to confirm that this is the desired package, note when the package was last updated, and read any comments.<br />
<br />
Download the necessary build files. From the package's information page download the build files by clicking the "Tarball" link on the left-hand side near the end of the package details. This file should be saved to the build directory or otherwise copied to the directory after downloading. In this example, the file is called "foo.tar.gz" (standard format is ''pkgname''.tar.gz, if it has been properly submitted).<br />
<br />
===Build the package===<br />
Extract the tarball. Change directories to the build directory if not already there and extract the build files.<br />
<br />
$ cd ~/builds<br />
$ tar -xvzf foo.tar.gz<br />
<br />
This should create a new directory called "foo" in the build directory.<br />
<br />
{{Warning|'''Carefully check all files.''' {{ic|cd}} to the newly created directory and carefully check the {{ic|PKGBUILD}} and any {{ic|.install}} file for malicious commands. {{ic|PKGBUILD}}s are bash scripts containing functions to be executed by {{ic|makepkg}}: these functions can contain ''any'' valid commands or bash syntax, so it is totally possible for a {{ic|PKGBUILD}} to contain dangerous commands through malice or ignorance on the part of the author. Since {{ic|makepkg}} uses fakeroot (and should never be run as root), there is some level of protection but you should never count on it. If in doubt, do not build the package and seek advice on the forums or mailing list.}}<br />
<br />
$ cd foo<br />
$ nano PKGBUILD<br />
$ nano foo.install<br />
<br />
Make the package. After manually confirming the integrity of the files, run [[makepkg]] as a normal user in the build directory.<br />
<br />
$ makepkg -s<br />
<br />
The {{ic|-s}} switch will use [[sudo]] to install any needed dependencies. If the use of sudo is undesirable, manually install required dependencies beforehand and exclude the {{ic|-s}} in the above command.<br />
<br />
===Install the package===<br />
Install the package using pacman. A tarball should have been created named:<br />
<br />
<''application name''>-<''application version number''>-<''package revision number''>-<''architecture''>.pkg.tar.xz<br />
<br />
This package can be installed using pacman's "upgrade" command:<br />
<br />
# pacman -U foo-0.1-1-i686.pkg.tar.xz <br />
<br />
These manually-installed packages are called foreign packages - packages which have not originated from any repository known to pacman. To list all foreign packages:<br />
$ pacman -Qm <br />
<br />
{{Note|The above example is only a brief summary of the package building process. A visit to the [[makepkg]] and [[ABS]] pages will provide more detail and is highly recommended (particularly for first-time users).}}<br />
<br />
==Feedback==<br />
The [https://aur.archlinux.org AUR Web Interface] has a comments facility that allows users to provide suggestions and feedback on improvements to the PKGBUILD contributor. Avoid pasting patches or PKGBUILDs into the comments section: they quickly become obsolete and just end up needlessly taking up lots of space. Instead email those files to the maintainer, or even use a [[pastebin Clients|pastebin]].<br />
<br />
One of the easiest activities for '''all''' Arch users is to browse the AUR and '''vote''' for their favourite packages using the online interface. All packages are eligible for adoption by a TU for inclusion in [community], and the vote count is one of the considerations in that process; it is in everyone's interest to vote!<br />
<br />
==Sharing and maintaining packages==<br />
The user plays an essential role in the AUR, which cannot fulfill its potential without the support, involvement, and contribution of the wider user community. The life-cycle of an AUR package starts and ends with the user and requires the user to contribute in several ways.<br />
<br />
Users can '''share''' PKGBUILDs using the Arch User Repository. It does not contain any binary packages but allows users to upload PKGBUILDs that can be downloaded by others. These PKGBUILDs are completely unofficial and have not been thoroughly vetted, so they should be used at your own risk.<br />
<br />
===Submitting packages===<br />
After logging in to the AUR web interface, a user can [https://aur.archlinux.org/pkgsubmit.php submit] a gzipped tarball ({{ic|.tar.gz}}) of a directory containing build files for a package. The directory inside the tarball should contain a [[PKGBUILD]], any {{ic|.install}} files, patches, etc. ('''absolutely''' no binaries). Examples of what such a directory should look like can be seen inside {{ic|/var/abs}} if the [[Arch Build System]] was installed.<br />
<br />
The tarball can be created with the following command:<br />
$ makepkg --source <br />
<br />
Note that this is a gzipped tarball; assuming you are uploading a package called ''libfoo'', when you create the file it should look similar to this:<br />
<br />
# List contents of tarball.<br />
$ tar tf libfoo-0.1-1.src.tar.gz<br />
libfoo/<br />
libfoo/PKGBUILD<br />
libfoo/libfoo.install<br />
<br />
When submitting a package, observe the following rules: <br />
* Check the [http://www.archlinux.org/packages/ package database] for the package. If it exists, '''do not''' submit the package. If the current package is broken or is lacking an included feature then please file a [https://bugs.archlinux.org/ bug report].<br />
* Check the AUR for the package. If it is currently maintained, changes can be submitted in a comment for the maintainer's attention. If it is unmaintained, the package can be adopted and updated as required. Do not create duplicate packages.<br />
* Verify carefully that what you are uploading is correct. All contributors must read and adhere to the [[Arch Packaging Standards]] when writing PKGBUILDs. This is essential to the smooth running and general success of the AUR. Remember that you are not going to earn any credit or respect from your peers by wasting their time with a bad PKGBUILD.<br />
* Packages that contain binaries or that are very poorly written may be deleted without warning.<br />
* If you are unsure about the package (or the build/submission process) in any way, submit the PKGBUILD to the [https://mailman.archlinux.org/mailman/listinfo/ AUR Mailing List] or the [https://bbs.archlinux.org/viewforum.php?id=4 AUR boards] on the forum for public review before adding it to the AUR.<br />
* Make sure the package is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission.<br />
* The AUR and official repositories are intended for packages which install generally software and software-related content, including one or more of the following: executable(s); config file(s); online or offline documentation for specific software or the Arch Linux distribution as a whole; media intended to be used directly by software.<br />
* Gain some experience before submitting packages. Build a few packages to learn the process and then submit.<br />
* If you submit a {{ic|package.tar.gz}} with a file named '{{ic|package}}' in it you will get an error: 'Could not change to directory {{ic|/home/aur/unsupported/package/package}}'. To resolve this, rename the file named '{{ic|package}}' to something else, for example, '{{ic|package.rc}}'. When it is installed in the {{ic|pkg}} directory you may rename it back to '{{ic|package}}'.<br />
Make sure to also read [[Arch Packaging Standards#Submitting packages to the AUR]].<br />
<br />
===Maintaining packages===<br />
* If you maintain a package and want to update the PKGBUILD for your package just resubmit it.<br />
* Check for feedback and comments from other users and try to incorporate any improvements they suggest; consider it a learning process!<br />
* Please do not just submit and forget about packages! It is the maintainer's job to maintain the package by checking for updates and improving the PKGBUILD.<br />
* If you do not want to continue to maintain the package for some reason, {{ic|disown}} the package using the AUR web interface and/or post a message to the AUR Mailing List.<br />
<br />
===Other requests===<br />
* Disownment requests and removal requests go to the aur-general mailing list for TUs and other users to decide upon.<br />
* '''Include package name and URL to AUR page''', preferably with a footnote [1].<br />
* Disownment requests will be granted two weeks after the current maintainer has been contacted by email and did not react.<br />
* '''Package merging has been implemented''', users still have to resubmit a package under a new name and may request merging of the old version's comments and votes on the mailing list<br />
* Removal requests require the following information:<br />
** Package name and URL to AUR page<br />
** Reason for deletion, at least a short note <br> '''Notice:''' A package's comments does not sufficiently point out the reasons why a package is up for deletion. Because as soon as a TU takes action, the only place where such information can be obtained is the aur-general mailing list.<br />
** Include supporting details, like when a package is provided by another package, if you are the maintainer yourself, it's renamed and the original owner agreed, etc.<br />
<br />
Removal requests can be disapproved, in which case you'll likely be advised to disown the package for a future packager's reference.<br />
<br />
==[community]==<br />
The [community] repository, maintained by [[Trusted Users]], contains the most popular packages from the AUR. It is enabled by default in {{ic|/etc/pacman.conf}}. If [community] has been disabled or removed, it can be enabled by uncommenting or adding these two lines: <br />
<br />
{{hc|/etc/pacman.conf|<nowiki><br />
...<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
...<br />
</nowiki>}}<br />
<br />
[community], unlike the AUR, contains binary packages that can be installed directly with [[pacman]] and the build files can also be accessed with the [[Arch Build System|ABS]]. Some of these packages may eventually make the transition to the [core] or [extra] repositories as the developers consider them crucial to the distribution.<br />
<br />
Users can also access the [community] build files by editing {{ic|/etc/abs.conf}} and enabling the [community] repository in the {{ic|REPOS}} array.<br />
<br />
==Git Repo==<br />
A Git Repo of the AUR is maintained by Thomas Dziedzic providing package history among other things. It is updated at least once a day. To clone the repository (several hundred MB):<br />
<br />
$ git clone git://pkgbuild.com/aur-mirror.git<br />
<br />
[http://pkgbuild.com/git/aur-mirror.git/ Web interface], [http://pkgbuild.com/~td123/readme Readme], [http://bbs.archlinux.org/viewtopic.php?id=113099 Forum thread]<br />
<br />
==FAQ==<br />
{{FAQ<br />
|question=What is the AUR?<br />
|answer=The AUR (Arch User Repository) is a place where the Arch Linux community can upload [[PKGBUILD]]s of applications, libraries, etc., and share them with the entire community. Fellow users can then vote for their favorites to be moved into the [community] repository to be shared with Arch Linux users in binary form.}}<br />
<br />
{{FAQ<br />
|question=What kind of packages are permitted on the AUR?<br />
|answer=The packages on the AUR are merely "build scripts", i.e recipes to build binaries for pacman. For most cases, everything is permitted, subject to the abovementioned usefulness and scope guidelines, as long as you are in compliance with the licensing terms of the content. For other cases, where it is mentioned that "you may not link" to downloads, i.e contents that are not redistributable, you may only use the file name itself as the source. This means and requires users to already have the restricted source in the build directory prior to building the package. When in doubt, ask.}}<br />
<br />
{{FAQ<br />
|question=What is a TU?<br />
|answer=A [[AUR Trusted User Guidelines|TU (Trusted User)]] is a person who is chosen to oversee AUR and the [community] repository. They're the ones who maintain popular PKGBUILDs in [community], and overall keep the AUR running.}}<br />
<br />
{{FAQ<br />
|question=What's the difference between the Arch User Repository and [community]?<br />
|answer=The Arch User Repository is where all PKGBUILDs that users submit are stored, and must be built manually with [[makepkg]]. When PKGBUILDs receive enough votes, they are moved into the [community] repository, where the TUs maintain binary packages that can be installed with [[pacman]].}}<br />
<br />
{{FAQ<br />
|question=How many votes does it take to get a PKGBUILD into [community]?<br />
|answer=Usually, at least 10 votes are required for something to move into [community]. However, if a TU wants to support a package, it will often be found in the repository.}}<br />
<br />
{{FAQ<br />
|question=How do I make a PKGBUILD?<br />
|answer=The best resource is [[Creating Packages]]. Remember to look in AUR before creating the PKGBUILD as to not duplicate efforts.}}<br />
<br />
{{FAQ<br />
|question=I'm trying to do {{ic|pacman -S foo}}; it isn't working but I know it's in [community]<br />
|answer=You probably haven't enabled [community] in your {{ic|/etc/pacman.conf}}. Just uncomment the relevant lines.<br />
If [community] is enabled in your {{ic|/etc/pacman.conf}} try running {{ic|pacman -S -y}} first to synchronize the pkgcache before trying your package again.}}<br />
<br />
{{FAQ<br />
|question=Foo in AUR is outdated; what do I do?<br />
|answer=For starters, you can flag packages out-of-date. If it stays out-of-date for an extended period of time, the best thing to do is email the maintainer. If there is no response from the maintainer after two weeks, you could send mail to the aur-general mailing list to have a TU orphan the PKGBUILD if you're willing to maintain it yourself.}}<br />
<br />
{{FAQ<br />
|question=I have a PKGBUILD I would like to submit; can someone check it to see if there are any errors?<br />
|answer=If you would like to have your PKGBUILD critiqued, post it on the aur-general mailing list to get feedback from the TUs and fellow AUR members. You could also get help from the [[ArchChannel|IRC channel]], #archlinux on irc.freenode.net. You can also<br />
use [[namcap]] to check your PKGBUILD and the resulting package for errors.}}<br />
<br />
{{FAQ<br />
|question=Foo in AUR doesn't compile when I do {{ic|makepkg}}; what should I do?<br />
|answer=You are probably missing something trivial.<br />
<br />
# Run {{ic|pacman -Syyu}} before compiling anything with {{ic|makepkg}} as the problem may be that your system is not up-to-date.<br />
# Ensure you have both "base" and "base-devel" groups installed.<br />
# Try using the "{{ic|-s}}" option with {{ic|makepkg}} to check and install all the dependencies needed before starting the build process.<br />
<br />
Be sure to first read the PKGBUILD and the comments on the AUR page of the package in question.<br />
The reason might not be trivial after all. Custom CFLAGS, LDFLAGS and MAKEFLAGS can cause failures. It's also possible that the PKGBUILD is broken for everyone. If you cannot figure it out on your own, just report it to the maintainer e.g. by posting the errors you are getting in the comments on the AUR page.}}<br />
<br />
{{FAQ<br />
|question=How can I speed up repeated build processes?<br />
|answer=If you frequently compile code that uses gcc - say, a git or SVN package - you may find [[ccache]], short for "compiler cache", useful.}}<br />
<br />
{{FAQ<br />
|question=How do I access unsupported packages?<br />
|answer=See [[#Installing packages]]}}<br />
<br />
{{FAQ<br />
|question=How can I upload to AUR without using the web interface?<br />
|answer=You can use {{AUR|aurploader}}, {{AUR|aurup}} or {{AUR|burp}} -- these are command-line programs.}}</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Arch_build_system&diff=202527Arch build system2012-05-22T16:49:27Z<p>Rnabioullin: /* Traditional method of compiling software, without ABS */ added FHS ref.</p>
<hr />
<div>[[Category:About Arch]]<br />
[[Category:Package development]]<br />
[[Category:Package management]]<br />
[[tr:Arch_derleme_sistemi]]<br />
{{i18n|Arch Build System}}<br />
[[de:Arch Build System]]<br />
[[fr:ABS]]<br />
[[ro:ABS]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|The Arch Build System is a ports-like system for building and packaging software from source code. This article includes a general overview of the ABS followed by detailed usage instructions.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Package management overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|ABS FAQ}}<br />
{{Article summary wiki|Arch Packaging Standards}}<br />
{{Article summary wiki|Creating Packages}}<br />
{{Article summary wiki|Kernel Compilation with ABS}}<br />
{{Article summary end}}<br />
<br />
This article provides an overview of the Arch Build System along with a walkthrough for beginners. It is not a complete reference guide! For a quick and simple introduction to the ABS, see the [[ABS FAQ]]. If you need more information, please reference the man pages.<br />
{{Note|ABS syncs once a day so it may lag behind what is already available in the repositories.}}<br />
== What is the Arch Build System? ==<br />
<br />
The Arch Build System, '''ABS''' for short, is a ''ports-like'' system for building and packaging software from source code. While [[pacman]] is the specialized Arch tool for binary package management (including packages built with the ABS), ABS is a collection of tools for compiling source into installable {{ic|.pkg.tar.gz/.pkg.tar.xz}} packages.<br />
<br />
=== What is a ports-like system? ===<br />
<br />
''Ports'' is a system used by *BSD to automate the process of building software from source code. The system uses a ''port'' to download, unpack, patch, compile, and install the given software. A ''port'' is merely a small directory on the user's computer, named after the corresponding software to be installed, that contains a few files with the instructions for building and installing the software from source. This makes installing software as simple as typing {{ic|make}} or {{ic|make install clean}} within the port's directory.<br />
<br />
=== '''ABS''' is a similar concept ===<br />
<br />
ABS is made up of a directory tree (the ABS tree) residing under {{ic|/var/abs}}. This tree contains many subdirectories, each within a category and each named by their respective package. This tree represents (but does not contain) all ''official Arch software'', retrievable through the SVN system. You may refer to each package-named subdirectory as an 'ABS', much the way one would refer to a 'port'. These ABS (or subdirectories) do not contain the software package nor the source but rather a [[PKGBUILD]] file (and sometimes other files). A PKGBUILD is a simple Bash build script -- a text file containing the compilation and packaging instructions as well as the URL of the appropriate '''source''' tarball to be downloaded. (The most important component of ABS are PKGBUILDs.) By issuing the ABS [[makepkg]] command, the software is first compiled and then ''packaged'' within the build directory before being installed. Now you may use [[pacman]], the Arch Linux package manager, to install, upgrade, and remove your new package.<br />
<br />
=== ABS overview ===<br />
<br />
'ABS' may be used as an umbrella term since it includes and relies on several other components; therefore, though not technically accurate, 'ABS' can refer to the following tools as a complete toolkit:<br />
<br />
; ABS tree: The ABS directory structure; an SVN hierarchy under {{ic|/var/abs/}} on your (local) machine. It contains many subdirectories, named for all available official Arch Linux software from repositories specified in {{ic|/etc/abs.conf}}, but not the packages themselves. The tree is created after installing the {{Pkg|abs}} package with [[pacman]] and subsequently running the {{ic|abs}} script.<br />
<br />
; [[PKGBUILD]]s: A [[Bash]] script that contains the URL of the source code along with the compilation and packaging instructions.<br />
<br />
; [[makepkg]]: ABS shell command tool which reads the PKGBUILDs, automatically downloads and compiles the sources and creates a {{ic|.pkg.tar*}} according to the {{ic|PKGEXT}} array in {{ic|makepkg.conf}}. You may also use makepkg to make your own custom packages from the [[AUR]] or third-party sources. (See the [[Creating Packages]] wiki article.)<br />
<br />
; [[pacman]]: pacman is completely separate, but is necessarily invoked either by makepkg or manually, to install and remove the built packages and for fetching dependencies.<br />
<br />
; [[Arch User Repository|AUR]]: The Arch User Repository is separate from ABS but AUR (unsupported) PKGBUILDs are built using makepkg to compile and package up software. In contrast to the ABS tree on your local machine, the AUR exists as a website interface. It contains many thousands of user-contributed PKGBUILDs for software which is unavailable as an official Arch package. If you need to build a package outside the official Arch tree, chances are it is in the AUR.<br />
<br />
== Why would I want to use ABS? ==<br />
<br />
The Arch Build System is used to:<br />
* Compile or recompile a package, for any reason<br />
* Make and install new packages from source of software for which no packages are yet available (see [[Creating Packages]]) <br />
* Customize existing packages to fit your needs (enabling or disabling options, patching)<br />
* Rebuild your entire system using your compiler flags, "a la FreeBSD" (e.g. with [[pacbuilder]])<br />
* Cleanly build and install your own custom kernel (see [[Kernel Compilation]])<br />
* Get kernel modules working with your custom kernel<br />
* Easily compile and install a newer, older, beta, or development version of an Arch package by editing the version number in the PKGBUILD<br />
<br />
ABS is not necessary to use Arch Linux, but it is useful for automating certain tasks of source compilation.<br />
<br />
== How to use ABS? ==<br />
<br />
Building packages using abs consists of these steps:<br />
#Install the {{Pkg|abs}} package with [[pacman]].<br />
#Run {{ic|abs}} as root to create the ABS tree by synchronizing it with the Arch Linux server.<br />
#Copy the build files (usually residing under {{ic|/var/abs/<repo>/<pkgname>}}) to a build directory.<br />
#Navigate to that directory, edit the PKGBUILD (if desired/necessary) and do '''makepkg'''. <br />
#According to instructions in the PKGBUILD, makepkg will download the appropriate source tarball, unpack it, patch if desired, compile according to {{ic|CFLAGS}} specified in {{ic|makepkg.conf}}, and finally compress the built files into a package with the extension {{ic|.pkg.tar.gz}} or {{ic|.pkg.tar.xz}}. <br />
#Installing is as easy as doing {{ic|pacman -U <.pkg.tar.xz file>}}. Package removal is also handled by pacman.<br />
<br />
=== Install tools ===<br />
<br />
To use the ABS, you first need to install {{Pkg|abs}} from the [[Official Repositories|official repositories]]:<br />
<br />
# pacman -S abs<br />
<br />
This will grab the abs-sync scripts, various build scipts, and [[rsync]] (as a dependency, if you do not already have it).<br />
<br />
Before you can actually build anything, however, you will also need to grab basic compiling tools. These are handily collected in the package group '''base-devel'''. This group can be installed with:<br />
<br />
# pacman -S base-devel<br />
<br />
=== /etc/abs.conf ===<br />
<br />
As root, edit {{ic|/etc/abs.conf}} to include your desired repositories.<br />
<br />
Remove the {{ic|!}} in front of the appropriate repositories. For example:<br />
REPOS=(core extra community !testing)<br />
<br />
=== ABS tree ===<br />
<br />
The ABS tree is an SVN directory hierarchy located under {{ic|/var/abs}} and looks like this:<br />
<br />
{{bc|<nowiki><br />
| -- core/<br />
| || -- acl/<br />
| || || -- PKGBUILD<br />
| || -- attr/<br />
| || || -- PKGBUILD<br />
| || -- abs/<br />
| || || -- PKGBUILD<br />
| || -- autoconf/<br />
| || || -- PKGBUILD<br />
| || -- ...<br />
| -- extra/<br />
| || -- acpid/<br />
| || || -- PKGBUILD<br />
| || -- apache/<br />
| || || -- PKGBUILD<br />
| || -- ...<br />
| -- community/<br />
| || -- ...<br />
</nowiki>}}<br />
<br />
The ABS tree has exactly the same structure as the package database:<br />
<br />
* First-level: Reposistory name<br />
* Second-level: Package name directories<br />
* Third level: PKGBUILD (contains information needed to build a package) and other related files (patches, other files needed for building the package)<br />
<br />
The source code for the package is not present in the ABS directory. Instead, the '''PKGBUILD''' file contains a URL that will download the source code when the package is built. So the size of abs tree is quite small.<br />
<br />
==== Download ABS tree ====<br />
As root, run:<br />
# abs<br />
<br />
Your ABS tree is now created under {{ic|/var/abs}}. Note the appropriate branches of the ABS tree now exist and correspond to the ones you specified in {{ic|/etc/abs.conf}}. <br />
<br />
The abs command should be run periodically to keep in sync with the official repositories. Individual ABS package files can also be downloaded with:<br />
<br />
# abs <repository>/<package><br />
This way you do not have to check out the entire abs tree just to build one package.<br />
<br />
=== /etc/makepkg.conf ===<br />
<br />
{{ic|/etc/makepkg.conf}} specifies global environment variables and compiler flags which you may wish to edit if you are using an SMP system, or to specify other desired optimizations. The default settings are for i686 and x86_64 optimizations which will work fine for those architectures on single-CPU systems. (The defaults will work on SMP machines, but will only use one core/CPU when compiling -- see [[makepkg.conf]].)<br />
<br />
==== Set the PACKAGER variable in /etc/makepkg.conf ====<br />
<br />
Setting the PACKAGER variable in {{ic|/etc/makepkg.conf}} is an optional but ''highly recommended'' step. It allows a "flag" to quickly identify which packages have been built and/or installed by YOU, not the official maintainer! This is easily accomplished using '''expac''' available from the community repo:<br />
<br />
===== Showing All Packages (including those from AUR) =====<br />
$ grep myname /etc/makepkg.conf<br />
PACKAGER="myname <myemail@myserver.com>"<br />
<br />
$ expac "%n %p" | grep "myname" | column -t<br />
archey3 myname<br />
binutils myname<br />
gcc myname<br />
gcc-libs myname<br />
glibc myname<br />
tar myname<br />
<br />
===== Showing Only Packages Contained in Repos =====<br />
<br />
This example only shows packages contained in the repos defined in {{ic|/etc/pacman.conf}}:<br />
<br />
$ . /etc/makepkg.conf; grep -xvFf <(pacman -Qqm) <(expac "%n\t%p" | grep "$PACKAGER$" | cut -f1)<br />
binutils<br />
gcc<br />
gcc-libs<br />
glibc<br />
tar<br />
<br />
=== Create a build directory ===<br />
<br />
It is recommended to create a build directory where the actual compiling will take place; you should never modify the ABS tree by building within it, as data will be lost (overwritten) on each ABS update. It is good practice to use your home directory, though some Arch users prefer to create a 'local' directory under {{ic|/var/abs/}}, owned by a normal user. <br />
<br />
Create your build directory. e.g.:<br />
<br />
$ mkdir -p $HOME/abs<br />
<br />
Copy the ABS from the tree ({{ic|/var/abs/branch/category/pkgname}}) to the build directory, {{ic|/path/to/build/dir}}.<br />
<br />
=== Build package ===<br />
<br />
In our example, we will build the ''slim'' display manager package.<br />
<br />
Copy the slim ABS from the ABS tree to a build directory:<br />
$ cp -r /var/abs/extra/slim/ ~/abs<br />
<br />
Navigate to the build directory:<br />
$ cd ~/abs/slim<br />
<br />
Modify the PKGBUILD to add or remove support for components, to patch or to change package versions, etc. (optional):<br />
$ nano PKGBUILD<br />
<br />
Run makepkg as normal user (with {{ic|-s}} switch to install with automatic dependency handling):<br />
$ makepkg -s<br />
<br />
{{Note|Before complaining about missing (make) dependencies, remember that the {{Grp|base}} group is assumed to be installed on all Arch Linux systems. The group "base-devel" is assumed to be installed when building with '''makepkg'''. See [[#Install tools]].}}<br />
<br />
Install as root:<br />
# pacman -U slim-1.3.0-2-i686.pkg.tar.xz<br />
<br />
That's it. You have just built slim from source and cleanly installed it to your system with pacman. Package removal is also handled by pacman -- ({{ic|pacman -R slim}}).<br />
<br />
The ABS method adds a level of convenience and automation, while still maintaining complete transparency and control of the build and installation functions by including them in the PKGBUILD.<br />
<br />
==== fakeroot ====<br />
Essentially, the same steps are being executed in the traditional method (generally including the {{ic|./configure, make, make install}} steps) but the software is installed into a ''fake root'' environment. (A ''fake root'' is simply a subdirectory within the build directory that functions and behaves as the system's root directory. In conjunction with the '''fakeroot''' program, makepkg creates a fake root directory, and installs the compiled binaries and associated files into it, with '''root''' as owner.) The ''fake root'', or subdirectory tree containing the compiled software, is then compressed into an archive with the extension {{ic|.pkg.tar.xz}}, or a ''package''. When invoked, pacman then extracts the package (installs it) into the system's real root directory ({{ic|/}}).<br />
<br />
== Traditional method of compiling software, without ABS ==<br />
<br />
If you are not familiar with manually compiling software from source, you should know that most packages (but not all) can be built from source in this '''traditional way''':<br />
<br />
* Download source tarball from remote server, using web browser, ftp, wget or alternate method.<br />
<br />
* Decompress the source file:<br />
$ tar -xzf foo-0.99.tar.gz<br />
or<br />
$ tar -xjf foo-0.99.tar.bz2<br />
<br />
* Enter the directory:<br />
$ cd foo-0.99<br />
<br />
* Configure the package. Generally, there is a script called {{ic|configure}} in the source directory that is used to configure the package (add or remove support for things, choose the install destination, etc.) and check that your computer has all the software needed by the package. It can be run by:<br />
$ ./configure [option]<br />
<br />
You should first try the help to better understand how it works:<br />
$ ./configure --help<br />
<br />
If a {{ic|--prefix}} option is not passed to the script, ''most'' scripts will use {{ic|/usr/local}} as the install path, but others will use {{ic|/usr}}. For the sake of consistency, it is generally advised to pass the {{ic|1=--prefix=/usr/local}} option. It is good practice, as per [http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard FHS], to install personal programs in {{ic|/usr/local}}, and to have the ones being managed by the distro in {{ic|/usr}}. This ensures personal program versions can coexist with those being managed by the distro's package manager -- in Arch's case, [[pacman]].<br />
$ ./configure --prefix=/usr/local<br />
<br />
* Compile the sources:<br />
<br />
$ make<br />
<br />
* Install:<br />
<br />
# make install<br />
<br />
* Removal would be accomplished by entering the source directory and running:<br />
<br />
# make uninstall<br />
<br />
However, you should always read the {{ic|INSTALL}} file to know how the package should be built and installed! '''Not all packages use the {{ic|configure; make; make install}} system!'''<br />
<br />
{{Note | The above traditional method of compiling source tarballs can, of course, still be used on Arch Linux. However, if you are not careful, files may become scattered throughout the filesystem that pacman (or any other package manager) will be unaware of. You should only use this method if you are experienced at manual compilation and system software tracking, as it can lead to future problems on Arch (or any distribution) if using a package manager.}}</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Arch_build_system&diff=202524Arch build system2012-05-22T16:18:09Z<p>Rnabioullin: /* ABS is a similar concept */ fixed capitalization of proper noun</p>
<hr />
<div>[[Category:About Arch]]<br />
[[Category:Package development]]<br />
[[Category:Package management]]<br />
[[tr:Arch_derleme_sistemi]]<br />
{{i18n|Arch Build System}}<br />
[[de:Arch Build System]]<br />
[[fr:ABS]]<br />
[[ro:ABS]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|The Arch Build System is a ports-like system for building and packaging software from source code. This article includes a general overview of the ABS followed by detailed usage instructions.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Package management overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|ABS FAQ}}<br />
{{Article summary wiki|Arch Packaging Standards}}<br />
{{Article summary wiki|Creating Packages}}<br />
{{Article summary wiki|Kernel Compilation with ABS}}<br />
{{Article summary end}}<br />
<br />
This article provides an overview of the Arch Build System along with a walkthrough for beginners. It is not a complete reference guide! For a quick and simple introduction to the ABS, see the [[ABS FAQ]]. If you need more information, please reference the man pages.<br />
{{Note|ABS syncs once a day so it may lag behind what is already available in the repositories.}}<br />
== What is the Arch Build System? ==<br />
<br />
The Arch Build System, '''ABS''' for short, is a ''ports-like'' system for building and packaging software from source code. While [[pacman]] is the specialized Arch tool for binary package management (including packages built with the ABS), ABS is a collection of tools for compiling source into installable {{ic|.pkg.tar.gz/.pkg.tar.xz}} packages.<br />
<br />
=== What is a ports-like system? ===<br />
<br />
''Ports'' is a system used by *BSD to automate the process of building software from source code. The system uses a ''port'' to download, unpack, patch, compile, and install the given software. A ''port'' is merely a small directory on the user's computer, named after the corresponding software to be installed, that contains a few files with the instructions for building and installing the software from source. This makes installing software as simple as typing {{ic|make}} or {{ic|make install clean}} within the port's directory.<br />
<br />
=== '''ABS''' is a similar concept ===<br />
<br />
ABS is made up of a directory tree (the ABS tree) residing under {{ic|/var/abs}}. This tree contains many subdirectories, each within a category and each named by their respective package. This tree represents (but does not contain) all ''official Arch software'', retrievable through the SVN system. You may refer to each package-named subdirectory as an 'ABS', much the way one would refer to a 'port'. These ABS (or subdirectories) do not contain the software package nor the source but rather a [[PKGBUILD]] file (and sometimes other files). A PKGBUILD is a simple Bash build script -- a text file containing the compilation and packaging instructions as well as the URL of the appropriate '''source''' tarball to be downloaded. (The most important component of ABS are PKGBUILDs.) By issuing the ABS [[makepkg]] command, the software is first compiled and then ''packaged'' within the build directory before being installed. Now you may use [[pacman]], the Arch Linux package manager, to install, upgrade, and remove your new package.<br />
<br />
=== ABS overview ===<br />
<br />
'ABS' may be used as an umbrella term since it includes and relies on several other components; therefore, though not technically accurate, 'ABS' can refer to the following tools as a complete toolkit:<br />
<br />
; ABS tree: The ABS directory structure; an SVN hierarchy under {{ic|/var/abs/}} on your (local) machine. It contains many subdirectories, named for all available official Arch Linux software from repositories specified in {{ic|/etc/abs.conf}}, but not the packages themselves. The tree is created after installing the {{Pkg|abs}} package with [[pacman]] and subsequently running the {{ic|abs}} script.<br />
<br />
; [[PKGBUILD]]s: A [[Bash]] script that contains the URL of the source code along with the compilation and packaging instructions.<br />
<br />
; [[makepkg]]: ABS shell command tool which reads the PKGBUILDs, automatically downloads and compiles the sources and creates a {{ic|.pkg.tar*}} according to the {{ic|PKGEXT}} array in {{ic|makepkg.conf}}. You may also use makepkg to make your own custom packages from the [[AUR]] or third-party sources. (See the [[Creating Packages]] wiki article.)<br />
<br />
; [[pacman]]: pacman is completely separate, but is necessarily invoked either by makepkg or manually, to install and remove the built packages and for fetching dependencies.<br />
<br />
; [[Arch User Repository|AUR]]: The Arch User Repository is separate from ABS but AUR (unsupported) PKGBUILDs are built using makepkg to compile and package up software. In contrast to the ABS tree on your local machine, the AUR exists as a website interface. It contains many thousands of user-contributed PKGBUILDs for software which is unavailable as an official Arch package. If you need to build a package outside the official Arch tree, chances are it is in the AUR.<br />
<br />
== Why would I want to use ABS? ==<br />
<br />
The Arch Build System is used to:<br />
* Compile or recompile a package, for any reason<br />
* Make and install new packages from source of software for which no packages are yet available (see [[Creating Packages]]) <br />
* Customize existing packages to fit your needs (enabling or disabling options, patching)<br />
* Rebuild your entire system using your compiler flags, "a la FreeBSD" (e.g. with [[pacbuilder]])<br />
* Cleanly build and install your own custom kernel (see [[Kernel Compilation]])<br />
* Get kernel modules working with your custom kernel<br />
* Easily compile and install a newer, older, beta, or development version of an Arch package by editing the version number in the PKGBUILD<br />
<br />
ABS is not necessary to use Arch Linux, but it is useful for automating certain tasks of source compilation.<br />
<br />
== How to use ABS? ==<br />
<br />
Building packages using abs consists of these steps:<br />
#Install the {{Pkg|abs}} package with [[pacman]].<br />
#Run {{ic|abs}} as root to create the ABS tree by synchronizing it with the Arch Linux server.<br />
#Copy the build files (usually residing under {{ic|/var/abs/<repo>/<pkgname>}}) to a build directory.<br />
#Navigate to that directory, edit the PKGBUILD (if desired/necessary) and do '''makepkg'''. <br />
#According to instructions in the PKGBUILD, makepkg will download the appropriate source tarball, unpack it, patch if desired, compile according to {{ic|CFLAGS}} specified in {{ic|makepkg.conf}}, and finally compress the built files into a package with the extension {{ic|.pkg.tar.gz}} or {{ic|.pkg.tar.xz}}. <br />
#Installing is as easy as doing {{ic|pacman -U <.pkg.tar.xz file>}}. Package removal is also handled by pacman.<br />
<br />
=== Install tools ===<br />
<br />
To use the ABS, you first need to install {{Pkg|abs}} from the [[Official Repositories|official repositories]]:<br />
<br />
# pacman -S abs<br />
<br />
This will grab the abs-sync scripts, various build scipts, and [[rsync]] (as a dependency, if you do not already have it).<br />
<br />
Before you can actually build anything, however, you will also need to grab basic compiling tools. These are handily collected in the package group '''base-devel'''. This group can be installed with:<br />
<br />
# pacman -S base-devel<br />
<br />
=== /etc/abs.conf ===<br />
<br />
As root, edit {{ic|/etc/abs.conf}} to include your desired repositories.<br />
<br />
Remove the {{ic|!}} in front of the appropriate repositories. For example:<br />
REPOS=(core extra community !testing)<br />
<br />
=== ABS tree ===<br />
<br />
The ABS tree is an SVN directory hierarchy located under {{ic|/var/abs}} and looks like this:<br />
<br />
{{bc|<nowiki><br />
| -- core/<br />
| || -- acl/<br />
| || || -- PKGBUILD<br />
| || -- attr/<br />
| || || -- PKGBUILD<br />
| || -- abs/<br />
| || || -- PKGBUILD<br />
| || -- autoconf/<br />
| || || -- PKGBUILD<br />
| || -- ...<br />
| -- extra/<br />
| || -- acpid/<br />
| || || -- PKGBUILD<br />
| || -- apache/<br />
| || || -- PKGBUILD<br />
| || -- ...<br />
| -- community/<br />
| || -- ...<br />
</nowiki>}}<br />
<br />
The ABS tree has exactly the same structure as the package database:<br />
<br />
* First-level: Reposistory name<br />
* Second-level: Package name directories<br />
* Third level: PKGBUILD (contains information needed to build a package) and other related files (patches, other files needed for building the package)<br />
<br />
The source code for the package is not present in the ABS directory. Instead, the '''PKGBUILD''' file contains a URL that will download the source code when the package is built. So the size of abs tree is quite small.<br />
<br />
==== Download ABS tree ====<br />
As root, run:<br />
# abs<br />
<br />
Your ABS tree is now created under {{ic|/var/abs}}. Note the appropriate branches of the ABS tree now exist and correspond to the ones you specified in {{ic|/etc/abs.conf}}. <br />
<br />
The abs command should be run periodically to keep in sync with the official repositories. Individual ABS package files can also be downloaded with:<br />
<br />
# abs <repository>/<package><br />
This way you do not have to check out the entire abs tree just to build one package.<br />
<br />
=== /etc/makepkg.conf ===<br />
<br />
{{ic|/etc/makepkg.conf}} specifies global environment variables and compiler flags which you may wish to edit if you are using an SMP system, or to specify other desired optimizations. The default settings are for i686 and x86_64 optimizations which will work fine for those architectures on single-CPU systems. (The defaults will work on SMP machines, but will only use one core/CPU when compiling -- see [[makepkg.conf]].)<br />
<br />
==== Set the PACKAGER variable in /etc/makepkg.conf ====<br />
<br />
Setting the PACKAGER variable in {{ic|/etc/makepkg.conf}} is an optional but ''highly recommended'' step. It allows a "flag" to quickly identify which packages have been built and/or installed by YOU, not the official maintainer! This is easily accomplished using '''expac''' available from the community repo:<br />
<br />
===== Showing All Packages (including those from AUR) =====<br />
$ grep myname /etc/makepkg.conf<br />
PACKAGER="myname <myemail@myserver.com>"<br />
<br />
$ expac "%n %p" | grep "myname" | column -t<br />
archey3 myname<br />
binutils myname<br />
gcc myname<br />
gcc-libs myname<br />
glibc myname<br />
tar myname<br />
<br />
===== Showing Only Packages Contained in Repos =====<br />
<br />
This example only shows packages contained in the repos defined in {{ic|/etc/pacman.conf}}:<br />
<br />
$ . /etc/makepkg.conf; grep -xvFf <(pacman -Qqm) <(expac "%n\t%p" | grep "$PACKAGER$" | cut -f1)<br />
binutils<br />
gcc<br />
gcc-libs<br />
glibc<br />
tar<br />
<br />
=== Create a build directory ===<br />
<br />
It is recommended to create a build directory where the actual compiling will take place; you should never modify the ABS tree by building within it, as data will be lost (overwritten) on each ABS update. It is good practice to use your home directory, though some Arch users prefer to create a 'local' directory under {{ic|/var/abs/}}, owned by a normal user. <br />
<br />
Create your build directory. e.g.:<br />
<br />
$ mkdir -p $HOME/abs<br />
<br />
Copy the ABS from the tree ({{ic|/var/abs/branch/category/pkgname}}) to the build directory, {{ic|/path/to/build/dir}}.<br />
<br />
=== Build package ===<br />
<br />
In our example, we will build the ''slim'' display manager package.<br />
<br />
Copy the slim ABS from the ABS tree to a build directory:<br />
$ cp -r /var/abs/extra/slim/ ~/abs<br />
<br />
Navigate to the build directory:<br />
$ cd ~/abs/slim<br />
<br />
Modify the PKGBUILD to add or remove support for components, to patch or to change package versions, etc. (optional):<br />
$ nano PKGBUILD<br />
<br />
Run makepkg as normal user (with {{ic|-s}} switch to install with automatic dependency handling):<br />
$ makepkg -s<br />
<br />
{{Note|Before complaining about missing (make) dependencies, remember that the {{Grp|base}} group is assumed to be installed on all Arch Linux systems. The group "base-devel" is assumed to be installed when building with '''makepkg'''. See [[#Install tools]].}}<br />
<br />
Install as root:<br />
# pacman -U slim-1.3.0-2-i686.pkg.tar.xz<br />
<br />
That's it. You have just built slim from source and cleanly installed it to your system with pacman. Package removal is also handled by pacman -- ({{ic|pacman -R slim}}).<br />
<br />
The ABS method adds a level of convenience and automation, while still maintaining complete transparency and control of the build and installation functions by including them in the PKGBUILD.<br />
<br />
==== fakeroot ====<br />
Essentially, the same steps are being executed in the traditional method (generally including the {{ic|./configure, make, make install}} steps) but the software is installed into a ''fake root'' environment. (A ''fake root'' is simply a subdirectory within the build directory that functions and behaves as the system's root directory. In conjunction with the '''fakeroot''' program, makepkg creates a fake root directory, and installs the compiled binaries and associated files into it, with '''root''' as owner.) The ''fake root'', or subdirectory tree containing the compiled software, is then compressed into an archive with the extension {{ic|.pkg.tar.xz}}, or a ''package''. When invoked, pacman then extracts the package (installs it) into the system's real root directory ({{ic|/}}).<br />
<br />
== Traditional method of compiling software, without ABS ==<br />
<br />
If you are not familiar with manually compiling software from source, you should know that most packages (but not all) can be built from source in this '''traditional way''':<br />
<br />
* Download source tarball from remote server, using web browser, ftp, wget or alternate method.<br />
<br />
* Decompress the source file:<br />
$ tar -xzf foo-0.99.tar.gz<br />
or<br />
$ tar -xjf foo-0.99.tar.bz2<br />
<br />
* Enter the directory:<br />
$ cd foo-0.99<br />
<br />
* Configure the package. Generally, there is a script called {{ic|configure}} in the source directory that is used to configure the package (add or remove support for things, choose the install destination, etc.) and check that your computer has all the software needed by the package. It can be run by:<br />
$ ./configure [option]<br />
<br />
You should first try the help to better understand how it works:<br />
$ ./configure --help<br />
<br />
If a {{ic|--prefix}} option is not passed to the script, ''most'' scripts will use {{ic|/usr/local}} as the install path, but others will use {{ic|/usr}}. For the sake of consistency, it is generally advised to pass the {{ic|1=--prefix=/usr/local}} option. It is good practice to install personal programs in {{ic|/usr/local}}, and to have the ones being managed by the distro in {{ic|/usr}}. This ensures personal program versions can coexist with those being managed by the distro's package manager -- in Arch's case, [[pacman]].<br />
$ ./configure --prefix=/usr/local<br />
<br />
* Compile the sources:<br />
<br />
$ make<br />
<br />
* Install:<br />
<br />
# make install<br />
<br />
* Removal would be accomplished by entering the source directory and running:<br />
<br />
# make uninstall<br />
<br />
However, you should always read the {{ic|INSTALL}} file to know how the package should be built and installed! '''Not all packages use the {{ic|configure; make; make install}} system!'''<br />
<br />
{{Note | The above traditional method of compiling source tarballs can, of course, still be used on Arch Linux. However, if you are not careful, files may become scattered throughout the filesystem that pacman (or any other package manager) will be unaware of. You should only use this method if you are experienced at manual compilation and system software tracking, as it can lead to future problems on Arch (or any distribution) if using a package manager.}}</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Arch_User_Repository&diff=202519Arch User Repository2012-05-22T15:36:47Z<p>Rnabioullin: /* FAQ */ mentioned guidelines</p>
<hr />
<div>[[Category:Arch User Repository]]<br />
[[Category:Package development]]<br />
[[Category:Package management]]<br />
[[tr:Arch_Kullanıcı_Deposu]]<br />
{{i18n|Arch User Repository}}<br />
[[fr:AUR]]<br />
{{Article summary start}}<br />
{{Article summary text|The Arch User Repository is a collection of user-submitted [[PKGBUILD]]s that supplement software available from the [[official repositories]]. This article describes how to build ''unsupported'' software packages from the AUR.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Package management overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|AUR Helpers}}<br />
{{Article summary wiki|AUR Trusted User Guidelines}}<br />
{{Article summary heading|Resources}}<br />
{{Article summary link|AUR Web Interface|https://aur.archlinux.org}}<br />
{{Article summary link|AUR Mailing List|http://www.archlinux.org/mailman/listinfo/aur-general}}<br />
{{Article summary end}}<br />
<br />
The Arch User Repository (AUR) is a community-driven repository for Arch users. It contains package descriptions (PKGBUILDs) that allow you to compile a package from source with [[makepkg]] and then install it via [[pacman]]. The AUR was created to organize and share new packages from the community and to help expedite popular packages' inclusion into the [[#.5Bcommunity.5D|[community]]] repository. This document explains how users can access and utilize the AUR.<br />
<br />
A good number of new packages that enter the official repositories start in the AUR. In the AUR, users are able to contribute their own package builds (PKGBUILD and related files). The AUR community has the ability to vote for or against packages in the AUR. If a package becomes popular enough -- provided it has a compatible license and good packaging technique -- it may be entered into the [community] repository (directly accessible by [[pacman]] or [[ABS|abs]]).<br />
<br />
==Getting started==<br />
Users can search and download PKGBUILDs from the [https://aur.archlinux.org AUR Web Interface]. These PKGBUILDs can be built into installable packages using [[makepkg]], then installed using pacman. <br />
<br />
* Install {{Grp|base-devel}} ({{ic|pacman -S base-devel}}), because members of this group are not explicitly required by AUR packages which may not build without them (more info in [https://bbs.archlinux.org/viewtopic.php?pid=632355 this thread]).<br />
* Read the remainder of this article for more info and a short tutorial on installing AUR packages.<br />
* Visit the [https://aur.archlinux.org AUR Web Interface] to inform yourself on updates and happenings. There you will also find statistics and an up-to-date list of newest available packages available in AUR.<br />
* Glance over the [[#FAQ]] for answers to the most common questions.<br />
* You may wish to adjust {{ic|/etc/makepkg.conf}} to better optimize for your processor prior to building packages from the AUR. A significant improvement in compile times can be realized on systems with multi-core processors by adjusting the MAKEFLAGS variable. Users can also enable hardware-specific optimizations in GCC via the CFLAGS variable. See [[makepkg.conf]] for more information.<br />
<br />
==History==<br />
The following items are listed for historical purposes only. They have since been superseded by the AUR and are no longer available.<br />
<br />
At the beginning, there was {{ic|<nowiki>ftp://ftp.archlinux.org/incoming</nowiki>}}, and people contributed by simply uploading the PKGBUILD, the needed supplementary files, and the built package itself to the server. The package and associated files remained there until a [[Package Maintainer]] saw the program and adopted it.<br />
<br />
Then the Trusted User Repositories were born. Certain individuals in the community were allowed to host their own repositories for anyone to use. The AUR expanded on this basis, with the aim of making it both more flexible and more usable. In fact, the AUR maintainers are still referred to as TUs (Trusted Users).<br />
<br />
==Searching==<br />
The AUR web interface can be found [https://aur.archlinux.org/ here], and an interface suitable for accessing the AUR from a script (for example) can be found [https://aur.archlinux.org/rpc.php here]<br />
<br />
Queries search package names and descriptions via a MySQL LIKE comparison. This allows for more flexible search criteria (e.g. try searching for 'tool%like%grep' instead of 'tool like grep'). If you need to search for a description that contains '%', escape it with '\%'.<br />
<br />
==Installing packages==<br />
Installing packages from the AUR is a relatively simple process. Essentially:<br />
# Acquire the tarball which contains the PKGBUILD and possibly other required files<br />
# Extract the tarball (preferably in a folder set aside just for builds from the AUR)<br />
# Run '''makepkg''' in the directory where the files are saved ("makepkg -s" will auto-resolve dependencies with pacman)<br />
# Install the resulting package with '''pacman''':<br />
<br />
# pacman -U /path/to/pkg.tar.xz<br />
<br />
[[AUR Helpers]] add seamless access to the AUR. They vary in their features, but can ease in searching, fetching, building, and installing from PKGBUILDs found in the AUR. All of these scripts can be found in the AUR.<br />
<br />
{{Note|There is not and will never be an ''official'' mechanism for installing build material from the AUR. All users should be familiar with the build process.}}<br />
<br />
What follows is a detailed example of installation of a package called "foo".<br />
<br />
===Prerequisites===<br />
First ensure that the necessary tools are installed. The package group "base-devel" should be sufficient; it includes ''make'' and other tools needed for compiling from source.<br />
<br />
{{Warning|Packages in the AUR assume "base-devel" is installed, and will not list members of this group as dependencies even if the package cannot be built without them. Please ensure this group is installed before complaining about failed builds.}}<br />
<br />
# pacman -S base-devel<br />
<br />
Next choose an appropriate build directory. A build directory is simply a directory where the package will be made or "built" and can be any directory. Examples of commonly used directories are:<br />
<br />
~/builds<br />
<br />
or if using ABS (the [[Arch Build System]]):<br />
<br />
/var/abs/local<br />
<br />
For more information on ABS read the [[Arch Build System]] article. The example will use {{ic|~/builds}} as the build directory.<br />
<br />
===Acquire build files===<br />
Locate the package in the AUR. This is done using the search feature (text field at the top of the [https://aur.archlinux.org/ AUR home page]). Clicking the application's name in the search list brings up an information page on the package. Read through the description to confirm that this is the desired package, note when the package was last updated, and read any comments.<br />
<br />
Download the necessary build files. From the package's information page download the build files by clicking the "Tarball" link on the left-hand side near the end of the package details. This file should be saved to the build directory or otherwise copied to the directory after downloading. In this example, the file is called "foo.tar.gz" (standard format is ''pkgname''.tar.gz, if it has been properly submitted).<br />
<br />
===Build the package===<br />
Extract the tarball. Change directories to the build directory if not already there and extract the build files.<br />
<br />
$ cd ~/builds<br />
$ tar -xvzf foo.tar.gz<br />
<br />
This should create a new directory called "foo" in the build directory.<br />
<br />
{{Warning|'''Carefully check all files.''' {{ic|cd}} to the newly created directory and carefully check the {{ic|PKGBUILD}} and any {{ic|.install}} file for malicious commands. {{ic|PKGBUILD}}s are bash scripts containing functions to be executed by {{ic|makepkg}}: these functions can contain ''any'' valid commands or bash syntax, so it is totally possible for a {{ic|PKGBUILD}} to contain dangerous commands through malice or ignorance on the part of the author. Since {{ic|makepkg}} uses fakeroot (and should never be run as root), there is some level of protection but you should never count on it. If in doubt, do not build the package and seek advice on the forums or mailing list.}}<br />
<br />
$ cd foo<br />
$ nano PKGBUILD<br />
$ nano foo.install<br />
<br />
Make the package. After manually confirming the integrity of the files, run [[makepkg]] as a normal user in the build directory.<br />
<br />
$ makepkg -s<br />
<br />
The {{ic|-s}} switch will use [[sudo]] to install any needed dependencies. If the use of sudo is undesirable, manually install required dependencies beforehand and exclude the {{ic|-s}} in the above command.<br />
<br />
===Install the package===<br />
Install the package using pacman. A tarball should have been created named:<br />
<br />
<''application name''>-<''application version number''>-<''package revision number''>-<''architecture''>.pkg.tar.xz<br />
<br />
This package can be installed using pacman's "upgrade" command:<br />
<br />
# pacman -U foo-0.1-1-i686.pkg.tar.xz <br />
<br />
These manually-installed packages are called foreign packages - packages which have not originated from any repository known to pacman. To list all foreign packages:<br />
$ pacman -Qm <br />
<br />
{{Note|The above example is only a brief summary of the package building process. A visit to the [[makepkg]] and [[ABS]] pages will provide more detail and is highly recommended (particularly for first-time users).}}<br />
<br />
==Feedback==<br />
The [https://aur.archlinux.org AUR Web Interface] has a comments facility that allows users to provide suggestions and feedback on improvements to the PKGBUILD contributor. Avoid pasting patches or PKGBUILDs into the comments section: they quickly become obsolete and just end up needlessly taking up lots of space. Instead email those files to the maintainer, or even use a [[pastebin Clients|pastebin]].<br />
<br />
One of the easiest activities for '''all''' Arch users is to browse the AUR and '''vote''' for their favourite packages using the online interface. All packages are eligible for adoption by a TU for inclusion in [community], and the vote count is one of the considerations in that process; it is in everyone's interest to vote!<br />
<br />
==Sharing packages==<br />
The user plays an essential role in the AUR, which cannot fulfill its potential without the support, involvement, and contribution of the wider user community. The life-cycle of an AUR package starts and ends with the user and requires the user to contribute in several ways.<br />
<br />
Users can '''share''' PKGBUILDs using the Arch User Repository. It does not contain any binary packages but allows users to upload PKGBUILDs that can be downloaded by others. These PKGBUILDs are completely unofficial and have not been thoroughly vetted, so they should be used at your own risk.<br />
<br />
===Submitting packages===<br />
After logging in to the AUR web interface, a user can [https://aur.archlinux.org/pkgsubmit.php submit] a gzipped tarball ({{ic|.tar.gz}}) of a directory containing build files for a package. The directory inside the tarball should contain a [[PKGBUILD]], any {{ic|.install}} files, patches, etc. ('''absolutely''' no binaries). Examples of what such a directory should look like can be seen inside {{ic|/var/abs}} if the [[Arch Build System]] was installed.<br />
<br />
The tarball can be created with the following command:<br />
$ makepkg --source <br />
<br />
Note that this is a gzipped tarball; assuming you are uploading a package called ''libfoo'', when you create the file it should look similar to this:<br />
<br />
# List contents of tarball.<br />
$ tar tf libfoo-0.1-1.src.tar.gz<br />
libfoo/<br />
libfoo/PKGBUILD<br />
libfoo/libfoo.install<br />
<br />
When submitting a package, observe the following rules: <br />
* Check the [http://www.archlinux.org/packages/ package database] for the package. If it exists, '''do not''' submit the package. If the current package is broken or is lacking an included feature then please file a [https://bugs.archlinux.org/ bug report].<br />
* Check the AUR for the package. If it is currently maintained, changes can be submitted in a comment for the maintainer's attention. If it is unmaintained, the package can be adopted and updated as required. Do not create duplicate packages.<br />
* Verify carefully that what you are uploading is correct. All contributors must read and adhere to the [[Arch Packaging Standards]] when writing PKGBUILDs. This is essential to the smooth running and general success of the AUR. Remember that you are not going to earn any credit or respect from your peers by wasting their time with a bad PKGBUILD.<br />
* Packages that contain binaries or that are very poorly written may be deleted without warning.<br />
* If you are unsure about the package (or the build/submission process) in any way, submit the PKGBUILD to the [https://mailman.archlinux.org/mailman/listinfo/ AUR Mailing List] or the [https://bbs.archlinux.org/viewforum.php?id=4 AUR boards] on the forum for public review before adding it to the AUR.<br />
* Make sure the package is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission.<br />
* The AUR and official repositories are intended for packages which install generally software and software-related content, including one or more of the following: executable(s); config file(s); online or offline documentation for specific software or the Arch Linux distribution as a whole; media intended to be used directly by software.<br />
* Gain some experience before submitting packages. Build a few packages to learn the process and then submit.<br />
* If you submit a {{ic|package.tar.gz}} with a file named '{{ic|package}}' in it you will get an error: 'Could not change to directory {{ic|/home/aur/unsupported/package/package}}'. To resolve this, rename the file named '{{ic|package}}' to something else, for example, '{{ic|package.rc}}'. When it is installed in the {{ic|pkg}} directory you may rename it back to '{{ic|package}}'.<br />
Make sure to also read [[Arch Packaging Standards#Submitting packages to the AUR]].<br />
<br />
===Maintaining packages===<br />
* If you maintain a package and want to update the PKGBUILD for your package just resubmit it.<br />
* Check for feedback and comments from other users and try to incorporate any improvements they suggest; consider it a learning process!<br />
* Please do not just submit and forget about packages! It is the maintainer's job to maintain the package by checking for updates and improving the PKGBUILD.<br />
* If you do not want to continue to maintain the package for some reason, {{ic|disown}} the package using the AUR web interface and/or post a message to the AUR Mailing List.<br />
<br />
===Other requests===<br />
* Disownment requests and removal requests go to the aur-general mailing list for TUs and other users to decide upon.<br />
* '''Include package name and URL to AUR page''', preferably with a footnote [1].<br />
* Disownment requests will be granted two weeks after the current maintainer has been contacted by email and did not react.<br />
* '''Package merging has been implemented''', users still have to resubmit a package under a new name and may request merging of the old version's comments and votes on the mailing list<br />
* Removal requests require the following information:<br />
** Package name and URL to AUR page<br />
** Reason for deletion, at least a short note <br> '''Notice:''' A package's comments does not sufficiently point out the reasons why a package is up for deletion. Because as soon as a TU takes action, the only place where such information can be obtained is the aur-general mailing list.<br />
** Include supporting details, like when a package is provided by another package, if you are the maintainer yourself, it's renamed and the original owner agreed, etc.<br />
<br />
Removal requests can be disapproved, in which case you'll likely be advised to disown the package for a future packager's reference.<br />
<br />
==[community]==<br />
The [community] repository, maintained by [[Trusted Users]], contains the most popular packages from the AUR. It is enabled by default in {{ic|/etc/pacman.conf}}. If [community] has been disabled or removed, it can be enabled by uncommenting or adding these two lines: <br />
<br />
{{hc|/etc/pacman.conf|<nowiki><br />
...<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
...<br />
</nowiki>}}<br />
<br />
[community], unlike the AUR, contains binary packages that can be installed directly with [[pacman]] and the build files can also be accessed with the [[Arch Build System|ABS]]. Some of these packages may eventually make the transition to the [core] or [extra] repositories as the developers consider them crucial to the distribution.<br />
<br />
Users can also access the [community] build files by editing {{ic|/etc/abs.conf}} and enabling the [community] repository in the {{ic|REPOS}} array.<br />
<br />
==Git Repo==<br />
A Git Repo of the AUR is maintained by Thomas Dziedzic providing package history among other things. It is updated at least once a day. To clone the repository (several hundred MB):<br />
<br />
$ git clone git://pkgbuild.com/aur-mirror.git<br />
<br />
[http://pkgbuild.com/git/aur-mirror.git/ Web interface], [http://pkgbuild.com/~td123/readme Readme], [http://bbs.archlinux.org/viewtopic.php?id=113099 Forum thread]<br />
<br />
==FAQ==<br />
{{FAQ<br />
|question=What is the AUR?<br />
|answer=The AUR (Arch User Repository) is a place where the Arch Linux community can upload [[PKGBUILD]]s of applications, libraries, etc., and share them with the entire community. Fellow users can then vote for their favorites to be moved into the [community] repository to be shared with Arch Linux users in binary form.}}<br />
<br />
{{FAQ<br />
|question=What kind of packages are permitted on the AUR?<br />
|answer=The packages on the AUR are merely "build scripts", i.e recipes to build binaries for pacman. For most cases, everything is permitted, subject to the abovementioned usefulness and scope guidelines, as long as you are in compliance with the licensing terms of the content. For other cases, where it is mentioned that "you may not link" to downloads, i.e contents that are not redistributable, you may only use the file name itself as the source. This means and requires users to already have the restricted source in the build directory prior to building the package. When in doubt, ask.}}<br />
<br />
{{FAQ<br />
|question=What is a TU?<br />
|answer=A [[AUR Trusted User Guidelines|TU (Trusted User)]] is a person who is chosen to oversee AUR and the [community] repository. They're the ones who maintain popular PKGBUILDs in [community], and overall keep the AUR running.}}<br />
<br />
{{FAQ<br />
|question=What's the difference between the Arch User Repository and [community]?<br />
|answer=The Arch User Repository is where all PKGBUILDs that users submit are stored, and must be built manually with [[makepkg]]. When PKGBUILDs receive enough votes, they are moved into the [community] repository, where the TUs maintain binary packages that can be installed with [[pacman]].}}<br />
<br />
{{FAQ<br />
|question=How many votes does it take to get a PKGBUILD into [community]?<br />
|answer=Usually, at least 10 votes are required for something to move into [community]. However, if a TU wants to support a package, it will often be found in the repository.}}<br />
<br />
{{FAQ<br />
|question=How do I make a PKGBUILD?<br />
|answer=The best resource is [[Creating Packages]]. Remember to look in AUR before creating the PKGBUILD as to not duplicate efforts.}}<br />
<br />
{{FAQ<br />
|question=I'm trying to do {{ic|pacman -S foo}}; it isn't working but I know it's in [community]<br />
|answer=You probably haven't enabled [community] in your {{ic|/etc/pacman.conf}}. Just uncomment the relevant lines.<br />
If [community] is enabled in your {{ic|/etc/pacman.conf}} try running {{ic|pacman -S -y}} first to synchronize the pkgcache before trying your package again.}}<br />
<br />
{{FAQ<br />
|question=Foo in AUR is outdated; what do I do?<br />
|answer=For starters, you can flag packages out-of-date. If it stays out-of-date for an extended period of time, the best thing to do is email the maintainer. If there is no response from the maintainer after two weeks, you could send mail to the aur-general mailing list to have a TU orphan the PKGBUILD if you're willing to maintain it yourself.}}<br />
<br />
{{FAQ<br />
|question=I have a PKGBUILD I would like to submit; can someone check it to see if there are any errors?<br />
|answer=If you would like to have your PKGBUILD critiqued, post it on the aur-general mailing list to get feedback from the TUs and fellow AUR members. You could also get help from the [[ArchChannel|IRC channel]], #archlinux on irc.freenode.net. You can also<br />
use [[namcap]] to check your PKGBUILD and the resulting package for errors.}}<br />
<br />
{{FAQ<br />
|question=Foo in AUR doesn't compile when I do {{ic|makepkg}}; what should I do?<br />
|answer=You are probably missing something trivial.<br />
<br />
# Run {{ic|pacman -Syyu}} before compiling anything with {{ic|makepkg}} as the problem may be that your system is not up-to-date.<br />
# Ensure you have both "base" and "base-devel" groups installed.<br />
# Try using the "{{ic|-s}}" option with {{ic|makepkg}} to check and install all the dependencies needed before starting the build process.<br />
<br />
Be sure to first read the PKGBUILD and the comments on the AUR page of the package in question.<br />
The reason might not be trivial after all. Custom CFLAGS, LDFLAGS and MAKEFLAGS can cause failures. It's also possible that the PKGBUILD is broken for everyone. If you cannot figure it out on your own, just report it to the maintainer e.g. by posting the errors you are getting in the comments on the AUR page.}}<br />
<br />
{{FAQ<br />
|question=How can I speed up repeated build processes?<br />
|answer=If you frequently compile code that uses gcc - say, a git or SVN package - you may find [[ccache]], short for "compiler cache", useful.}}<br />
<br />
{{FAQ<br />
|question=How do I access unsupported packages?<br />
|answer=See [[#Installing packages]]}}<br />
<br />
{{FAQ<br />
|question=How can I upload to AUR without using the web interface?<br />
|answer=You can use {{AUR|aurploader}}, {{AUR|aurup}} or {{AUR|burp}} -- these are command-line programs.}}</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Arch_User_Repository&diff=202517Arch User Repository2012-05-22T15:32:48Z<p>Rnabioullin: /* Submitting packages */ Added guideline on the scope of content.</p>
<hr />
<div>[[Category:Arch User Repository]]<br />
[[Category:Package development]]<br />
[[Category:Package management]]<br />
[[tr:Arch_Kullanıcı_Deposu]]<br />
{{i18n|Arch User Repository}}<br />
[[fr:AUR]]<br />
{{Article summary start}}<br />
{{Article summary text|The Arch User Repository is a collection of user-submitted [[PKGBUILD]]s that supplement software available from the [[official repositories]]. This article describes how to build ''unsupported'' software packages from the AUR.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Package management overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|AUR Helpers}}<br />
{{Article summary wiki|AUR Trusted User Guidelines}}<br />
{{Article summary heading|Resources}}<br />
{{Article summary link|AUR Web Interface|https://aur.archlinux.org}}<br />
{{Article summary link|AUR Mailing List|http://www.archlinux.org/mailman/listinfo/aur-general}}<br />
{{Article summary end}}<br />
<br />
The Arch User Repository (AUR) is a community-driven repository for Arch users. It contains package descriptions (PKGBUILDs) that allow you to compile a package from source with [[makepkg]] and then install it via [[pacman]]. The AUR was created to organize and share new packages from the community and to help expedite popular packages' inclusion into the [[#.5Bcommunity.5D|[community]]] repository. This document explains how users can access and utilize the AUR.<br />
<br />
A good number of new packages that enter the official repositories start in the AUR. In the AUR, users are able to contribute their own package builds (PKGBUILD and related files). The AUR community has the ability to vote for or against packages in the AUR. If a package becomes popular enough -- provided it has a compatible license and good packaging technique -- it may be entered into the [community] repository (directly accessible by [[pacman]] or [[ABS|abs]]).<br />
<br />
==Getting started==<br />
Users can search and download PKGBUILDs from the [https://aur.archlinux.org AUR Web Interface]. These PKGBUILDs can be built into installable packages using [[makepkg]], then installed using pacman. <br />
<br />
* Install {{Grp|base-devel}} ({{ic|pacman -S base-devel}}), because members of this group are not explicitly required by AUR packages which may not build without them (more info in [https://bbs.archlinux.org/viewtopic.php?pid=632355 this thread]).<br />
* Read the remainder of this article for more info and a short tutorial on installing AUR packages.<br />
* Visit the [https://aur.archlinux.org AUR Web Interface] to inform yourself on updates and happenings. There you will also find statistics and an up-to-date list of newest available packages available in AUR.<br />
* Glance over the [[#FAQ]] for answers to the most common questions.<br />
* You may wish to adjust {{ic|/etc/makepkg.conf}} to better optimize for your processor prior to building packages from the AUR. A significant improvement in compile times can be realized on systems with multi-core processors by adjusting the MAKEFLAGS variable. Users can also enable hardware-specific optimizations in GCC via the CFLAGS variable. See [[makepkg.conf]] for more information.<br />
<br />
==History==<br />
The following items are listed for historical purposes only. They have since been superseded by the AUR and are no longer available.<br />
<br />
At the beginning, there was {{ic|<nowiki>ftp://ftp.archlinux.org/incoming</nowiki>}}, and people contributed by simply uploading the PKGBUILD, the needed supplementary files, and the built package itself to the server. The package and associated files remained there until a [[Package Maintainer]] saw the program and adopted it.<br />
<br />
Then the Trusted User Repositories were born. Certain individuals in the community were allowed to host their own repositories for anyone to use. The AUR expanded on this basis, with the aim of making it both more flexible and more usable. In fact, the AUR maintainers are still referred to as TUs (Trusted Users).<br />
<br />
==Searching==<br />
The AUR web interface can be found [https://aur.archlinux.org/ here], and an interface suitable for accessing the AUR from a script (for example) can be found [https://aur.archlinux.org/rpc.php here]<br />
<br />
Queries search package names and descriptions via a MySQL LIKE comparison. This allows for more flexible search criteria (e.g. try searching for 'tool%like%grep' instead of 'tool like grep'). If you need to search for a description that contains '%', escape it with '\%'.<br />
<br />
==Installing packages==<br />
Installing packages from the AUR is a relatively simple process. Essentially:<br />
# Acquire the tarball which contains the PKGBUILD and possibly other required files<br />
# Extract the tarball (preferably in a folder set aside just for builds from the AUR)<br />
# Run '''makepkg''' in the directory where the files are saved ("makepkg -s" will auto-resolve dependencies with pacman)<br />
# Install the resulting package with '''pacman''':<br />
<br />
# pacman -U /path/to/pkg.tar.xz<br />
<br />
[[AUR Helpers]] add seamless access to the AUR. They vary in their features, but can ease in searching, fetching, building, and installing from PKGBUILDs found in the AUR. All of these scripts can be found in the AUR.<br />
<br />
{{Note|There is not and will never be an ''official'' mechanism for installing build material from the AUR. All users should be familiar with the build process.}}<br />
<br />
What follows is a detailed example of installation of a package called "foo".<br />
<br />
===Prerequisites===<br />
First ensure that the necessary tools are installed. The package group "base-devel" should be sufficient; it includes ''make'' and other tools needed for compiling from source.<br />
<br />
{{Warning|Packages in the AUR assume "base-devel" is installed, and will not list members of this group as dependencies even if the package cannot be built without them. Please ensure this group is installed before complaining about failed builds.}}<br />
<br />
# pacman -S base-devel<br />
<br />
Next choose an appropriate build directory. A build directory is simply a directory where the package will be made or "built" and can be any directory. Examples of commonly used directories are:<br />
<br />
~/builds<br />
<br />
or if using ABS (the [[Arch Build System]]):<br />
<br />
/var/abs/local<br />
<br />
For more information on ABS read the [[Arch Build System]] article. The example will use {{ic|~/builds}} as the build directory.<br />
<br />
===Acquire build files===<br />
Locate the package in the AUR. This is done using the search feature (text field at the top of the [https://aur.archlinux.org/ AUR home page]). Clicking the application's name in the search list brings up an information page on the package. Read through the description to confirm that this is the desired package, note when the package was last updated, and read any comments.<br />
<br />
Download the necessary build files. From the package's information page download the build files by clicking the "Tarball" link on the left-hand side near the end of the package details. This file should be saved to the build directory or otherwise copied to the directory after downloading. In this example, the file is called "foo.tar.gz" (standard format is ''pkgname''.tar.gz, if it has been properly submitted).<br />
<br />
===Build the package===<br />
Extract the tarball. Change directories to the build directory if not already there and extract the build files.<br />
<br />
$ cd ~/builds<br />
$ tar -xvzf foo.tar.gz<br />
<br />
This should create a new directory called "foo" in the build directory.<br />
<br />
{{Warning|'''Carefully check all files.''' {{ic|cd}} to the newly created directory and carefully check the {{ic|PKGBUILD}} and any {{ic|.install}} file for malicious commands. {{ic|PKGBUILD}}s are bash scripts containing functions to be executed by {{ic|makepkg}}: these functions can contain ''any'' valid commands or bash syntax, so it is totally possible for a {{ic|PKGBUILD}} to contain dangerous commands through malice or ignorance on the part of the author. Since {{ic|makepkg}} uses fakeroot (and should never be run as root), there is some level of protection but you should never count on it. If in doubt, do not build the package and seek advice on the forums or mailing list.}}<br />
<br />
$ cd foo<br />
$ nano PKGBUILD<br />
$ nano foo.install<br />
<br />
Make the package. After manually confirming the integrity of the files, run [[makepkg]] as a normal user in the build directory.<br />
<br />
$ makepkg -s<br />
<br />
The {{ic|-s}} switch will use [[sudo]] to install any needed dependencies. If the use of sudo is undesirable, manually install required dependencies beforehand and exclude the {{ic|-s}} in the above command.<br />
<br />
===Install the package===<br />
Install the package using pacman. A tarball should have been created named:<br />
<br />
<''application name''>-<''application version number''>-<''package revision number''>-<''architecture''>.pkg.tar.xz<br />
<br />
This package can be installed using pacman's "upgrade" command:<br />
<br />
# pacman -U foo-0.1-1-i686.pkg.tar.xz <br />
<br />
These manually-installed packages are called foreign packages - packages which have not originated from any repository known to pacman. To list all foreign packages:<br />
$ pacman -Qm <br />
<br />
{{Note|The above example is only a brief summary of the package building process. A visit to the [[makepkg]] and [[ABS]] pages will provide more detail and is highly recommended (particularly for first-time users).}}<br />
<br />
==Feedback==<br />
The [https://aur.archlinux.org AUR Web Interface] has a comments facility that allows users to provide suggestions and feedback on improvements to the PKGBUILD contributor. Avoid pasting patches or PKGBUILDs into the comments section: they quickly become obsolete and just end up needlessly taking up lots of space. Instead email those files to the maintainer, or even use a [[pastebin Clients|pastebin]].<br />
<br />
One of the easiest activities for '''all''' Arch users is to browse the AUR and '''vote''' for their favourite packages using the online interface. All packages are eligible for adoption by a TU for inclusion in [community], and the vote count is one of the considerations in that process; it is in everyone's interest to vote!<br />
<br />
==Sharing packages==<br />
The user plays an essential role in the AUR, which cannot fulfill its potential without the support, involvement, and contribution of the wider user community. The life-cycle of an AUR package starts and ends with the user and requires the user to contribute in several ways.<br />
<br />
Users can '''share''' PKGBUILDs using the Arch User Repository. It does not contain any binary packages but allows users to upload PKGBUILDs that can be downloaded by others. These PKGBUILDs are completely unofficial and have not been thoroughly vetted, so they should be used at your own risk.<br />
<br />
===Submitting packages===<br />
After logging in to the AUR web interface, a user can [https://aur.archlinux.org/pkgsubmit.php submit] a gzipped tarball ({{ic|.tar.gz}}) of a directory containing build files for a package. The directory inside the tarball should contain a [[PKGBUILD]], any {{ic|.install}} files, patches, etc. ('''absolutely''' no binaries). Examples of what such a directory should look like can be seen inside {{ic|/var/abs}} if the [[Arch Build System]] was installed.<br />
<br />
The tarball can be created with the following command:<br />
$ makepkg --source <br />
<br />
Note that this is a gzipped tarball; assuming you are uploading a package called ''libfoo'', when you create the file it should look similar to this:<br />
<br />
# List contents of tarball.<br />
$ tar tf libfoo-0.1-1.src.tar.gz<br />
libfoo/<br />
libfoo/PKGBUILD<br />
libfoo/libfoo.install<br />
<br />
When submitting a package, observe the following rules: <br />
* Check the [http://www.archlinux.org/packages/ package database] for the package. If it exists, '''do not''' submit the package. If the current package is broken or is lacking an included feature then please file a [https://bugs.archlinux.org/ bug report].<br />
* Check the AUR for the package. If it is currently maintained, changes can be submitted in a comment for the maintainer's attention. If it is unmaintained, the package can be adopted and updated as required. Do not create duplicate packages.<br />
* Verify carefully that what you are uploading is correct. All contributors must read and adhere to the [[Arch Packaging Standards]] when writing PKGBUILDs. This is essential to the smooth running and general success of the AUR. Remember that you are not going to earn any credit or respect from your peers by wasting their time with a bad PKGBUILD.<br />
* Packages that contain binaries or that are very poorly written may be deleted without warning.<br />
* If you are unsure about the package (or the build/submission process) in any way, submit the PKGBUILD to the [https://mailman.archlinux.org/mailman/listinfo/ AUR Mailing List] or the [https://bbs.archlinux.org/viewforum.php?id=4 AUR boards] on the forum for public review before adding it to the AUR.<br />
* Make sure the package is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission.<br />
* The AUR and official repositories are intended for packages which install generally software and software-related content, including one or more of the following: executable(s); config file(s); online or offline documentation for specific software or the Arch Linux distribution as a whole; media intended to be used directly by software.<br />
* Gain some experience before submitting packages. Build a few packages to learn the process and then submit.<br />
* If you submit a {{ic|package.tar.gz}} with a file named '{{ic|package}}' in it you will get an error: 'Could not change to directory {{ic|/home/aur/unsupported/package/package}}'. To resolve this, rename the file named '{{ic|package}}' to something else, for example, '{{ic|package.rc}}'. When it is installed in the {{ic|pkg}} directory you may rename it back to '{{ic|package}}'.<br />
Make sure to also read [[Arch Packaging Standards#Submitting packages to the AUR]].<br />
<br />
===Maintaining packages===<br />
* If you maintain a package and want to update the PKGBUILD for your package just resubmit it.<br />
* Check for feedback and comments from other users and try to incorporate any improvements they suggest; consider it a learning process!<br />
* Please do not just submit and forget about packages! It is the maintainer's job to maintain the package by checking for updates and improving the PKGBUILD.<br />
* If you do not want to continue to maintain the package for some reason, {{ic|disown}} the package using the AUR web interface and/or post a message to the AUR Mailing List.<br />
<br />
===Other requests===<br />
* Disownment requests and removal requests go to the aur-general mailing list for TUs and other users to decide upon.<br />
* '''Include package name and URL to AUR page''', preferably with a footnote [1].<br />
* Disownment requests will be granted two weeks after the current maintainer has been contacted by email and did not react.<br />
* '''Package merging has been implemented''', users still have to resubmit a package under a new name and may request merging of the old version's comments and votes on the mailing list<br />
* Removal requests require the following information:<br />
** Package name and URL to AUR page<br />
** Reason for deletion, at least a short note <br> '''Notice:''' A package's comments does not sufficiently point out the reasons why a package is up for deletion. Because as soon as a TU takes action, the only place where such information can be obtained is the aur-general mailing list.<br />
** Include supporting details, like when a package is provided by another package, if you are the maintainer yourself, it's renamed and the original owner agreed, etc.<br />
<br />
Removal requests can be disapproved, in which case you'll likely be advised to disown the package for a future packager's reference.<br />
<br />
==[community]==<br />
The [community] repository, maintained by [[Trusted Users]], contains the most popular packages from the AUR. It is enabled by default in {{ic|/etc/pacman.conf}}. If [community] has been disabled or removed, it can be enabled by uncommenting or adding these two lines: <br />
<br />
{{hc|/etc/pacman.conf|<nowiki><br />
...<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
...<br />
</nowiki>}}<br />
<br />
[community], unlike the AUR, contains binary packages that can be installed directly with [[pacman]] and the build files can also be accessed with the [[Arch Build System|ABS]]. Some of these packages may eventually make the transition to the [core] or [extra] repositories as the developers consider them crucial to the distribution.<br />
<br />
Users can also access the [community] build files by editing {{ic|/etc/abs.conf}} and enabling the [community] repository in the {{ic|REPOS}} array.<br />
<br />
==Git Repo==<br />
A Git Repo of the AUR is maintained by Thomas Dziedzic providing package history among other things. It is updated at least once a day. To clone the repository (several hundred MB):<br />
<br />
$ git clone git://pkgbuild.com/aur-mirror.git<br />
<br />
[http://pkgbuild.com/git/aur-mirror.git/ Web interface], [http://pkgbuild.com/~td123/readme Readme], [http://bbs.archlinux.org/viewtopic.php?id=113099 Forum thread]<br />
<br />
==FAQ==<br />
{{FAQ<br />
|question=What is the AUR?<br />
|answer=The AUR (Arch User Repository) is a place where the Arch Linux community can upload [[PKGBUILD]]s of applications, libraries, etc., and share them with the entire community. Fellow users can then vote for their favorites to be moved into the [community] repository to be shared with Arch Linux users in binary form.}}<br />
<br />
{{FAQ<br />
|question=What kind of packages are permitted on the AUR?<br />
|answer=The packages on the AUR are merely "build scripts", i.e recipes to build binaries for pacman. For most cases, everything is permitted, as long as you are in compliance with the licensing terms of the content. For other cases, where it is mentioned that "you may not link" to downloads, i.e contents that are not redistributable, you may only use the file name itself as the source. This means and requires users to already have the restricted source in the build directory prior to building the package. When in doubt, ask.}}<br />
<br />
{{FAQ<br />
|question=What is a TU?<br />
|answer=A [[AUR Trusted User Guidelines|TU (Trusted User)]] is a person who is chosen to oversee AUR and the [community] repository. They're the ones who maintain popular PKGBUILDs in [community], and overall keep the AUR running.}}<br />
<br />
{{FAQ<br />
|question=What's the difference between the Arch User Repository and [community]?<br />
|answer=The Arch User Repository is where all PKGBUILDs that users submit are stored, and must be built manually with [[makepkg]]. When PKGBUILDs receive enough votes, they are moved into the [community] repository, where the TUs maintain binary packages that can be installed with [[pacman]].}}<br />
<br />
{{FAQ<br />
|question=How many votes does it take to get a PKGBUILD into [community]?<br />
|answer=Usually, at least 10 votes are required for something to move into [community]. However, if a TU wants to support a package, it will often be found in the repository.}}<br />
<br />
{{FAQ<br />
|question=How do I make a PKGBUILD?<br />
|answer=The best resource is [[Creating Packages]]. Remember to look in AUR before creating the PKGBUILD as to not duplicate efforts.}}<br />
<br />
{{FAQ<br />
|question=I'm trying to do {{ic|pacman -S foo}}; it isn't working but I know it's in [community]<br />
|answer=You probably haven't enabled [community] in your {{ic|/etc/pacman.conf}}. Just uncomment the relevant lines.<br />
If [community] is enabled in your {{ic|/etc/pacman.conf}} try running {{ic|pacman -S -y}} first to synchronize the pkgcache before trying your package again.}}<br />
<br />
{{FAQ<br />
|question=Foo in AUR is outdated; what do I do?<br />
|answer=For starters, you can flag packages out-of-date. If it stays out-of-date for an extended period of time, the best thing to do is email the maintainer. If there is no response from the maintainer after two weeks, you could send mail to the aur-general mailing list to have a TU orphan the PKGBUILD if you're willing to maintain it yourself.}}<br />
<br />
{{FAQ<br />
|question=I have a PKGBUILD I would like to submit; can someone check it to see if there are any errors?<br />
|answer=If you would like to have your PKGBUILD critiqued, post it on the aur-general mailing list to get feedback from the TUs and fellow AUR members. You could also get help from the [[ArchChannel|IRC channel]], #archlinux on irc.freenode.net. You can also<br />
use [[namcap]] to check your PKGBUILD and the resulting package for errors.}}<br />
<br />
{{FAQ<br />
|question=Foo in AUR doesn't compile when I do {{ic|makepkg}}; what should I do?<br />
|answer=You are probably missing something trivial.<br />
<br />
# Run {{ic|pacman -Syyu}} before compiling anything with {{ic|makepkg}} as the problem may be that your system is not up-to-date.<br />
# Ensure you have both "base" and "base-devel" groups installed.<br />
# Try using the "{{ic|-s}}" option with {{ic|makepkg}} to check and install all the dependencies needed before starting the build process.<br />
<br />
Be sure to first read the PKGBUILD and the comments on the AUR page of the package in question.<br />
The reason might not be trivial after all. Custom CFLAGS, LDFLAGS and MAKEFLAGS can cause failures. It's also possible that the PKGBUILD is broken for everyone. If you cannot figure it out on your own, just report it to the maintainer e.g. by posting the errors you are getting in the comments on the AUR page.}}<br />
<br />
{{FAQ<br />
|question=How can I speed up repeated build processes?<br />
|answer=If you frequently compile code that uses gcc - say, a git or SVN package - you may find [[ccache]], short for "compiler cache", useful.}}<br />
<br />
{{FAQ<br />
|question=How do I access unsupported packages?<br />
|answer=See [[#Installing packages]]}}<br />
<br />
{{FAQ<br />
|question=How can I upload to AUR without using the web interface?<br />
|answer=You can use {{AUR|aurploader}}, {{AUR|aurup}} or {{AUR|burp}} -- these are command-line programs.}}</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Official_repositories&diff=202511Official repositories2012-05-22T15:03:19Z<p>Rnabioullin: /* [core] */ Stated specific internetwork.</p>
<hr />
<div>[[Category:Package management]]<br />
[[Category:About Arch]]<br />
[[tr:Resmi_Depolar]]<br />
{{i18n|Official Repositories}}<br />
[[fr:Depots]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|Software repositories contain software compiled and packaged by developers and Trusted Users, readily accessible via pacman. This article outlines the official repositories provided and supported by Arch Linux developers.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Package management overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Mirrors}}<br />
{{Article summary wiki|Arch User Repository}}<br />
{{Article summary wiki|Unofficial User Repositories}}<br />
{{Article summary end}}<br />
<br />
A [[Wikipedia:software repository|software repository]] is a storage location from which software packages may be retrieved and installed on a computer. Arch Linux [[Package Maintainer|package maintainers]] (developers and [[Trusted Users]]) maintain a number of official repositories containing software packages for essential and popular software, readily accessible via [[pacman]]. This article outlines those officially-supported repositories.<br />
<br />
== Historical background ==<br />
<br />
Most of the repository splits are for historical reasons. Originally, when Arch Linux was used by very few users, there was only one repository known as ''[official]'' (now '''[core]'''). At the time, [official] basically contained Judd Vinet's preferred applications. It was designed to contain one of each "type" of program -- one DE, one major browser, etc.<br />
<br />
There were users back then that did not like Judd's selection, so since the [[Arch Build System]] is so easy to use, they created packages of their own. These packages went into a repository called ''[unofficial]'', and were maintained by developers other than Judd. Eventually, the two repositories were both considered equally supported by the developers, so the names [official] and [unofficial] no longer reflected their true purpose. They were subsequently renamed to ''[current]'' and ''[extra]'' sometime near the release version 0.5.<br />
<br />
Shortly after the 2007.8.1 release, [current] was renamed [core] in order to prevent confusion over what exactly it contains. The repositories are now more or less equal in the eyes of the developers and the community, but [core] does have some differences. The main distinction is that packages used for Installation CDs and release snapshots are taken only from [core]. This repository still gives a complete Linux system, though it may not be the Linux system you want.<br />
<br />
Now, sometime around 0.5 or 0.6, they found there were a lot of packages that the developers did not want to maintain. One of the developers (Xentac) set up the "Trusted User Repositories", which were unofficial repositories in which trusted users could place packages they had created. There was a ''[staging]'' repository where packages could be promoted into the official repositories by one of the Arch Linux developers, but other than this, the developers and trusted users were more or less distinct.<br />
<br />
This worked for a while, but not when trusted users got bored with their repositories, and not when untrusted users wanted to share their own packages. This led to the development of the [https://aur.archlinux.org/ AUR]. The TUs were conglomerated into a more closely knit group, and they now collectively maintain the '''[community]''' repository. The Trusted Users are still a separate group from the Arch Linux developers, and there is not a lot of communication between them. However, popular packages are still promoted from [community] to '''[extra]''' on occasion. The [https://aur.archlinux.org/ AUR] also supports allowing untrusted users to submit PKGBUILDs for other users to use if they wish. These packages are unsupported, and the packages are sometimes called the '''[unsupported]''' repository, though since no binary packages are distributed, unsupported is not really a repository. Trusted users can adopt packages from unsupported into [community] at their discretion, whether it is because the package is popular or because they are interested in maintaining it.<br />
<br />
After a kernel in '''[core]''' [https://www.archlinux.org/news/please-avoid-kernel-261614-1/ broke many user systems] the "core signoff policy" was introduced, since then all package updates for [core] need to go through a '''[testing]''' repository first, only after multiple signoffs from other developers they were allowed to move. Over time it was noticed various [core] packages have low usage and user signoffs or even lack of bugreports became informally accepted as criteria to accept such packages.<br />
Late 2009/begin 2010, with the advent of some new filesystems (and the desire to support them during installation) and the realization that the [core] repository was never clearly defined (just "important packages, handpicked by developers") - although some developers required "enough usage among developers to warrant signoffs" before adoption into [core] - the repository received a more accurate description (see below).<br />
<br />
== [core] ==<br />
<br />
The [core] repository can be found in ''core/os/i686'' or ''core/os/x86_64'' on your favorite mirror.<br />
It has fairly strict quality requirements:<br />
* developers and/or users need to signoff on updates before package updates are accepted.<br />
* for packages with low usage a reasonable exposure (as in: inform people about update, request signoffs, keep in testing for a few days up to a week depending on the severity of the change) lack of outstanding bugreports, along with the implicit signoff of the package maintainer is enough).<br />
<br />
It contains packages which:<br />
<br />
* are needed to boot any kind of supported Arch system.<br />
* may be needed to connect to the Internet.<br />
* are essential for package building.<br />
* can manage and check/repair supported filesystems.<br />
* virtually anyone will want or need early in the system setup process (like openssh).<br />
* are dependencies (but not necessarily makedepends) of the above.<br />
<br />
''This repository is included in the core installation media, so you can build a fully working base system without Internet access.''<br />
<br />
== [extra] ==<br />
<br />
The [extra] repository can be found in ''extra/os/i686'' or ''extra/os/x86_64'' on your favorite mirror. It contains all packages that do not fit in [core]<br><br />
Example: X.org, window managers, web servers, media players, languages like Python and Ruby, and a lot more.<br />
<br />
== [community] ==<br />
<br />
The [community] repository can be found in ''community/os/i686'' or ''community/os/x86_64'' on your favorite mirror. It is maintained by the ''Trusted Users (TUs)'' and is part of the ''Arch User Repository (AUR)''. It contains packages from the ''AUR'' that have enough votes and were adopted by a ''TU''.<br />
<br />
== [multilib] ==<br />
<br />
The [[multilib]] repository can be found in ''multilib/os/x86_64'' on your favorite mirror. It contains 32 bit libraries that can be used to run 32 bit applications like the flash plugin and skype in 64 bit installation.<br />
<br />
== [testing] ==<br />
<br />
The [testing] repository can be found in ''testing/os/i686'' on your favorite mirror. [testing] is special because it contains packages that are candidates for the [core] or [extra] repositories. New packages go into [testing] if:<br />
* they are expected to break something on update and need to be tested first<br />
* they require other packages to be rebuilt. In this case, all packages that need to be rebuilt are put into [testing] first and when all rebuilds are done, they are moved back to the other repositories.<br />
<br />
[testing] is the only repository that can have name collisions with any of the other official repositories. If enabled, it has to be the first repository listed in your {{ic|/etc/pacman.conf}} file.<br />
<br />
{{Warning|Be careful when enabling [testing]. Your system may break after you perform an update with the [testing] repository enabled. Only experienced users who know how to deal with potential system breakage should use it.}}<br />
<br />
The [testing] repository is not for the "newest of the new" package versions. Part of its purpose is to hold package updates that have the potential to '''cause system breakage''', either by being part of the [core] set of packages, or by being critical in other ways. As such, users of the [testing] repository are '''strongly encouraged''' to subscribe to the [https://mailman.archlinux.org/mailman/listinfo/arch-dev-public arch-dev-public] mailing list, watch the [testing] Repository Forum, and to report all bugs to the bug tracker.<br />
<br />
If you enable testing, you must also enable community-testing.<br />
<br />
== [community-testing] ==<br />
<br />
The [community-testing] repository is like the [testing] repository but for packages that are candidates for the [community] repository.<br />
<br />
If you enable community-testing, you must also enable testing.<br />
<br />
== [multilib-testing] ==<br />
<br />
The [multilib-testing] repository is like the [testing] repository but for packages that are candidates for the [multilib] repository.<br />
<br />
If you enable multilib-testing, you must also enable testing.<br />
<br />
== [unsupported] a.k.a The AUR ==<br />
<br />
[unsupported] is the web based repository that is commonly referred to as the [[AUR]], or Arch User Repository.* Users can submit source packages containing various build files including [[PKGBUILD]]s to this repository. This is an unofficial and unsupported repository which is not directly accessible via pacman. To install a package from [unsupported] a user would have to download and extract the source package, run [[makepkg]] which downloads upstream sources and builds the package, and finally install the built package using pacman. One of the popular [[AUR Helpers]] may be used to help with these tasks.<br />
<br />
{{Note|Technically, both the [community] and [unsupported] repository make up the AUR.}}<br />
<br />
== Unofficial user repositories ==<br />
<br />
A few users run public but unofficial custom repositories. See [[Unofficial User Repositories]].</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Arch_User_Repository&diff=201256Arch User Repository2012-05-13T15:07:44Z<p>Rnabioullin: /* FAQ */ removed redundancy (licensing restriction already stated)</p>
<hr />
<div>[[Category:Arch User Repository]]<br />
[[Category:About Arch]]<br />
[[Category:Package development]]<br />
[[Category:Package management]]<br />
[[Category:Arch development]]<br />
[[tr:Arch_Kullanıcı_Deposu]]<br />
{{i18n|Arch User Repository}}<br />
[[fr:AUR]]<br />
{{Article summary start}}<br />
{{Article summary text|The Arch User Repository is a collection of user-submitted [[PKGBUILD]]s that supplement software available from the [[official repositories]]. This article describes how to build ''unsupported'' software packages from the AUR.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Package management overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|AUR Helpers}}<br />
{{Article summary wiki|AUR Trusted User Guidelines}}<br />
{{Article summary heading|Resources}}<br />
{{Article summary link|AUR Web Interface|https://aur.archlinux.org}}<br />
{{Article summary link|AUR Mailing List|http://www.archlinux.org/mailman/listinfo/aur-general}}<br />
{{Article summary end}}<br />
<br />
The Arch User Repository (AUR) is a community-driven repository for Arch users. It contains package descriptions (PKGBUILDs) that allow you to compile a package from source with [[makepkg]] and then install it via [[pacman]]. The AUR was created to organize and share new packages from the community and to help expedite popular packages' inclusion into the [[#.5Bcommunity.5D|[community]]] repository. This document explains how users can access and utilize the AUR.<br />
<br />
A good number of new packages that enter the official repositories start in the AUR. In the AUR, users are able to contribute their own package builds (PKGBUILD and related files). The AUR community has the ability to vote for or against packages in the AUR. If a package becomes popular enough -- provided it has a compatible license and good packaging technique -- it may be entered into the [community] repository (directly accessible by [[pacman]] or [[ABS|abs]]).<br />
<br />
==Getting started==<br />
Users can search and download PKGBUILDs from the [https://aur.archlinux.org AUR Web Interface]. These PKGBUILDs can be built into installable packages using [[makepkg]], then installed using pacman. <br />
<br />
* Install {{Grp|base-devel}} ({{ic|pacman -S base-devel}}), because members of this group are not explicitly required by AUR packages which may not build without them (more info in [https://bbs.archlinux.org/viewtopic.php?pid=632355 this thread]).<br />
* Read the remainder of this article for more info and a short tutorial on installing AUR packages.<br />
* Visit the [https://aur.archlinux.org AUR Web Interface] to inform yourself on updates and happenings. There you will also find statistics and an up-to-date list of newest available packages available in AUR.<br />
* Glance over the [[#FAQ]] for answers to the most common questions.<br />
* You may wish to adjust {{ic|/etc/makepkg.conf}} to better optimize for your processor prior to building packages from the AUR. A significant improvement in compile times can be realized on systems with multi-core processors by adjusting the MAKEFLAGS variable. Users can also enable hardware-specific optimizations in GCC via the CFLAGS variable. See [[makepkg.conf]] for more information.<br />
<br />
==History==<br />
The following items are listed for historical purposes only. They have since been superseded by the AUR and are no longer available.<br />
<br />
At the beginning, there was {{ic|<nowiki>ftp://ftp.archlinux.org/incoming</nowiki>}}, and people contributed by simply uploading the PKGBUILD, the needed supplementary files, and the built package itself to the server. The package and associated files remained there until a [[Package Maintainer]] saw the program and adopted it.<br />
<br />
Then the Trusted User Repositories were born. Certain individuals in the community were allowed to host their own repositories for anyone to use. The AUR expanded on this basis, with the aim of making it both more flexible and more usable. In fact, the AUR maintainers are still referred to as TUs (Trusted Users).<br />
<br />
==Searching==<br />
The AUR web interface can be found [https://aur.archlinux.org/ here], and an interface suitable for accessing the AUR from a script (for example) can be found [https://aur.archlinux.org/rpc.php here]<br />
<br />
Queries search package names and descriptions via a MySQL LIKE comparison. This allows for more flexible search criteria (e.g. try searching for 'tool%like%grep' instead of 'tool like grep'). If you need to search for a description that contains '%', escape it with '\%'.<br />
<br />
==Installing packages==<br />
Installing packages from the AUR is a relatively simple process. Essentially:<br />
# Acquire the tarball which contains the PKGBUILD and possibly other required files<br />
# Extract the tarball (preferably in a folder set aside just for builds from the AUR)<br />
# Run '''makepkg''' in the directory where the files are saved ("makepkg -s" will auto-resolve dependencies with pacman)<br />
# Install the resulting package with '''pacman''':<br />
<br />
# pacman -U /path/to/pkg.tar.xz<br />
<br />
[[AUR Helpers]] add seamless access to the AUR. They vary in their features, but can ease in searching, fetching, building, and installing from PKGBUILDs found in the AUR. All of these scripts can be found in the AUR.<br />
<br />
{{Note|There is not and will never be an ''official'' mechanism for installing build material from the AUR. All users should be familiar with the build process.}}<br />
<br />
What follows is a detailed example of installation of a package called "foo".<br />
<br />
===Prerequisites===<br />
First ensure that the necessary tools are installed. The package group "base-devel" should be sufficient; it includes ''make'' and other tools needed for compiling from source.<br />
<br />
{{Warning|Packages in the AUR assume "base-devel" is installed, and will not list members of this group as dependencies even if the package cannot be built without them. Please ensure this group is installed before complaining about failed builds.}}<br />
<br />
# pacman -S base-devel<br />
<br />
Next choose an appropriate build directory. A build directory is simply a directory where the package will be made or "built" and can be any directory. Examples of commonly used directories are:<br />
<br />
~/builds<br />
<br />
or if using ABS (the [[Arch Build System]]):<br />
<br />
/var/abs/local<br />
<br />
For more information on ABS read the [[Arch Build System]] article. The example will use {{ic|~/builds}} as the build directory.<br />
<br />
===Acquire build files===<br />
Locate the package in the AUR. This is done using the search feature (text field at the top of the [https://aur.archlinux.org/ AUR home page]). Clicking the application's name in the search list brings up an information page on the package. Read through the description to confirm that this is the desired package, note when the package was last updated, and read any comments.<br />
<br />
Download the necessary build files. From the package's information page download the build files by clicking the "Tarball" link on the left-hand side near the end of the package details. This file should be saved to the build directory or otherwise copied to the directory after downloading. In this example, the file is called "foo.tar.gz" (standard format is ''pkgname''.tar.gz, if it has been properly submitted).<br />
<br />
===Build the package===<br />
Extract the tarball. Change directories to the build directory if not already there and extract the build files.<br />
<br />
$ cd ~/builds<br />
$ tar -xvzf foo.tar.gz<br />
<br />
This should create a new directory called "foo" in the build directory.<br />
<br />
{{Warning|'''Carefully check all files.''' {{ic|cd}} to the newly created directory and carefully check the {{ic|PKGBUILD}} and any {{ic|.install}} file for malicious commands. {{ic|PKGBUILD}}s are bash scripts containing functions to be executed by {{ic|makepkg}}: these functions can contain ''any'' valid commands or bash syntax, so it is totally possible for a {{ic|PKGBUILD}} to contain dangerous commands through malice or ignorance on the part of the author. Since {{ic|makepkg}} uses fakeroot (and should never be run as root), there is some level of protection but you should never count on it. If in doubt, do not build the package and seek advice on the forums or mailing list.}}<br />
<br />
$ cd foo<br />
$ nano PKGBUILD<br />
$ nano foo.install<br />
<br />
Make the package. After manually confirming the integrity of the files, run [[makepkg]] as a normal user in the build directory.<br />
<br />
$ makepkg -s<br />
<br />
The {{ic|-s}} switch will use [[sudo]] to install any needed dependencies. If the use of sudo is undesirable, manually install required dependencies beforehand and exclude the {{ic|-s}} in the above command.<br />
<br />
===Install the package===<br />
Install the package using pacman. A tarball should have been created named:<br />
<br />
<''application name''>-<''application version number''>-<''package revision number''>-<''architecture''>.pkg.tar.xz<br />
<br />
This package can be installed using pacman's "upgrade" command:<br />
<br />
# pacman -U foo-0.1-1-i686.pkg.tar.xz <br />
<br />
These manually-installed packages are called foreign packages - packages which have not originated from any repository known to pacman. To list all foreign packages:<br />
$ pacman -Qm <br />
<br />
{{Note|The above example is only a brief summary of the package building process. A visit to the [[makepkg]] and [[ABS]] pages will provide more detail and is highly recommended (particularly for first-time users).}}<br />
<br />
==Feedback==<br />
The [https://aur.archlinux.org AUR Web Interface] has a comments facility that allows users to provide suggestions and feedback on improvements to the PKGBUILD contributor. Avoid pasting patches or PKGBUILDs into the comments section: they quickly become obsolete and just end up needlessly taking up lots of space. Instead email those files to the maintainer, or even use a [[pastebin Clients|pastebin]].<br />
<br />
One of the easiest activities for '''all''' Arch users is to browse the AUR and '''vote''' for their favourite packages using the online interface. All packages are eligible for adoption by a TU for inclusion in [community], and the vote count is one of the considerations in that process; it is in everyone's interest to vote!<br />
<br />
==Sharing packages==<br />
The user plays an essential role in the AUR, which cannot fulfill its potential without the support, involvement, and contribution of the wider user community. The life-cycle of an AUR package starts and ends with the user and requires the user to contribute in several ways.<br />
<br />
Users can '''share''' PKGBUILDs using the Arch User Repository. It does not contain any binary packages but allows users to upload PKGBUILDs that can be downloaded by others. These PKGBUILDs are completely unofficial and have not been thoroughly vetted, so they should be used at your own risk.<br />
<br />
===Submitting packages===<br />
After logging in to the AUR web interface, a user can [https://aur.archlinux.org/pkgsubmit.php submit] a gzipped tarball ({{ic|.tar.gz}}) of a directory containing build files for a package. The directory inside the tarball should contain a [[PKGBUILD]], any {{ic|.install}} files, patches, etc. ('''absolutely''' no binaries). Examples of what such a directory should look like can be seen inside {{ic|/var/abs}} if the [[Arch Build System]] was installed.<br />
<br />
The tarball can be created with the following command:<br />
$ makepkg --source <br />
<br />
Note that this is a gzipped tarball; assuming you are uploading a package called ''libfoo'', when you create the file it should look similar to this:<br />
<br />
# List contents of tarball.<br />
$ tar tf libfoo-0.1-1.src.tar.gz<br />
libfoo/<br />
libfoo/PKGBUILD<br />
libfoo/libfoo.install<br />
<br />
When submitting a package, observe the following rules: <br />
* Check the [http://www.archlinux.org/packages/ package database] for the package. If it exists, '''do not''' submit the package. If the current package is broken or is lacking an included feature then please file a [https://bugs.archlinux.org/ bug report].<br />
* Check the AUR for the package. If it is currently maintained, changes can be submitted in a comment for the maintainer's attention. If it is unmaintained, the package can be adopted and updated as required. Do not create duplicate packages.<br />
* Verify carefully that what you are uploading is correct. All contributors must read and adhere to the [[Arch Packaging Standards]] when writing PKGBUILDs. This is essential to the smooth running and general success of the AUR. Remember that you are not going to earn any credit or respect from your peers by wasting their time with a bad PKGBUILD.<br />
* Packages that contain binaries or that are very poorly written may be deleted without warning.<br />
* If you are unsure about the package (or the build/submission process) in any way, submit the PKGBUILD to the [https://mailman.archlinux.org/mailman/listinfo/ AUR Mailing List] or the [https://bbs.archlinux.org/viewforum.php?id=4 AUR boards] on the forum for public review before adding it to the AUR.<br />
* Make sure the package is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission.<br />
* Gain some experience before submitting packages. Build a few packages to learn the process and then submit.<br />
* If you submit a {{ic|package.tar.gz}} with a file named '{{ic|package}}' in it you will get an error: 'Could not change to directory {{ic|/home/aur/unsupported/package/package}}'. To resolve this, rename the file named '{{ic|package}}' to something else, for example, '{{ic|package.rc}}'. When it is installed in the {{ic|pkg}} directory you may rename it back to '{{ic|package}}'.<br />
Make sure to also read [[Arch Packaging Standards#Submitting packages to the AUR]].<br />
<br />
===Maintaining packages===<br />
* If you maintain a package and want to update the PKGBUILD for your package just resubmit it.<br />
* Check for feedback and comments from other users and try to incorporate any improvements they suggest; consider it a learning process!<br />
* Please do not just submit and forget about packages! It is the maintainer's job to maintain the package by checking for updates and improving the PKGBUILD.<br />
* If you do not want to continue to maintain the package for some reason, {{ic|disown}} the package using the AUR web interface and/or post a message to the AUR Mailing List.<br />
<br />
===Other requests===<br />
* Disownment requests and removal requests go to the aur-general mailing list for TUs and other users to decide upon.<br />
* '''Include package name and URL to AUR page''', preferably with a footnote [1].<br />
* Disownment requests will be granted two weeks after the current maintainer has been contacted by email and did not react.<br />
* '''Package merging has been implemented''', users still have to resubmit a package under a new name and may request merging of the old version's comments and votes on the mailing list<br />
* Removal requests require the following information:<br />
** Package name and URL to AUR page<br />
** Reason for deletion, at least a short note <br> '''Notice:''' A package's comments does not sufficiently point out the reasons why a package is up for deletion. Because as soon as a TU takes action, the only place where such information can be obtained is the aur-general mailing list.<br />
** Include supporting details, like when a package is provided by another package, if you are the maintainer yourself, it's renamed and the original owner agreed, etc.<br />
<br />
Removal requests can be disapproved, in which case you'll likely be advised to disown the package for a future packager's reference.<br />
<br />
==[community]==<br />
The [community] repository, maintained by [[Trusted Users]], contains the most popular packages from the AUR. It is enabled by default in {{ic|/etc/pacman.conf}}. If [community] has been disabled or removed, it can be enabled by uncommenting or adding these two lines: <br />
<br />
{{hc|/etc/pacman.conf|<nowiki><br />
...<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
...<br />
</nowiki>}}<br />
<br />
[community], unlike the AUR, contains binary packages that can be installed directly with [[pacman]] and the build files can also be accessed with the [[Arch Build System|ABS]]. Some of these packages may eventually make the transition to the [core] or [extra] repositories as the developers consider them crucial to the distribution.<br />
<br />
Users can also access the [community] build files by editing {{ic|/etc/abs.conf}} and enabling the [community] repository in the {{ic|REPOS}} array.<br />
<br />
==Git Repo==<br />
A Git Repo of the AUR is maintained by Thomas Dziedzic providing package history among other things. It is updated at least once a day. To clone the repository (several hundred MB):<br />
<br />
$ git clone git://pkgbuild.com/aur-mirror.git<br />
<br />
[http://pkgbuild.com/git/aur-mirror.git/ Web interface], [http://pkgbuild.com/~td123/readme Readme], [http://bbs.archlinux.org/viewtopic.php?id=113099 Forum thread]<br />
<br />
==FAQ==<br />
{{FAQ<br />
|question=What is the AUR?<br />
|answer=The AUR (Arch User Repository) is a place where the Arch Linux community can upload [[PKGBUILD]]s of applications, libraries, etc., and share them with the entire community. Fellow users can then vote for their favorites to be moved into the [community] repository to be shared with Arch Linux users in binary form.}}<br />
<br />
{{FAQ<br />
|question=What kind of packages are permitted on the AUR?<br />
|answer=The packages on the AUR are merely "build scripts", i.e recipes to build binaries for pacman. For most cases, everything is permitted, as long as you are in compliance with the licensing terms of the content. For other cases, where it is mentioned that "you may not link" to downloads, i.e contents that are not redistributable, you may only use the file name itself as the source. This means and requires users to already have the restricted source in the build directory prior to building the package. When in doubt, ask.}}<br />
<br />
{{FAQ<br />
|question=What is a TU?<br />
|answer=A [[AUR Trusted User Guidelines|TU (Trusted User)]] is a person who is chosen to oversee AUR and the [community] repository. They're the ones who maintain popular PKGBUILDs in [community], and overall keep the AUR running.}}<br />
<br />
{{FAQ<br />
|question=What's the difference between the Arch User Repository and [community]?<br />
|answer=The Arch User Repository is where all PKGBUILDs that users submit are stored, and must be built manually with [[makepkg]]. When PKGBUILDs receive enough votes, they are moved into the [community] repository, where the TUs maintain binary packages that can be installed with [[pacman]].}}<br />
<br />
{{FAQ<br />
|question=How many votes does it take to get a PKGBUILD into [community]?<br />
|answer=Usually, at least 10 votes are required for something to move into [community]. However, if a TU wants to support a package, it will often be found in the repository.}}<br />
<br />
{{FAQ<br />
|question=How do I make a PKGBUILD?<br />
|answer=The best resource is [[Creating Packages]]. Remember to look in AUR before creating the PKGBUILD as to not duplicate efforts.}}<br />
<br />
{{FAQ<br />
|question=I'm trying to do {{ic|pacman -S foo}}; it isn't working but I know it's in [community]<br />
|answer=You probably haven't enabled [community] in your {{ic|/etc/pacman.conf}}. Just uncomment the relevant lines.<br />
If [community] is enabled in your {{ic|/etc/pacman.conf}} try running {{ic|pacman -S -y}} first to synchronize the pkgcache before trying your package again.}}<br />
<br />
{{FAQ<br />
|question=Foo in AUR is outdated; what do I do?<br />
|answer=For starters, you can flag packages out-of-date. If it stays out-of-date for an extended period of time, the best thing to do is email the maintainer. If there is no response from the maintainer after two weeks, you could send mail to the aur-general mailing list to have a TU orphan the PKGBUILD if you're willing to maintain it yourself.}}<br />
<br />
{{FAQ<br />
|question=I have a PKGBUILD I would like to submit; can someone check it to see if there are any errors?<br />
|answer=If you would like to have your PKGBUILD critiqued, post it on the aur-general mailing list to get feedback from the TUs and fellow AUR members. You could also get help from the [[ArchChannel|IRC channel]], #archlinux on irc.freenode.net. You can also<br />
use [[namcap]] to check your PKGBUILD and the resulting package for errors.}}<br />
<br />
{{FAQ<br />
|question=Foo in AUR doesn't compile when I do {{ic|makepkg}}; what should I do?<br />
|answer=You are probably missing something trivial.<br />
<br />
# Run {{ic|pacman -Syyu}} before compiling anything with {{ic|makepkg}} as the problem may be that your system is not up-to-date.<br />
# Ensure you have both "base" and "base-devel" groups installed.<br />
# Try using the "{{ic|-s}}" option with {{ic|makepkg}} to check and install all the dependencies needed before starting the build process.<br />
<br />
Be sure to first read the PKGBUILD and the comments on the AUR page of the package in question.<br />
The reason might not be trivial after all. Custom CFLAGS, LDFLAGS and MAKEFLAGS can cause failures. It's also possible that the PKGBUILD is broken for everyone. If you cannot figure it out on your own, just report it to the maintainer e.g. by posting the errors you are getting in the comments on the AUR page.}}<br />
<br />
{{FAQ<br />
|question=How can I speed up repeated build processes?<br />
|answer=If you frequently compile code that uses gcc - say, a git or SVN package - you may find [[ccache]], short for "compiler cache", useful.}}<br />
<br />
{{FAQ<br />
|question=How do I access unsupported packages?<br />
|answer=See [[#Installing packages]]}}<br />
<br />
{{FAQ<br />
|question=How can I upload to AUR without using the web interface?<br />
|answer=You can use {{AUR|aurploader}}, {{AUR|aurup}} or {{AUR|burp}} -- these are command-line programs.}}</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Arch_User_Repository&diff=201188Arch User Repository2012-05-12T17:03:14Z<p>Rnabioullin: /* FAQ */ fixed IP restriction - is applicable to all IP, not just software</p>
<hr />
<div>[[Category:Arch User Repository]]<br />
[[Category:About Arch]]<br />
[[Category:Package development]]<br />
[[Category:Package management]]<br />
[[Category:Arch development]]<br />
[[tr:Arch_Kullanıcı_Deposu]]<br />
{{i18n|Arch User Repository}}<br />
[[fr:AUR]]<br />
{{Article summary start}}<br />
{{Article summary text|The Arch User Repository is a collection of user-submitted [[PKGBUILD]]s that supplement software available from the [[official repositories]]. This article describes how to build ''unsupported'' software packages from the AUR.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Package management overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|AUR Helpers}}<br />
{{Article summary wiki|AUR Trusted User Guidelines}}<br />
{{Article summary heading|Resources}}<br />
{{Article summary link|AUR Web Interface|https://aur.archlinux.org}}<br />
{{Article summary link|AUR Mailing List|http://www.archlinux.org/mailman/listinfo/aur-general}}<br />
{{Article summary end}}<br />
<br />
The Arch User Repository (AUR) is a community-driven repository for Arch users. It contains package descriptions (PKGBUILDs) that allow you to compile a package from source with [[makepkg]] and then install it via [[pacman]]. The AUR was created to organize and share new packages from the community and to help expedite popular packages' inclusion into the [[#.5Bcommunity.5D|[community]]] repository. This document explains how users can access and utilize the AUR.<br />
<br />
A good number of new packages that enter the official repositories start in the AUR. In the AUR, users are able to contribute their own package builds (PKGBUILD and related files). The AUR community has the ability to vote for or against packages in the AUR. If a package becomes popular enough -- provided it has a compatible license and good packaging technique -- it may be entered into the [community] repository (directly accessible by [[pacman]] or [[ABS|abs]]).<br />
<br />
==Getting started==<br />
Users can search and download PKGBUILDs from the [https://aur.archlinux.org AUR Web Interface]. These PKGBUILDs can be built into installable packages using [[makepkg]], then installed using pacman. <br />
<br />
* Install {{Grp|base-devel}} ({{ic|pacman -S base-devel}}), because members of this group are not explicitly required by AUR packages which may not build without them (more info in [https://bbs.archlinux.org/viewtopic.php?pid=632355 this thread]).<br />
* Read the remainder of this article for more info and a short tutorial on installing AUR packages.<br />
* Visit the [https://aur.archlinux.org AUR Web Interface] to inform yourself on updates and happenings. There you will also find statistics and an up-to-date list of newest available packages available in AUR.<br />
* Glance over the [[#FAQ]] for answers to the most common questions.<br />
* You may wish to adjust {{ic|/etc/makepkg.conf}} to better optimize for your processor prior to building packages from the AUR. A significant improvement in compile times can be realized on systems with multi-core processors by adjusting the MAKEFLAGS variable. Users can also enable hardware-specific optimizations in GCC via the CFLAGS variable. See [[makepkg.conf]] for more information.<br />
<br />
==History==<br />
The following items are listed for historical purposes only. They have since been superseded by the AUR and are no longer available.<br />
<br />
At the beginning, there was {{ic|<nowiki>ftp://ftp.archlinux.org/incoming</nowiki>}}, and people contributed by simply uploading the PKGBUILD, the needed supplementary files, and the built package itself to the server. The package and associated files remained there until a [[Package Maintainer]] saw the program and adopted it.<br />
<br />
Then the Trusted User Repositories were born. Certain individuals in the community were allowed to host their own repositories for anyone to use. The AUR expanded on this basis, with the aim of making it both more flexible and more usable. In fact, the AUR maintainers are still referred to as TUs (Trusted Users).<br />
<br />
==Searching==<br />
The AUR web interface can be found [https://aur.archlinux.org/ here], and an interface suitable for accessing the AUR from a script (for example) can be found [https://aur.archlinux.org/rpc.php here]<br />
<br />
Queries search package names and descriptions via a MySQL LIKE comparison. This allows for more flexible search criteria (e.g. try searching for 'tool%like%grep' instead of 'tool like grep'). If you need to search for a description that contains '%', escape it with '\%'.<br />
<br />
==Installing packages==<br />
Installing packages from the AUR is a relatively simple process. Essentially:<br />
# Acquire the tarball which contains the PKGBUILD and possibly other required files<br />
# Extract the tarball (preferably in a folder set aside just for builds from the AUR)<br />
# Run '''makepkg''' in the directory where the files are saved ("makepkg -s" will auto-resolve dependencies with pacman)<br />
# Install the resulting package with '''pacman''':<br />
<br />
# pacman -U /path/to/pkg.tar.xz<br />
<br />
[[AUR Helpers]] add seamless access to the AUR. They vary in their features, but can ease in searching, fetching, building, and installing from PKGBUILDs found in the AUR. All of these scripts can be found in the AUR.<br />
<br />
{{Note|There is not and will never be an ''official'' mechanism for installing build material from the AUR. All users should be familiar with the build process.}}<br />
<br />
What follows is a detailed example of installation of a package called "foo".<br />
<br />
===Prerequisites===<br />
First ensure that the necessary tools are installed. The package group "base-devel" should be sufficient; it includes ''make'' and other tools needed for compiling from source.<br />
<br />
{{Warning|Packages in the AUR assume "base-devel" is installed, and will not list members of this group as dependencies even if the package cannot be built without them. Please ensure this group is installed before complaining about failed builds.}}<br />
<br />
# pacman -S base-devel<br />
<br />
Next choose an appropriate build directory. A build directory is simply a directory where the package will be made or "built" and can be any directory. Examples of commonly used directories are:<br />
<br />
~/builds<br />
<br />
or if using ABS (the [[Arch Build System]]):<br />
<br />
/var/abs/local<br />
<br />
For more information on ABS read the [[Arch Build System]] article. The example will use {{ic|~/builds}} as the build directory.<br />
<br />
===Acquire build files===<br />
Locate the package in the AUR. This is done using the search feature (text field at the top of the [https://aur.archlinux.org/ AUR home page]). Clicking the application's name in the search list brings up an information page on the package. Read through the description to confirm that this is the desired package, note when the package was last updated, and read any comments.<br />
<br />
Download the necessary build files. From the package's information page download the build files by clicking the "Tarball" link on the left-hand side near the end of the package details. This file should be saved to the build directory or otherwise copied to the directory after downloading. In this example, the file is called "foo.tar.gz" (standard format is ''pkgname''.tar.gz, if it has been properly submitted).<br />
<br />
===Build the package===<br />
Extract the tarball. Change directories to the build directory if not already there and extract the build files.<br />
<br />
$ cd ~/builds<br />
$ tar -xvzf foo.tar.gz<br />
<br />
This should create a new directory called "foo" in the build directory.<br />
<br />
{{Warning|'''Carefully check all files.''' {{ic|cd}} to the newly created directory and carefully check the {{ic|PKGBUILD}} and any {{ic|.install}} file for malicious commands. {{ic|PKGBUILD}}s are bash scripts containing functions to be executed by {{ic|makepkg}}: these functions can contain ''any'' valid commands or bash syntax, so it is totally possible for a {{ic|PKGBUILD}} to contain dangerous commands through malice or ignorance on the part of the author. Since {{ic|makepkg}} uses fakeroot (and should never be run as root), there is some level of protection but you should never count on it. If in doubt, do not build the package and seek advice on the forums or mailing list.}}<br />
<br />
$ cd foo<br />
$ nano PKGBUILD<br />
$ nano foo.install<br />
<br />
Make the package. After manually confirming the integrity of the files, run [[makepkg]] as a normal user in the build directory.<br />
<br />
$ makepkg -s<br />
<br />
The {{ic|-s}} switch will use [[sudo]] to install any needed dependencies. If the use of sudo is undesirable, manually install required dependencies beforehand and exclude the {{ic|-s}} in the above command.<br />
<br />
===Install the package===<br />
Install the package using pacman. A tarball should have been created named:<br />
<br />
<''application name''>-<''application version number''>-<''package revision number''>-<''architecture''>.pkg.tar.xz<br />
<br />
This package can be installed using pacman's "upgrade" command:<br />
<br />
# pacman -U foo-0.1-1-i686.pkg.tar.xz <br />
<br />
These manually-installed packages are called foreign packages - packages which have not originated from any repository known to pacman. To list all foreign packages:<br />
$ pacman -Qm <br />
<br />
{{Note|The above example is only a brief summary of the package building process. A visit to the [[makepkg]] and [[ABS]] pages will provide more detail and is highly recommended (particularly for first-time users).}}<br />
<br />
==Feedback==<br />
The [https://aur.archlinux.org AUR Web Interface] has a comments facility that allows users to provide suggestions and feedback on improvements to the PKGBUILD contributor. Avoid pasting patches or PKGBUILDs into the comments section: they quickly become obsolete and just end up needlessly taking up lots of space. Instead email those files to the maintainer, or even use a [[pastebin Clients|pastebin]].<br />
<br />
One of the easiest activities for '''all''' Arch users is to browse the AUR and '''vote''' for their favourite packages using the online interface. All packages are eligible for adoption by a TU for inclusion in [community], and the vote count is one of the considerations in that process; it is in everyone's interest to vote!<br />
<br />
==Sharing packages==<br />
The user plays an essential role in the AUR, which cannot fulfill its potential without the support, involvement, and contribution of the wider user community. The life-cycle of an AUR package starts and ends with the user and requires the user to contribute in several ways.<br />
<br />
Users can '''share''' PKGBUILDs using the Arch User Repository. It does not contain any binary packages but allows users to upload PKGBUILDs that can be downloaded by others. These PKGBUILDs are completely unofficial and have not been thoroughly vetted, so they should be used at your own risk.<br />
<br />
===Submitting packages===<br />
After logging in to the AUR web interface, a user can [https://aur.archlinux.org/pkgsubmit.php submit] a gzipped tarball ({{ic|.tar.gz}}) of a directory containing build files for a package. The directory inside the tarball should contain a [[PKGBUILD]], any {{ic|.install}} files, patches, etc. ('''absolutely''' no binaries). Examples of what such a directory should look like can be seen inside {{ic|/var/abs}} if the [[Arch Build System]] was installed.<br />
<br />
The tarball can be created with the following command:<br />
$ makepkg --source <br />
<br />
Note that this is a gzipped tarball; assuming you are uploading a package called ''libfoo'', when you create the file it should look similar to this:<br />
<br />
# List contents of tarball.<br />
$ tar tf libfoo-0.1-1.src.tar.gz<br />
libfoo/<br />
libfoo/PKGBUILD<br />
libfoo/libfoo.install<br />
<br />
When submitting a package, observe the following rules: <br />
* Check the [http://www.archlinux.org/packages/ package database] for the package. If it exists, '''do not''' submit the package. If the current package is broken or is lacking an included feature then please file a [https://bugs.archlinux.org/ bug report].<br />
* Check the AUR for the package. If it is currently maintained, changes can be submitted in a comment for the maintainer's attention. If it is unmaintained, the package can be adopted and updated as required. Do not create duplicate packages.<br />
* Verify carefully that what you are uploading is correct. All contributors must read and adhere to the [[Arch Packaging Standards]] when writing PKGBUILDs. This is essential to the smooth running and general success of the AUR. Remember that you are not going to earn any credit or respect from your peers by wasting their time with a bad PKGBUILD.<br />
* Packages that contain binaries or that are very poorly written may be deleted without warning.<br />
* If you are unsure about the package (or the build/submission process) in any way, submit the PKGBUILD to the [https://mailman.archlinux.org/mailman/listinfo/ AUR Mailing List] or the [https://bbs.archlinux.org/viewforum.php?id=4 AUR boards] on the forum for public review before adding it to the AUR.<br />
* Make sure the package is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission.<br />
* Gain some experience before submitting packages. Build a few packages to learn the process and then submit.<br />
* If you submit a {{ic|package.tar.gz}} with a file named '{{ic|package}}' in it you will get an error: 'Could not change to directory {{ic|/home/aur/unsupported/package/package}}'. To resolve this, rename the file named '{{ic|package}}' to something else, for example, '{{ic|package.rc}}'. When it is installed in the {{ic|pkg}} directory you may rename it back to '{{ic|package}}'.<br />
Make sure to also read [[Arch Packaging Standards#Submitting packages to the AUR]].<br />
<br />
===Maintaining packages===<br />
* If you maintain a package and want to update the PKGBUILD for your package just resubmit it.<br />
* Check for feedback and comments from other users and try to incorporate any improvements they suggest; consider it a learning process!<br />
* Please do not just submit and forget about packages! It is the maintainer's job to maintain the package by checking for updates and improving the PKGBUILD.<br />
* If you do not want to continue to maintain the package for some reason, {{ic|disown}} the package using the AUR web interface and/or post a message to the AUR Mailing List.<br />
<br />
===Other requests===<br />
* Disownment requests and removal requests go to the aur-general mailing list for TUs and other users to decide upon.<br />
* '''Include package name and URL to AUR page''', preferably with a footnote [1].<br />
* Disownment requests will be granted two weeks after the current maintainer has been contacted by email and did not react.<br />
* '''Package merging has been implemented''', users still have to resubmit a package under a new name and may request merging of the old version's comments and votes on the mailing list<br />
* Removal requests require the following information:<br />
** Package name and URL to AUR page<br />
** Reason for deletion, at least a short note <br> '''Notice:''' A package's comments does not sufficiently point out the reasons why a package is up for deletion. Because as soon as a TU takes action, the only place where such information can be obtained is the aur-general mailing list.<br />
** Include supporting details, like when a package is provided by another package, if you are the maintainer yourself, it's renamed and the original owner agreed, etc.<br />
<br />
Removal requests can be disapproved, in which case you'll likely be advised to disown the package for a future packager's reference.<br />
<br />
==[community]==<br />
The [community] repository, maintained by [[Trusted Users]], contains the most popular packages from the AUR. It is enabled by default in {{ic|/etc/pacman.conf}}. If [community] has been disabled or removed, it can be enabled by uncommenting or adding these two lines: <br />
<br />
{{hc|/etc/pacman.conf|<nowiki><br />
...<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
...<br />
</nowiki>}}<br />
<br />
[community], unlike the AUR, contains binary packages that can be installed directly with [[pacman]] and the build files can also be accessed with the [[Arch Build System|ABS]]. Some of these packages may eventually make the transition to the [core] or [extra] repositories as the developers consider them crucial to the distribution.<br />
<br />
Users can also access the [community] build files by editing {{ic|/etc/abs.conf}} and enabling the [community] repository in the {{ic|REPOS}} array.<br />
<br />
==Git Repo==<br />
A Git Repo of the AUR is maintained by Thomas Dziedzic providing package history among other things. It is updated at least once a day. To clone the repository (several hundred MB):<br />
<br />
$ git clone git://pkgbuild.com/aur-mirror.git<br />
<br />
[http://pkgbuild.com/git/aur-mirror.git/ Web interface], [http://pkgbuild.com/~td123/readme Readme], [http://bbs.archlinux.org/viewtopic.php?id=113099 Forum thread]<br />
<br />
==FAQ==<br />
{{FAQ<br />
|question=What is the AUR?<br />
|answer=The AUR (Arch User Repository) is a place where the Arch Linux community can upload [[PKGBUILD]]s of applications, libraries, etc., and share them with the entire community. Fellow users can then vote for their favorites to be moved into the [community] repository to be shared with Arch Linux users in binary form.}}<br />
<br />
{{FAQ<br />
|question=What kind of packages are permitted on the AUR?<br />
|answer=The packages on the AUR are merely "build scripts", i.e recipes to build binaries for pacman. For most cases, everything is permitted, as long as you are in compliance with the licensing terms of the content. For other cases, where it is mentioned that "you may not link" to downloads, i.e contents that are not redistributable, you may only use the file name itself as the source. This means and requires users to already have the restricted source in the build directory prior to building the package. Piracy is frowned upon, so "warez" is absolutely not permitted. When in doubt, ask.}}<br />
<br />
{{FAQ<br />
|question=What is a TU?<br />
|answer=A [[AUR Trusted User Guidelines|TU (Trusted User)]] is a person who is chosen to oversee AUR and the [community] repository. They're the ones who maintain popular PKGBUILDs in [community], and overall keep the AUR running.}}<br />
<br />
{{FAQ<br />
|question=What's the difference between the Arch User Repository and [community]?<br />
|answer=The Arch User Repository is where all PKGBUILDs that users submit are stored, and must be built manually with [[makepkg]]. When PKGBUILDs receive enough votes, they are moved into the [community] repository, where the TUs maintain binary packages that can be installed with [[pacman]].}}<br />
<br />
{{FAQ<br />
|question=How many votes does it take to get a PKGBUILD into [community]?<br />
|answer=Usually, at least 10 votes are required for something to move into [community]. However, if a TU wants to support a package, it will often be found in the repository.}}<br />
<br />
{{FAQ<br />
|question=How do I make a PKGBUILD?<br />
|answer=The best resource is [[Creating Packages]]. Remember to look in AUR before creating the PKGBUILD as to not duplicate efforts.}}<br />
<br />
{{FAQ<br />
|question=I'm trying to do {{ic|pacman -S foo}}; it isn't working but I know it's in [community]<br />
|answer=You probably haven't enabled [community] in your {{ic|/etc/pacman.conf}}. Just uncomment the relevant lines.<br />
If [community] is enabled in your {{ic|/etc/pacman.conf}} try running {{ic|pacman -S -y}} first to synchronize the pkgcache before trying your package again.}}<br />
<br />
{{FAQ<br />
|question=Foo in AUR is outdated; what do I do?<br />
|answer=For starters, you can flag packages out-of-date. If it stays out-of-date for an extended period of time, the best thing to do is email the maintainer. If there is no response from the maintainer after two weeks, you could send mail to the aur-general mailing list to have a TU orphan the PKGBUILD if you're willing to maintain it yourself.}}<br />
<br />
{{FAQ<br />
|question=I have a PKGBUILD I would like to submit; can someone check it to see if there are any errors?<br />
|answer=If you would like to have your PKGBUILD critiqued, post it on the aur-general mailing list to get feedback from the TUs and fellow AUR members. You could also get help from the [[ArchChannel|IRC channel]], #archlinux on irc.freenode.net. You can also<br />
use [[namcap]] to check your PKGBUILD and the resulting package for errors.}}<br />
<br />
{{FAQ<br />
|question=Foo in AUR doesn't compile when I do {{ic|makepkg}}; what should I do?<br />
|answer=You are probably missing something trivial.<br />
<br />
# Run {{ic|pacman -Syyu}} before compiling anything with {{ic|makepkg}} as the problem may be that your system is not up-to-date.<br />
# Ensure you have both "base" and "base-devel" groups installed.<br />
# Try using the "{{ic|-s}}" option with {{ic|makepkg}} to check and install all the dependencies needed before starting the build process.<br />
<br />
Be sure to first read the PKGBUILD and the comments on the AUR page of the package in question.<br />
The reason might not be trivial after all. Custom CFLAGS, LDFLAGS and MAKEFLAGS can cause failures. It's also possible that the PKGBUILD is broken for everyone. If you cannot figure it out on your own, just report it to the maintainer e.g. by posting the errors you are getting in the comments on the AUR page.}}<br />
<br />
{{FAQ<br />
|question=How can I speed up repeated build processes?<br />
|answer=If you frequently compile code that uses gcc - say, a git or SVN package - you may find [[ccache]], short for "compiler cache", useful.}}<br />
<br />
{{FAQ<br />
|question=How do I access unsupported packages?<br />
|answer=See [[#Installing packages]]}}<br />
<br />
{{FAQ<br />
|question=How can I upload to AUR without using the web interface?<br />
|answer=You can use {{AUR|aurploader}}, {{AUR|aurup}} or {{AUR|burp}} -- these are command-line programs.}}</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Talk:Arch_User_Repository&diff=201093Talk:Arch User Repository2012-05-11T16:29:43Z<p>Rnabioullin: /* Standards on content */ re</p>
<hr />
<div>==<s>Merge with [[Arch User Repository]]</s>==<br />
<br />
Are there any objections to merging this article with the [[Arch User Repository]] article? It seems odd to redirect users to a separate "usage" page.<br />
<br />
-- [[User:Pointone|pointone]] 15:21, 12 March 2010 (EST)<br />
<br />
== Removing / changing the part about [community] ==<br />
<br />
IMO this whole part should just be removed now that community have been seperated from aur.<br />
But as a minimum it should be cleaned up, since there have been cases where it have confused users rather than help them:<br />
<br />
Perhaps something like:<br><br />
...<br><br />
The [community] repo is enabled by default in {{ic|pacman.conf}}. If disabled/removed, it can be enabled by uncommenting/adding these two lines:<br />
{{hc|/etc/pacman.conf|2=<br />
<nowiki><br />
...<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
...<br />
</nowiki><br />
}}<br />
...<br> <br />
Any typos would have to be fixed of course :p <br><br />
Is community still disabled by default in abs.conf btw?<br />
<br />
[[User:Mr.Elendig|Mr.Elendig]] 21:37, 21 November 2009 (EST)<br />
<br />
:I don't think the [community] section should be removed; improved, maybe. Where does this confusion arise from? What do you mean by "separated from AUR"? My understanding is that they are very much connected.<br />
<br />
:-- [[User:Pointone|pointone]] 22:33, 23 January 2010 (EST)<br />
<br />
== JSON ==<br />
There should be some sort of info on the JSON interface [[User:Daenyth|Daenyth]] 20:10, 29 November 2009 (EST)<br />
<br />
== Standards on content ==<br />
I believe that there should be more comprehensive, clear, and explicit standards on what content is allowed to be installed by an AUR package. There already exist two guidelines:<br />
<br />
1. usefulness:<br />
"Make sure the package is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission."<br />
<br />
2. IP restrictions:<br />
"For most cases, everything is permitted, as long as you are in compliance with the licensing terms of the software..."<br />
<br />
The former is acceptable because "usefulness" is inherently subjective. The latter does state an important restriction, but implicitly assumes that only software is permissible for AUR packages, when in fact there exist packages within the AUR which install only non-executable data. I ''believe'' that it is overall community consensus that such packages are permissible as long as they install documentation for a particular software package, a set of ''closely''-related software packages, or the Archlinux distro as a whole (e.g., offline Archlinux wiki), and that documentation not directly applicable to the aforementioned, any standards (e.g., FHS, OFM), and any books (e.g., Pro Git, Crime and Punishment, etc.) are outside the scope of the AUR. Any ideas? Do these proposed standards accurately reflect community consensus? [[User:Rnabioullin|Rnabioullin]] ([[User talk:Rnabioullin|talk]]) 19:13, 10 May 2012 (UTC)<br />
<br />
:This is an interesting observation indeed, but it goes beyond the scope of this wiki talk page; I suggest you start a thread in the forum or the mailing lists. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:02, 11 May 2012 (UTC)<br />
<br />
::I have posted this to the arch-general mailing list. [[User:Rnabioullin|Rnabioullin]] ([[User talk:Rnabioullin|talk]]) 16:29, 11 May 2012 (UTC)</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Talk:Arch_User_Repository&diff=200959Talk:Arch User Repository2012-05-10T19:13:03Z<p>Rnabioullin: /* Standards on content */ added signature</p>
<hr />
<div>==<s>Merge with [[Arch User Repository]]</s>==<br />
<br />
Are there any objections to merging this article with the [[Arch User Repository]] article? It seems odd to redirect users to a separate "usage" page.<br />
<br />
-- [[User:Pointone|pointone]] 15:21, 12 March 2010 (EST)<br />
<br />
== Removing / changing the part about [community] ==<br />
<br />
IMO this whole part should just be removed now that community have been seperated from aur.<br />
But as a minimum it should be cleaned up, since there have been cases where it have confused users rather than help them:<br />
<br />
Perhaps something like:<br><br />
...<br><br />
The [community] repo is enabled by default in {{ic|pacman.conf}}. If disabled/removed, it can be enabled by uncommenting/adding these two lines:<br />
{{hc|/etc/pacman.conf|2=<br />
<nowiki><br />
...<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
...<br />
</nowiki><br />
}}<br />
...<br> <br />
Any typos would have to be fixed of course :p <br><br />
Is community still disabled by default in abs.conf btw?<br />
<br />
[[User:Mr.Elendig|Mr.Elendig]] 21:37, 21 November 2009 (EST)<br />
<br />
:I don't think the [community] section should be removed; improved, maybe. Where does this confusion arise from? What do you mean by "separated from AUR"? My understanding is that they are very much connected.<br />
<br />
:-- [[User:Pointone|pointone]] 22:33, 23 January 2010 (EST)<br />
<br />
== JSON ==<br />
There should be some sort of info on the JSON interface [[User:Daenyth|Daenyth]] 20:10, 29 November 2009 (EST)<br />
<br />
== Standards on content ==<br />
I believe that there should be more comprehensive, clear, and explicit standards on what content is allowed to be installed by an AUR package. There already exist two guidelines:<br />
<br />
1. usefulness:<br />
"Make sure the package is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission."<br />
<br />
2. IP restrictions:<br />
"For most cases, everything is permitted, as long as you are in compliance with the licensing terms of the software..."<br />
<br />
The former is acceptable because "usefulness" is inherently subjective. The latter does state an important restriction, but implicitly assumes that only software is permissible for AUR packages, when in fact there exist packages within the AUR which install only non-executable data. I ''believe'' that it is overall community consensus that such packages are permissible as long as they install documentation for a particular software package, a set of ''closely''-related software packages, or the Archlinux distro as a whole (e.g., offline Archlinux wiki), and that documentation not directly applicable to the aforementioned, any standards (e.g., FHS, OFM), and any books (e.g., Pro Git, Crime and Punishment, etc.) are outside the scope of the AUR. Any ideas? Do these proposed standards accurately reflect community consensus? [[User:Rnabioullin|Rnabioullin]] ([[User talk:Rnabioullin|talk]]) 19:13, 10 May 2012 (UTC)</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Talk:Arch_User_Repository&diff=200958Talk:Arch User Repository2012-05-10T19:12:28Z<p>Rnabioullin: added Standards on content</p>
<hr />
<div>==<s>Merge with [[Arch User Repository]]</s>==<br />
<br />
Are there any objections to merging this article with the [[Arch User Repository]] article? It seems odd to redirect users to a separate "usage" page.<br />
<br />
-- [[User:Pointone|pointone]] 15:21, 12 March 2010 (EST)<br />
<br />
== Removing / changing the part about [community] ==<br />
<br />
IMO this whole part should just be removed now that community have been seperated from aur.<br />
But as a minimum it should be cleaned up, since there have been cases where it have confused users rather than help them:<br />
<br />
Perhaps something like:<br><br />
...<br><br />
The [community] repo is enabled by default in {{ic|pacman.conf}}. If disabled/removed, it can be enabled by uncommenting/adding these two lines:<br />
{{hc|/etc/pacman.conf|2=<br />
<nowiki><br />
...<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
...<br />
</nowiki><br />
}}<br />
...<br> <br />
Any typos would have to be fixed of course :p <br><br />
Is community still disabled by default in abs.conf btw?<br />
<br />
[[User:Mr.Elendig|Mr.Elendig]] 21:37, 21 November 2009 (EST)<br />
<br />
:I don't think the [community] section should be removed; improved, maybe. Where does this confusion arise from? What do you mean by "separated from AUR"? My understanding is that they are very much connected.<br />
<br />
:-- [[User:Pointone|pointone]] 22:33, 23 January 2010 (EST)<br />
<br />
== JSON ==<br />
There should be some sort of info on the JSON interface [[User:Daenyth|Daenyth]] 20:10, 29 November 2009 (EST)<br />
<br />
== Standards on content ==<br />
I believe that there should be more comprehensive, clear, and explicit standards on what content is allowed to be installed by an AUR package. There already exist two guidelines:<br />
<br />
1. usefulness:<br />
"Make sure the package is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission."<br />
<br />
2. IP restrictions:<br />
"For most cases, everything is permitted, as long as you are in compliance with the licensing terms of the software..."<br />
<br />
The former is acceptable because "usefulness" is inherently subjective. The latter does state an important restriction, but implicitly assumes that only software is permissible for AUR packages, when in fact there exist packages within the AUR which install only non-executable data. I ''believe'' that it is overall community consensus that such packages are permissible as long as they install documentation for a particular software package, a set of ''closely''-related software packages, or the Archlinux distro as a whole (e.g., offline Archlinux wiki), and that documentation not directly applicable to the aforementioned, any standards (e.g., FHS, OFM), and any books (e.g., Pro Git, Crime and Punishment, etc.) are outside the scope of the AUR. Any ideas? Do these proposed standards accurately reflect community consensus?</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Unison&diff=193064Unison2012-04-06T20:26:39Z<p>Rnabioullin: /* Save human time and keystrokes */ typo</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:Daemons and system services (English)]]<br />
'''Unison''' is a bidirectional file-synchronization tool for Unix and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other.<br />
<br />
Not only can Unison sync between Windows and Unix ( OSX, Solaris, Linux etc.) systems, it also unrestricted in terms of which system can be the host.<br />
<br />
Common uses include syncing configuration files, photos, and other content.<br />
<br />
<br />
==Installation==<br />
# pacman -S unison<br />
This provides a CLI and GTK+ 1 & 2 frontends.<br />
<br />
Offline documentation is available in the [https://aur.archlinux.org/packages.php?ID=56922 unison-doc] AUR package.<br />
<br />
==Configuration==<br />
In order to use Unison, you need to create a profile. You can use the supplied GUI tool or you can manually create a profile in {{ic|~/.unison}}.<br />
<br />
If you want to use the GUI configuration, run:<br />
$ unison-gtk2<br />
Otherwise, edit the default config file:<br />
# nano ~/.unison/default.prf<br />
<br />
First, define the root of what you want to sync:<br />
root=/home/user/<br />
<br />
Then, define the root of where to sync it to:<br />
root=ssh://example.com//path/to/server/storage<br />
<br />
Optionally, you can give arguments to SSH:<br />
sshargs=-p 4000<br />
<br />
Now you are going to define which directories and files to include in the sync:<br />
# dirs<br />
path=Documents<br />
path=Photos<br />
path=Study<br />
# files<br />
path=.bashrc<br />
path=.vimrc<br />
<br />
You can also define which files to ignore:<br />
ignore=Name temp.*<br />
ignore=Name .*~<br />
ignore=Name *.tmp<br />
<br />
For further references check the Unison [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#profileegs documentation].<br />
<br />
<br />
==Usage==<br />
Once your profile is set up, you can start syncing:<br />
$ unison <profilename><br />
or using the GUI tool:<br />
unison-gtk2<br />
and select the profile. Unison has a nice interface where you can view the progress and changes.<br />
<br />
<br />
==Version Incompatibility==<br />
For Unison to function properly, the same version ''must'' be installed on all clients. If, for example, one computer has version 2.40 and the other has 2.32, they will not be able to sync with each other. This applies to ''all'' computers that share a directory to be synchronized across your machines.<br />
<br />
Due to the staggered releases with varying Linux distros, you might be stuck with older versions of Unison, while Arch Linux has the latest upstream version in the Extra repository. There are unofficial [[PKGBUILD]]s for versions [https://aur.archlinux.org/packages.php?ID=46811 2.32] and [https://aur.archlinux.org/packages.php?ID=46823 2.27] on the [[AUR]] that allow users of multiple distros to continue using Unison with their existing systems.<br />
<br />
<br />
==Tips & Tricks==<br />
===Save human time and keystrokes===<br />
If one runs unison within a VDT emulator capable of maintaining a suitable scrollback buffer, there is no purpose in having to confirm every non-conflicting change; set the {{ic|auto}} option to true to avoid these prompts.<br />
<br />
===Common config sync===<br />
When syncing configuration files which would vary (e.g., due to endemic applications, security-sensitive configuration) among systems (servers, workstations, laptops, smartphones, etc.) but nevertheless contain common constructs (e.g., key bindings, basic shell aliases), it would be apt to separate such content into separate config files (e.g., {{ic|.bashrc_common}}), and sync only these.<br />
<br />
{{Warning|Bidirectional syncing of config files can lend itself to become an avenue for an attack, by enabling the peer syncing system to receive malicious changes to config files (and perhaps even other peers the system syncs with). This is an attractive option for adversaries, especially when the conceptual security levels of the two systems differ (e.g., public shell server vs. personal workstation), since it would likely be simpler to compromise a system of lower security. Always use the {{ic|noupdate}} option when bidirectional syncing between two particular systems is deemed unnecessary; when necessary, verify each change when syncing. Automatic bidirectional syncs should be done with extreme caution.}}<br />
<br />
==External Links==<br />
*[http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#afterinstall Official User Manual and Reference Guide, Section "Running Unison"]<br />
<br />
*[http://www.stanford.edu/~pgbovine/unison_guide.htm Useful advice]</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Unison&diff=193062Unison2012-04-06T20:21:32Z<p>Rnabioullin: /* Tips & Tricks */ auto option</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:Daemons and system services (English)]]<br />
'''Unison''' is a bidirectional file-synchronization tool for Unix and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other.<br />
<br />
Not only can Unison sync between Windows and Unix ( OSX, Solaris, Linux etc.) systems, it also unrestricted in terms of which system can be the host.<br />
<br />
Common uses include syncing configuration files, photos, and other content.<br />
<br />
<br />
==Installation==<br />
# pacman -S unison<br />
This provides a CLI and GTK+ 1 & 2 frontends.<br />
<br />
Offline documentation is available in the [https://aur.archlinux.org/packages.php?ID=56922 unison-doc] AUR package.<br />
<br />
==Configuration==<br />
In order to use Unison, you need to create a profile. You can use the supplied GUI tool or you can manually create a profile in {{ic|~/.unison}}.<br />
<br />
If you want to use the GUI configuration, run:<br />
$ unison-gtk2<br />
Otherwise, edit the default config file:<br />
# nano ~/.unison/default.prf<br />
<br />
First, define the root of what you want to sync:<br />
root=/home/user/<br />
<br />
Then, define the root of where to sync it to:<br />
root=ssh://example.com//path/to/server/storage<br />
<br />
Optionally, you can give arguments to SSH:<br />
sshargs=-p 4000<br />
<br />
Now you are going to define which directories and files to include in the sync:<br />
# dirs<br />
path=Documents<br />
path=Photos<br />
path=Study<br />
# files<br />
path=.bashrc<br />
path=.vimrc<br />
<br />
You can also define which files to ignore:<br />
ignore=Name temp.*<br />
ignore=Name .*~<br />
ignore=Name *.tmp<br />
<br />
For further references check the Unison [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#profileegs documentation].<br />
<br />
<br />
==Usage==<br />
Once your profile is set up, you can start syncing:<br />
$ unison <profilename><br />
or using the GUI tool:<br />
unison-gtk2<br />
and select the profile. Unison has a nice interface where you can view the progress and changes.<br />
<br />
<br />
==Version Incompatibility==<br />
For Unison to function properly, the same version ''must'' be installed on all clients. If, for example, one computer has version 2.40 and the other has 2.32, they will not be able to sync with each other. This applies to ''all'' computers that share a directory to be synchronized across your machines.<br />
<br />
Due to the staggered releases with varying Linux distros, you might be stuck with older versions of Unison, while Arch Linux has the latest upstream version in the Extra repository. There are unofficial [[PKGBUILD]]s for versions [https://aur.archlinux.org/packages.php?ID=46811 2.32] and [https://aur.archlinux.org/packages.php?ID=46823 2.27] on the [[AUR]] that allow users of multiple distros to continue using Unison with their existing systems.<br />
<br />
<br />
==Tips & Tricks==<br />
===Save human time and keystrokes===<br />
If one runs unison within a VDT emulator capable of maintaining a suitable scrollback buffer, there is no purpose (apart from the case of syncing between systems of differing conceptual security levels) in having to confirm every non-conflicting change; set the {{ic|auto}} option to true to avoid these prompts.<br />
<br />
===Common config sync===<br />
When syncing configuration files which would vary (e.g., due to endemic applications, security-sensitive configuration) among systems (servers, workstations, laptops, smartphones, etc.) but nevertheless contain common constructs (e.g., key bindings, basic shell aliases), it would be apt to separate such content into separate config files (e.g., {{ic|.bashrc_common}}), and sync only these.<br />
<br />
{{Warning|Bidirectional syncing of config files can lend itself to become an avenue for an attack, by enabling the peer syncing system to receive malicious changes to config files (and perhaps even other peers the system syncs with). This is an attractive option for adversaries, especially when the conceptual security levels of the two systems differ (e.g., public shell server vs. personal workstation), since it would likely be simpler to compromise a system of lower security. Always use the {{ic|noupdate}} option when bidirectional syncing between two particular systems is deemed unnecessary; when necessary, verify each change when syncing. Automatic bidirectional syncs should be done with extreme caution.}}<br />
<br />
==External Links==<br />
*[http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#afterinstall Official User Manual and Reference Guide, Section "Running Unison"]<br />
<br />
*[http://www.stanford.edu/~pgbovine/unison_guide.htm Useful advice]</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=User:Rnabioullin&diff=191894User:Rnabioullin2012-03-27T16:04:54Z<p>Rnabioullin: Removed old contact info</p>
<hr />
<div></div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=User_talk:Kynikos&diff=190501User talk:Kynikos2012-03-20T15:40:00Z<p>Rnabioullin: Added deletion request</p>
<hr />
<div>Feel free to leave here your comments on my edits or anything else you want to talk about: I'll reply as soon as I can!<br />
<br />
{{Note|Please, add new discussions at the bottom, and with a proper title: I'll take care of removing old discussions once they are exhausted.}}<br />
<br />
==Xyne-related page edits after Powerpill, Bauerbill... discontinuation==<br />
See [[User_talk:Kynikos/Xyne-related pages|Xyne-related page edits after Powerpill, Bauerbill... discontinuation]].<br />
<br />
==Thank you!==<br />
Thank you for your massive contribution in initiating -- and completing! -- [[Help:Style]]. This is something I have wanted to tackle for [https://bbs.archlinux.org/viewtopic.php?id=61033 years]! Well done! -- [[User:Pointone|pointone]] 14:23, 1 November 2011 (EDT)<br />
:In Italian on these occasions we say literally "praised by Caesar" :) I'm proud and eager to be helping the community of this amazing project, and to be working with other enthusiastic people like you! ^^ -- [[User:Kynikos|Kynikos]] 16:02, 1 November 2011 (EDT)<br />
<br />
==<s>Categories for [[Port Knocking]]</s>==<br />
Hi, I saw you set back the category to "secure shell" only. <br />
<br />
''08:30, 17 November 2011 Kynikos (Talk | contribs) (5,369 bytes) (Category:Secure Shell is already under both Security and Networking, adding all of them doesn't comply with Help:Style#Categories) (undo)''<br />
<br />
I understand having the three of them wasn't correct, however, I think that instead of removing "security" and "networking", it would be better to remove "secure shell". The reason is because port knocking is not only for port 22, but it can be used for any other port (for instance, I have used it for openvpn with some different rules)<br />
<br />
And since [[iptables]] has both categories (security and networking), and this article is mostly some special use of iptables, I think their categories fit fine here.<br />
<br />
What you think? [[User:Chrisl|Chrisl]] 11:52, 17 November 2011 (EST)<br />
<br />
:Agreed, you can go on and recategorize the article, thanks for contributing :) (remember to sign your edits in talk pages with {{ic|<nowiki>~~~~</nowiki>}}) -- [[User:Kynikos|Kynikos]] 11:06, 17 November 2011 (EST)<br />
::Thanks :D [[User:Chrisl|Chrisl]] 11:52, 17 November 2011 (EST)<br />
<br />
== Thanks! ==<br />
Thanks for fixing the style on the [[Step By Step Debugging Guide]] page!<br />
--[[User:Trontonic|Trontonic]] 20:52, 6 January 2012 (EST)<br />
:Thank you for contributing :) Actually it'd require more fixes, for example the expansion of contractions, see [[Help:Style]] for more information.<br />
:By the way I've noticed that I put the article in the wrong category: it's somewhat fixed now, but if you're interested, in [[ArchWiki:Reports#System recovery category]] we're also talking about the possibility of merging [[Step By Step Debugging Guide]] with [[General Troubleshooting]].<br />
:-- [[User:Kynikos|Kynikos]] 07:29, 7 January 2012 (EST)<br />
<br />
==<s>Template Yes and No</s>==<br />
<br />
After adding <nowiki> <includeonly> </nowiki> markup ,it only shows a empty table in the template page. --[[User:Skydiver|Skydiver]] 10:12, 2 February 2012 (EST)<br />
:Uh, to say the truth I thought it was the usual problem with the cache that doesn't refresh after updating a template, but you're right, &lt;includeonly> breaks the example. We should create a separate example like it's done for all the other templates, thanks for reporting! -- [[User:Kynikos|Kynikos]] 11:20, 2 February 2012 (EST)<br />
:I've fixed the examples, the Chinese versions need some translation. -- [[User:Kynikos|Kynikos]] 05:37, 3 February 2012 (EST)<br />
::Ok, Chinese version translated. --[[User:Skydiver|Skydiver]] 06:01, 3 February 2012 (EST)<br />
:::Perfect, closing. -- [[User:Kynikos|Kynikos]] 06:07, 3 February 2012 (EST)<br />
<br />
== About [[Template:Filename]] => [[Template:ic]] ==<br />
<br />
Thanks for your contribution and your bot :) But i think the original [[Template:Filename]] has its advantage too. Although both template have the same display style now, they actually have different meanings. Filename and codes is different. Now it's very easy to replace filename with ic, but if we want to have a different styles of filename one day, it's rather difficult to find whether it means code or filename. --[[User:Skydiver|Skydiver]] 23:52, 13 February 2012 (EST)<br />
:Eheh you're quite late about this :) We discussed it a lot in [[Help talk:Style]] and [[Help talk:Style/Migration to new Code formatting templates]] (see their history). This is the direction where the wiki is headed, we can't cyclically call into question always the same things, otherwise there will never be any real improvement. Basically we just decided to keep it simple: Template:Filename wasn't used consistently anyway, and there were many cases of ambiguity, so now we're just distinguishing between inline and block code. -- [[User:Kynikos|Kynikos]] 07:29, 14 February 2012 (EST)<br />
::Haha~ yeah, i'm late. I didn't notice your notice before and right after i post here I found your bot have done all replacement and Template:Filename has been deleted ... --[[User:Skydiver|Skydiver]] 10:23, 14 February 2012 (EST)<br />
:BTW I see you're actually using Wiki Monkey yourself :D Honestly I didn't think somebody was using it except for me, so be advised that if you had installed version 1.6.1 or previous, it won't update automatically to 1.7.x because I've changed the path for configuration files (I won't break the update system anymore, I promise ^^ ). Also please report any bugs you find! -- [[User:Kynikos|Kynikos]] 09:12, 14 February 2012 (EST)<br />
::Yep, I found your Wiki Monkey very useful ^_^. I am using 1.7.0 now and find it useful when doing replaces. I'm trying to make a plugin that can automatically find articles w/o i18n template and add i18n template to them, but i've no idea how to do till now.--[[User:Skydiver|Skydiver]] 10:23, 14 February 2012 (EST)<br />
:::Good to hear that you like it, thanks! I've just released 1.7.2 (just bug fixes), however if you don't enable automatic updates as described in [[User:Kynikos/Wiki_Monkey#Updates]] you will have to update manually; unfortunately automatic updates are disabled by default by Scriptish's design, there's nothing I can do about that :)<br />
:::If you want to fix the header of articles (including the i18n template), simply in editor pages, just write a js function that has the source text and the title as input arguments and the modified source as the return value, and I'll think of Wiki-Monkey-zing it ;)<br />
{{bc|function fixHeader(title, source) {<br />
//your code here<br />
return modSource;<br />
} }}<br />
:::Note that you won't probably be able to just add i18n without also recognizing categories and other stuff that goes at the top of the article.<br />
:::About doing that on all articles automatically, it's easy to adapt it also for What Links Here pages, since launching the bot from there is already implemented, however you'd more likely need to launch the bot recursively over all the articles under a category and its sub-categories, and that functionality still needs to be implemented. Another way to do that job, which I'd like even more, would be to make Wiki Monkey semi-automatically process the recent changes, suggesting automatic fixes to every article that is edited and letting the user decide whether to apply them or not. A recent changes helper is also in the todo list, but will require some time to develop it.<br />
:::-- [[User:Kynikos|Kynikos]] 13:14, 14 February 2012 (EST)<br />
<br />
== Template:Cmd Thanks ==<br />
<br />
Hey Kynikos thanks so much for getting me that [[User_talk:AskApache#Template:Cmd_2|template source]]! I spent many hours working on it and am really happy to have it back. Thank you. --[[User:AskApache|AskApache]] 11:21, 27 February 2012 (EST)<br />
: :) -- [[User:Kynikos|Kynikos]] 05:49, 28 February 2012 (EST)<br />
<br />
== html comments in page source ==<br />
<br />
Thank you for constant improvement of articles sources! Most of comments in source code of [[Common Applications]] and sub-articles were left by me. These comments were initially added to be later turned into proper categories etc. but due to lack of time I often forget about it. Please consider reorganizing entries instead of just removing comments - it sometimes require a bit of work to determine for example which version of Quake engine is used in every game. --[[User:AlexanderR|AlexanderR]] 05:38, 11 March 2012 (EDT)<br />
:Html comments are strongly discouraged right because they tend to be forgotten :P<br />
:The edits that removed potentially relevant comments are [https://wiki.archlinux.org/index.php?title=Common_Applications/Games/Emulators&diff=prev&oldid=188719] and [https://wiki.archlinux.org/index.php?title=Common_Applications/Games/Free&diff=prev&oldid=188723]: the only ways I can think of using those info are either creating subsections (=====PS1=====, =====PS2=====, =====Quake 1=====, ...) or adding those info in the descriptions of the appropriate app entries (I probably prefer the latter solution).<br />
:-- [[User:Kynikos|Kynikos]] 07:54, 11 March 2012 (EDT)<br />
<br />
== Deletion request ==<br />
Could you please delete [[LED_Status_Display]]? Although I disagree with your claim that it is not pertinent to Arch Linux, I have concluded that my ideas on that page were half-baked and impractical. Thanks. [[User:Rnabioullin|Rnabioullin]] 11:40, 20 March 2012 (EDT)</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Unison&diff=187114Unison2012-03-02T02:57:57Z<p>Rnabioullin: /* Tips & Tricks */ Added to warning.</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:Daemons and system services (English)]]<br />
'''Unison''' is a bidirectional file-synchronization tool for Unix and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other.<br />
<br />
Not only can Unison sync between Windows and Unix ( OSX, Solaris, Linux etc.) systems, it also unrestricted in terms of which system can be the host.<br />
<br />
Common uses include syncing configuration files, photos, and other content.<br />
<br />
<br />
==Installation==<br />
# pacman -S unison<br />
This provides a CLI and GTK+ 1 & 2 frontends.<br />
<br />
Offline documentation is available in the [https://aur.archlinux.org/packages.php?ID=56922 unison-doc] AUR package.<br />
<br />
==Configuration==<br />
In order to use Unison, you need to create a profile. You can use the supplied GUI tool or you can manually create a profile in {{ic|~/.unison}}.<br />
<br />
If you want to use the GUI configuration, run:<br />
$ unison-gtk2<br />
Otherwise, edit the default config file:<br />
# nano ~/.unison/default.prf<br />
<br />
First, define the root of what you want to sync:<br />
root=/home/user/<br />
<br />
Then, define the root of where to sync it to:<br />
root=ssh://example.com//path/to/server/storage<br />
<br />
Optionally, you can give arguments to SSH:<br />
sshargs=-p 4000<br />
<br />
Now you are going to define which directories and files to include in the sync:<br />
# dirs<br />
path=Documents<br />
path=Photos<br />
path=Study<br />
# files<br />
path=.bashrc<br />
path=.vimrc<br />
<br />
You can also define which files to ignore:<br />
ignore=Name temp.*<br />
ignore=Name .*~<br />
ignore=Name *.tmp<br />
<br />
For further references check the Unison [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#profileegs documentation].<br />
<br />
<br />
==Usage==<br />
Once your profile is set up, you can start syncing:<br />
$ unison <profilename><br />
or using the GUI tool:<br />
unison-gtk2<br />
and select the profile. Unison has a nice interface where you can view the progress and changes.<br />
<br />
<br />
==Version Incompatibility==<br />
For Unison to function properly, the same version ''must'' be installed on all clients. If, for example, one computer has version 2.40 and the other has 2.32, they will not be able to sync with each other. This applies to ''all'' computers that share a directory to be synchronized across your machines.<br />
<br />
Due to the staggered releases with varying Linux distros, you might be stuck with older versions of Unison, while Arch Linux has the latest upstream version in the Extra repository. There are unofficial [[PKGBUILD]]s for versions [https://aur.archlinux.org/packages.php?ID=46811 2.32] and [https://aur.archlinux.org/packages.php?ID=46823 2.27] on the [[AUR]] that allow users of multiple distros to continue using Unison with their existing systems.<br />
<br />
<br />
==Tips & Tricks==<br />
When syncing configuration files which would vary (e.g., due to endemic applications, security-sensitive configuration) among systems (servers, workstations, laptops, smartphones, etc.) but nevertheless contain common constructs (e.g., key bindings, basic shell aliases), it would be apt to separate such content into separate config files (e.g., {{ic|.bashrc_common}}), and sync only these.<br />
<br />
{{Warning|Bidirectional syncing of config files can lend itself to become an avenue for an attack, by enabling the peer syncing system to receive malicious changes to config files (and perhaps even other peers the system syncs with). This is an attractive option for adversaries, especially when the conceptual security levels of the two systems differ (e.g., public shell server vs. personal workstation), since it would likely be simpler to compromise a system of lower security. Always use the {{ic|noupdate}} option when bidirectional syncing between two particular systems is deemed unnecessary; when necessary, verify each change when syncing. Automatic bidirectional syncs should be done with extreme caution.}}<br />
<br />
==External Links==<br />
*[http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#afterinstall Official User Manual and Reference Guide, Section "Running Unison"]<br />
<br />
*[http://www.stanford.edu/~pgbovine/unison_guide.htm Useful advice]</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Unison&diff=187113Unison2012-03-02T02:52:54Z<p>Rnabioullin: /* Tips & Tricks */ Added attack warning.</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:Daemons and system services (English)]]<br />
'''Unison''' is a bidirectional file-synchronization tool for Unix and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other.<br />
<br />
Not only can Unison sync between Windows and Unix ( OSX, Solaris, Linux etc.) systems, it also unrestricted in terms of which system can be the host.<br />
<br />
Common uses include syncing configuration files, photos, and other content.<br />
<br />
<br />
==Installation==<br />
# pacman -S unison<br />
This provides a CLI and GTK+ 1 & 2 frontends.<br />
<br />
Offline documentation is available in the [https://aur.archlinux.org/packages.php?ID=56922 unison-doc] AUR package.<br />
<br />
==Configuration==<br />
In order to use Unison, you need to create a profile. You can use the supplied GUI tool or you can manually create a profile in {{ic|~/.unison}}.<br />
<br />
If you want to use the GUI configuration, run:<br />
$ unison-gtk2<br />
Otherwise, edit the default config file:<br />
# nano ~/.unison/default.prf<br />
<br />
First, define the root of what you want to sync:<br />
root=/home/user/<br />
<br />
Then, define the root of where to sync it to:<br />
root=ssh://example.com//path/to/server/storage<br />
<br />
Optionally, you can give arguments to SSH:<br />
sshargs=-p 4000<br />
<br />
Now you are going to define which directories and files to include in the sync:<br />
# dirs<br />
path=Documents<br />
path=Photos<br />
path=Study<br />
# files<br />
path=.bashrc<br />
path=.vimrc<br />
<br />
You can also define which files to ignore:<br />
ignore=Name temp.*<br />
ignore=Name .*~<br />
ignore=Name *.tmp<br />
<br />
For further references check the Unison [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#profileegs documentation].<br />
<br />
<br />
==Usage==<br />
Once your profile is set up, you can start syncing:<br />
$ unison <profilename><br />
or using the GUI tool:<br />
unison-gtk2<br />
and select the profile. Unison has a nice interface where you can view the progress and changes.<br />
<br />
<br />
==Version Incompatibility==<br />
For Unison to function properly, the same version ''must'' be installed on all clients. If, for example, one computer has version 2.40 and the other has 2.32, they will not be able to sync with each other. This applies to ''all'' computers that share a directory to be synchronized across your machines.<br />
<br />
Due to the staggered releases with varying Linux distros, you might be stuck with older versions of Unison, while Arch Linux has the latest upstream version in the Extra repository. There are unofficial [[PKGBUILD]]s for versions [https://aur.archlinux.org/packages.php?ID=46811 2.32] and [https://aur.archlinux.org/packages.php?ID=46823 2.27] on the [[AUR]] that allow users of multiple distros to continue using Unison with their existing systems.<br />
<br />
<br />
==Tips & Tricks==<br />
When syncing configuration files which would vary (e.g., due to endemic applications, security-sensitive configuration) among systems (servers, workstations, laptops, smartphones, etc.) but nevertheless contain common constructs (e.g., key bindings, basic shell aliases), it would be apt to separate such content into separate config files (e.g., {{ic|.bashrc_common}}), and sync only these.<br />
<br />
{{Warning|Bidirectional syncing of config files can lend itself to become an avenue for an attack, by enabling the peer syncing system to receive malicious changes to config files (and perhaps even other peers the system syncs with). This is an attractive option for adversaries, especially when the conceptual security levels of the two systems differ (e.g., public shell server vs. personal workstation), since it would likely be simpler to compromise a system of lower security. Always use the {{ic|noupdate}} option when bidirectional syncing between two particular systems is not necessary.}}<br />
<br />
==External Links==<br />
*[http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#afterinstall Official User Manual and Reference Guide, Section "Running Unison"]<br />
<br />
*[http://www.stanford.edu/~pgbovine/unison_guide.htm Useful advice]</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Unison&diff=187096Unison2012-03-01T19:39:46Z<p>Rnabioullin: Added config file advice</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:Daemons and system services (English)]]<br />
'''Unison''' is a bidirectional file-synchronization tool for Unix and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other.<br />
<br />
Not only can Unison sync between Windows and Unix ( OSX, Solaris, Linux etc.) systems, it also unrestricted in terms of which system can be the host.<br />
<br />
Common uses include syncing configuration files, photos, and other content.<br />
<br />
<br />
==Installation==<br />
# pacman -S unison<br />
This provides a CLI and GTK+ 1 & 2 frontends.<br />
<br />
Offline documentation is available in the [https://aur.archlinux.org/packages.php?ID=56922 unison-doc] AUR package.<br />
<br />
==Configuration==<br />
In order to use Unison, you need to create a profile. You can use the supplied GUI tool or you can manually create a profile in {{ic|~/.unison}}.<br />
<br />
If you want to use the GUI configuration, run:<br />
$ unison-gtk2<br />
Otherwise, edit the default config file:<br />
# nano ~/.unison/default.prf<br />
<br />
First, define the root of what you want to sync:<br />
root=/home/user/<br />
<br />
Then, define the root of where to sync it to:<br />
root=ssh://example.com//path/to/server/storage<br />
<br />
Optionally, you can give arguments to SSH:<br />
sshargs=-p 4000<br />
<br />
Now you are going to define which directories and files to include in the sync:<br />
# dirs<br />
path=Documents<br />
path=Photos<br />
path=Study<br />
# files<br />
path=.bashrc<br />
path=.vimrc<br />
<br />
You can also define which files to ignore:<br />
ignore=Name temp.*<br />
ignore=Name .*~<br />
ignore=Name *.tmp<br />
<br />
For further references check the Unison [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#profileegs documentation].<br />
<br />
<br />
==Usage==<br />
Once your profile is set up, you can start syncing:<br />
$ unison <profilename><br />
or using the GUI tool:<br />
unison-gtk2<br />
and select the profile. Unison has a nice interface where you can view the progress and changes.<br />
<br />
<br />
==Version Incompatibility==<br />
For Unison to function properly, the same version ''must'' be installed on all clients. If, for example, one computer has version 2.40 and the other has 2.32, they will not be able to sync with each other. This applies to ''all'' computers that share a directory to be synchronized across your machines.<br />
<br />
Due to the staggered releases with varying Linux distros, you might be stuck with older versions of Unison, while Arch Linux has the latest upstream version in the Extra repository. There are unofficial [[PKGBUILD]]s for versions [https://aur.archlinux.org/packages.php?ID=46811 2.32] and [https://aur.archlinux.org/packages.php?ID=46823 2.27] on the [[AUR]] that allow users of multiple distros to continue using Unison with their existing systems.<br />
<br />
<br />
==Tips & Tricks==<br />
When syncing configuration files which would vary (e.g., due to endemic applications, security-sensitive configuration) among systems (servers, workstations, laptops, smartphones, etc.) but nevertheless contain common constructs (e.g., key bindings, basic shell aliases), it would be apt to separate such content into separate config files (e.g., {{ic|.bashrc_common}}), and sync only these.<br />
<br />
<br />
==External Links==<br />
*[http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#afterinstall Official User Manual and Reference Guide, Section "Running Unison"]<br />
<br />
*[http://www.stanford.edu/~pgbovine/unison_guide.htm Useful advice]</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Unison&diff=187084Unison2012-03-01T17:30:14Z<p>Rnabioullin: Added description, doc package link, external link</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:Daemons and system services (English)]]<br />
'''Unison''' is a bidirectional file-synchronization tool for Unix and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other.<br />
<br />
Not only can Unison sync between Windows and Unix ( OSX, Solaris, Linux etc.) systems, it also unrestricted in terms of which system can be the host.<br />
<br />
Common uses include syncing configuration files, photos, and other content.<br />
<br />
<br />
==Installation==<br />
# pacman -S unison<br />
This provides a CLI and GTK+ 1 & 2 frontends.<br />
<br />
Offline documentation is available in the [https://aur.archlinux.org/packages.php?ID=56922 unison-doc] AUR package.<br />
<br />
==Configuration==<br />
In order to use Unison, you need to create a profile. You can use the supplied GUI tool or you can manually create a profile in {{ic|~/.unison}}.<br />
<br />
If you want to use the GUI configuration, run:<br />
$ unison-gtk2<br />
Otherwise, edit the default config file:<br />
# nano ~/.unison/default.prf<br />
<br />
First, define the root of what you want to sync:<br />
root=/home/user/<br />
<br />
Then, define the root of where to sync it to:<br />
root=ssh://example.com//path/to/server/storage<br />
<br />
Optionally, you can give arguments to SSH:<br />
sshargs=-p 4000<br />
<br />
Now you are going to define which directories and files to include in the sync:<br />
# dirs<br />
path=Documents<br />
path=Photos<br />
path=Study<br />
# files<br />
path=.bashrc<br />
path=.vimrc<br />
<br />
You can also define which files to ignore:<br />
ignore=Name temp.*<br />
ignore=Name .*~<br />
ignore=Name *.tmp<br />
<br />
For further references check the Unison [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#profileegs documentation].<br />
<br />
<br />
==Usage==<br />
Once your profile is set up, you can start syncing:<br />
$ unison <profilename><br />
or using the GUI tool:<br />
unison-gtk2<br />
and select the profile. Unison has a nice interface where you can view the progress and changes.<br />
<br />
<br />
==Version Incompatibility==<br />
For Unison to function properly, the same version ''must'' be installed on all clients. If, for example, one computer has version 2.40 and the other has 2.32, they will not be able to sync with each other. This applies to ''all'' computers that share a directory to be synchronized across your machines.<br />
<br />
Due to the staggered releases with varying Linux distros, you might be stuck with older versions of Unison, while Arch Linux has the latest upstream version in the Extra repository. There are unofficial [[PKGBUILD]]s for versions [https://aur.archlinux.org/packages.php?ID=46811 2.32] and [https://aur.archlinux.org/packages.php?ID=46823 2.27] on the [[AUR]] that allow users of multiple distros to continue using Unison with their existing systems.<br />
<br />
<br />
==External Links==<br />
*[http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#afterinstall Official User Manual and Reference Guide, Section "Running Unison"]<br />
<br />
*[http://www.stanford.edu/~pgbovine/unison_guide.htm Useful advice]</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Tmux&diff=185429Tmux2012-02-20T17:10:46Z<p>Rnabioullin: /* ICCCM Selection Integration */ Refined command to allow for hyphen(s) in CLIPBOARD.</p>
<hr />
<div>{{i18n|Tmux}}<br />
[[Category:Software (English)]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|This article explains how to install and configure tmux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GNU Screen}}<br />
{{Article summary end}}<br />
<br />
[http://tmux.sourceforge.net/ Tmux] is a "terminal multiplexer: it enables a number of terminals (or windows), each running a separate program, to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached." <br />
<br />
Tmux is notable as a BSD-licensed alternative to [[Screen Tips|GNU Screen]]. Although similar, there are many differences between the programs, as noted on the [http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ tmux FAQ page]. Most notably, tmux is currently under active development, in contrast to screen, which has not had a stable release since August 8, 2008.<br />
<br />
==Install==<br />
A stable version of tmux may be installed using [[pacman]]:<br />
# pacman -S tmux<br />
Alternatively, [https://aur.archlinux.org/packages.php?ID=35618 tmux-git] is available from the [[AUR]].<br />
<br />
==Configure==<br />
A user-specific configuration file should be located at {{ic|~/.tmux.conf}}, while a global configuration file should be located at {{ic|/etc/tmux.conf}}. Default configuration files can be found in {{Ic|/usr/share/tmux/}}. <br />
<br />
===Key bindings===<br />
{| style="float:right;border:1px #cccccc solid;margin:5px;padding:5px;width:200px;"<br />
|+ ''Prefix all commands with'' {{Ic|Ctrl-b}}<br />
!Cmd<br />
!Action<br />
|-<br />
|c<br />
|Create a new window<br />
|-<br />
|n<br />
|Change to next window<br />
|-<br />
|p<br />
|Change to previous window<br />
|-<br />
|"<br />
|Split pane horizontally<br />
|-<br />
|%<br />
|Split pane vertically<br />
|-<br />
|,<br />
|Rename current window<br />
|-<br />
|o<br />
|Move to next pane<br />
|}<br />
<br />
By default, command key bindings are prefixed by Ctrl-b. For example, to vertically split a window type {{Ic|Ctrl-b %}}.<br />
<br />
After splitting a window into multiple panes, you can resize a pane by the hitting prefix key (i.e. {{Ic|Ctrl-b}}) and, while continuing to hold Ctrl, press Left/Right/Up/Down. Swapping panes is achieved in the same manner, but by hitting ''o'' instead of a directional key.<br />
<br />
{{Tip|To mimic screen key bindings copy {{ic|/usr/share/tmux/screen-keys.conf}} to either of the configuration locations.}}<br />
<br />
Key bindings may be changed with the bind and unbind commands in {{ic|tmux.conf}}. For example, you can change the prefix key (i.e. {{Ic|Ctrl-b}}) to {{Ic|Ctrl-a}} by adding the following commands in your configuration file:<br />
unbind C-b<br />
set -g prefix C-a<br />
<br />
Additional ways to move between windows include:<br />
Ctrl-b l (Move to the previously selected window)<br />
Ctrl-b w (List all windows / window numbers)<br />
Ctrl-b <window number> (Move to the specified window number, the default bindings are from 0 – 9)<br />
Ctrl-b q (Show pane numbers, when the numbers show up type the key to goto that pane)<br />
<br />
What if you have 10+ windows open? Tmux has a find-window option & keybinding. <br />
Ctrl-b f <window name> (Search for window name)<br />
Ctrl-b w (Select from interactive list of windows)<br />
<br />
===Browsing URL's===<br />
To browse URL's inside tmux you must have urlview installed and configured:<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; run-shell "$TERMINAL -e 'cat /tmp/tmux-buffer | urlview'"<br />
<br />
=== Setting the correct term===<br />
If you are using a 256 colour terminal, you will need to set the correct term in tmux. You can do this in either the {{ic|tmux.conf}}:<br />
<br />
set -g default-terminal "screen-256color" <br />
<br />
or in your {{ic|.bashrc}} with a test like:<br />
<br />
# for tmux: export 256color<br />
[ -n "$TMUX" ] && export TERM=screen-256color<br />
<br />
If you enable xterm-keys in your {{ic|tmux.conf}}, then you need to build a custom terminfo to declare the new escape codes or applications will not know about them. Compile the following with {{ic|tic}} and you can use "xterm-screen-256color" as your TERM:<br />
<br />
# A screen- based TERMINFO that declares the escape sequences<br />
# enabled by the tmux config "set-window-option -g xterm-keys".<br />
#<br />
# Prefix the name with xterm- since some applications inspect<br />
# the TERM *name* in addition to the terminal capabilities advertised.<br />
xterm-screen-256color|GNU Screen with 256 colors bce and tmux xterm-keys,<br />
<br />
# As of Nov'11, the below keys are picked up by<br />
# .../tmux/blob/master/trunk/xterm-keys.c:<br />
kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H,<br />
kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~,<br />
kRIT=\E[1;2C,<br />
<br />
# Change this to screen-256color if the terminal you run tmux in<br />
# doesn't support bce:<br />
use=screen-256color-bce,<br />
<br />
==Session initialization==<br />
You can have tmux open a session with preloaded windows by including those details in your {{ic|~/.tmux.conf}}:<br />
<br />
new -n WindowName Command<br />
neww -n WindowName Command<br />
neww -n WindowName Command<br />
<br />
To start a session with split windows (multiple panes), include the splitw command below the neww you would like to split; thus:<br />
<br />
new -s SessionName -n WindowName Command<br />
neww -n foo/bar foo<br />
splitw -v -p 50 -t 0 bar<br />
selectw -t 1 <br />
selectp -t 0<br />
<br />
would open 2 windows, the second of which would be named foo/bar and would be split vertically in half (50%) with foo running above bar. Focus would be in window 2 (foo/bar), top pane (foo).<br />
<br />
{{Note|Numbering for sessions, windows and panes starts at zero, unless you have specified a base-index of 1 in your {{ic|.conf}} }}<br />
<br />
To manage multiple sessions, source separate session files from your conf file:<br />
<br />
# initialize sessions<br />
bind F source-file ~/.tmux/foo<br />
bind B source-file ~/.tmux/bar<br />
<br />
==Scrolling issues==<br />
If you have issues scrolling with Shift-PageUp/Shift-PageDown in your terminal, try this:<br />
<br />
set -g terminal-overrides 'xterm*:smcup@:rmcup@'<br />
<br />
==ICCCM Selection Integration==<br />
It is possible to copy a tmux paste buffer to an ICCCM selection, and vice-versa, by defining a shell command which interfaces tmux with an X11 selection interface. The following tmux config file snippet effectively integrates {{Ic|CLIPBOARD}} with the current tmux paste buffer using xclip:<br />
<br />
{{hc|~/.tmux.conf|<br />
...<br />
##CLIPBOARD selection integration<br />
##Requires prefix key before the command key<br />
#Copy tmux paste buffer to CLIPBOARD<br />
bind C-c run "tmux show-buffer <nowiki>|</nowiki> xclip -i -selection clipboard"<br />
#Copy CLIPBOARD to tmux paste buffer and paste tmux paste buffer<br />
bind C-v run "tmux set-buffer -- \"$(xclip -o -selection clipboard)\"; tmux paste-buffer"<br />
}}<br />
<br />
If you get an output similar to {{ic| \346\227\245\346\234\254\350\252\236\343\201\247 }} when pasting utf-8 characters, try changing this line:<br />
{{bc|bind C-c run "tmux show-buffer <nowiki>|</nowiki> xclip -i -selection clipboard"}}<br />
to this:<br />
{{bc|bind C-p run "tmux save-buffer - <nowiki>|</nowiki> xclip -i -selection clipboard"}}<br />
<br />
==Tips & Tricks==<br />
<br />
===Start tmux on every shell login===<br />
<br />
Simply add the following line of bash code to your .bashrc before your aliases; the code for other shells is very similar:<br />
<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
Example .bashrc:<br />
#<br />
# ~/.bashrc<br />
#<br />
<br />
# If not running interactively, do not do anything<br />
&#91;&#91; $- != *i* &#93;&#93; && return<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
# Irrelevant from here on, but does show that things here are working from within tmux..<br />
alias svile="sudo vile"<br />
alias updatedb="sudo updatedb"<br />
alias sprunge="curl -F 'sprunge=<-' http://sprunge.us"<br />
pacman() {<br />
case $1 in<br />
-S | -S[^sih]* | -R* | -U*)<br />
/usr/bin/sudo /usr/bin/pacman-color "$@" ;;<br />
*) /usr/bin/pacman-color "$@" ;;<br />
esac<br />
}<br />
<br />
{{note|At first you may read screen as if we were using screen and not tmux, but tmux also uses screen for the TERM enviroment variable.}}<br />
<br />
This snippet does the same thing, but also checks tmux is installed before trying to launch it. It also tries to reattach you to an existing tmux session at logout, so that you can shut down every tmux session quickly from the same terminal at logout.<br />
# TMUX<br />
if which tmux 2>&1 >/dev/null; then<br />
# if no session is started, start a new session<br />
if test -z ${TMUX}; then<br />
tmux<br />
fi<br />
# when quitting tmux, try to attach<br />
while test -z ${TMUX}; do<br />
tmux attach || break<br />
done<br />
fi<br />
<br />
{{note|Instead of using the bashrc file, you can launch tmux when you start your terminal emulator. (i. e. urxvt -e tmux)}}<br />
<br />
===Split window and retain current directory===<br />
<br />
{{Note|1=With [http://tmux.svn.sourceforge.net/viewvc/tmux?view=revision&revision=2647 revision 2647] this behavior became standard.}}<br />
<br />
====Fast method====<br />
<br />
{{Note|If you have set default-path to something for another convince; it will be reset to ~/}}<br />
<br />
This command simply sets the default-path to your current path, splits the window, and resets it to your home directory. Can be easily bound to a key if you wish.<br />
<br />
tmux set default-path $(pwd) \; split-window\; set default-path ~/<br />
<br />
====cd method====<br />
<br />
{{Note|This trick tries to inject a key into your session, which only works if it is at a command prompt (i. e. fails within a program like vim, emacs, …).}}<br />
<br />
Create a excutable file as follows, for example {{ic|~/.scripts/tmux-split}}:<br />
<br />
#!/usr/bin/env bash<br />
PWD=`pwd`<br />
tmux split-window $1<br />
tmux send-keys " cd $PWD;clear"<br />
tmux send-keys "Enter"<br />
<br />
and change the configure from:<br />
<br />
bind v split-window -h<br />
bind n split-window -v<br />
<br />
to<br />
<br />
bind v send-keys " ~/mbin/split-tmux -h" \; send-keys "Enter"<br />
bind n send-keys " ~/mbin/split-tmux -v" \; send-keys "Enter"<br />
<br />
====/proc method====<br />
<br />
{{Note|This script, [http://chneukirchen.org/dotfiles/bin/tmux-neww-in-cwd borrowed from] Christian Neukirchen, reads the present pane's CWD from {{Ic|/proc/[pane's top program's $PID]/cwd}}. Some shells like zsh will not always properly update that entry.}}<br />
<br />
Pasted into e. g. {{ic|~/.scripts/tmux-split-in-cwd}}:<br />
<br />
#!/bin/sh<br />
# tmux-split-in-cwd - open a new shell with same cwd as calling pane<br />
<br />
SIP=$(tmux display-message -p "#S:#I:#P")<br />
PTY=$(tmux server-info |<br />
egrep flags=\|bytes |<br />
awk '/windows/ { s = $2 }<br />
/references/ { i = $1 }<br />
/bytes/ { print s i $1 $2 } ' |<br />
grep "$SIP" |<br />
cut -d: -f4)<br />
PTS=${PTY#/dev/}<br />
PID=$(ps -eao pid,tty,command --forest | awk '$2 == "'$PTS'" {print $1; exit}')<br />
DIR=$(readlink /proc/$PID/cwd)<br />
<br />
case "$1" in<br />
h) tmux splitw -h "cd '$DIR'; $SHELL"<br />
;;<br />
v) tmux splitw -v "cd '$DIR'; $SHELL"<br />
;;<br />
*) tmux neww "cd '$DIR'; $SHELL"<br />
;;<br />
esac<br />
<br />
{{ic|~/.tmux.conf}} could thus contain:<br />
<br />
bind | run '~/.scripts/tmux-split-in-cwd h' # horizontal split in cwd<br />
bind _ run '~/.scripts/tmux-split-in-cwd v' # vertical split in cwd<br />
bind m run '~/.scripts/tmux-split-in-cwd' # new window in cwd<br />
<br />
===Use tmux windows like tabs===<br />
<br />
The following settings added to {{ic|~/.tmux.conf}} allow to use tmux windows like tabs, such as those provided by the reference of these hotkeys — [[rxvt-unicode#urxvtq_with_tabbing|urxvt's tabbing extensions]]. An advantage thereof is that these virtual “tabs” are independent of the terminal emulator.<br />
<br />
#urxvt tab like window switching (-n: no prior escape seq)<br />
bind -n S-down new-window<br />
bind -n S-left prev<br />
bind -n S-right next<br />
bind -n C-left swap-window -t -1<br />
bind -n C-right swap-window -t +1<br />
<br />
Of course, those should not overlap with other applications' hotkeys, such as the terminal's. Given that they substitute terminal tabbing that might as well be deactivated, though.<br />
<br />
It can also come handy to supplement the EOT hotkey {{Keypress|Ctrl}}+{{Keypress|d}} with one for tmux's detach:<br />
<br />
bind-key -n C-j detach<br />
<br />
===Clients simultaneously interacting with various windows of a session===<br />
<br />
In “[http://mutelight.org/articles/practical-tmux Practical Tmux]”, Brandur Leach writes:<br />
<br />
{{Box||Screen and tmux's behaviour for when multiple clients are attached to one session differs slightly. In Screen, each client can be connected to the session but view different windows within it, but in tmux, all clients connected to one session must view the same window.<br />
<br />
This problem can be solved in tmux by spawning two separate sessions and synchronizing the second one to the windows of the first, then pointing a second new session to the first.<br />
<br />
However, this usage of tmux results in the problem that detaching from these mirrored sessions will start to litter your system with defunct sessions which can only be cleaned up with some pretty extreme micromanagement.}}<br />
<br />
{{Note|Since tmux 1.4 mirrored sessions may be set to auto-destroy with the {{Ic|destroy-unattached}} session option}}<br />
<br />
To avoid these issues he wrote the script “{{Ic|tmx}}” — the version below is slightly modified to execute “{{Ic|tmux new-window}}” if “1” is its second parameter. Invoked as {{Ic|tmx <base session name> [1]}} it launches the base session if necessary. Otherwise it will kill any “zombie” sessions, launch a new “client” session linked to the base, optionally add a new window and attach. Then it waits for detachment and kills its session.<br />
<br />
{{hc|tmx|2=<nowiki><br />
#!/bin/bash<br />
<br />
#<br />
# Modified TMUX start script from:<br />
# http://forums.gentoo.org/viewtopic-t-836006-start-0.html<br />
#<br />
# Store it to `~/bin/tmx` and issue `chmod +x`.<br />
#<br />
<br />
# Works because bash automatically trims by assigning to variables and by <br />
# passing arguments<br />
trim() { echo $1; }<br />
<br />
if [[ -z "$1" ]]; then<br />
echo "Specify session name as the first argument"<br />
exit<br />
fi<br />
<br />
# Only because I often issue `ls` to this script by accident<br />
if [[ "$1" == "ls" ]]; then<br />
tmux ls<br />
exit<br />
fi<br />
<br />
base_session="$1"<br />
# This actually works without the trim() on all systems except OSX<br />
tmux_nb=$(trim `tmux ls | grep "^$base_session" | wc -l`)<br />
if [[ "$tmux_nb" == "0" ]]; then<br />
echo "Launching tmux base session $base_session ..."<br />
tmux new-session -s $base_session<br />
else<br />
# Make sure we are not already in a tmux session<br />
if [[ -z "$TMUX" ]]; then<br />
# Kill defunct sessions first<br />
old_sessions=$(tmux ls 2>/dev/null | egrep "^[0-9]{14}.*[0-9]+\)$" | cut -f 1 -d:)<br />
for old_session_id in $old_sessions; do<br />
tmux kill-session -t $old_session_id<br />
done<br />
<br />
echo "Launching copy of base session $base_session ..."<br />
# Session is is date and time to prevent conflict<br />
session_id=`date +%Y%m%d%H%M%S`<br />
# Create a new session (without attaching it) and link to base session <br />
# to share windows<br />
tmux new-session -d -t $base_session -s $session_id<br />
if [[ "$2" == "1" ]]; then<br />
# Create a new window in that session<br />
tmux new-window<br />
fi<br />
# Attach to the new session<br />
tmux attach-session -t $session_id<br />
# When we detach from it, kill the session<br />
tmux kill-session -t $session_id<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
A useful setting for this is<br />
<br />
setw -g aggressive-resize on<br />
<br />
added to {{ic|~/.tmux.conf}}. It causes tmux to resize a window based on the smallest client actually viewing it, not on the smallest one attached to the entire session.<br />
<br />
===Changing the configuration with tmux started===<br />
<br />
By default tmux reads {{ic|~/.tmux.conf}} only if it was not already running. To have tmux load a configuration file afterwards, execute:<br />
<br />
tmux source-file <path><br />
<br />
This can be added to {{ic|~/.tmux.conf}} as e. g.:<br />
<br />
bind r source-file <path><br />
<br />
===Template script to run program in new session resp. attach to existing one===<br />
<br />
This script checks for a program presumed to have been started by a previous run of itself. Unless found it creates a new tmux session and attaches to a window named after and running the program. If however the program was found it merely attaches to the session and selects the window.<br />
<br />
#!/bin/bash<br />
<br />
PID=$(pidof $1)<br />
<br />
if [ -z "$PID" ]; then<br />
tmux new-session -d -s main ;<br />
tmux new-window -t main -n $1 "$*" ;<br />
fi<br />
tmux attach-session -d -t main ;<br />
tmux select-window -t $1 ;<br />
exit 0<br />
<br />
A derived version to run ''irssi'' with the ''nicklist'' plugin can be found on [[Irssi#irssi_with_nicklist_in_tmux|its ArchWiki page]].<br />
<br />
== See also ==<br />
* [http://mutelight.org/articles/practical-tmux Practical Tmux] by Brandur Leach, providing a number of configuration tips<br />
* [http://www.openbsd.org/faq/faq7.html#tmux Tmux tutorial] section from the OpenBSD FAQ<br />
* [http://www.dayid.org/os/notes/tm.html Screen and tmux feature comparison] page by Dayid Alan<br />
* [http://blog.hawkhost.com/2010/06/28/tmux-the-terminal-multiplexer/ Tmux tutorial Part 1] & [http://blog.hawkhost.com/2010/07/02/tmux-%E2%80%93-the-terminal-multiplexer-part-2 Part 2] blog posts on Hawk Host<br />
<br />
'''Forum threads'''<br />
* 2009-11-06 - Arch Linux - [https://bbs.archlinux.org/viewtopic.php?id=84157&p=1 Anyone loving Tmux in place of Screen? Info/Tips etc. URLs I've found]</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Daemons&diff=181745Daemons2012-02-03T01:20:20Z<p>Rnabioullin: /* List of Daemons */ Added soundmodem</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:Daemons and system services (English)]]<br />
{{i18n|Daemon}}<br />
[[de:Daemons]]<br />
[[ro:Daemon]]<br />
<br />
A [[Wikipedia:Daemon (computing)|daemon]] is a program that runs in the background, waiting for events to occur and offering services. A good example is a web server that waits for a request to deliver a page or a ssh server waiting for someone trying to log in. While these are full featured applications, there are daemons whose work is not that visible. Daemons are for tasks like writing messages into a log file (e.g. syslog, metalog) or keeping your system time accurate (e.g. [[Network Time Protocol daemon|ntpd]]).<br />
<br />
{{Note|The word daemon is sometimes used for a class of programs that are started at boot but have no process which remains in memory. They are called daemons simply because they utilize the same startup/shutdown framework (e.g. {{ic|/etc/rc.d/}} scripts) used to start traditional daemons. For example, the {{ic|/etc/rc.d}} scripts for ''alsa'' and ''cpufreq'' provide persistent configuration support for their perspective kernel modules but do not start additional background processes to service requests or respond to events.<br />
<br />
From the user's perspective the distinction is typically not significant unless the user tries to look for the "daemon" in a process list.<br />
}}<br />
<br />
==Starting on Boot==<br />
A default install of Arch Linux will leave you with very few services (or daemons) enabled during boot. You can add or remove services by editing the {{ic|DAEMONS}} array in your [[rc.conf]] file. It will initially look something like this:<br />
DAEMONS=(syslog-ng network netfs crond)<br />
<br />
They will start in the order you have them listed. You can disable one and keep it in the array by prefixing it with an exclamation mark ({{ic|!}}). You can also have them start in the background by adding the {{ic|@}} symbol in front of it.<br />
<br />
Daemon scripts are stored in {{ic|/etc/rc.d/}}. You can print the list of all the available daemons on your system, along with their current status, with:<br />
$ rc.d list<br />
<br />
==Performing daemon actions manually==<br />
Every daemon has a series of actions that can be called with specific commands: usually there are at least {{ic|start}}, {{ic|stop}}, and {{ic|restart}}. You can issue each with:<br />
# /etc/rc.d/''daemon-name'' {start|stop|restart|...}<br />
A completely equivalent way is:<br />
# rc.d {start|stop|restart|...} ''daemon-name-1'' ''daemon-name-2'' ''daemon-name-3'' ...<br />
which, as it is clear from the example, works also with a list of daemons, calling for each the given action.<br />
<br />
For a list of all the available commands for a specific daemon, check its documentation, or just open the script in a text viewer.<br />
<br />
==Essentials==<br />
You do not have to add any more services, if you do not feel the need. However, a typical desktop user will add at least [[CUPS]] and [[dbus]]. As you install new services, you will have to manually add them to the {{ic|DAEMONS}} array in {{ic|/etc/rc.conf}}. (The {{ic|DAEMONS}} array is at the end of the default {{ic|rc.conf}} file.)<br />
<br />
==Starting Daemons in Background==<br />
This is helpful for starting a service and letting the next service start before the previous one has finished. Which services to start background depends on your needs. Do not background anything you need immediately. Here is an example:<br />
DAEMONS=(syslog-ng gensplash dbus network netfs @avahi-daemon @samba @crond @openntpd @cupsd @mpd)<br />
<br />
Starting {{ic|openntpd}} in the background could lead to synchronization errors between the actual time and the time stored on your computer. If you recognize an increasing time difference between your desktop clock and the actual time, try to start the {{ic|openntpd}} daemon normally and not in the background.<br />
<br />
==Rc.conf GUI Frontends==<br />
[[Rc.conf GUI Frontends]] allow you to easily change settings in {{ic|/etc/rc.conf}} using graphical application.<br />
<br />
==List of Daemons==<br />
Here is a list of daemons. Note that any package can provide a daemon, so this list will never be complete. Please feel free to add any missing daemons here, in alphabetical order.<br />
{| border="1"<br />
!Daemon!!Description<br />
|-<br />
|[[Acpid|acpid]]||Delivers ACPI events.<br />
|-<br />
|[[Advanced Linux Sound Architecture|alsa]]||Advanced Linux Sound Architecture; provides device drivers for sound cards.<br />
|-<br />
|atd||Run jobs queued for later execution.<br />
|-<br />
|[[Avahi|avahi-daemon]]||Allows programs to automatically find local network services.<br />
|-<br />
|[[Avahi|avahi-dnsconfd]]||<br />
|-<br />
|crond||Daemon to schedule and time events. The daemon name ''crond'' is used by at least two packages, {{Pkg|cronie}} and {{Pkg|dcron}}. See [[Cron]] for more information.<br />
|-<br />
|[[CUPS|cupsd]]||Common UNIX Printing System daemon.<br />
|-<br />
|[[D-Bus|dbus]]||Message bus system for software communication.<br />
|-<br />
|[[FAM|fam]]||File Alteration Monitor. (deprecated)<br />
|-<br />
|[[Fbsplash|fbsplash]]||Graphical boot splash screen for the user.<br />
|-<br />
|[[GDM|gdm]]||Gnome Display Manager (Login Screen)<br />
|-<br />
|[[Console Mouse Support|gpm]]||Console mouse support.<br />
|-<br />
|[[Fbsplash|gensplash]]||(see fbsplash)<br />
|-<br />
|[[HAL|hal]]||Hardware Abstraction Layer. (Deprecated)<br />
|-<br />
|[[LAMP|httpd]]||Apache HTTP Server (Web Server)<br />
|-<br />
|[[hwclock]]||Not a daemon as such, but on shutdown, updates hwclock to compensate for drift. Only run this daemon if ntpd is not running as both daemons adjust the hardware clock.<br />
|-<br />
|[[MDADM|mdadm]]||MD Administration (Linux Software RAID).<br />
|-<br />
|[[Music Player Daemon|mpd]]||Music Player Daemon.<br />
|-<br />
|[[MySQL|mysqld]]||MySQL database server.<br />
|-<br />
|netfs||Mounts network file systems.<br />
|-<br />
|[[Configuring_Network|network]]||To bring up the network connections.<br />
|-<br />
|[[NetworkManager|networkmanager]]||Replace network, and provide configuration and detection for automatic network connections.<br />
|-<br />
|nsyslogd||<br />
|-<br />
|[[Network Time Protocol daemon|ntpd]]||Network Time Protocol daemon (client and server).<br />
|-<br />
|[[OpenNTPD|openntpd]]||alternate Network Time Protocol daemon (client and server).<br />
|-<br />
|[[Pure-FTPD|pure-ftpd]]||FTP server.<br />
|-<br />
|[[Powernowd|powernowd]]||To adjust speed of CPU depending on system load. See also [[CPU_Frequency_Scaling]]<br />
|-<br />
|[[Rsyslog|rsyslogd]]||The latest version of a system logger.<br />
|-<br />
|[[SLiM|slim]]||Simple Login Manager<br />
|-<br />
|[[Samba|samba]]||File and print services for Microsoft Windows clients.<br />
|-<br />
|soundmodem||Multiplatform Soundcard Packet Radio Modem<br />
|-<br />
|[[USB_Scanner_Support|saned]]||To share the scanner system over network.<br />
|-<br />
|[[Lm_sensors|sensors]]||Hardware (temperature, fans etc) monitoring.<br />
|-<br />
|[[SMART|smartd]]||Self-Monitoring, Analysis, and Reporting Technology (S.M.A.R.T) Hard Disk Monitoring<br />
|-<br />
|[[Secure Shell|sshd]]||OpenSSH (secure shell) daemon.<br />
|-<br />
|stbd ||This daemon was previously necessary for gnome-system-tools. However, as of gnome-tools 2.28, it is no longer needed.<br />
|-<br />
|syslogd||This was the older and basic system logger.<br />
|-<br />
|[[Syslog-ng|syslog-ng]]||System logger next generation.<br />
|-<br />
|[[Timidity|timidity++]]||Software synthesizer for MIDI.<br />
|-<br />
|[[VirtualBox|vboxdrv]]||Necessary to run VirtualBox.<br />
|-<br />
|[[Very Secure FTP Daemon|vsftpd]]||FTP server.<br />
|-<br />
|[[Wicd|wicd]]||Combine with dbus to replace network, a lightweight alternative to NetworkManager.<br />
|-<br />
|}<br />
<br />
==See also==<br />
Examples for [[writing rc.d scripts]]</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Ham_Radio&diff=181694Ham Radio2012-02-02T16:48:07Z<p>Rnabioullin: created redirect page</p>
<hr />
<div>#REDIRECT [[Amateur_Radio]]</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Owx&diff=179518Owx2012-01-22T02:02:50Z<p>Rnabioullin: /* Tips and Tricks */ Added MURS freqs</p>
<hr />
<div>[[Category:Telephony and Voice (English)]]<br />
{{i18n|Owx}}<br />
{{Stub}}<br />
<br />
[http://owx.chmurka.net owx] (open wouxun) is a CLI utility used to program KG669V radios by means of a CSV spreadsheet.<br />
<br />
== Installation ==<br />
[http://aur.archlinux.org/packages.php?ID=42448 owx] is available in the [[AUR]].<br />
<br />
== Tips and Tricks ==<br />
Frequency lists; replace {{ic|CH}} with the desired channel number.<br />
<br />
U.S. [http://en.wikipedia.org/wiki/NOAA_Weather_Radio NOAA Weather Radio]:<br />
{{bc|"CH","NWR1","162.40000","162.40000","","","narrow","high","no","no"<br />
"CH","NWR2","162.42500","162.42500","","","narrow","high","no","no"<br />
"CH","NWR3","162.45000","162.45000","","","narrow","high","no","no"<br />
"CH","NWR4","162.47500","162.47500","","","narrow","high","no","no"<br />
"CH","NWR5","162.50000","162.50000","","","narrow","high","no","no"<br />
"CH","NWR6","162.52500","162.52500","","","narrow","high","no","no"<br />
"CH","NWR7","162.55000","162.55000","","","narrow","high","no","no"}}<br />
<br />
U.S. [http://en.wikipedia.org/wiki/Family_Radio_Service Family Radio Service (FRS)]:<br />
{{bc|"CH","FRS1","462.56250","462.56250","","","narrow","high","yes","no"<br />
"CH","FRS2","462.58750","462.58750","","","narrow","high","yes","no"<br />
"CH","FRS3","462.61250","462.61250","","","narrow","high","yes","no"<br />
"CH","FRS4","462.63750","462.63750","","","narrow","high","yes","no"<br />
"CH","FRS5","462.66250","462.66250","","","narrow","high","yes","no"<br />
"CH","FRS6","462.68750","462.68750","","","narrow","high","yes","no"<br />
"CH","FRS7","462.71250","462.71250","","","narrow","high","yes","no"<br />
"CH","FRS8","467.56250","467.56250","","","narrow","high","yes","no"<br />
"CH","FRS9","467.58750","467.58750","","","narrow","high","yes","no"<br />
"CH","FRS10","467.61250","467.61250","","","narrow","high","yes","no"<br />
"CH","FRS11","467.63750","467.63750","","","narrow","high","yes","no"<br />
"CH","FRS12","467.66250","467.66250","","","narrow","high","yes","no"<br />
"CH","FRS13","467.68750","467.68750","","","narrow","high","yes","no"<br />
"CH","FRS14","467.71250","467.71250","","","narrow","high","yes","no"}}<br />
<br />
U.S. [http://en.wikipedia.org/wiki/GMRS General Mobile Radio Service (GMRS)], exclusive of interstitial frequencies shared by FRS, and using simplex operation:<br />
{{bc|"CH","GMRS1","462.55000","462.55000","","","narrow","high","yes","no"<br />
"CH","GMRS2","462.57500","462.57500","","","narrow","high","yes","no"<br />
"CH","GMRS3","462.60000","462.60000","","","narrow","high","yes","no"<br />
"CH","GMRS4","462.62500","462.62500","","","narrow","high","yes","no"<br />
"CH","GMRS5","462.65000","462.65000","","","narrow","high","yes","no"<br />
"CH","GMRS6","462.67500","462.67500","","","narrow","high","yes","no"<br />
"CH","GMRS7","462.70000","462.70000","","","narrow","high","yes","no"<br />
"CH","GMRS8","462.72500","462.72500","","","narrow","high","yes","no"}}<br />
<br />
U.S. [http://en.wikipedia.org/wiki/Multi-Use_Radio_Service Multi-Use Radio Service (MURS)]:<br />
{{bc|"CH","MURS1","151.82000","151.82000","","","narrow","high","yes","no"<br />
"CH","MURS2","151.88000","151.88000","","","narrow","high","yes","no"<br />
"CH","MURS3","151.94000","151.94000","","","narrow","high","yes","no"<br />
"CH","MURS4","154.57000","154.57000","","","narrow","high","yes","no"<br />
"CH","MURS5","154.60000","154.60000","","","narrow","high","yes","no"}}</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Owx&diff=179233Owx2012-01-20T00:16:42Z<p>Rnabioullin: /* Tips and Tricks */ Added GMRS freqs</p>
<hr />
<div>[[Category:Telephony and Voice (English)]]<br />
{{i18n|Owx}}<br />
{{Stub}}<br />
<br />
[http://owx.chmurka.net owx] (open wouxun) is a CLI utility used to program KG669V radios by means of a CSV spreadsheet.<br />
<br />
== Installation ==<br />
[http://aur.archlinux.org/packages.php?ID=42448 owx] is available in the [[AUR]].<br />
<br />
== Tips and Tricks ==<br />
Frequency lists; replace {{ic|CH}} with the desired channel number.<br />
<br />
U.S. [http://en.wikipedia.org/wiki/NOAA_Weather_Radio NOAA Weather Radio]:<br />
{{bc|"CH","NWR1","162.40000","162.40000","","","narrow","high","no","no"<br />
"CH","NWR2","162.42500","162.42500","","","narrow","high","no","no"<br />
"CH","NWR3","162.45000","162.45000","","","narrow","high","no","no"<br />
"CH","NWR4","162.47500","162.47500","","","narrow","high","no","no"<br />
"CH","NWR5","162.50000","162.50000","","","narrow","high","no","no"<br />
"CH","NWR6","162.52500","162.52500","","","narrow","high","no","no"<br />
"CH","NWR7","162.55000","162.55000","","","narrow","high","no","no"}}<br />
<br />
U.S. [http://en.wikipedia.org/wiki/Family_Radio_Service Family Radio Service (FRS)]:<br />
{{bc|"CH","FRS1","462.56250","462.56250","","","narrow","high","yes","no"<br />
"CH","FRS2","462.58750","462.58750","","","narrow","high","yes","no"<br />
"CH","FRS3","462.61250","462.61250","","","narrow","high","yes","no"<br />
"CH","FRS4","462.63750","462.63750","","","narrow","high","yes","no"<br />
"CH","FRS5","462.66250","462.66250","","","narrow","high","yes","no"<br />
"CH","FRS6","462.68750","462.68750","","","narrow","high","yes","no"<br />
"CH","FRS7","462.71250","462.71250","","","narrow","high","yes","no"<br />
"CH","FRS8","467.56250","467.56250","","","narrow","high","yes","no"<br />
"CH","FRS9","467.58750","467.58750","","","narrow","high","yes","no"<br />
"CH","FRS10","467.61250","467.61250","","","narrow","high","yes","no"<br />
"CH","FRS11","467.63750","467.63750","","","narrow","high","yes","no"<br />
"CH","FRS12","467.66250","467.66250","","","narrow","high","yes","no"<br />
"CH","FRS13","467.68750","467.68750","","","narrow","high","yes","no"<br />
"CH","FRS14","467.71250","467.71250","","","narrow","high","yes","no"}}<br />
<br />
U.S. [http://en.wikipedia.org/wiki/GMRS General Mobile Radio Service (GMRS)], exclusive of interstitial frequencies shared by FRS, and using simplex operation:<br />
{{bc|"CH","GMRS1","462.55000","462.55000","","","narrow","high","yes","no"<br />
"CH","GMRS2","462.57500","462.57500","","","narrow","high","yes","no"<br />
"CH","GMRS3","462.60000","462.60000","","","narrow","high","yes","no"<br />
"CH","GMRS4","462.62500","462.62500","","","narrow","high","yes","no"<br />
"CH","GMRS5","462.65000","462.65000","","","narrow","high","yes","no"<br />
"CH","GMRS6","462.67500","462.67500","","","narrow","high","yes","no"<br />
"CH","GMRS7","462.70000","462.70000","","","narrow","high","yes","no"<br />
"CH","GMRS8","462.72500","462.72500","","","narrow","high","yes","no"}}</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Owx&diff=179232Owx2012-01-19T23:54:43Z<p>Rnabioullin: /* Tips and Tricks */ Added FRS freqs</p>
<hr />
<div>[[Category:Telephony and Voice (English)]]<br />
{{i18n|Owx}}<br />
{{Stub}}<br />
<br />
[http://owx.chmurka.net owx] (open wouxun) is a CLI utility used to program KG669V radios by means of a CSV spreadsheet.<br />
<br />
== Installation ==<br />
[http://aur.archlinux.org/packages.php?ID=42448 owx] is available in the [[AUR]].<br />
<br />
== Tips and Tricks ==<br />
Frequency lists; replace {{ic|CH}} with the desired channel number.<br />
<br />
U.S. [http://en.wikipedia.org/wiki/NOAA_Weather_Radio NOAA Weather Radio]:<br />
{{bc|"CH","NWR1","162.40000","162.40000","","","narrow","high","no","no"<br />
"CH","NWR2","162.42500","162.42500","","","narrow","high","no","no"<br />
"CH","NWR3","162.45000","162.45000","","","narrow","high","no","no"<br />
"CH","NWR4","162.47500","162.47500","","","narrow","high","no","no"<br />
"CH","NWR5","162.50000","162.50000","","","narrow","high","no","no"<br />
"CH","NWR6","162.52500","162.52500","","","narrow","high","no","no"<br />
"CH","NWR7","162.55000","162.55000","","","narrow","high","no","no"}}<br />
<br />
U.S. [http://en.wikipedia.org/wiki/Family_Radio_Service Family Radio Service (FRS)]:<br />
{{bc|"CH","FRS1","462.56250","462.56250","","","narrow","high","yes","no"<br />
"CH","FRS2","462.58750","462.58750","","","narrow","high","yes","no"<br />
"CH","FRS3","462.61250","462.61250","","","narrow","high","yes","no"<br />
"CH","FRS4","462.63750","462.63750","","","narrow","high","yes","no"<br />
"CH","FRS5","462.66250","462.66250","","","narrow","high","yes","no"<br />
"CH","FRS6","462.68750","462.68750","","","narrow","high","yes","no"<br />
"CH","FRS7","462.71250","462.71250","","","narrow","high","yes","no"<br />
"CH","FRS8","467.56250","467.56250","","","narrow","high","yes","no"<br />
"CH","FRS9","467.58750","467.58750","","","narrow","high","yes","no"<br />
"CH","FRS10","467.61250","467.61250","","","narrow","high","yes","no"<br />
"CH","FRS11","467.63750","467.63750","","","narrow","high","yes","no"<br />
"CH","FRS12","467.66250","467.66250","","","narrow","high","yes","no"<br />
"CH","FRS13","467.68750","467.68750","","","narrow","high","yes","no"<br />
"CH","FRS14","467.71250","467.71250","","","narrow","high","yes","no"}}</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Tor&diff=179225Tor2012-01-19T21:23:41Z<p>Rnabioullin: Added pacman as Tor application</p>
<hr />
<div>[[Category:Internet Applications (English)]]<br />
[[Category:Proxy servers (English)]]<br />
[[Category:Daemons and system services (English)]]<br />
{{i18n|Tor}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|This article will explain how to install and configure Tor alongside HTTP proxies like Privoxy and Polipo.}}<br />
{{Article summary heading|Required software}}<br />
{{Article summary link|Tor|https://www.torproject.org/download/download.html.en}}<br />
{{Article summary link|Privoxy|http://www.privoxy.org/}}<br />
{{Article summary link|Polipo|http://www.pps.jussieu.fr/~jch/software/polipo/}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Privoxy}}<br />
{{Article summary wiki|Polipo}}<br />
{{Article summary end}}<br />
<br />
'''Tor''' is an open source implementation of 2nd generation [[Wikipedia:Onion routing|onion routing]] that provides free access to an anonymous proxy network. Its primary goal is to enable [[Wikipedia:internet anonymity|online anonymity]] by protecting against [[Wikipedia:Traffic analysis|traffic analysis]] attacks.<br />
<br />
==Introduction==<br />
{{Wikipedia|Tor (anonymity network)}}<br />
Users of the Tor network run an onion proxy on their machine. This software connects out to Tor, periodically negotiating a virtual circuit through the Tor network. Tor employs cryptography in a layered manner (hence the 'onion' analogy), ensuring perfect forward secrecy between routers. At the same time, the onion proxy software presents a SOCKS interface to its clients. SOCKS-aware applications may be pointed at Tor, which then multiplexes the traffic through a Tor virtual circuit.<br />
<br />
{{Warning|Tor by itself is ''not'' all you need to maintain your anonymity. There are several major pitfalls to watch out for (see: [https://www.torproject.org/download/download.html.en#warning Want Tor to really work?]).}}<br />
<br />
Through this process the onion proxy manages networking traffic for end-user anonymity. It keeps a user anonymous by encrypting traffic, sending it through other nodes of the Tor network, and decrypting it at the last node to receive your traffic before forwarding it to the server you specified. Although Tor is considerably safer than the commonly used direct DNS connections (i.e. without a proxy), it can be considerably slower due to the large amount of traffic re-routing. Additionally, although Tor provides protection against traffic analysis it cannot prevent traffic confirmation at the boundaries of the Tor network (i.e. the traffic entering and exiting the network).<br />
<br />
==Installation==<br />
Install the Tor package located in {{Ic|[community]}} using [[Pacman]].<br />
# pacman -S tor<br />
<br />
==Configuration==<br />
To get a better understanding of Tor review the {{ic|/etc/tor/torrc}} configuration file. The configuration options are explained in {{Ic|man tor}} and the [https://www.torproject.org/docs/tor-manual.html.en Tor website]. <br />
<br />
The default configuration should work fine for most Tor users, with the one notable exception being those using Vidalia, a Qt GUI frontend for Tor. There is a [https://aur.archlinux.org/packages.php?ID=9731 Vidalia package] available in the [[AUR]]. In addition to controlling the process Vidalia allows you to view the status of Tor; monitor bandwidth usage; view, filter, and search log messages; and configure some aspects of Tor.<br />
<br />
You can set custom file descriptor ulimits for Tor in {{ic|/etc/conf.d/tor}} using the {{Ic|TOR_MAX_FD}} variable.<br />
<br />
===Logging===<br />
By default Tor logs to "stdout" at log-level notice. If you enable logs in your {{ic|torrc}} file, they default to {{Ic|/usr/local/var/log/tor/}}.<br />
<br />
==Usage==<br />
To start Tor issue the following command as root to start the Tor service:<br />
# /etc/rc.d/tor start<br />
<br />
To start Tor at boot add {{Ic|tor}} to the {{Ic|DAEMONS}} array in {{ic|/etc/rc.conf}}:<br />
DAEMONS=(... '''tor''' ...)<br />
<br />
To check if TOR is functioning properly visit the [https://check.torproject.org/ Tor], [http://serifos.eecs.harvard.edu/cgi-bin/ipaddr.pl?tor=1 Harvard] or [https://torcheck.xenobite.eu/ Xenobite.eu] websites.<br />
<br />
==Web browsing==<br />
Tor is supported primarily by Firefox, but can also be used with Chromium.<br />
<br />
===Firefox===<br />
<br />
You can simply point Firefox manually to use the SOCKS proxy "localhost" port "9050" in the preferences>Advanced>Network tab>Settings.<br />
<br />
You can also install this plug-in: [https://www.torproject.org/torbutton/ TorButton].<br />
This will allow you to toggle very easily between tor navigation and normal navigation instead of changing the preferences.<br />
<br />
Optionally, if you're using multiple Proxies (for example if you want to use both TOR and "ssh -D") then there's also an addon called "[https://addons.mozilla.org/en-us/firefox/addon/foxyproxy-standard/ FoxyProxy]" for Firefox which allows you to specify multiple Proxies for different URLs or for all your browsing. Just point it to port 8118 (where polipo is running) on localhost.<br />
To test it, point your browser to [https://check.torproject.org/ this website] with and without tor enabled.<br />
<br />
Please read [https://www.torproject.org/docs/tor-doc-unix.html.en the official doc] for more infos.<br />
<br />
===Chromium===<br />
You can simply run:<br />
$ chromium --proxy-server="socks://localhost:9050"<br />
<br />
==Irssi with Tor==<br />
Freenode does not recommend that you use Privoxy with [[Irssi]]. Instead they recommend using the {{Ic|mapaddress}} approach and running {{Ic|torify irssi}} to start it up. Therefore, add the following to {{ic|/etc/tor/torrc}}:<br />
mapaddress 10.40.40.40 p4fsi4ockecnea7l.onion<br />
<br />
Freenode requires charybdis and ircd-seven's SASL mechanism for identifying to nickserv during<br />
connection. Download {{ic|cap_sasl.pl}}, which enables SASL, from the Freenode website (i.e. http://www.freenode.net/sasl/cap_sasl.pl) and save it to {{Ic|~/.irssi/scripts/cap_sasl.pl}}<br />
<br />
Then install the following required perl modules with [[pacman]] and then [http://aur.archlinux.org/packages.php?ID=34386 Crypt::DH] from the [[AUR]].<br />
$ pacman -S perl-crypt-openssl-bignum perl-crypt-blowfish<br />
Alternatively, you can install the modules using perl:<br />
$ perl -MCPAN -e 'install Crypt::OpenSSL::Bignum Crypt::DH Crypt::Blowfish'<br />
<br />
Start irssi <br />
$ torify irssi<br />
<br />
Load the script that will employ the SASL mechanism.<br />
/script load cap_sasl.pl<br />
<br />
Set your identification to nickserv, which will be read when connecting. Supported mechanisms are PLAIN and DH-BLOWFISH. <br />
/sasl set <network> <username> <password> <mechanism><br />
<br />
Connect to Freenode:<br />
/connect -network <network> 10.40.40.40<br />
<br />
For more information check [http://freenode.net/irc_servers.shtml#tor Accessing freenode Via Tor] and the [http://freenode.net/sasl/README.txt SASL README] at freenode.net or the [https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/IrcSilc IRC/SILC Wiki article] at torproject.org.<br />
<br />
===Troubleshooting===<br />
If you are having errors check [https://bbs.archlinux.org/viewtopic.php?pid=956467 this thread].<br />
<br />
==Pacman with Tor==<br />
Pacman download operations (repository DBs, packages, and public keys) can be done using the Tor network. Though relatively extreme, this measure is useful to prevent an adversary (most likely at one's LAN or the mirror) from knowing a subset of the packages you have installed, at the cost of longer latency, lower throughput, possible suspicion, and possible failure (if Tor is being filtered via the current connection).<br />
<br />
{{Warning|It would be arguably simpler for an adversary, specifically one who desires to indiscriminately disseminate malware, to perform his/her activity by deploying malicious Tor exit node(s). Always use signed packages and verify new public keys by out-of-band means.}}<br />
<br />
{{hc|/etc/pacman.conf|<br />
...<br />
<nowiki>XferCommand = /usr/bin/curl --socks5-hostname localhost:9050 -C - -f %u > %o</nowiki><br />
...}}<br />
<br />
==Tor with an HTTP Proxy==<br />
If you need an HTTP proxy.<br />
<br />
{{note|Polipo is now recommended over Privoxy by the Tor dev team. <sup>[Source Needed]</sup>}}<br />
<br />
===Polipo===<br />
Polipo is a small and fast HTTP proxy. Install and configure according to the [[Polipo]] article. The Tor Project has created a custom [https://gitweb.torproject.org/torbrowser.git/blob_plain/HEAD:/build-scripts/config/polipo.conf Polipo configuration file] to prevent potential problems with Polipo as well to provide better anonymity.<br />
<br />
Keep in mind that polipo is not required if you can use a SOCKS 5 proxy, which TOR starts automatically on port 9050. Notably, if you want to use [[Chromium]] to use TOR, you do not need the polipo package. See [[#Chromium and tor|below]] on how to use TOR with [[Chromium]].<br />
<br />
===Privoxy===<br />
Privoxy is an HTTP proxy that speaks SOCKS4a and does html/cookie scrubbing. It can be installed and configured according to the [[Privoxy]] article.<br />
<br />
====Tor and Privoxy in Firefox====<br />
The easiest way to do this is to use the [https://www.torproject.org/torbutton Torbutton] extension.<br />
<br />
Alternatively, you can use [https://addons.mozilla.org/en-US/firefox/addon/foxyproxy-standard Foxyproxy]. After restarting Firefox you will have a new toolbar. Click ''Add'', select ''Standard proxy type''. Choose whatever ''Proxy Label'' you want, e.g ''Tor''. Enter into both the ''HTTP Proxy'' and ''SSL Proxy'' fields:<br />
<br />
Hostname: 127.0.0.1 Port: 8118<br />
<br />
This will point Firefox at Privoxy. You can also add exceptions in the ''No Proxy for'' field.<br />
<br />
Now, return to http://whatsmyip.net/ and check so that your IP is diffrent from before.<br />
<br />
====Tor and Privoxy in other applications====<br />
You can also use this setup in other applications like instant messaging, Jabber, IRC, etc.<br />
<br />
Applications that support HTTP proxies you can point at Privoxy (127.0.0.1 port 8118).<br />
<br />
To use SOCKS proxy directly, you can point your application at Tor (127.0.0.1 port 9050). A problem with this method though is that applications doing DNS resolves by themselves may leak information. Consider using Socks4A (e.g. via privoxy) instead.<br />
<br />
==Running a Tor Server==<br />
===Configuration===<br />
You should at least share 20kb/s:<br />
Nickname <tornickname><br />
ORPort 9001<br />
BandwidthRate 20 KB # Throttle traffic to 20KB/s<br />
BandwidthBurst 50 KB # But allow bursts up to 50KB/s<br />
<br />
Allow irc ports 6660-6667 to exit from node:<br />
ExitPolicy accept *:6660-6667,reject *:* # Allow irc ports but no more<br />
<br />
Run Tor as an exit node:<br />
ExitPolicy accept *:119 # Accept nntp as well as default exit policy<br />
<br />
Run Tor as middleman ( a relay):<br />
ExitPolicy reject *:*<br />
<br />
==TorDNS==<br />
The Tor 0.2.x series provides a built-in DNS forwarder. To enable it add the following lines to the Tor configuration file:<br />
{{hc|/etc/tor/torrc|<br />
DNSPort 9053<br />
AutomapHostsOnResolve 1<br />
AutomapHostsSuffixes .exit,.onion<br />
}}<br />
And restart Tor to load the updated configuration file:<br />
/etc/rc.d/tor restart<br />
<br />
This will allow Tor to accept DNS requests (listening on port 9053 in this example) like a regular DNS server, and resolve the domain via the Tor network. A downside is that it's only able to resolve DNS queries for A-records; MX and NS queries are never answered. For more information see this [https://techstdout.boum.org/TorDns/ Debian-based introduction].<br />
<br />
DNS queries can also be performed through a command line interface by using {{Ic|<nowiki>tor-resolve</nowiki>}}. For example:<br />
{{bc|<br />
$ tor-resolve archlinux.org<br />
66.211.214.131<br />
}}<br />
<br />
==Torify==<br />
<br />
{{Ic|<nowiki>torify</nowiki>}} will allow you use an application via the Tor network without the need to make configuration changes to the application involved. From the man page:<br />
{{bc|<br />
torify is a simple wrapper that calls tsocks with a tor specific configuration<br />
file.<br />
<br />
tsocks itself is a wrapper between the tsocks library and the application that<br />
you would like to run socksified<br />
}}<br />
Usage example:<br />
{{bc|<nowiki><br />
$ torify elinks checkip.dyndns.org<br />
$ torify wget -qO- https://check.torproject.org/ | grep -i congratulations<br />
</nowiki>}}<br />
<br />
Torify ''will not'', however, perform DNS lookups through the Tor network. A workaround is to use it in conjunction with {{Ic|<nowiki>tor-resolve</nowiki>}} (described above). In this case, the procedure for the first of the above examples would look like this:<br />
{{bc|<br />
$ tor-resolve checkip.dyndns.org<br />
208.78.69.70<br />
$ torify elinks 208.78.69.70<br />
}}<br />
<br />
==Troubleshooting==<br />
<br />
===Problem with User value===<br />
<br />
If the ''tor'' daemon failed to start, then run the following command as root (or use sudo)<br />
<br />
# tor<br />
<br />
If you get the following error<br />
<br />
May 23 00:27:24.624 [warn] Error setting groups to gid 43: "Operation not permitted".<br />
May 23 00:27:24.624 [warn] If you set the "User" option, you must start Tor as root.<br />
May 23 00:27:24.624 [warn] Failed to parse/validate config: Problem with User value. See logs for details.<br />
May 23 00:27:24.624 [err] Reading config failed--see warnings above.<br />
<br />
Then it means that the problem is with the User value. So proceed with the following steps.<br />
<br />
Check the permissions of the directory {{ic|/var/lib/tor}} by running<br />
<br />
# ls -l /var/lib/<br />
<br />
If the permission for {{ic|/var/lib/tor}} is as shown below<br />
<br />
drwx------ 2 tor tor 4096 May 12 21:03 tor<br />
<br />
This means that the directory is owned by the user ''tor'' and the group ''tor''.<br />
Change the owner to the user ''root'', and the group ''root'' with the command:<br />
<br />
# chown -R root:root /var/lib/tor<br />
<br />
If you check the permissions again, it should now show<br />
<br />
drwx------ 2 root root 4096 May 12 21:03 tor<br />
<br />
Now open {{ic|/etc/tor/torrc}} and find the following lines<br />
<br />
## Uncomment this to start the process in the background... or use<br />
## --runasdaemon 1 on the command line.<br />
RunAsDaemon 1<br />
User tor<br />
Group tor<br />
<br />
Comment out the lines ''User tor'' and ''Group tor'', so that the lines read as <br />
<br />
## Uncomment this to start the process in the background... or use<br />
## --runasdaemon 1 on the command line.<br />
RunAsDaemon 1<br />
#User tor<br />
#Group tor<br />
<br />
Save the changes and restart the ''tor'' daemon, it should now work.<br />
<br />
# /etc/rc.d/tor restart<br />
<br />
== External Links ==<br />
* [https://www.torproject.org/ Official Website]<br />
* [https://trac.torproject.org/projects/tor/wiki#Unixish Unix-based Tor Articles]<br />
* [https://trac.torproject.org/projects/tor/wiki/doc/SupportPrograms Software commonly integrated with Tor]<br />
* [https://www.torproject.org/docs/tor-hidden-service.html.en How to set up a Tor ''Hidden Service'']</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=VCS_package_guidelines&diff=178916VCS package guidelines2012-01-17T21:46:01Z<p>Rnabioullin: /* Tips */ Grammar, clarification, typo.</p>
<hr />
<div>[[Category:Package development (English)]]<br />
{{i18n|VCS PKGBUILD Guidelines}}<br />
{{Article summary start}}<br />
{{Article summary text|Creating PKGBUILDs for software managed with version control systems.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch Build System}}<br />
{{Article summary wiki|Arch User Repository}}<br />
{{Article summary wiki|Creating Packages}}<br />
{{Article summary wiki|makepkg}}<br />
{{Article summary wiki|pacman}}<br />
{{Article summary wiki|PKGBUILD}}<br />
{{Article summary end}}<br />
<br />
Guidelines for creating PKGBUILDs for software managed with version control systems.<br />
<br />
== Prototypes ==<br />
<br />
The {{Package Official|abs}} package provides prototypes for cvs, svn, git, mercurial, and darcs PKGBUILDs. When abs is installed, you can find them in {{Filename|/usr/share/pacman}}. Or browse the [https://projects.archlinux.org/abs.git/tree/prototypes prototypes] directory in the [[ABS]] Git repository.<br />
<br />
== Guidelines ==<br />
<br />
* Properly suffix {{Ic|pkgname}} with {{Ic|-cvs}}, {{Ic|-svn}}, {{Ic|-hg}}, {{Ic|-darcs}}, {{Ic|-bzr}} or {{Ic|-git}}. If the package tracks a moving development trunk it should be given a suffix. If the package fetches a release from a VCS tag then it should not be given a suffix. Use this rule of thumb: if the output of the package depends on the time at which it was compiled, append a suffix; otherwise do not.<br />
<br />
* A VCS package may be updated as and when needed to adopt changes to the build system, including ammendments to dependencies, URL, sources, etc. If the revision number remains the same after such an update, but produces a resulting binary which is different, increasing the {{Ic|pkgrel}} is mandatory. If both the revision number and the resulting binary remain the same, {{Ic|pkgrel}} should be kept intact. There is no need to update the VCS package just to accommodate a revision bump, but one may choose to do so.<br />
<br />
* When [[makepkg]] is run, by default it will check for newer revisions and then update the {{Ic|pkgver}} in the PKGBUILD. Look at {{Ic|--holdver}} in [http://www.archlinux.org/pacman/makepkg.8.html man makepkg] if you want otherwise. {{Ic|--holdver}} only works for cvs and svn, which allow checkout of older revisions.<br />
<br />
* Check for package conflicts. For example ''fluxbox-svn'' will conflict with ''fluxbox''. In this case, you need to use {{Ic|1=conflicts=('fluxbox')}}.<br />
<br />
* Use the {{Ic|provides}} field so that packages that require the non-VCS package can be installed ({{Ic|1=provides=('fluxbox')}}).<br />
<br />
* You should AVOID using {{Ic|1=replaces=...}} as it generally causes unnecessary problems.<br />
<br />
* When using/defining the cvsroot, use {{Ic|anonymous:@}} rather than {{Ic|anonymous@}} to avoid a password prompt and having to enter a blank password ''OR'' use {{Ic|anonymous:password@}} if a password is required.<br />
<br />
* Don't forget to include the appropriate VCS tool (cvs, subversion, git, ...) in {{Ic|1=makedepends=...}}.<br />
<br />
* To preserve the integrity of the checked-out code consider copying the original build directory if you have to make edits. For example, having checked out source code to {{Filename|src/$_cvsmod}} from {{Filename|$startdir}} you can use:<br />
<br />
mkdir src/$_cvsmod-build<br />
<br />
cd src/$_cvsmod-build<br />
../$_cvsmod/configure<br />
<br />
or:<br />
<br />
cp -r src/$_cvsmod src/$_cvsmod-build<br />
cd src/$_cvsmod-build<br />
<br />
* With the introduction of the [[AUR]], it is most important to avoid using backtick execution to create package variables. makepkg will automatically bump the {{Ic|pkgver}} anyway when building the package (unless {{Ic|--holdver}} is used).<br />
<br />
== Tips ==<br />
<br />
* You should make sure that there are no VCS directories and files left over in your package. If there are, you may want to remove them, by adding a command similar to this one at the end of the the package() script:<br />
<br />
rm -rf $(find "$pkgdir" -type d -name ".svn")<br />
<br />
* When using Git, one can speed up the cloning operation using the {{Ic|1=--depth=1}} parameter. This creates a shallow clone, and has only the last change history - since histories are unimportant for builds most of the time.<br />
<br />
git clone git://hostname.dom/project.git --depth=1<br />
<br />
* It's possible to create the package also from a branch other than the master. To do so add {{Ic|1=--branch branch_name}} after the first {{Ic|1=git clone}}, in this way:<br />
<br />
git clone "$_gitroot" "$_gitname" --branch branch_name<br />
Remember to save package with a different name, for example {{Ic|1= pkgname-branchname-git}}, in order to avoid confusion with the package from the branch master.<br />
<br />
* Copy paste script when building from repo<br />
If you are lazy here is a sample script when making git-based PKGBUILDs.<br />
<br />
cd "$srcdir"<br />
msg "Connecting to GIT server...."<br />
if [ -d $_gitname ] ; then<br />
cd $_gitname && git pull origin<br />
msg "The local files are updated."<br />
else<br />
git clone --depth=1 $_gitroot $_gitname<br />
fi<br />
msg "GIT checkout done or server timeout"<br />
<br />
* Temporary build directories: When using Git, and where you need to create a separate build directory (e.g., for building/compiling), you should avoid copying over the {{Ic|1=.git}} directory located in the parent folder because it contains history information that Git uses internally. With repos with thousands of commits, this .git directory will contain upwards of hundreds of MiB of useless commit history that has *nothing* to do with the current working tree. The only time you'd need to copy over the .git directory itself is when you need to build from a specific, older commit (which is generally never the case as the point of a VCS PKGBUILD is to pull from the latest bleeding edge commit). Thus, instead of<br />
<br />
rm -rf "$srcdir/$_gitname-build"<br />
cp -R "$srcdir/$_gitname" "$srcdir/$_gitname-build" # copy everything, including the useless .git folder<br />
cd "$srcdir/$_gitname-build"<br />
make # build/compile from source<br />
<br />
you should do<br />
<br />
rm -rf "$srcdir/$_gitname-build"<br />
cd "$srcdir/$_gitname" && ls -A | grep -v .git | xargs -d '\n' cp -r -t ../$_gitname-build # do not copy over the .git folder<br />
cd "$srcdir/$_gitname-build"<br />
make # build/compile from source<br />
<br />
to cut down on build time and disk usage.</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=SSH_keys&diff=177099SSH keys2012-01-06T01:21:09Z<p>Rnabioullin: /* Generating an SSH key pair */ Added link to paper; typo</p>
<hr />
<div>[[Category:Secure Shell (English)]]<br />
{{i18n|Using SSH Keys}}<br />
<br />
SSH keys serve as a means of identifying yourself to an SSH server using [[Wikipedia:Public-key cryptography|public-key cryptography]] and [[Wikipedia:Challenge-response authentication|challenge-response authentication]]. One immediate advantange this method has over traditional password authentication is that you can be authenticated by the server without ever having to send your password over the network. Anyone eavesdropping on your connection will not be able to intercept and crack your password because it is never actually transmitted. Additionally, Using SSH keys for authentication virtually eliminates the risk posed by brute-force password attacks by drastically reducing the chances of the attacker correctly guessing the proper credentials.<br />
<br />
As well as offering additional security, SSH key authentication can be more convenient than the more traditional password authentication. When used with a program known as an SSH agent, SSH keys can allow you to connect to a server, or multiple servers, without having to remember or enter your password for each system.<br />
<br />
SSH keys are not without their drawbacks and may not be appropriate for all environments, but in many circumstances they can offer some strong advantages. A general understanding of how SSH keys work will help you decide how and when to use them to meet your needs. This article assumes you already have a basic understanding of the [[Secure Shell]] protocol and have installed the {{Pkg|openssh}} package, available in the [[Official Repositories]].<br />
<br />
==Background==<br />
SSH keys always come in pairs, one private and the other public. The private key is known only to you and it should be safely guarded. By contrast, the public key can be shared freely with any SSH server to which you would like to connect.<br />
<br />
When an SSH server has your public key on file and sees you requesting a connection, it uses your public key to construct and send you a challenge. This challenge is like a coded message and it must be met with the appropriate response before the server will grant you access. What makes this coded message particularly secure is that it can only be understood by someone with the private key. While the public key can be used to encrypt the message, it cannot be used to decrypt that very same message. Only you, the holder of the private key, will be able to correctly understand the challenge and produce the correct response.<br />
<br />
This challenge-response phase happens behind the scenes and is invisible to the user. As long as you hold the private key, which is typically stored in the {{ic|~/.ssh/}} directory, your SSH client should be able to reply with the appropriate response to the server.<br />
<br />
Because private keys are considered sensitive information, they are often stored on disk in an encrypted form. In this case, when the private key is required, a passphrase must first be entered in order to decrypt it. While this might superficially appear the same as entering a login password on the SSH server, it is only used to decrypt the private key on the local system. This passphrase is not, and should not, be transmitted over the network.<br />
<br />
==Generating an SSH key pair==<br />
An SSH key pair can be generated by running the {{ic|ssh-keygen}} command:<br />
{{hc|1=<br />
$ ssh-keygen -b 521 -t ecdsa -C"$(id -un)@$(hostname)-$(date --rfc-3339=date)"|2= <nowiki>Generating public/private ecdsa key pair.<br />
Enter file in which to save the key (/home/username/.ssh/id_ecdsa):<br />
Enter passphrase (empty for no passphrase):<br />
Enter same passphrase again:<br />
Your identification has been saved in /home/username/.ssh/id_ecdsa.<br />
Your public key has been saved in /home/username/.ssh/id_ecdsa.pub.<br />
The key fingerprint is:<br />
dd:15:ee:24:20:14:11:01:b8:72:a2:0f:99:4c:79:7f username@localhost-2011-12-22<br />
The key's randomart image is:<br />
+--[ECDSA 521]---+<br />
| ..oB=. . |<br />
| . . . . . |<br />
| . . . + |<br />
| oo.o . . = |<br />
|o+.+. S . . . |<br />
|=. . E |<br />
| o . |<br />
| . |<br />
| |<br />
+-----------------+</nowiki>}}<br />
<br />
In the above example, {{ic|ssh-keygen}} generates a 521 bit long ({{ic|-b 521}}) public/private ECDSA ({{ic|-t ecdsa}}) key pair with an extended comment including the data ({{ic|-C"$(id -un)"@$(hostname)-$(date --rfc-3339&#61;date)}}). The [http://www.cs.berkeley.edu/~dawnsong/papers/randomart.pdf randomart image] was introduced in OpenSSH 5.1 as an easier means of visually identifying the key fingerprint.<br />
<br />
===Choosing the type of encryption===<br />
The Elliptic Curve Digital Signature Algorithm (ECDSA) provides smaller key sizes and faster operations for equivalent estimated security to the previous methods. It was introduced as the preferred algorithm for authentication in OpenSSH 5.7, see [http://openssh.org/txt/release-5.7 OpenSSH 5.7 Release Notes]. ECDSA keys might not be compatible with systems that ship old versions of OpenSSH. Some vendors also disable the required implementations due to potential patent issues.<br />
<br />
If you choose to create an RSA (2048-4096 bit) or DSA (1024 bit) key pair instead of ECDSA, use the {{ic|-t rsa}} or {{ic|-t dsa}} switches in your {{ic|ssh-keygen}} command and do not forget to increase the key size. Running {{ic|ssh-keygen}} without the {{ic|-b}} switch should provide reasonable defaults.<br />
<br />
{{Note|These keys are used only to authenticate you, choosing stronger keys will not increase CPU load when transferring data over SSH.}}<br />
<br />
===Choosing the key location and passphrase===<br />
Upon issuing the {{ic|ssh-keygen}} command, you will be prompted for the desired name an location of your private key. By default, keys are stored in the {{ic|~/.ssh/}} directory and named according the type of encryption used. You are advised to accept the default name and location in order for later code examples in this article to work properly.<br />
<br />
When prompted for a passphrase, choose something that will be hard to guess if you have the security of your private key in mind. A longer, more random password will generally be stronger and harder to crack should it fall into the wrong hands.<br />
<br />
It is also possible to create your private key without a passphrase. While this can be convenient, you need to be aware of the associated risks. Without a passphrase, your private key will be stored on disk in an unencrypted form. Anyone who gains access to your private key file will then be able to assume your identity on any SSH server to which you connect using key-based authentication. Furthermore, without a passphrase, you must also trust the root user, as he can bypass file permissions and will be able to access your unencrypted private key file at any time.<br />
<br />
==Copying the public key to the remote server==<br />
Once you have generated a key pair, you will need to copy the public key to the remote server so that it will use SSH key authentication. The public key file shares the same name as the private key except that is appended with a {{ic|.pub}} extension. Note that the private key is not shared and remains on the local machine.<br />
<br />
===Simple method===<br />
If your key file is {{ic|~/.ssh/id_rsa.pub}} you can simply enter the following command.<br />
$ ssh-copy-id remote-server.org<br />
<br />
If your username differs on remote machine, be sure to prepend the username followed by {{ic|@}} to the server name.<br />
$ ssh-copy-id username@remote-server.org<br />
<br />
If your public key filename is anything other than the default of {{ic|~/.ssh/id_rsa.pub}} you will get an error stating {{ic|/usr/bin/ssh-copy-id: ERROR: No identities found}}. In this case, you must explicitly provide the location of the public key.<br />
$ ssh-copy-id -i ~/.ssh/id_ecdsa.pub username@remote-server.org<br />
<br />
If the ssh server is listening on a port other than default of 22, be sure to include it within the host argument.<br />
$ ssh-copy-id -i ~/.ssh/id_rsa.pub '-p 221 username@remote-server.org'<br />
<br />
===Traditional method===<br />
By default, for OpenSSH, the public key needs to be concatenated with {{ic|~/.ssh/authorized_keys}}. Begin by copying the public key to the remote server.<br />
<br />
$ scp ~/.ssh/id_ecdsa.pub username@remote-server.org:<br />
<br />
The above example copies the public key ({{ic|id_ecdsa.pub}}) to your home directory on the remote server via {{ic|scp}}. Do not forget to include the {{ic|:}} at the end of the server address. Also note that the name of your public key may differ from the example given.<br />
<br />
On the remote server, you will need to create the {{ic|~/.ssh}} directory if it does not yet exist and append your public key to the {{ic|authorized_keys}} file.<br />
<br />
$ ssh username@remote-server.org<br />
username@remote-server.org's password:<br />
$ mkdir ~/.ssh<br />
$ cat ~/id_ecdsa.pub >> ~/.ssh/authorized_keys<br />
$ rm ~/id_ecdsa.pub<br />
$ chmod 600 ~/.ssh/authorized_keys<br />
<br />
The last two commands remove the public key file from the server and set the permissions on the {{ic|authorized_keys}} file such that it is only readable and writable by you, the owner.<br />
<br />
Disconnect from the server and then attempt to reconnect. You should now be asked for the passphrase of the key.<br />
<br />
$ ssh username@remote-server.org<br />
Enter passphrase for key '/home/username/.ssh/id_ecdsa':<br />
<br />
If you are unable to login with the key, double check the permissions on the {{ic|authorized_keys}} file.<br />
<br />
Also check the permissions on the {{ic|~/.ssh}} directory, which should have write permissions off for 'group' and 'other'. Run the following command to disable 'group' and 'other' write permissions for the {{ic|~/.ssh}} directory.<br />
$ chmod go-w ~/.ssh<br />
<br />
==Disabling password logins==<br />
While copying your public key to the remote SSH server eliminates the need to transmit your password over the network, it does not give any added protection against a brute-force password attack. In the absense of a private key, the SSH server will fall back to password authentication by default, thus allowing a malicious user to attempt to gain access by guessing your password. To disable this behavior, edit the following lines in the {{ic|/etc/ssh/sshd_config}} file on the remote server.<br />
<br />
{{hc|/etc/ssh/sshd_config|<br />
PasswordAuthentication no<br />
ChallengeResponseAuthentication no}}<br />
<br />
==SSH agents==<br />
If your private key is encrypted with a passphrase, this passphrase must be entered every time you attempt to connect to an SSH server using public-key authentication. Each individual invocation of {{ic|ssh}} or {{ic|scp}} will need the passphrase in order to decrypt your private key before authentication can proceed.<br />
<br />
An SSH agent is a program which caches your decrypted private keys and provides them to SSH client programs on your behalf. In this arrangement, you must only provide your passphrase once, when adding your private key to the agent's cache. This facility can be of great convenience when making frequent SSH connections.<br />
<br />
An agent is typically configured to run automatically upon login and persist for the duration of your login session. A variety of agents, front-ends, and configurations exist to achieve this effect. This section provides an overview of a number of different solutions which can be adapted to meet your specific needs.<br />
<br />
===ssh-agent===<br />
ssh-agent is the default agent included with OpenSSH. It can be used directly or serve as the back-end to a few of the front-end solutions mentioned later in this section. When {{ic|ssh-agent}} is run, it will fork itself to the background and print out the environment variables it would use.<br />
<br />
$ ssh-agent<br />
SSH_AUTH_SOCK=/tmp/ssh-vEGjCM2147/agent.2147; export SSH_AUTH_SOCK;<br />
SSH_AGENT_PID=2148; export SSH_AGENT_PID;<br />
echo Agent pid 2148;<br />
<br />
To make use of these variables, run the command through the {{ic|eval}} command.<br />
<br />
$ eval $(ssh-agent)<br />
Agent pid 2157<br />
<br />
You can append the above command to your {{ic|~/.bash_profile}} script so that it will run automatically when starting a login shell.<br />
<br />
$ echo 'eval $(ssh-agent)' >> ~/.bash_profile<br />
<br />
If you would rather have ssh-agent run automatically for all users append the command to {{ic|/etc/profile}} instead.<br />
<br />
# echo 'eval $(ssh-agent)' >> /etc/profile<br />
<br />
Once {{ic|ssh-agent}} is running, you will need to add your private key to its cache.<br />
<br />
$ ssh-add ~/.ssh/id_ecdsa<br />
Enter passphrase for /home/user/.ssh/id_ecdsa:<br />
Identity added: /home/user/.ssh/id_ecdsa (/home/user/.ssh/id_ecdsa)<br />
<br />
If you would like your private keys to be added automatically on login. Append the following command to your {{ic|~/.bash_profile}} as well.<br />
<br />
$ echo 'ssh-add' >> ~/.bash_profile<br />
<br />
If your private key is encrypted {{ic|ssh-add}} will prompt you to enter your passphrase. Once your private key has been successfully added to the agent you will be able to make SSH connections without having to enter a passphrase.<br />
<br />
One downside to this approach is that a new instance of {{ic|ssh-agent}} is created for every login shell and each instance will persist between login sessions. Over time you can wind up with dozens of needless {{ic|ssh-agent}} processes running. There exist a number of front-ends to ssh-agent and alternative agents described later in this section which avoid this problem.<br />
<br />
===GnuPG Agent===<br />
<br />
The [[GnuPG]] agent, distributed with the {{Pkg|gnupg2}} package, available in the [[Official Repositories]], has OpenSSH agent emulation. If you use GPG you might consider using its agent to take care of all of your keys. Otherwise you might like the PIN entry dialog it provides and its passphrase management, which is different from Keychain.<br />
<br />
To start using GPG agent for your SSH keys you should first start the gpg-agent with the {{ic|--enable-ssh-support}} option. Example (don't forget to make the file executable):<br />
{{hc|/etc/profile.d/gpg-agent.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Start the GnuPG agent and enable OpenSSH agent emulation<br />
gnupginf="${HOME}/.gnupg/gpg-agent.info"<br />
<br />
if pgrep -u "${USER}" gpg-agent >/dev/null 2>&1; then<br />
eval `cat $gnupginf`<br />
eval `cut -d= -f1 $gnupginf | xargs echo export`<br />
else<br />
eval `gpg-agent --enable-ssh-support --daemon`<br />
fi<br />
</nowiki>}}<br />
<br />
Once gpg-agent is running you can use ssh-add to approve keys, just like you did with plain ssh-agent. The list of approved keys is stored in the {{ic|~/.gnupg/sshcontrol}} file. Once your key is approved you will get a PIN entry dialog every time your passphrase is needed. You can control passphrase caching in the {{ic|~/.gnupg/gpg-agent.conf}} file. The following example would have gpg-agent cache your keys for 3 hours: <br />
<br />
# Cache settings<br />
default-cache-ttl 10800<br />
default-cache-ttl-ssh 10800<br />
<br />
Other useful settings for this file include the PIN entry program (GTK, QT or ncurses version), keyboard grabbing and so on...:<br />
<br />
# Environment file<br />
write-env-file /home/username/.gnupg/gpg-agent.info<br />
<br />
# Keyboard control<br />
#no-grab<br />
<br />
# PIN entry program<br />
#pinentry-program /usr/bin/pinentry-curses<br />
#pinentry-program /usr/bin/pinentry-qt4<br />
pinentry-program /usr/bin/pinentry-gtk-2<br />
<br />
===Keychain===<br />
[http://www.funtoo.org/en/security/keychain/intro/ Keychain] is a program designed to help you easily manage your SSH keys with minimal user interaction. It is implemented as a shell script which drives both {{ic|ssh-agent}} and {{ic|ssh-add}}. A notable feature of Keychain is that it can maintain a single {{ic|ssh-agent}} process across multiple login sessions. This means that you only need to enter your passphrase once each time your local machine is booted.<br />
<br />
[[pacman|Install]] the {{Pkg|keychain}} package, available from the [[Official Repositories]].<br />
<br />
Append the following line to {{ic|~/.bash_profile}}, or create {{ic|/etc/profile.d/keychain.sh}} as root and make it executable (e.g. {{ic|chmod 755 keychain.sh}}):<br />
{{hc|~/.bash_profile|<br />
eval $(keychain --eval --agents ssh -Q --quiet id_ecdsa)<br />
}}<br />
<br />
In the above example, the {{ic|--eval}} switch outputs lines to be evaluated by the opening {{ic|eval}} command. This sets the necessary environments variables for SSH client to be able to find your agent. The {{ic|--agents}} switch is not strictly necessary, because Keychain will build the list automatically based on the existence of ssh-agent or gpg-agent on the system. Adding the {{ic|--quiet}} switch will limit output to warnings, errors, and user prompts. If you want greater security replace {{ic|-Q}} with {{ic|--clear}} but will be less convenient.<br />
<br />
If necessary, replace {{ic|~/.ssh/id_ecdsa}} with the path to your private key. For those using a non-Bash compatible shell, see {{ic|keychain --help}} or {{ic|man keychain}} for details on other shells.<br />
<br />
To test Keychain, log out from your session and log back in. If this is your first time running Keychain, it will prompt you for the passphrase of the specified private key. Because Keychain reuses the same {{ic|ssh-agent}} process on successive logins, you shouldn't have to enter your passphrase the next time you log in. You will only ever be prompted for your passphrase once each time the machine is rebooted.<br />
<br />
====Alternate startup methods====<br />
There are numerous ways in which Keychain can be invoked and you are encouraged to experiment to find a method that works for you. The {{ic|keychain}} command itself comes with dozens of command-line options which are described in the Keychain man page.<br />
<br />
One alternative implementation of a Keychain startup script could be to create the file {{ic|/etc/profile.d/keychain.sh}} as the root user and add the following lines.<br />
<br />
{{hc|/etc/profile.d/keychain.sh|<nowiki><br />
/usr/bin/keychain -Q -q --nogui ~/.ssh/id_ecdsa<br />
[[ -f $HOME/.keychain/$HOSTNAME-sh ]] && source $HOME/.keychain/$HOSTNAME-sh<br />
</nowiki>}}<br />
<br />
Be sure to also make {{ic|/etc/profile.d/keychain.sh}} executable by changing its file permissions.<br />
# chmod 755 /etc/profile.d/keychain.sh<br />
<br />
===x11-ssh-askpass===<br />
The x11-ssh-askpass package provides a graphical dialog for entering your passhrase when running an X session. x11-ssh-askpass depends only the {{Pkg|libx11}} and {{Pkg|libxt}} libraries, and the appearance of x11-ssh-askpass is customizable. While it can be invoked by the {{ic|ssh-add}} program which will then load your decrypted keys into [[#ssh-agent|ssh-agent]], the following instructions will instead configure x11-ssh-askpass to be invoked by the aforementioned [[#Keychain|Keychain]] script.<br />
<br />
Install {{Pkg|keychain}} and {{Pkg|x11-ssh-askpass}}, both available in the [[Official Repositories]].<br />
<br />
Edit your {{ic|~/.xinitrc}} file to include the lines highlighted in bold, replacing the name and location of your private if necessary. Be sure to place these commands '''before''' the line which invokes your window mananger.<br />
<br />
{{hc|~/.xinitrc|<br />
'''keychain ~/.ssh/id_ecdsa'''<br />
'''[ -f ~/.keychain/$HOSTNAME-sh ] && . ~/.keychain/$HOSTNAME-sh 2>/dev/null'''<br />
'''[ -f ~/.keychain/$HOSTNAME-sh-gpg ] && . ~/.keychain/$HOSTNAME-sh-gpg 2>/dev/null'''<br />
...<br />
exec openbox-session}}<br />
<br />
In the above example, the first line invokes {{ic|keychain}} and passes the name and location of your private key. If this is not the first time keychain was invoked, the following two lines load the contents of {{ic|$HOSTNAME-sh}} and {{ic|$HOSTNAME-sh-gpg}} if they exist. These files store the environment variables of the previous instance of {{ic|keychain}}.<br />
<br />
====Theming====<br />
The appearance of the x11-ssh-askpass dialog can be customized by setting its associated [[X resources]]. The x11-ssh-askpass [http://www.jmknoble.net/software/x11-ssh-askpass/ homepage] presents some example [http://www.jmknoble.net/software/x11-ssh-askpass/screenshots.html example themes]. See the x11-ssh-askpass man page for full details.<br />
<br />
====Alternative passphrase dialogs====<br />
There are other passphrase dialog programs which can be used instead of x11-ssh-askpass. The following list provides some alternative solutions.<br />
<br />
* {{Pkg|ksshaskpass}} is available in the Official Repositories. It is dependent on {{Pkg|kdelibs}} and is suitable for the KDE Desktop Environment.<br />
<br />
* {{Pkg|openssh-askpass}} depends on the {{Pkg|qt}} libraries, and is available from the Official Repositories.<br />
<br />
===pam_ssh===<br />
The [http://pam-ssh.sourceforge.net/ pam_ssh] project exists to provide a [[Wikipedia:Pluggable authentication module|Pluggable Authentication Module]] (PAM) for SSH private keys. This module can provide single sign-on behavior for your SSH connections. On login, your SSH private key passphrase can be entered in place of, or in addition to, your traditional system password. Once you have been authenticated, the pam_ssh module spawns ssh-agent to store your decrypted private key for the duration of the session.<br />
<br />
To enable single sign-on behavior at the tty login prompt, install the unofficial {{AUR|pam_ssh}} package, available in the [[Arch User Repository]]. <br />
<br />
Edit the {{ic|/etc/pam.d/login}} configuration file to include the text highlighted in bold in the example below. The order in which these lines appear is significiant and can affect login behavior.<br />
<br />
{{Warning|Misconfiguring PAM can leave the system in a state where all users become locked out. Before making any changes, you should have an understanding of how PAM configuration works as well as a backup means of accessing the PAM configuration files, such as an Arch Live CD, in case you become locked out and need to revert any changes. An IBM developerWorks [http://www.ibm.com/developerworks/linux/library/l-pam/index.html article] is available which explains PAM configuration in further detail.}}<br />
<br />
{{hc|/etc/pam.d/login|2=<br />
#%PAM-1.0<br />
auth required pam_securetty.so<br />
auth requisite pam_nologin.so<br />
'''auth sufficient pam_ssh.so'''<br />
auth required pam_unix.so nullok '''use_first_pass'''<br />
auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
# use this to lockout accounts for 10 minutes after 3 failed attempts<br />
#auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
account required pam_access.so<br />
account required pam_time.so<br />
account required pam_unix.so<br />
#password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3<br />
#password required pam_unix.so sha512 shadow use_authtok<br />
session required pam_unix.so<br />
session required pam_env.so<br />
session required pam_motd.so<br />
session required pam_limits.so<br />
session optional pam_mail.so dir=/var/spool/mail standard<br />
session optional pam_lastlog.so<br />
session optional pam_loginuid.so<br />
'''session optional pam_ssh.so'''<br />
-session optional pam_ck_connector.so nox11<br />
-session optional pam_systemd.so<br />
}}<br />
<br />
In the above example, login uses pam_ssh to check the entered password against the user's SSH private key passphrase. If the password matches, the user is immediately granted access to the system. If the password does not match, control falls to the pam_unix module which provides traditional password authentication. Because the {{ic|use_first_pass}} option is set, the pam_unix module checks the previously entered password against the {{ic|/etc/passwd}} file instead of asking for a password again. In this way, ssh_pam will be transparent to users without an SSH private key.<br />
<br />
If you use a another means of logging in, such as an X11 display manager like [[SLiM]] or [[XDM]] and you would like it to provide similar functionality, you must edit its associated PAM configuration file in a similar fashion. Packages providing support for PAM typically place a default configuration file in the {{ic|/etc/pam.d/}} directory.<br />
<br />
Further details on how to use pam_ssh and a list of its options can be found in the pam_ssh man page.<br />
<br />
====Known issues with pam_ssh====<br />
Work on the pam_ssh project is infrequent and the documentation provided is sparse. You should be aware of some of its limitations which are not mentioned in the package itself.<br />
<br />
* SSH keys employing the newer option of ECDSA (elliptic curve) cryptography do not appear to be supported by pam_ssh. You must use either RSA or DSA keys.<br />
<br />
* The {{ic|ssh-agent}} process spawned by pam_ssh does not persist between user logins. If you like to keep a [[GNU Screen]] session active between logins you may notice when reattaching to your screen session that it can no longer communicate with ssh-agent. This is because the GNU Screen environment and those of its children will still reference the instance of ssh-agent which existed when GNU Screen was invoked but was subsequently killed in a previous logout. The [[#keychain|Keychain]] front-end avoids this problem by keeping the ssh-agent process alive between logins.<br />
<br />
===GNOME Keyring===<br />
If you use the [[GNOME]] desktop, the [[GNOME Keyring]] tool can be used as an SSH agent. Visit the [[GNOME Keyring]] article.<br />
<br />
==Troubleshooting==<br />
If it appears that the SSH server is ignoring your keys, ensure that you have the proper permissions set on all relevant files.<br />
<br />
For the local machine:<br />
<br />
$ chmod 700 ~/<br />
$ chmod 700 ~/.ssh<br />
$ chmod 600 ~/.ssh/id_ecdsa<br />
<br />
For the remote machine:<br />
<br />
$ chmod 700 ~/<br />
$ chmod 700 ~/.ssh<br />
$ chmod 600 ~/.ssh/authorized_keys<br />
<br />
Failing this, run the sshd in debug mode and monitor the output while connecting:<br />
<br />
# /usr/sbin/sshd -d<br />
<br />
==See also==<br />
* [http://www-106.ibm.com/developerworks/linux/library/l-keyc.html OpenSSH key management, Part 1]<br />
* [http://www-106.ibm.com/developerworks/linux/library/l-keyc2/ OpenSSH key management, Part 2]<br />
* [http://www-106.ibm.com/developerworks/library/l-keyc3/ OpenSSH key management, Part 3]<br />
* [http://kimmo.suominen.com/docs/ssh/ Getting started with SSH]<br />
* [http://openssh.org/txt/release-5.7 OpenSSH 5.7 Release Notes]</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Amateur_radio&diff=176615Amateur radio2012-01-02T15:41:33Z<p>Rnabioullin: /* Interfacing */ Changed link to the archwiki page</p>
<hr />
<div>{{i18n|Amateur Radio}}<br />
[[Category:Telephony and Voice (English)]]<br />
<br />
Amateur radio enthusiasts (sometimes called ham radio operators or "hams") have been at the forefront of experimentation and development since the earliest days of radio. A wide variety of communication modes are used on a vast range of frequencies that span the electromagnetic spectrum. <br />
This page lists software related to amateur radio that can be found in the AUR. Some of it is stand-alone while the various digital communication applications require interfacing to radio hardware and possibly the computer soundcard. Interface hardware can be purchased from vendors or home-built. <br />
<br />
'''Note:''' International treaties require that users of amateur radio frequencies have a government-issued license.<br />
<br />
==Interfacing==<br />
{{Note|Many of the following programs will need to access a serial port to key the transmitter (eg. /dev/ttyS0). This requires that the user belong to the uucp group. To add the user to the uucp group issue the following command as root:<br />
<br />
# gpasswd -a ''username'' uucp<br />
<br />
then logoff and logon.<br />
}}<br />
* [http://sourceforge.net/apps/mediawiki/hamlib/index.php?title=Main_Page Hamlib] provides an interface between hardware and radio control programs. It is a software layer to facilitate the control of radios and other hardware (eg. for logging, digital modes) and is not a stand-alone application. It is available in the [http://aur.archlinux.org/packages.php?ID=22311 AUR].<br />
* [http://www.baycom.org/~tom/ham/soundmodem/ Soundmodem] was written by Tom Sailer (HB9JNX/AE4WA) to allow a standard PC soundcard to act as a packet radio modem for use with the various AX.25 communication modes. The data rate can be as high as 9600 baud depending on the hardware and application. Soundmodem can be used as a KISS modem on the serial port or as an AX.25 network device. To use soundmodem as an MKISS network device, the kernel must be re-built with MKISS modules. More information is in the [http://www.xastir.org/wiki/index.php/HowTo:SoundModem Xastir wiki]. Soundmodem is available in the [http://aur.archlinux.org/packages.php?ID=17084 AUR].<br />
:Run soundmodem as root:<br />
# soundmodem<br />
:If you have configured soundmodem as a KISS modem, you will need to change permissions to make it user-readable:<br />
# chmod 666 /dev/soundmodem0<br />
* [http://aur.archlinux.org/packages.php?ID=22315 grig] is a simple control program based on Hamlib. <br />
* [http://aur.archlinux.org/packages.php?ID=40593 gmfsk] is a user interface that supports a multitude of digital modes. It uses hamlib and xlog for logging.<br />
*[http://aur.archlinux.org/packages.php?ID=45354 lysdr-git] is a highly customizable radio interface<br />
*[http://aur.archlinux.org/packages.php?ID=47557 linrad] Software defined radio by SM5BSZ <br />
*[http://aur.archlinux.org/packages.php?ID=48589 quisk] Software defined radio by N2ADR<br />
*[[owx]] Command-line utility for programming Wouxun radios<br />
*[http://aur.archlinux.org/packages.php?ID=22304 cwdaemon] cw keyer for serial or parallel port<br />
*[http://aur.archlinux.org/packages.php?ID=22326 twcw] Extension for cwirc<br />
*[http://aur.archlinux.org/packages.php?ID=22310 fldigi] Popular GUI developed by W1HKJ for a variety of digital communication modes<br />
*[http://aur.archlinux.org/packages.php?ID=45203 libfap] APRS packet parser<br />
*[http://aur.archlinux.org/packages.php?ID=47724 aprx] Lightweight APRS digipeater and i-Gate interface<br />
*[http://aur.archlinux.org/packages.php?ID=22329 xdx] Network client<br />
*[http://aur.archlinux.org/packages.php?ID=47690 d-rats] D-STAR communication tool<br />
*[http://aur.archlinux.org/packages.php?ID=22323 qsstv] Slow-scan television<br />
*[https://aur.archlinux.org/packages.php?ID=48029 linpsk] PSK31<br />
*[https://aur.archlinux.org/packages.php?ID=49556 psk31lx] PSK31 using Pulseaudio<br />
*[https://aur.archlinux.org/packages.php?ID=48594 twpsk] Soundcard based program for PSK31<br />
*[https://aur.archlinux.org/packages.php?ID=49217 xpsk31] PSK31 using a GUI rendered by GTK+<br />
<br />
==AX.25==<br />
[http://en.wikipedia.org/wiki/AX.25 AX.25] is a data link layer protocol that is used extensively in packet radio networks. It supports connected operation (eg. keyboard-to-keyboard contacts, access to local bulletin board systems, and DX clusters) as well as connectionless operation (eg. [http://en.wikipedia.org/wiki/APRS APRS]). The Linux kernel includes native support for AX.25 networking. Please refer to this [http://tldp.org/HOWTO/AX25-HOWTO/ guide] for more information. The following software is available in the AUR:<br />
* [http://aur.archlinux.org/packages.php?ID=17085 ax25-apps]<br />
* [http://aur.archlinux.org/packages.php?ID=17083 ax25-tools]<br />
* [http://aur.archlinux.org/packages.php?ID=22319 libax25]<br />
* [http://aur.archlinux.org/packages.php?ID=32125 node]<br />
<br />
==WSJT==<br />
[http://www.physics.princeton.edu/pulsar/K1JT/ WSJT] stands for "Weak Signal Communication by K1JT". WSJT was developed by Nobel Prize winning physicist Joe Taylor, who has the amateur radio callsign K1JT. The software offers offers a rich variety of features, including specific digital protocols optimized for meteor scatter, ionospheric scatter, and EME (moonbounce) at VHF/UHF, as well as HF skywave propagation. The program can decode fraction-of-a-second signals reflected from ionized meteor trails and steady signals 10 dB below the audible threshold. <br />
<br />
WSJT is in ongoing, active development by a team of programmers led by K1JT. The latest verion of the software can be retrieved and built from the svn repository at [http://sourceforge.net/projects/wsjt/ sourceforge] using [http://aur.archlinux.org/packages.php?ID=47447 wsjt-svn] in the AUR. WSJT (and the related program WSPR) has the option of being configured with <br />
<br />
$ ./configure --enable-g95 <br />
<br />
or <br />
<br />
$ ./configure --enable-gfortran <br />
<br />
If you build with one and experience problems, edit PKGBUILD to try the other. <br />
<br />
WSJT requires access to the serial port; see the note in the Interfacing section above about the uucp group.<br />
<br />
==WSPR==<br />
[http://en.wikipedia.org/wiki/WSPR_%28Amateur_radio_software%29 WSPR] (pronounced whisper) is a Weak Signal Propagation Reporter. It was introduced in 2008 by K1JT following the success and widespread adoption of WSJT by the amateur radio community. WSPR enables the probing of propagation paths on the amateur radio bands using low power transmissions. Stations with Internet access can automatically upload their reception reports to a central database called [http://wsprnet.org/drupal/ WSPRnet], which includes a [http://wsprnet.org/drupal/wsprnet/map mapping facility]. The package [https://aur.archlinux.org/packages.php?ID=47405 wspr-svn] in the AUR builds the current version of the program from the svn repository.<br />
<br />
==Xastir==<br />
[http://www.xastir.org Xastir] stands for X Amateur Station and Information Reporting. It works with [http://en.wikipedia.org/wiki/APRS APRS], an amateur radio-based system for real time tactical digital communications. Xastir is an open-source program that provides full-featured, client-side access to APRS. It is currently in a state of active development. Arch users can install the bleeding-edge version of Xastir from the CVS repository on Sourceforge with [http://aur.archlinux.org/packages.php?ID=46938 xastir-cvs] in the AUR. <br />
<br />
Xastir is highly flexible and there are a wide variety of ways it can be configured. For example, it can be evaluated without radio hardware if an Internet connection is available. The wiki at xastir.org is very thorough and gives excellent information on its range of capabilities and setup.<br />
<br />
An optional speech feature can be enabled with the {{package AUR|festival}} package; you will also need a speaker package such as festival-en or festival-english. If you want this option, festival must be installed on your system before building xastir. Launch festival before the xastir program is started for speech to function properly:<br />
$ festival --server<br />
or you can write a simple script to automate the sequential starting process. There may be problems if other programs such as a media player are accessing sound simultaneously. <br />
<br />
The PKGBUILD automatically downloads an 850 kB bundle of .wav files and places them here:<br />
/usr/share/xastir/sounds/<br />
These are audio alarm recordings of a North American English speaker that do not require the presence of festival to render. The audio play command `play' in the configure menu may not work; try `aplay' instead.<br />
<br />
==Analysis tools==<br />
* [http://aur.archlinux.org/packages.php?ID=34132 fl_moxgen] Moxon antenna designer<br />
* [http://aur.archlinux.org/packages.php?ID=22313 geoid] Geodetic calculator<br />
* [http://aur.archlinux.org/packages.php?ID=22314 gpredict] Real-time satellite tracking and orbit prediction application<br />
* [http://aur.archlinux.org/packages.php?ID=48583 hamsolar] Small desktop display of the current solar indices<br />
* [http://aur.archlinux.org/packages.php?ID=22324 splat] rf signal propagation, loss, and terrain analysis<br />
* [http://aur.archlinux.org/packages.php?ID=5919 sunclock] Useful for predicting grayline propagation paths<br />
* [http://aur.archlinux.org/packages.php?ID=22331 xnec2c] Electromagnetic antenna modeler<br />
<br />
==Logging==<br />
* [http://aur.archlinux.org/packages.php?ID=29015 callsign] Callsign info lookup<br />
* [http://www.cqrlog.com/ cqrlog] is a popular Linux logging program. Compiling from source, however, is a complicated process and no package is currently available in the AUR. Instead, a binary can be installed with a script: Go to the cqrlog [http://www.cqrlog.com/?q=node/4 website] and download a version compatible with your architecture. Unbundle the tarball and run:<br />
$ ./cqrlog_install.sh<br />
then follow the directions. The only dependency is {{package AUR|hamlib}}.<br />
* [https://aur.archlinux.org/packages.php?ID=34845 cty] Databases for logging programs<br />
* [https://aur.archlinux.org/packages.php?ID=22307 dxcc] Determines DXCC entity of amateur callsigns<br />
* [https://aur.archlinux.org/packages.php?ID=22309 fdlog] Field Day logger<br />
* [https://aur.archlinux.org/packages.php?ID=40660 klog]<br />
* [https://aur.archlinux.org/packages.php?ID=48452 qle] Full-featured logging program<br />
* [https://aur.archlinux.org/packages.php?ID=22325 tlf]<br />
* [https://aur.archlinux.org/packages.php?ID=29821 tucnak2] VHF contest logger<br />
* [https://aur.archlinux.org/packages.php?ID=22317 xlog]<br />
* [https://aur.archlinux.org/packages.php?ID=22333 yfklog]<br />
* [https://aur.archlinux.org/packages.php?ID=22332 yfktest]<br />
<br />
==Morse code trainers==<br />
* [https://aur.archlinux.org/packages.php?ID=22302 aldo]<br />
* [https://aur.archlinux.org/packages.php?ID=45022 cutecw]<br />
* [https://aur.archlinux.org/packages.php?ID=22308 ebook2cw]<br />
* [https://aur.archlinux.org/packages.php?ID=22318 gtkmmorse]<br />
* [https://aur.archlinux.org/packages.php?ID=23997 kochmorse]<br />
* [https://aur.archlinux.org/packages.php?ID=22322 qrq]<br />
* [https://aur.archlinux.org/packages.php?ID=22305 unixcw]<br />
<br />
==Other==<br />
*[http://aur.archlinux.org/packages.php?ID=22306 cwirc] Send and receive Morse code messages via IRC</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Owx&diff=176614Owx2012-01-02T15:38:19Z<p>Rnabioullin: enabled templates</p>
<hr />
<div>[[Category:Telephony and Voice (English)]]<br />
{{Stub}}<br />
<br />
[http://owx.chmurka.net owx] (open wouxun) is a CLI utility used to program KG669V radios by means of a CSV spreadsheet.<br />
<br />
== Installation ==<br />
[http://aur.archlinux.org/packages.php?ID=42448 owx] is available in the [[AUR]].<br />
<br />
== Tips and Tricks ==<br />
U.S. [http://en.wikipedia.org/wiki/NOAA_Weather_Radio NOAA Weather Radio] frequencies (replace {{ic|CH}} with a desired channel number):<br />
{{bc|"CH","NWR1","162.40000","162.40000","","","narrow","high","no","no"<br />
"CH","NWR2","162.42500","162.42500","","","narrow","high","no","no"<br />
"CH","NWR3","162.45000","162.45000","","","narrow","high","no","no"<br />
"CH","NWR4","162.47500","162.47500","","","narrow","high","no","no"<br />
"CH","NWR5","162.50000","162.50000","","","narrow","high","no","no"<br />
"CH","NWR6","162.52500","162.52500","","","narrow","high","no","no"<br />
"CH","NWR7","162.55000","162.55000","","","narrow","high","no","no"}}</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Owx&diff=176612Owx2012-01-02T15:26:58Z<p>Rnabioullin: Created new stub</p>
<hr />
<div>[[Category:Telephony and Voice (English)]]<br />
{{Stub}}<br />
<br />
[http://owx.chmurka.net owx] (open wouxun) is a CLI utility used to program KG669V radios by means of a CSV spreadsheet.<br />
<br />
== Installation ==<br />
[http://aur.archlinux.org/packages.php?ID=42448 owx] is available in the [[AUR]].<br />
<br />
== Tips and Tricks ==<br />
U.S. [http://en.wikipedia.org/wiki/NOAA_Weather_Radio NOAA Weather Radio] frequencies (replace CH with a desired channel number):<br />
<code>"CH","NWR1","162.40000","162.40000","","","narrow","high","no","no"<br />
"CH","NWR2","162.42500","162.42500","","","narrow","high","no","no"<br />
"CH","NWR3","162.45000","162.45000","","","narrow","high","no","no"<br />
"CH","NWR4","162.47500","162.47500","","","narrow","high","no","no"<br />
"CH","NWR5","162.50000","162.50000","","","narrow","high","no","no"<br />
"CH","NWR6","162.52500","162.52500","","","narrow","high","no","no"<br />
"CH","NWR7","162.55000","162.55000","","","narrow","high","no","no"<br />
</code></div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=PKGBUILD&diff=175555PKGBUILD2011-12-22T16:41:27Z<p>Rnabioullin: grammar</p>
<hr />
<div>[[Category:About Arch (English)]]<br />
[[Category:Package development (English)]]<br />
{{i18n|PKGBUILD}}<br />
[[fr:PKGBUILD]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|A PKGBUILD is a script that describes how software is to be compiled and packaged. This article provides an explanation of PKGBUILD variables used when [[Creating Packages|creating packages]].}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Package management overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Creating Packages}}<br />
{{Article summary wiki|Custom local repository}}<br />
{{Article summary wiki|pacman Tips}}<br />
{{Article summary heading|Resources}}<br />
{{Article summary link|PKGBUILD(5) Manual Page|https://www.archlinux.org/pacman/PKGBUILD.5.html}}<br />
{{Article summary end}}<br />
<br />
A {{ic|PKGBUILD}} is an Arch Linux package build description file used when [[Creating Packages|creating packages]].<br />
<br />
Packages in Arch Linux are built using the [[makepkg]] utility and information stored in {{ic|PKGBUILD}} files. When {{ic|makepkg}} is run, it searches for a {{ic|PKGBUILD}} in the current directory and follows the instructions therein to either compile or otherwise acquire the files to build a package file ({{ic|pkgname.pkg.tar.xz}}). The resulting package contains binary files and installation instructions, readily installed with [[pacman]].<br />
<br />
==Variables==<br />
<br />
The following are variables that can be filled out in the {{ic|PKGBUILD}} file.<br />
<br />
It is common practice to define the variables in the {{ic|PKGBUILD}} in same order as given here. However, this is not mandatory, as long as correct [[Bash]] syntax is used.<br />
<br />
===pkgname===<br />
<br />
The name of the package. It should consist of '''alphanumeric characters and dashes ('-')''' and all letters should be '''lowercase'''. For the sake of consistency, {{ic|pkgname}} should match the name of the source tarball of the software you are packaging. For instance, if the software is in {{ic|foobar-2.5.tar.gz}}, the {{ic|pkgname}} value should be ''foobar''. The present working directory the {{ic|PKGBUILD}} file is in should also match the {{ic|pkgname}}.<br />
<br />
===pkgver===<br />
<br />
The version of the package. The value should be the same as the version released by the author of the package. It can contain letters, numbers and periods but '''CANNOT''' contain a hyphen. If the author of the package uses a hyphen in their version numbering scheme, replace it with an underscore. For instance, if the version is ''0.99-10'', it should be changed to ''0.99_10''. If the {{ic|pkgver}} variable is used later in the PKGBUILD then the underscore can easily be substituted for a dash on usage e.g.:<br />
source=($pkgname-${pkgver//_/-}.tar.gz)<br />
<br />
===pkgrel===<br />
The release number of the package specific to Arch Linux. This value allows users to differentiate between consecutive builds of the same version of a package. When a new package version is first released, the '''release number starts at 1'''. As fixes and optimizations are made to the {{ic|PKGBUILD}} file, the package will be '''re-released''' and the '''release number''' will increment by 1. When a new version of the package comes out, the release number resets to 1.<br />
<br />
===epoch===<br />
<br />
An integer value, specific to Arch Linux, representing what 'lifetime' to compare version numbers against. This value allows overrides of the normal version comparison rules for packages that have inconsistent version numbering, require a downgrade, change numbering schemes, etc. By default, packages are assumed to have an epoch value of ''0''. Do not use this unless you know what you are doing.<br />
<br />
===pkgdesc===<br />
<br />
The description of the package. The description should be about 80 characters or less and should not include the package name in a self-referencing way. For instance, "Nedit is a text editor for X11" should be written as "A text editor for X11."<br />
<br />
===arch===<br />
<br />
An array of architectures that the {{ic|PKGBUILD}} file is known to build and work on. Currently, it should contain {{ic|i686}} and/or {{ic|x86_64}}, {{ic|<nowiki>arch=('i686' 'x86_64')</nowiki>}}. The value {{ic|any}} can also be used for architechture-independent packages.<br />
<br />
You can access the target architecture with the variable {{ic|$CARCH}} during a build, and even when defining variables. See also {{bug|16352}}. Example:<br />
<br />
<pre><br />
depends=(foobar)<br />
if test "$CARCH" == x86_64; then<br />
depends=("${depends[@]}" lib32-glibc)<br />
fi<br />
</pre><br />
<br />
===url===<br />
<br />
The URL of the official site of the software being packaged.<br />
<br />
===license===<br />
<br />
The license under which the software is distributed. A {{pkg|licenses}} package has been created in {{ic|[core]}} that stores common licenses in {{ic|/usr/share/licenses/common}}, e.g. {{ic|/usr/share/licenses/common/GPL}}. If a package is licensed under one of these licenses, the value should be set to the directory name, e.g. {{ic|<nowiki>license=('GPL')</nowiki>}}. If the appropriate license is not included in the official {{Pkg|licenses}} package, several things must be done:<br />
<br />
# The license file(s) should be included in: {{ic|/usr/share/licenses/'''pkgname'''/}}, e.g. {{ic|/usr/share/licenses/foobar/LICENSE}}.<br />
# If the source tarball does '''NOT''' contain the license details and the license is only displayed elsewhere, e.g. a website, then you need to copy the license to a file and include it.<br />
# Add {{ic|custom}} to the {{ic|license}} array. Optionally, you can replace {{ic|custom}} with {{ic|custom:name of license}}. Once a license is used in two or more packages in an official repository (including {{ic|[community]}}), it becomes a part of the {{Pkg|licenses}} package.<br />
* The [[Wikipedia:BSD License|BSD]], [[Wikipedia:MIT License|MIT]], [[Wikipedia:ZLIB license|zlib/png]] and [[Wikipedia:Python License|Python]] licenses are special cases and could not be included in the {{pkg|licenses}} package. For the sake of the {{ic|license}} array, it is treated as a common license ({{ic|<nowiki>license=('BSD')</nowiki>}}, {{ic|<nowiki>license=('MIT')</nowiki>}}, {{ic|<nowiki>license=('ZLIB')</nowiki>}} and {{ic|<nowiki>license=('Python')</nowiki>}}) but technically each one is a custom license because each one has its own copyright line. Any packages licensed under these four should have its own unique license stored in {{ic|/usr/share/licenses/'''pkgname'''}}. Some packages may not be covered by a single license. In these cases, multiple entries may be made in the license array, e.g. {{ic|<nowiki>license=('GPL' 'custom:name of license')</nowiki>}}.<br />
* Additionally, the (L)GPL has many versions and permutations of those versions. For (L)GPL software, the convention is:<br />
** (L)GPL - (L)GPLv2 or any later version<br />
** (L)GPL2 - (L)GPL2 only<br />
** (L)GPL3 - (L)GPL3 or any later version<br />
* If after researching the issue no license can be determined, {{ic|PKGBUILD.proto}} suggests using {{ic|unknown}}. However, upstream should be contacted about the conditions under which the software is (and is not) available.<br />
<br />
===groups===<br />
<br />
The group the package belongs in. For instance, when you install the {{Pkg|kdebase}} package, it installs all packages that belong in the ''kde'' group.<br />
<br />
===depends===<br />
<br />
An array of package names that must be installed before this software can be run. If a software requires a minimum version of a dependency, the {{ic|1=>=}} operator should be used to point this out, e.g. {{ic|<nowiki>depends=('foobar>=1.8.0')</nowiki>}}. You do not need to list packages that your software depends on if other packages your software depends on already have those packages listed in their dependency. For instance, {{pkg|gtk2}} depends on {{pkg|glib2}} and {{pkg|glibc}}. However, {{pkg|glibc}} does not need to be listed as a dependency for {{pkg|gtk2}} because it is a dependency for {{pkg|glib2}}.<br />
<br />
===makedepends===<br />
<br />
An array of package names that must be installed to build the software but unnecessary for using the software after installation. You can specify the minimum version dependency of the packages in the same format as the {{ic|depends}} array.<br />
<br />
{{Warning|The group "base-devel" is assumed already installed when building with makepkg . Members of "base-devel" '''should not''' be included in {{ic|makedepends}} arrays.}}<br />
<br />
===checkdepends===<br />
<br />
An array of packages this package depends on to run its test suite but are not needed at runtime. Packages in this list follow the same format as depends. These dependencies are only considered when the {{ic|check()}} function is present and is to be run by makepkg.<br />
<br />
===optdepends===<br />
<br />
An array of package names that are not needed for the software to function but provides additional features. A short description of what each package provides should also be noted. An {{ic|optdepends}} may look like this:<br />
optdepends=('cups: printing support'<br />
'sane: scanners support'<br />
'libgphoto2: digital cameras support'<br />
'alsa-lib: sound support'<br />
'giflib: GIF images support'<br />
'libjpeg: JPEG images support'<br />
'libpng: PNG images support')<br />
<br />
===provides===<br />
<br />
An array of package names that this package provides the features of (or a virtual package such as ''cron'' or ''sh''). If you use this variable, you should add the version ({{ic|pkgver}} and perhaps the {{ic|pkgrel}}) that this package will provide if dependencies may be affected by it. For instance, if you are providing a modified ''qt'' package named ''qt-foobar'' version 3.3.8 which provides ''qt'' then the {{ic|provides}} array should look like {{ic|<nowiki>provides=('qt=3.3.8')</nowiki>}}. Putting {{ic|<nowiki>provides=('qt')</nowiki>}} will cause to fail those dependencies that require a specific version of ''qt''. Do not add {{ic|pkgname}} to your provides array, this is done automatically.<br />
<br />
===conflicts===<br />
<br />
An array of package names that may cause problems with this package if installed. You can also specify the version properties of the conflicting packages in the same format as the {{ic|depends}} array.<br />
<br />
===replaces===<br />
<br />
An array of obsolete package names that are replaced by this package, e.g. {{ic|<nowiki>replaces=('ethereal')</nowiki>}} for the {{pkg|wireshark}} package. After syncing with {{ic|pacman -Sy}}, it will immediately replace an installed package upon encountering another package with the matching {{ic|replaces}} in the repositories. If you are providing an alternate version of an already existing package, use the {{ic|conflicts}} variable which is only evaluated when actually installing the conflicting package.<br />
<br />
===backup===<br />
<br />
An array of files to be backed up as {{ic|file.pacsave}} when the package is removed. This is commonly used for packages placing configuration files in {{ic|/etc}}. The file paths in this array should be relative paths (e.g. {{ic|etc/pacman.conf}}) not absolute paths (e.g. {{ic|/etc/pacman.conf}}).<br />
<br />
===options===<br />
<br />
This array allows you to override some of the default behavior of {{ic|makepkg}}. To set an option, include the option name in the array. To reverse the default behavior, place an '''{{ic|!}}''' at the front of the option. The following options may be placed in the array:<br />
<br />
* '''''strip''''' - Strips symbols from binaries and libraries.<br />
* '''''docs''''' - Save {{ic|/doc}} directories.<br />
* '''''libtool''''' - Leave ''libtool'' ({{ic|.la}}) files in packages.<br />
* '''''emptydirs''''' - Leave empty directories in packages.<br />
* '''''zipman''''' - Compress ''man'' and ''info'' pages with ''gzip''.<br />
* '''''ccache''''' - Allow the use of {{ic|ccache}} during build. More useful in its negative form {{ic|!ccache}} with select packages that have problems building with {{ic|ccache}}.<br />
* '''''distcc''''' - Allow the use of {{ic|distcc}} during build. More useful in its negative form {{ic|!distcc}} with select packages that have problems building with {{ic|distcc}}.<br />
* '''''buildflags''''' - Allow the use of user-specific {{ic|buildflags}} (CFLAGS, CXXFLAGS, LDFLAGS) during build. More useful in its negative form {{ic|!buildflags}} with select packages that have problems building with custom {{ic|buildflags}}.<br />
* '''''makeflags''''' - Allow the use of user-specific {{ic|makeflags}} during build. More useful in its negative form {{ic|!makeflags}} with select packages that have problems building with custom {{ic|makeflags}}.<br />
<br />
===install===<br />
<br />
The name of the {{ic|.install}} script to be included in the package. ''pacman'' has the ability to store and execute a package-specific script when it installs, removes or upgrades a package. The script contains the following functions which run at different times:<br />
<br />
* '''''pre_install''''' - The script is run right before files are extracted. One argument is passed: new package version.<br />
* '''''post_install''''' - The script is run right after files are extracted. One argument is passed: new package version.<br />
* '''''pre_upgrade''''' - The script is run right before files are extracted. Two arguments are passed in the following order: new package version, old package version.<br />
* '''''post_upgrade''''' - The script is run after files are extracted. Two arguments are passed in the following order: new package version, old package version.<br />
* '''''pre_remove''''' - The script is run right before files are removed. One argument is passed: old package version.<br />
* '''''post_remove''''' - The script is run right after files are removed. One argument is passed: old package version.<br />
<br />
Each function is run chrooted inside the pacman install directory. See [https://bbs.archlinux.org/viewtopic.php?pid=913891 this thread].<br />
<br />
{{Tip|A prototype {{ic|.install}} is provided at {{ic|/usr/share/pacman/proto.install}}.}}<br />
<br />
===source===<br />
<br />
An array of files which are needed to build the package. It must contain the location of the software source, which in most cases is a full HTTP or FTP URL. The previously set variables {{ic|pkgname}} and {{ic|pkgver}} can be used effectively here (e.g. {{ic|<nowiki>source=(http://example.com/$pkgname-$pkgver.tar.gz)</nowiki>}})<br />
<br />
{{Note|If you need to supply files which are not downloadable on the fly, e.g. self-made patches, you simply put those into the same directory where your {{ic|PKGBUILD}} file is in and add the filename to this array. Any paths you add here are resolved relative to the directory where the {{ic|PKGBUILD}} lies. Before the actual build process is started, all of the files referenced in this array will be downloaded or checked for existence, and {{ic|makepkg}} will not proceed if any are missing.}}<br />
<br />
{{Note|You can specify a different name for the downloaded file - if the downloaded file has a different name for some reason like the URL had a GET parameter - using the following syntax: <filename>::<fileuri>, do not include the '<' and '>' characters}}<br />
<br />
===noextract===<br />
<br />
An array of files listed under the {{ic|source}} array which should not be extracted from their archive format by {{ic|makepkg}}. This most commonly applies to certain zip files which cannot be handled by {{ic|/usr/bin/bsdtar}} because {{Pkg|libarchive}} processes all files as streams rather than random access as {{Pkg|unzip}} does. In these situations {{ic|unzip}} should be added in the {{ic|makedepends}} array and the first line of the {{ic|build()}} function should contain:<br />
cd $srcdir/$pkgname-$pkgver<br />
unzip [source].zip<br />
Note that while the {{ic|source}} array accepts URLs, {{ic|noextract}} is '''just''' the file name portion. So, for example, you would do something like this (simplified from [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/grub2&id=f054e33a0b5cbdfe7d81e91a8c4c807a9bfaa124 grub2's PKGBUILD]):<br />
source=(<nowiki>"http://ftp.archlinux.org/other/grub2/grub2_extras_lua_r20.tar.xz"</nowiki>)<br />
noextract=("grub2_extras_lua_r20.tar.xz")<br />
To extract ''nothing'', you can do something fancy like this (taken from [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/firefox-i18n&id=cb10a40aeda9b444285d1ae6959c344110b4c936 firefox-i18n]):<br />
noextract=(${source[@]##*/})<br />
Note that a more conservative Bash substitution would include quotes, or possibly even a loop that calls {{ic|basename}}. If you have read this far, you should get the idea.<br />
<br />
===md5sums===<br />
<br />
An array of MD5 checksums of the files listed in the {{ic|source}} array. Once all files in the {{ic|source}} array are available, an MD5 hash of each file will be automatically generated and compared with the values of this array in the same order they appear in the {{ic|source}} array. While the order of the source files itself does not matter, it is important that it matches the order of this array since {{ic|makepkg}} cannot guess which checksum belongs to what source file. You can generate this array quickly and easily using the command {{ic|makepkg -g}} in the directory that contains the {{ic|PKGBUILD}} file. Note that the MD5 algorithm is known to have weaknesses, so you should consider using a stronger alternative.<br />
<br />
===sha1sums===<br />
<br />
An array of SHA-1 160-bit checksums. This is an alternative to {{ic|md5sums}} described above, but it is also known to have weaknesses, so you should consider using a stronger alternative. To enable use and generation of these checksums, be sure to set up the {{ic|INTEGRITY_CHECK}} option in {{ic|/etc/makepkg.conf}}. See {{ic|man makepkg.conf}}.<br />
<br />
===sha256sums, sha384sums, sha512sums===<br />
<br />
An array of SHA-2 checksums with digest sizes 256, 384 and 512 bits respectively. These are alternatives to {{ic|md5sums}} described above and are generally believed to be stronger. To enable use and generation of these checksums, be sure to set up the {{ic|INTEGRITY_CHECK}} option in {{ic|/etc/makepkg.conf}}. See {{ic|man makepkg.conf}}.<br />
<br />
==See also==<br />
*[http://pastebin.com/MeXiLDV9 Example PKGBUILD file]<br />
*[http://seberm.pastebin.com/gP0tBqvs Example .install file]<br />
*[[Creating Packages]] for more information on creating packages<br />
*[[Custom local repository]] for information on using packages after they have been created<br />
*[[Arch Packaging Standards]] for various guidelines</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Arch_User_Repository&diff=175496Arch User Repository2011-12-22T02:23:39Z<p>Rnabioullin: /* Install the package */ Rephrased, clarified sentence.</p>
<hr />
<div>[[Category:Arch User Repository (English)]]<br />
[[Category:About Arch (English)]]<br />
[[Category:Package development (English)]]<br />
[[Category:Package management (English)]]<br />
[[Category:Arch development (English)]]<br />
{{i18n|Arch User Repository}}<br />
[[fr:AUR]]<br />
{{Article summary start}}<br />
{{Article summary text|The Arch User Repository is a collection of user-submitted PKGBUILDs that supplement software available from the official repositories. This article describes how to build ''unsupported'' software packages from the AUR.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Package management overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|AUR Helpers}}<br />
{{Article summary wiki|AUR Trusted User Guidelines}}<br />
{{Article summary heading|Resources}}<br />
{{Article summary link|AUR Web Interface|http://aur.archlinux.org}}<br />
{{Article summary link|AUR Mailing List|http://www.archlinux.org/mailman/listinfo/aur-general}}<br />
{{Article summary end}}<br />
<br />
The [[Arch User Repository]] (AUR) is a community-driven repository for Arch users. It contains package descriptions ([[PKGBUILD]]s) that allow you to compile a package from source with [[makepkg]] and then install it via [[pacman]]. The AUR was created to organize and share new packages from the community and to help expedite popular packages' inclusion into the [[#.5Bcommunity.5D|[community]]] repository. This document explains how users can access and utilize the AUR.<br />
<br />
A good number of new packages that enter the official repositories start in the AUR. In the AUR, users are able to contribute their own package builds (PKGBUILD and related files). The AUR community has the ability to vote for or against packages in the AUR. If a package becomes popular enough -- provided it has a compatible license and good packaging technique -- it may be entered into the [community] repository (directly accessible by {{ic|pacman}} or {{ic|abs}}).<br />
<br />
==Getting started==<br />
<br />
Users can search and download [[PKGBUILD]]s from the [http://aur.archlinux.org AUR Web Interface]. These PKGBUILDs can be built into installable packages using [[makepkg]], then installed using [[pacman]]. <br />
<br />
* Install "base-devel" ({{ic|pacman -S base-devel}}), because members of this group are not explicitly required by AUR packages which may not build without them (more info in [http://bbs.archlinux.org/viewtopic.php?pid=632355 this thread]).<br />
* Read the remainder of this article for more info and a short tutorial on installing AUR packages.<br />
* Visit the [http://aur.archlinux.org AUR Web Interface] to inform yourself on updates and happenings. There you will also find statistics and an up-to-date list of newest available packages available in AUR.<br />
* Glance over the [[#FAQ]] for answers to the most common questions.<br />
* You may wish to adjust {{ic|/etc/makepkg.conf}} to better optimize for your processor prior to building packages from the AUR. A significant improvement in compile times can be realized on systems with multi-core processors by adjusting the MAKEFLAGS variable. Users can also enable hardware-specific optimizations in GCC via the CFLAGS variable. See [[makepkg.conf]] for more information.<br />
<br />
==History==<br />
The following items are listed for historical purposes only. They have since been superseded by the AUR and are no longer available.<br />
<br />
At the beginning, there was {{ic|<nowiki>ftp://ftp.archlinux.org/incoming</nowiki>}}, and people contributed by simply uploading the [[PKGBUILD]], the needed supplementary files, and the built package itself to the server. The package and associated files remained there until a [[Package Maintainer]] saw the program and adopted it.<br />
<br />
Then the Trusted User Repositories were born. Certain individuals in the community were allowed to host their own repositories for anyone to use. The AUR expanded on this basis, with the aim of making it both more flexible and more usable. In fact, the AUR maintainers are still referred to as TUs (Trusted Users).<br />
<br />
==Searching==<br />
The AUR web interface can be found [http://aur.archlinux.org/ here], and an interface suitable for accessing the AUR from a script (for example) can be found [http://aur.archlinux.org/rpc.php here]<br />
<br />
Queries search package names and descriptions via a MySQL LIKE comparison. This allows for more flexible search criteria (e.g. try searching for 'tool%like%grep' instead of 'tool like grep'). If you need to search for a description that contains '%', escape it with '\%'.<br />
<br />
==Installing packages==<br />
Installing packages from the AUR (aka the [unsupported] repository) is a relatively simple process. Essentially:<br />
# Acquire the tarball which contains the [[PKGBUILD]] and possibly other required files<br />
# Extract the tarball (preferably in a folder set aside just for builds from the AUR)<br />
# Run [[makepkg]] in the directory where the files are saved ("makepkg -s" will auto-resolve dependencies with [[pacman]])<br />
# Install the resulting package with [[pacman]]<br />
<br />
# pacman -U /path/to/pkg.tar.xz<br />
<br />
[[AUR Helpers]] add seamless access to the AUR. They vary in their features, but can ease in searching, fetching, building, and installing from PKGBUILDs found in the AUR. All of these scripts can be found in UNSUPPORTED. <br />
<br />
{{Note|There is not and will never be an ''official'' mechanism for installing build material from UNSUPPORTED. All users should be familiar with the build process.}}<br />
<br />
What follows is a detailed example of installation of a package called "foo".<br />
<br />
===Prerequisites===<br />
First ensure that the necessary tools are installed. The package group "base-devel" should be sufficient; it includes ''make'' and other tools needed for compiling from source.<br />
<br />
{{Warning|Packages in the AUR assume "base-devel" is installed, and will not list members of this group as dependencies even if the package cannot be built without them. Please ensure this group is installed before complaining about failed builds.}}<br />
<br />
# pacman -S base-devel<br />
<br />
Next choose an appropriate build directory. A build directory is simply a directory where the package will be made or "built" and can be any directory. Examples of commonly used directories are:<br />
<br />
~/builds<br />
<br />
or if using ABS (the [[Arch Build System]]):<br />
<br />
/var/abs/local<br />
<br />
For more information on ABS read the [[Arch Build System]] article. The example will use {{ic|~/builds}} as the build directory.<br />
<br />
===Acquire build files===<br />
Locate the package in the AUR. This is done using the search feature (text field at the top of the [http://aur.archlinux.org/ AUR home page]). Clicking the application's name in the search list brings up an information page on the package. Read through the description to confirm that this is the desired package, note when the package was last updated, and read any comments.<br />
<br />
Download the necessary build files. From the package's information page download the build files by clicking the "Tarball" link on the left-hand side near the end of the package details. This file should be saved to the build directory or otherwise copied to the directory after downloading. In this example, the file is called "foo.tar.gz" (standard format is <pkgname>.tar.gz, if it has been properly submitted).<br />
<br />
===Build the package===<br />
Extract the tarball. Change directories to the build directory if not already there and extract the build files.<br />
<br />
$ cd ~/builds<br />
$ tar -xvzf foo.tar.gz<br />
<br />
This should create a new directory called "foo" in the build directory.<br />
<br />
{{Warning|'''Carefully check all files.''' {{ic|cd}} to the newly created directory and carefully check the {{ic|PKGBUILD}} and any {{ic|.install}} file for malicious commands. {{ic|[[PKGBUILD]]}}s are bash scripts containing functions to be executed by {{ic|makepkg}}: these functions can contain ''any'' valid commands or bash syntax, so it is totally possible for a {{ic|PKGBUILD}} to contain dangerous commands through malice or ignorance on the part of the author. Since {{ic|makepkg}} uses fakeroot (and should never be run as root), there is some level of protection but you should never count on it. If in doubt, do not build the package and seek advice on the forums or mailing list.}}<br />
<br />
$ cd foo<br />
$ nano PKGBUILD<br />
$ nano foo.install<br />
<br />
Make the package. After manually confirming the integrity of the files, run [[makepkg]] as a normal user in the build directory.<br />
<br />
$ makepkg -s<br />
<br />
The {{ic|-s}} switch will use [[sudo]] to install any needed dependencies. If the use of sudo is undesirable, manually install required dependencies beforehand and exclude the {{ic|-s}} in the above command.<br />
<br />
===Install the package===<br />
Install the package using [[pacman]]. A tarball should have been created named:<br />
<br />
<application name>-<application version number>-<package revision number>-<architecture>.pkg.tar.xz<br />
<br />
This package can be installed using [[pacman]]'s "upgrade" command:<br />
<br />
# pacman -U foo-0.1-1-i686.pkg.tar.xz <br />
<br />
These manually-installed packages are called foreign packages - packages which have not originated from any repository known to pacman. To list all foreign packages:<br />
$ pacman -Qm <br />
<br />
{{Note|The above example is only a brief summary of the package building process. A visit to the [[makepkg]] and [[ABS]] pages will provide more detail and is highly recommended (particularly for first-time users).}}<br />
<br />
==Feedback==<br />
The [http://aur.archlinux.org AUR Web Interface] has a comments facility that allows users to provide suggestions and feedback on improvements to the PKGBUILD contributor. Avoid pasting patches or PKGBUILDs into the comments section: they quickly become obsolete and just end up needlessly taking up lots of space. Instead email those files to the maintainer, or even use a [[pastebin Clients|pastebin]].<br />
<br />
One of the easiest activities for '''all''' Arch users is to browse the AUR and '''vote''' for their favourite packages using the online interface. All packages are eligible for adoption by a TU for inclusion in [community], and the vote count is one of the considerations in that process; it is in everyone's interest to vote!<br />
<br />
==Sharing packages==<br />
The user plays an essential role in the AUR, which cannot fulfill its potential without the support, involvement, and contribution of the wider user community. The life-cycle of an AUR package starts and ends with the user and requires the user to contribute in several ways.<br />
<br />
Users can '''share''' [[PKGBUILD]]s using the UNSUPPORTED area in the AUR. UNSUPPORTED does not contain any binary packages but allows users to upload PKGBUILDs that can be downloaded by others. These PKGBUILDs are completely unofficial and have not been thoroughly vetted, so they should be used at your own risk.<br />
<br />
===Submitting packages===<br />
After logging in to the AUR web interface, a user can [https://aur.archlinux.org/pkgsubmit.php submit] a gzipped tarball ({{ic|.tar.gz}}) of a directory containing build files for a package. The directory inside the tarball should contain a [[PKGBUILD]], any {{ic|.install}} files, patches, etc. (ABSOLUTELY no binaries). Examples of what such a directory should look like can be seen inside {{ic|/var/abs}} if the [[Arch Build System]] was installed.<br />
<br />
The tarball can be created with the following command:<br />
$ makepkg --source <br />
<br />
Note that this is a gzipped tarball; assuming you are uploading a package called ''libfoo'', when you create the file it should look similar to this:<br />
<br />
# List contents of tarball.<br />
$ tar tf libfoo-0.1-1.src.tar.gz<br />
libfoo/<br />
libfoo/PKGBUILD<br />
libfoo/libfoo.install<br />
<br />
When submitting a package, observe the following rules: <br />
* Check [core], [extra], and [community] for the package. If it is inside any of those repositories in ANY form, DO NOT submit the package (if the current package is broken or is lacking an included feature then please file a bug report in [https://bugs.archlinux.org/ FlySpray]).<br />
* Check the AUR for the package. If it is currently maintained, changes can be submitted in a comment for the maintainer's attention. If it is unmaintained, the package can be adopted and updated as required.<br />
* Verify carefully that what you are uploading is correct. All contributors must read and adhere to the [[Arch Packaging Standards]] when writing PKGBUILDs. This is essential to the smooth running and general success of the AUR. Remember that you are not going to earn any credit or respect from your peers by wasting their time with a bad PKGBUILD.<br />
* Packages that contain binaries or that are very poorly written may be deleted without warning.<br />
* If you are unsure about the package (or the build/submission process) in any way, submit the PKGBUILD to the [https://mailman.archlinux.org/mailman/listinfo/ AUR Mailing List] or the [https://bbs.archlinux.org/viewforum.php?id=4 AUR boards] on the forum for public review before adding it to the AUR.<br />
* Make sure the package is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission.<br />
* Gain some experience before submitting packages. Build a few packages to learn the process and then submit.<br />
* If you submit a {{ic|package.tar.gz}} with a file named '{{ic|package}}' in it you will get an error: 'Could not change to directory {{ic|/home/aur/unsupported/package/package}}'. To resolve this, rename the file named '{{ic|package}}' to something else, for example, '{{ic|package.rc}}'. When it is installed in the {{ic|pkg}} directory you may rename it back to '{{ic|package}}'.<br />
<br />
===Maintaining packages===<br />
* If you maintain a package and want to update the PKGBUILD for your package just resubmit it.<br />
* Check for feedback and comments from other users and try to incorporate any improvements they suggest; consider it a learning process!<br />
* Please DO NOT just submit and forget about packages! While in UNSUPPORTED, it is the user's job to maintain the package by checking for updates and improving the PKGBUILD.<br />
* If you do not want to continue to maintain the package for some reason, {{ic|disown}} the package using the AUR web interface and/or post a message to the AUR Mailing List.<br />
<br />
===Other requests===<br />
* Disownment requests and removal requests go to the aur-general mailing list for TUs and other users to decide upon.<br />
* '''Include package name and URL to AUR page''', preferably with a footnote [1].<br />
* Disownment requests will be granted two weeks after the current maintainer has been contacted by email and did not react.<br />
* '''Package merging has been implemented''', users still have to resubmit a package under a new name and may request merging of the old version's comments and votes on the mailing list<br />
* Removal requests require the following information:<br />
** Package name and URL to AUR page<br />
** Reason for deletion, at least a short note <br> '''Notice:''' A package's comments does not sufficiently point out the reasons why a package is up for deletion. Because as soon as a TU takes action, the only place where such information can be obtained is the aur-general mailing list.<br />
** Include supporting details, like when a package is provided by another package, if you are the maintainer yourself, it's renamed and the original owner agreed, etc.<br />
<br />
Removal requests can be disapproved, in which case you'll likely be advised to disown the package for a future packager's reference.<br />
<br />
==[community]==<br />
The [community] repository, maintained by [[Trusted Users]], contains the most popular packages from the AUR. It is enabled by default in {{ic|/etc/pacman.conf}}. If [community] has been disabled or removed, it can be enabled by uncommenting or adding these two lines: <br />
<br />
{{hc|/etc/pacman.conf|<nowiki><br />
...<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
...<br />
</nowiki>}}<br />
<br />
[community], unlike the AUR, contains binary packages that can be installed directly with [[pacman]] and the build files can also be accessed with the [[Arch Build System|ABS]]. Some of these packages may eventually make the transition to the [core] or [extra] repositories as the developers consider them crucial to the distribution.<br />
<br />
Users can also access the [community] build files by editing {{ic|/etc/abs.conf}} and enabling the [community] repository in the {{ic|REPOS}} array.<br />
<br />
==Git Repo==<br />
A Git Repo of the AUR is maintained by Thomas Dziedzic providing package history among other things. It is updated at least once a day. To clone the repository (several hundred MB):<br />
<br />
$ git clone git://pkgbuild.com/aur.git<br />
<br />
[http://pkgbuild.com/git/aur.git/ Web interface], [http://pkgbuild.com/~td123/readme Readme], [http://bbs.archlinux.org/viewtopic.php?id=113099 Forum thread]<br />
<br />
==FAQ==<br />
<br />
{{FAQ<br />
|question=What is the AUR?<br />
|answer=The AUR (Arch User Repository) is a place where the Arch Linux community can upload [[PKGBUILD]]s of applications, libraries, etc., and share them with the entire community. Fellow users can then vote for their favorites to be moved into the [community] repository to be shared with Arch Linux users in binary form.}}<br />
<br />
{{FAQ<br />
|question=What kind of packages are permitted on the AUR?<br />
|answer=The packages on the AUR are merely "build scripts", i.e recipes to build binaries for pacman. For most cases, everything is permitted, as long as you are in compliance with the licensing terms of the software. For other cases, where it is mentioned that "you may not link" to downloads, i.e contents that are not redistributable, you may only use the file name itself as the source. This means and requires users to already have the restricted source in the build directory prior to building the package. Piracy is frowned upon, so "warez" is absolutely not permitted. When in doubt, ask.}}<br />
<br />
{{FAQ<br />
|question=What is a TU?<br />
|answer=A [[AUR Trusted User Guidelines|TU (Trusted User)]] is a person who is chosen to oversee AUR and the [community] repository. They're the ones who maintain popular PKGBUILDs in [community], and overall keep the AUR running.}}<br />
<br />
{{FAQ<br />
|question=What's the difference between [unsupported] and [community]?<br />
|answer=[unsupported] is where all PKGBUILDs that users submit are stored, and must be built manually with [[makepkg]]. When PKGBUILDs receive enough votes, they are moved into the [community] repository, where the TUs maintain binary packages that can be installed with [[pacman]].}}<br />
<br />
{{FAQ<br />
|question=How many votes does it take to get a PKGBUILD into [community]?<br />
|answer=Usually, at least 10 votes are required for something to move into [community]. However, if a TU wants to support a package, it will often be found in the repository.}}<br />
<br />
{{FAQ<br />
|question=How do I make a PKGBUILD?<br />
|answer=The best resource is [[Creating Packages]]. Remember to look in AUR before creating the PKGBUILD as to not duplicate efforts.}}<br />
<br />
{{FAQ<br />
|question=I'm trying to do {{ic|pacman -S foo}}; it isn't working but I know it's in [community]<br />
|answer=You probably haven't enabled [community] in your {{ic|/etc/pacman.conf}}. Just uncomment the relevant lines.<br />
If [community] is enabled in your {{ic|/etc/pacman.conf}} try running {{ic|pacman -S -y}} first to synchronize the pkgcache before trying your package again.}}<br />
<br />
{{FAQ<br />
|question=Foo in AUR is outdated; what do I do?<br />
|answer=For starters, you can flag packages out-of-date. If it stays out-of-date for an extended amount of time, the best thing to do is email the maintainer. If there is no response from the maintainer, you could mail to the aur-general mailing list to have a TU orphan the PKGBUILD if you're willing to maintain it yourself.}}<br />
<br />
{{FAQ<br />
|question=I have a PKGBUILD I would like to submit; can someone check it to see if there are any errors?<br />
|answer=If you would like to have your PKGBUILD critiqued, post it on the aur-general mailing list to get feedback from the TUs and fellow AUR members. You could also get help from the [[ArchChannel|IRC channel]], #archlinux on irc.freenode.net. You can also<br />
use [[namcap]] to check your PKGBUILD and the resulting package for errors.}}<br />
<br />
{{FAQ<br />
|question=Foo in AUR doesn't compile when I do {{ic|makepkg}}; what should I do?<br />
|answer=You are probably missing something trivial.<br />
<br />
# Run {{ic|pacman -Syyu}} before compiling anything with {{ic|makepkg}} as the problem may be that your system is not up-to-date.<br />
# Ensure you have both "base" and "base-devel" groups installed.<br />
# Try using the "{{ic|-s}}" option with {{ic|makepkg}} to check and install all the dependencies needed before starting the build process.<br />
<br />
The reason might not be trivial after all. Custom CFLAGS, LDFLAGS and MAKEFLAGS can cause failures. It's also possible that the PKGBUILD is broken for everyone. If you can't figure it out on your own, just report it to the maintainer.}}<br />
<br />
{{FAQ<br />
|question=How can I speed up repeated build processes?<br />
|answer=If you frequently compile code that uses gcc - say, a git or SVN package - you may find [[ccache]], short for "compiler cache", useful.}}<br />
<br />
{{FAQ<br />
|question=How do I access unsupported packages?<br />
|answer=See [[#Installing packages]]}}<br />
<br />
{{FAQ<br />
|question=How can I upload to AUR without using the web interface?<br />
|answer=You can use [https://aur.archlinux.org/packages.php?ID=23393 aurploader] or [https://aur.archlinux.org/packages.php?ID=37216 burp] -- both with command-line interfaces.}}</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=User:Rnabioullin&diff=170225User:Rnabioullin2011-11-16T04:27:29Z<p>Rnabioullin: Added IRC contact info</p>
<hr />
<div>IRC Nick (Freenode): rrn</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Microsoft_Compiled_HTML_Help_(CHM)&diff=170224Microsoft Compiled HTML Help (CHM)2011-11-16T04:20:00Z<p>Rnabioullin: Created new stub</p>
<hr />
<div>[[Category: Software (English)]]<br />
{{Stub}}<br />
<br />
==Viewers==<br />
===GnoCHM===<br />
[[Gnochm]]<br />
==Utilities==<br />
===chmlib===<br />
chmlib<br />
==Tips and tricks==<br />
===Extract (to HTML files)===<br />
{{Cli|$ extract_chmLib ebook.chm ebook/}}</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Gnochm&diff=170219Gnochm2011-11-16T03:20:12Z<p>Rnabioullin: Removed FS category (program is not directly related to FSs)</p>
<hr />
<div>{{stub}}<br />
== Overview ==<br />
Gnochm is a chm file viewer desinged to intergrate with gnome2 <br />
<br />
Total installed size is about 5MB - 4.5MB<br />
<br />
Install with<br />
# pacman -S gnochm<br />
<br />
== Features ==<br />
<br />
* Text search<br />
* Bookmarks<br />
* Support for HTTP links<br />
* Support for multiple languages<br />
* Display HTML source</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Udev&diff=166049Udev2011-10-15T19:44:26Z<p>Rnabioullin: Added mount point deletion info</p>
<hr />
<div>[[Category:Hardware detection and troubleshooting (English)]]<br />
[[Category:Auto-mounting (English)]]<br />
{{i18n|Udev}}<br />
{{Lowercase title}}<br />
<br />
'''udev''' replaces the functionality of both {{Codeline|hotplug}} and {{Codeline|hwdetect}}.<br />
<br />
''"udev is the device manager for the Linux kernel. Primarily, it manages device nodes in {{Filename|/dev}}. It is the successor of devfs and hotplug, which means that it handles the {{Filename|/dev}} directory and all user space actions when adding/removing devices, including firmware load."'' Source: [[Wikipedia:Udev]]<br />
<br />
udev loads kernel modules by utilizing coding parallelism to provide a potential performance advantage versus loading these modules serially. The modules are therefore loaded asynchronously. The inherent disadvantage of this method is that udev does not always load modules in the same order on each boot. If the machine has multiple block devices, this may manifest itself in the form of device nodes changing designations randomly. For example, if the machine has two hard drives, /dev/sda may randomly become /dev/sdb. See below for more info on this.<br />
<br />
==About udev rules==<br />
udev rules written by the administrator go in {{Filename|/etc/udev/rules.d/}}, their file name has to end with {{Filename|.rules}}. The udev rules shipped with various packages are found in {{Filename|/lib/udev/rules.d/}}. If there are two files by the same name under /lib and /etc, the ones in /etc take precedence.<br />
<br />
If you want to learn how to write udev rules see [http://www.reactivated.net/writing_udev_rules.html Writing udev rules].<br />
<br />
To get a list of all the attributes of a device you can use to write rules:<br />
# udevadm info -a -n [device name]<br />
<br />
Replace [device name] with the device present in the system, such as '/dev/sda' or '/dev/ttyUSB0'.<br />
<br />
Udev automatically detects changes to rule files, so changes take effect immediately without requiring udev to be restarted. However, the rules are not re-triggered automatically on already existing devices, so hotpluggable devices, such as USB devices, will probably have to be reconnected for the new rules to take effect.<br />
<br />
== Tips & Tricks ==<br />
=== UDisks ===<br />
Simply install UDisks:<br />
pacman -S udisks<br />
and all your media should be auto mounted in GNOME and KDE SC 4.6. There is no need for any additional rules this way.<br />
As an extra bonus you can remove HAL if you were only using that for auto mounting purposes.<br />
<br />
==== Automounting UDisks Wrappers ====<br />
A UDisks wrapper has the advantage of being very easy to install and needing no (or minimal) configuration. The wrapper will automatically mount things like CDs and flash drives.<br />
<br />
* [http://igurublog.wordpress.com/downloads/script-devmon/ devmon] - devmon ([http://aur.archlinux.org/packages.php?ID=45842 AUR]) is a configuration-less bash wrapper script for udisks which automounts optical discs and removable drives. It can also selectively autostart apps or execute commands after mounting, ignore specified devices and volume labels, and unmount removable drives. <br />
* [[udiskie]] - Written in Python. Allows auto mount and unmount by any user.<br />
* [http://aur.archlinux.org/packages.php?ID=38723 udisksevt] - Written in Haskell. Allows auto mount by any user. Designed to be integrated with [http://aur.archlinux.org/packages.php?ID=32005 traydevice].<br />
* The [http://aur.archlinux.org/packages.php?ID=46572 udisksvm bash script] uses udisks and [http://aur.archlinux.org/packages.php?ID=32005 Traydevice] to automount removable media and to control in GUI, with mouse clicks in systray, the un-mounting and re-mounting of disks or the ejection of optical disks.<br />
<br />
==== UDisks Shell Functions ====<br />
While UDisks includes a simple method of (un)mounting devices via command-line, it can be tiresome to type the commands out each time. These shell functions will generally shorten and ease command-line usage.<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=109307 udisks_functions] - Written for Bash.<br />
* [https://bbs.archlinux.org/viewtopic.php?id=117674 bashmount] - bashmount [http://aur.archlinux.org/packages.php?ID=48524 (AUR)] is a menu-driven bash script with a configuration file that makes it easy to configure and extend.<br />
<br />
=== Auto mounting USB devices ===<br />
{{Note|In the following rules the mount options are defined as {{Codeline|<nowiki>ENV{mount_options}="relatime"</nowiki>}}, see {{Codeline|man mount}} (and possibly {{Codeline|man ntfs-3g}}) for all available options and [[Maximizing Performance#Mount options]] for performance-related options.}}<br />
{{Note|The {{Codeline|users}} mount option will '''not''' allow users to unmount the filesystem.}}<br />
{{Tip|The {{Codeline|noexec}} mount option prevents execution of binaries on the mounted filesystem.}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present ====<br />
The following udev rule set automatically mounts devices/partitions that are represented by /dev/sd* (USB drives, external hard drives and sometimes SD cards). If a partition label is available, it mounts the device to /media/<label> and otherwise to /media/usbhd-sd* (ex: /media/usbhd-sdb1):<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Import FS infos<br />
IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
<br />
# Get a label if present, otherwise specify one<br />
ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"<br />
ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Mount the device<br />
ACTION=="add", RUN+="/bin/mkdir -p /media/%E{dir_name}", RUN+="/bin/mount -o $env{mount_options} /dev/%k /media/%E{dir_name}"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l /media/%E{dir_name}", RUN+="/bin/rmdir /media/%E{dir_name}"<br />
<br />
# Exit<br />
LABEL="media_by_label_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present; supports LUKS encryption ====<br />
Similar to the above rule set, but if the device is a LUKS-encrypted partition it will open an xterm window to ask for the passphrase (provided that xterm is installed). Also see [http://bbs.archlinux.org/viewtopic.php?pid=696239#p696239 this post] and the follow-ups.<br />
<br />
{{Note|You may need to modify the path to cryptsetup, depending on the version installed (e.g., < 1.1.1_rc2-1).}}<br />
<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z]*", GOTO="media_by_label_auto_mount_end"<br />
ACTION=="add", PROGRAM!="/sbin/blkid %N", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Do not mount devices already mounted somewhere else to avoid entries for all your local partitions in /media<br />
ACTION=="add", PROGRAM=="/bin/grep -q ' /dev/%k ' /proc/self/mountinfo", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Open LUKS partition if necessary<br />
PROGRAM=="/sbin/blkid -o value -s TYPE %N", RESULT=="crypto_LUKS", ENV{crypto}="mapper/", ENV{device}="/dev/mapper/%k"<br />
ENV{crypto}=="", ENV{device}="%N"<br />
ACTION=="add", ENV{crypto}!="", PROGRAM=="/usr/bin/xterm -display :0.0 -e 'echo Password for /dev/%k; /sbin/cryptsetup luksOpen %N %k'"<br />
ACTION=="add", ENV{crypto}!="", TEST!="/dev/mapper/%k", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="noatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", PROGRAM=="/sbin/blkid -o value -s TYPE %E{device}", RESULT=="vfat|ntfs", ENV{mount_options}="%E{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Get label if present, otherwise assign one<br />
PROGRAM=="/sbin/blkid -o value -s LABEL %E{device}", ENV{dir_name}="%c"<br />
# Use basename to correctly handle labels such as ../mnt/foo<br />
PROGRAM=="/usr/bin/basename '%E{dir_name}'", ENV{dir_name}="%c"<br />
ENV{dir_name}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
# Mount the device<br />
ACTION=="add", ENV{dir_name}!="", RUN+="/bin/mkdir -p '/media/%E{dir_name}'", RUN+="/bin/mount -o %E{mount_options} /dev/%E{crypto}%k '/media/%E{dir_name}'"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l '/media/%E{dir_name}'"<br />
ACTION=="remove", ENV{crypto}!="", RUN+="/sbin/cryptsetup luksClose %k"<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/rmdir '/media/%E{dir_name}'"<br />
<br />
# Exit<br />
LABEL="media_by_label_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present; support user un-mounting ====<br />
This is a variation on the above rule set. It uses pmount (which will need to be installed) instead of mount, allowing a non-root user to unmount udev-mounted devices, and automatically removing the mount point. The required username (here tomk) must be hard-coded in the RUN command, so this rule set may not be suitable for multi-user systems. LUKS support has also been removed from the example, but can be easily reinstated as above. You must edit the /bin/su invocation to run as the correct user for your system. Note that the mount point will remain if the device is mounted and the system, with a persistent /media, is shutdown, since rc.shutdown uses umount, which does not remove the mount point. To avoid having /media contain old mount points, one solution is to mount /media as tmpfs.<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-with-pmount.rules|content=<nowiki><br />
KERNEL!="sd[a-z]*", GOTO="media_by_label_auto_mount_end"<br />
ACTION=="add", PROGRAM!="/sbin/blkid %N", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Get label<br />
PROGRAM=="/sbin/blkid -o value -s LABEL %N", ENV{dir_name}="%c"<br />
# use basename to correctly handle labels such as ../mnt/foo<br />
PROGRAM=="/usr/bin/basename '%E{dir_name}'", ENV{dir_name}="%c"<br />
ENV{dir_name}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
ACTION=="add", ENV{dir_name}!="", RUN+="/bin/su tomk -c '/usr/bin/pmount %N %E{dir_name}'"<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/su tomk -c '/usr/bin/pumount /media/%E{dir_name}'"<br />
LABEL="media_by_label_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/mnt}}; create symbolic link under {{Filename|/media}} ====<br />
The following rule set does not make use of partition labels; instead it mounts devices as usbhd-sdXY under the /mnt directory (ex: /mnt/usbhd-sdb1) and creates a symbolic link under /media.<br />
{{File|name=/etc/udev/rules.d/11-mnt-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z][0-9]", GOTO="mnt_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Mount under /mnt and create the symbolic link in /media <br />
ACTION=="add", RUN+="/bin/mount -o $env{mount_options} /dev/%k /mnt/usbhd-%k", RUN+="/bin/ln -s /mnt/usbhd-%k /media/usbhd-%k"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", RUN+="/bin/rm -f /media/usbhd-%k", RUN+="/bin/umount -l /mnt/usbhd-%k", RUN+="/bin/rmdir /mnt/usbhd-%k"<br />
<br />
# Exit<br />
LABEL="mnt_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}} ''only'' if the partition has a label ====<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-only-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_only_auto_mount_end"<br />
<br />
# Import FS infos<br />
IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
ENV{ID_FS_LABEL}=="", GOTO="media_by_label_only_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Mount the device<br />
ACTION=="add", RUN+="/bin/mkdir -p /media/$env{ID_FS_LABEL}", RUN+="/bin/mount -o $env{mount_options} /dev/%k /media/$env{ID_FS_LABEL}"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", ENV{ID_FS_LABEL}!="", RUN+="/bin/umount -l /media/$env{ID_FS_LABEL}", RUN+="/bin/rmdir /media/$env{ID_FS_LABEL}"<br />
<br />
# Exit<br />
LABEL="media_by_label_only_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present; ntfs-3g ====<br />
Yet another example, this time making use of ntfs-3g read/write drivers for NTFS filesystems:<br />
<br />
{{File|name=/etc/udev/rules.d/10-my-media-automount.rules|content=<nowiki><br />
# vim:enc=utf-8:nu:ai:si:et:ts=4:sw=4:ft=udevrules:<br />
#<br />
# /etc/udev/rules.d/10-my-media-automount.rules<br />
<br />
# start at sdb to ignore the system hard drive<br />
KERNEL!="sd[b-z]*", GOTO="my_media_automount_end"<br />
ACTION=="add", PROGRAM!="/sbin/blkid %N", GOTO="my_media_automount_end"<br />
<br />
# import some useful filesystem info as variables<br />
IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
<br />
# get the label if present, otherwise assign one based on device/partition<br />
ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"<br />
ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
# create the dir in /media and symlink it to /mnt<br />
ACTION=="add", RUN+="/bin/mkdir -p '/media/%E{dir_name}'"<br />
<br />
# global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# filesystem-specific mount options (777/666 dir/file perms for ntfs/vfat) <br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},gid=100,dmask=000,fmask=111,utf8"<br />
<br />
# automount ntfs filesystems using ntfs-3g driver<br />
ACTION=="add", ENV{ID_FS_TYPE}=="ntfs", RUN+="/bin/mount -t ntfs-3g -o %E{mount_options} /dev/%k '/media/%E{dir_name}'"<br />
# automount all other filesystems<br />
ACTION=="add", ENV{ID_FS_TYPE}!="ntfs", RUN+="/bin/mount -t auto -o %E{mount_options} /dev/%k '/media/%E{dir_name}'"<br />
<br />
# clean up after device removal<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l '/media/%E{dir_name}'", RUN+="/bin/rmdir '/media/%E{dir_name}'"<br />
<br />
# exit<br />
LABEL="my_media_automount_end"<br />
<br />
</nowiki>}}<br />
<br />
==== Mount SD cards ====<br />
The same rules as above can be used to auto-mount SD cards, you just need to replace {{Codeline|sd[a-z][0-9]}} by {{Codeline|mmcblk[0-9]p[0-9]}}:<br />
{{File|name=/etc/udev/rules.d/11-sd-cards-auto-mount.rules|content=<nowiki><br />
KERNEL!="mmcblk[0-9]p[0-9]", GOTO="sd_cards_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem specific options<br />
ACTION=="add", IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
ACTION=="add", RUN+="/bin/mkdir -p /media/sd-%k", RUN+="/bin/ln -s /media/sd-%k /mnt/sd-%k", RUN+="/bin/mount -o $env{mount_options} /dev/%k /media/sd-%k"<br />
ACTION=="remove", RUN+="/bin/umount -l /media/sd-%k", RUN+="/bin/rmdir /media/sd-%k"<br />
LABEL="sd_cards_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount CDs ====<br />
To auto mount a CD a simple [[#Automounting_UDisks_Wrappers|UDisks wrapper]] will get the job done properly.<br />
{{Note|Maybe this should be merged to the Udisks wrapper section.}}<br />
<br />
==== Accessing Firmware Programmers and USB Virtual Comm Devices ====<br />
The following ruleset will allow normal users (within the "users" group) the ability to access the [http://www.ladyada.net/make/usbtinyisp/ USBtinyISP] USB programmer for AVR microcontrollers and a generic (SiLabs [http://www.silabs.com/products/interface/usbtouart CP2102]) USB to UART adapter. Adjust the permissions accordingly. Verified as of 2010-02-11.<br />
<br />
{{File|name=/etc/udev/rules.d/50-embedded_devices.rules|content=<nowiki><br />
# USBtinyISP Programmer rules<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", GROUP="users", MODE="0666"<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0479", GROUP="users", MODE="0666"<br />
# USBasp Programmer rules http://www.fischl.de/usbasp/<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="users", MODE="0666"<br />
<br />
# Mdfly.com Generic (SiLabs CP2102) 3.3v/5v USB VComm adapter<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", GROUP="users", MODE="0666"<br />
</nowiki>}}<br />
<br />
=== Execute on USB Insert ===<br />
<br />
See [[Execute_on_usb_insert|execute on usb insert]] article or the [http://igurublog.wordpress.com/downloads/script-devmon/ devmon wrapper script].<br />
<br />
=== Mount internal drives as a normal user ===<br />
<br />
If you want to mount an internal drive in KDE or Gnome (maybe on other Desktop Environments too) as a normal user (without the need to type your superuser password), you just have to create the following file in [[PolicyKit]] Local Authority:<br />
{{File|name=/etc/polkit-1/localauthority/50-local.d/50-filesystem-mount-system-internal.pkla|content=<nowiki><br />
[Mount a system-internal device]<br />
Identity=*<br />
Action=org.freedesktop.udisks.filesystem-mount-system-internal<br />
ResultActive=yes<br />
</nowiki>}}<br />
<br />
=== Mark internal SATA-Ports as eSATA-Ports ===<br />
<br />
If you connected a eSATA bay or an other eSATA adapter the system will still recognize this disk as an internal SATA drive. Gnome and KDE will ask you for your root password all the time. The following rule will mark the specified SATA-Port as an external eSATA-Port. With that, a normal Gnome user can connect their eSATA drives to that port like a USB drive, without any root password and so on.<br />
<br />
{{File|name=/etc/udev/rules.d/10-esata.rules|content=<nowiki><br />
DEVPATH=="/devices/pci0000:00/0000:00:1f.2/host4/*", ENV{UDISKS_SYSTEM_INTERNAL}="0"<br />
</nowiki>}}<br />
<br />
{{Note| The DEVPATH can be found after connection the eSata drive with the following command (replace sdb to your needs):<br />
<br />
# find /sys/devices/ -name sdb<br />
/sys/devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sdb<br />
<br />
}}<br />
<br />
==Troubleshooting==<br />
<br />
=== Blacklisting Modules ===<br />
In rare cases, udev can make mistakes and load the wrong modules. To prevent it from doing this, you can blacklist modules. Once blacklisted, udev will never load that module. See [[blacklisting]]. Not at boot-time ''or'' later on when a hotplug event is received (eg, you plug in your USB flash drive).<br />
<br />
=== udevd hangs at boot ===<br />
After migrating to LDAP or updating an LDAP-backed system udevd can hang at boot at the message "Starting UDev Daemon". This is usually caused by udevd trying to look up a name from LDAP but failing, because the network is not up yet. The solution is to ensure that all system group names are present locally.<br />
<br />
Extract the group names referenced in udev rules and the group names actually present on the system:<br />
<br />
# fgrep -r GROUP /etc/udev/rules.d/ /lib/udev/rules.d | perl -nle '/GROUP\s*=\s*"(.*?)"/ && print $1;' | sort | uniq > udev_groups<br />
# cut -f1 -d: /etc/gshadow /etc/group | sort | uniq > present_groups<br />
<br />
To see the differences, do a side-by-side diff:<br />
<br />
# diff -y present_groups udev_groups<br />
...<br />
network <<br />
nobody <<br />
ntp <<br />
optical optical<br />
power | pcscd<br />
rfkill <<br />
root root<br />
scanner scanner<br />
smmsp <<br />
storage storage<br />
...<br />
<br />
In this case, the pcscd group is for some reason not present in the system. Add the missing groups:<br />
<br />
# groupadd pcscd<br />
<br />
Also, make sure local resources are looked up before resorting to LDAP. {{Filename|/etc/nsswitch.conf}} should contain the line<br />
<br />
group: files ldap<br />
<br />
=== Known Problems with Hardware ===<br />
====BusLogic devices can be broken and will cause a freeze during startup====<br />
This is a kernel bug and no fix has been provided yet.<br />
====Some devices, that should be treated as removable, are not====<br />
Create a custom udev rule, setting UDISKS_SYSTEM_INTERNAL=0. For more details, see the manpage of udisks.<br />
<br />
=== Known Problems with Auto-Loading ===<br />
==== CPU frequency modules ====<br />
The current detection method for the various CPU frequency controllers is inadequate, so this has been omitted from the auto-loading process for the time being. To use [[CPU Frequency Scaling]], load the proper module explicitly in your {{Codeline|MODULES}} array in {{Filename|/etc/rc.conf}}. Further reading: [[rc.conf]].<br />
<br />
====Sound Problems or Some Modules Not Loaded Automatically====<br />
Some users have traced this problem to old entries in {{Filename|/etc/modprobe.d/sound.conf}}. Try cleaning that file out and trying again.<br />
{{Note|Since {{Codeline|udev>&#61;171}}, the OSS emulation modules ({{Codeline|snd_seq_oss, snd_pcm_oss, snd_mixer_oss}}) are not automatically loaded by default.}}<br />
<br />
==== Mixed Up Devices, Sound/Network Cards Changing Order Each Boot ====<br />
Because udev loads all modules asynchronously, they are initialized in a different order. This can result in devices randomly switching names. For example, with two network cards, you may notice a switching of designations between {{Codeline|eth0}} and {{Codeline|eth1}}.<br />
<br />
Arch Linux provides the advantage of specifying the module load order by listing the modules in the {{Codeline|MODULES}} array in {{Filename|[[rc.conf]]}}. Modules in this array are loaded before udev begins auto-loading, so you have full control over the load order.<br />
<br />
# Always load 8139too before e100<br />
MODULES=(8139too e100)<br />
<br />
Another method for network card ordering is to use the udev-sanctioned method of statically-naming each interface. Create the following file to bind the MAC address of each of your cards to a certain interface name:<br />
{{File|name=/etc/udev/rules.d/10-network.rules|content=<nowiki><br />
SUBSYSTEM=="net", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="lan0"<br />
SUBSYSTEM=="net", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="wlan0"<br />
</nowiki>}}<br />
<br />
A couple things to note:<br />
* To get the MAC address of each card, use this command: {{Codeline|<nowiki>udevadm info -a -p /sys/class/net/<yourdevice> | grep address | tr [A-Z] [a-z]</nowiki>}}<br />
* Make sure to use the lower-case hex values in your udev rules. It doesn't like upper-case.<br />
* Some people have problems naming their interfaces after the old style: eth0, eth1, etc. Try something like "lan" or "wlan" if you experience this problem.<br />
<br />
Don't forget to update your {{Filename|/etc/rc.conf}} and other configuration files using the old ethX notation!<br />
<br />
<br />
Other methods for setting network interface names are described in the [[Configuring Network#Interface names varying]] wiki entry.<br />
<br />
=== Known Problems for Custom Kernel Users ===<br />
==== Udev doesn't start at all ====<br />
Make sure you have a kernel version later than or equal to 2.6.32. Earlier kernels do not have the necessary uevent stuff that udev needs for auto-loading.<br />
<br />
=== IDE CD/DVD-drive support ===<br />
Starting with version 170, udev doesn't support CD-ROM/DVD-ROM drives, which are loaded as traditional IDE drives with the {{Codeline|ide_cd_mod}} module and show up as {{Filename|/dev/hd*}}. The drive remains usable for tools which access the hardware directly, like cdparanoia, but is invisible for higher userspace programs, like KDE.<br />
<br />
A cause for the loading of the ide_cd_mod module prior to others, like sr_mod, could be e.g. that you have for some reason the module piix loaded with your initramfs. In that case you can just replace it with ata_piix in your {{Filename|/etc/mkinitcpio.conf}}.<br />
<br />
==Other Resources==<br />
* [http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html Udev Homepage]<br />
* [http://www.linux.com/news/hardware/peripherals/180950-udev An Introduction to Udev]<br />
* [http://vger.kernel.org/vger-lists.html#linux-hotplug Udev mailing list information]</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Bash&diff=163976Bash2011-10-04T18:12:35Z<p>Rnabioullin: Elucidated previous edit</p>
<hr />
<div>[[Category:Command shells (English)]] <br />
{{i18n|Bash}}<br />
{{Article summary start}}<br />
{{Article summary text|Improving Bash over its default capabilities.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Color Bash Prompt}}<br />
{{Article summary wiki|Core Utilities}}<br />
{{Article summary wiki|Zsh}}<br />
{{Article summary wiki|Heirloom}}<br />
{{Article summary end}}<br />
'''Bash''' (Bourne-again Shell) is a shell/programming language by the [[GNU Project]]. Its name is a homaging reference to its predecessor: the long-deprecated Bourne shell. Bash can be run on most UNIX-like operating systems, including GNU/Linux. Arch copiously uses Bash throughout its init-scripts.<br />
<br />
==Configuration==<br />
* {{Filename|/etc/profile}}<br />
* {{Filename|~/.bash_profile}}<br />
* {{Filename|~/.bash_login}}<br />
* {{Filename|~/.profile}}<br />
* {{Filename|/etc/bash.bashrc}} (''Non-standard'': only some distros, Arch included)<br />
* {{Filename|~/.bashrc}}<br />
* {{Filename|~/.bash_logout}}<br />
These files are sourced by bash in different circumstances. When an interactive and login shell is started, it will source {{Filename|/etc/profile}}, and the first of {{Filename|~/.bash_profile}}, {{Filename|~/.bash_login}} and {{Filename|~/.profile}} that exists and is readable. Bash will source {{Filename|~/.bash_logout}} upon exit. However, when a non-login interactive shell is started, it will only source {{Filename|/etc/bash.bashrc}} and {{Filename|~/.bashrc}}. Examples of the user dotfiles can be found in {{Filename|/etc/skel/}}.<br />
<br />
An overview of the commonly used configuration files:<br />
====/etc/profile====<br />
{{Filename|/etc/profile}} is sourced by all Bourne-compatible shells upon login. It sets up an environment upon login and loads application-specific ({{Filename|/etc/profile.d/*.sh}}) settings.<br />
<br />
====.profile====<br />
This file is read and sourced by bash when an interactive login shell is started.<br />
<br />
====.bashrc====<br />
The file {{Filename|~/.bashrc}} is read and sourced by bash when a non-login interactive shell is started, for example, when you open a virtual console from the desktop environment. This file is useful for setting up a user-specific shell environment.<br />
<br />
===Shell and environment variables===<br />
<br />
Environment variables are used to store useful values such as command search directories, or which browser to use. When a new shell or script is launched it inherits its parent's variables, thus starting with an internal set of shell variables[http://www.kingcomputerservices.com/unix_101/understanding_unix_shells_and_environment_variables.htm ].<br />
<br />
These shell variables can be exported in order to become environment variables:<br />
VARIABLE=content<br />
export VARIABLE<br />
<br />
Environment variables are conventionally placed in {{Filename|~/.profile}} or {{Filename|/etc/profile}} so that all bourne-compatible shells can use them.<br />
<br />
See [[Environment Variables]] for more general information.<br />
<br />
====Examples====<br />
{{Moveto|Environment Variables}}<br />
<!-- not specific to bash. zsh/$SHELL users would benefit too. --><br />
=====BROWSER=====<br />
The web browser. Helpful to set in an interactive shell configuration file so that it may be dynamically altered depending on the availability of a graphic environment, such as [[X]]:<br />
<pre><br />
if [ -n "$DISPLAY" ]; then<br />
BROWSER=firefox<br />
else<br />
BROWSER=links<br />
fi<br />
</pre><br />
<br />
=====EDITOR=====<br />
Should point to a lightweight text editor, such as ''ed'' or ''ex''. Convenient for editing SCM commit logs that do not require a whole lot of features from the application. ex has more features, but it will clear the whole screen, while ed does not.<br />
<br />
=====FTP and HTTP proxy=====<br />
FTP and HTTP proxy server, respectively:<br />
<pre><br />
ftp_proxy="ftp://192.168.0.1:21"<br />
http_proxy="http://192.168.0.1:80"<br />
</pre><br />
<br />
=====MAIL=====<br />
The location of incoming email. The traditional setting is {{Filename|/var/spool/mail/$LOGNAME}}.<br />
<br />
=====PAGER=====<br />
The pager called by [[man]] and other applications; for example, ''less'', or ''more''.<br />
<br />
=====PATH=====<br />
The '''PATH''' variable is a string delimited by colons (:) which specifies the directories to search for when users enter a command name without an explicit path preface. If the command is found in the directories specified in PATH, the program is executed.<br />
PATH=$PATH:/path/to/directory<br />
{{Note|It's advised not to include the current working directory (.) into your PATH for security reasons, as it may trick the user to execute vicious commands.}}<br />
<br />
=====VISUAL=====<br />
Regards full-fledged editors that are used for more demanding tasks, such as editing mail; e.g., ''vi'', [[vim]], [[emacs]], etc.<br />
<br />
==Tips and tricks==<br />
===Prompt customization===<br />
The bash prompt is governed by the variable $PS1. To colorize the bash prompt, first comment out the default $PS1:<br />
#PS1='[\u@\h \W]\$ '<br />
Then add the following line:<br />
PS1='\[\e[0;31m\]\u\[\e[m\] \[\e[1;34m\]\w\[\e[m\] \[\e[0;31m\]\$ \[\e[m\]\[\e[0;32m\] '<br />
This $PS1 is useful for a root bash prompt, with red designation and green console text. For details on customizing your bash prompt, see [[Color Bash Prompt]].<br />
<br />
===Aliases===<br />
An Alias substitutes a word with a user-defined string, this is useful for creating abbreviations of a command or adding default arguments to a command.<br />
<br />
For example, to make rm prompt before every removal:<br />
alias rm='rm -i'<br />
or once before removing more than three files and when removing recursively<br />
alias rm='rm -I'<br />
To make cp and mv prompt for overwrite:<br />
alias cp='cp -i'<br />
alias mv='mv -i'<br />
To use vi instead of nano (to force someone to learn vi):<br />
alias nano='vi'<br />
<br />
===Auto-completion===<br />
It is useful to have the auto-complete feature (pressing {{Keypress|Tab}} key twice on the keyboard) after you type some command like sudo.<br />
<br />
To do this add a line in this format to your {{Filename|~/.bashrc}} file:<br />
complete -cf your_command<br />
<br />
For example, to enable auto-complete after sudo and man:<br />
complete -cf sudo<br />
complete -cf man<br />
<br />
====Advanced completion====<br />
Despite Bash's native support for basic file name, command, and variable auto-completion, there are ways of improving and extending its reach.<br />
<br />
The {{Package Official|bash-completion}} package extends functionality by adding auto-completion to a wide range of commands and their options. Enabling advanced bash completion is quite simple, just install the following package:<br />
# pacman -S bash-completion<br />
Start a new shell and it will be automatically enabled thanks to {{Filename|/etc/bash.bashrc}}.<br />
<br />
====Faster completion====<br />
By appending the following into the readline initialization file ({{Filename|~/.inputrc}} or {{Filename|/etc/inputrc}} by default):<br />
set show-all-if-ambiguous on<br />
it is no longer necessary to hit {{Keypress|Tab}} (default binding) twice to produce a list of all possible completions (both when a partial completion is possible and when no completion is possible), as a single key-press will suffice. Alternatively, to produce such a list only when no completion is possible (i.e., not when a partial completion is possible), append the following command in lieu of the previous one:<br />
set show-all-if-unmodified on<br />
<br />
===History search===<br />
See [[Readline#History]].<br />
==== Avoid duplicates ====<br />
If you repeat the same command several times, they will all be appended in your history. To prevent this, add to your {{Filename|~/.bashrc}}:<br />
export HISTCONTROL=ignoredups<br />
<br />
==== Avoid whitespaces ====<br />
To disable logging blank commands add this to your {{Filename|~/.bashrc}}:<br />
export HISTCONTROL=ignorespace<br />
If your {{Filename|~/.bashrc}} already contains <br />
export HISTCONTROL=ignoredups<br />
replace it with<br />
export HISTCONTROL=ignoreboth<br />
<br />
=== Disable Ctrl-Z in terminal===<br />
You can disable {{Keypress|Ctrl}}+{{Keypress|Z}} (pauses/closes your CLI application) feature for you CLI by wrapping your command in this script<br />
#!/bin/bash<br />
trap "" 20<br />
/path_to_your_application/<br />
example:<br />
#!/bin/bash<br />
trap "" 20<br />
/usr/bin/adom<br />
<br />
With this example script, when you accidentally press {{Keypress|Ctrl}}+{{Keypress|Z}} instead of {{Keypress|Shift}}+{{Keypress|Z}} or some other key combo while playing Adom(game) your game will not end. Nothing will happen because {{Keypress|Ctrl}}+{{Keypress|Z}} will be ignored.<br />
<br />
===Disabling control echo===<br />
Due to an update to {{Package Official|readline}}, the terminal now echoes {{Codeline|^C}} after {{Keypress|Ctrl}}+{{Keypress|C}} is pressed. For users who wish to disable this, simply add the following to {{Filename|~/.inputrc}}:<br />
set echo-control-characters off<br />
<br />
===Readline macros===<br />
Readline also supports binding keys to keyboard macros. For simple example, run this command in Bash:<br />
bind '"\ew":"\C-e # macro"'<br />
<br />
or add the part within single quotes to inputrc:<br />
"\ew":"\C-e # macro"<br />
<br />
Now type a line and press {{Keypress|Alt}}+{{Keypress|W}}. Readline will act as though {{Keypress|Ctrl}}+{{Keypress|E}} (end-of-line) had been pressed, appended with '{{codeline| # macro}}'.<br />
<br />
Use any of the existing keybindings within a readline macro, which can be quite useful to automate frequently used idioms. For example, this one makes {{Keypress|Ctrl}}+{{Keypress|Alt}}+{{Keypress|L}} append "| less" to the line and run it ({{Keypress|Ctrl}}+{{Keypress|M}} is equivalent to {{Keypress|Enter}}:<br />
"\e\C-l":"\C-e | less\C-m"<br />
<br />
The next one prefixes the line with 'yes |' when pressing {{Keypress|Ctrl}}+{{Keypress|Alt}}+{{Keypress|Y}}, confirming any yes/no question the command might ask:<br />
"\e\C-y":"\C-ayes | \C-m"<br />
<br />
This example wraps the line in {{Codeline|su -c &#39;&#39;}}, if {{Keypress|Alt}}+{{Keypress|S}} is pressed:<br />
"\es":"\C-a su -c '\C-e'\C-m"<br />
<br />
As a last example, quickly send a command in the background with {{Keypress|Ctrl}}+{{Keypress|Alt}}+{{Keypress|B}}, discarding all of its output:<br />
"\e\C-b":"\C-e > /dev/null 2>&1 &\C-m"<br />
<br />
===Command-line editing===<br />
As stated above, bash is readline-powered. Therefore you may find the readline instructions in the [http://www.gnu.org/software/bash/manual/html_node/Readline-Interaction.html#Readline-Interaction GNU Bash manual] or the shortcuts table at [http://www.bigsmoke.us/readline/shortcuts www.bigsmoke.us] very useful.<br />
<br />
If you are a [[vi]] or vim user, you may want to put the following line to your {{Filename|~/.bashrc}} to enable vi-like keybindings:<br />
set -o vi<br />
Taken from [http://www.catonmat.net/blog/bash-vi-editing-mode-cheat-sheet/ www.catonmat.net]<br />
<br />
===Startup files===<br />
There are different possibilities:<br />
* if login shell → {{Filename|/etc/profile}} then the first readable of {{Filename|~/.bash_profile}}, {{Filename|~/.bash_login}}, and {{Filename|~/.profile}}<br />
* if interactive + non-login shell → {{Filename|/etc/bash.bashrc}} then {{Filename|~/.bashrc}}<br />
* if login shell + legacy mode → {{Filename|/etc/profile}} then {{Filename|~/.profile}}<br />
<br />
But, in Arch, by default:<br />
* {{Filename|/etc/profile}} (indirectly) sources {{Filename|/etc/bash.bashrc}}<br />
* {{Filename|/etc/skel/.bash_profile}} which users are encouraged to copy to {{Filename|~/.bash_profile}}, sources {{Filename|~/.bashrc}}<br />
which means that {{Filename|/etc/bash.bashrc}} and {{Filename|~/.bashrc}} will be executed for all interactive shells, whether they are login shells or not.<br />
<br />
{{Note|legacy mode is when invoked with the name {{Codeline|sh}}}}<br />
<br />
===Clear the screen after logging out===<br />
To clear the screen after logging out on a virtual terminal, append the following lines to {{Filename|~/.bash_logout}}:<br />
clear<br />
reset<br />
<br />
===ASCII art, fortunes and cowsay===<br />
Along with a colors, system info and ASCII symbols, BASH can be made to display a piece of ASCII art on login. ASCII images can be found online and pasted into a text file, or generated from scratch. To set the image to display in a terminal on login, place the string <code> cat /path/to/text/file</code> at the top of {{filename|~/.bashrc}}.<br />
<br />
Random poignant, inspirational, silly or snide phrases can also be shown. To see an example, install the [http://www.archlinux.org/packages/?sort=&arch=&repo=&q=fortune-mod&maintainer=&last_update=&flagged=&limit=50/ fortune-mod] package from the extra repository.<br />
<br />
{{cli|1=<br />
'''<font color=red>(</font><font color=green>user@host</font><font color=red>)-(</font><font color=green>10:10 AM Wed Dec 22</font><font color=red>)'''<br />
--(</font><font color=green>~</font><font color=red>)---> </font> fortune <br/> <br />
It is Texas law that when two trains meet each other at a railroad crossing,<br />
each shall come to a full stop, and neither shall proceed until the other<br />
has gone.}}<br />
<br />
To have a random phrase displayed when logging into a terminal, just set <code>command fortune</code> as the top line in {{filename|~/.bashrc}}.<br />
<br />
{{Note|By default, <code>fortune</code> displays quotes and phrases that are rather inoccuous. However, the package does contain a set of comments some will find offensive, located in {{filename|/usr/share/fortune/off}}. See the man page for more info on these.}}<br />
<br />
These two features can be combined, using the program [http://www.archlinux.org/packages/?sort=&arch=&repo=&q=cowsay&maintainer=&last_update=&flagged=&limit=50/ cowsay.] Modify the line at the top of {{filename|~/.bashrc}} to read <code>command cowsay $(fortune)</code>or <code> command cowthink $(fortune).</code><br />
<br />
<br />
The earth is like a tiny grain of sand, <br />
only much, much heavier. <br />
----------------------------------------- <br />
\ ^__^<br />
\ (oo)\_______<br />
(__)\ )\/\<br />
||----w |<br />
|| ||<br />
<br />
The ASCII images are generated by {{filename|.cow}} text files located in {{filename|/usr/share/cows}}, and all themes can be listed with the command <code>cowsay -l</code> These files can be edited to the user's liking; custom images can also be created from scratch or found on the net. The easiest way create a custom cow file from an image found online would be to open an existing {{filename|.cow}} file in a text editor, copy-and-paste the image from a browser and save the file as a different name. Test the custom file using<br />
<br />
# cowsay -f {{filename|cowfile}} $(fortune)<br />
<br />
This can produce some nice eye candy, and the commands used can be more complex. For a specialized example, take a look [http://bambambambam.wordpress.com/2009/07/04/futurama-ascii-with-slashdot-header-quotes-in-your-terminal/ here.]<br />
<br />
________________________________________ <br />
( Fry: I must be a robot. Why else would )<br />
( human women refuse to date me? )<br />
---------------------------------------- <br />
o<br />
o<br />
o <br />
,'``.._ ,'``.<br />
:,--._:)\,:,._,.:<br />
:`--,''@@@:`...';\ <br />
`,'@@@@@@@`---'@@`. <br />
/@@@@@@@@@@@@@@@@@:<br />
/@@@@@@@@@@@@@@@@@@@\<br />
,'@@@@@@@@@@@@@@@@@@@@@:\.___,-.<br />
`...,---'``````-..._@@@@|:@@@@@@@\<br />
( )@@@;:@@@@)@@@\ _,-.<br />
`. (@@@//@@@@@@@@@@`'@@@@\<br />
: `.//@@)@@@@@@)@@@@@,@;<br />
|`. _,'/@@@@@@@)@@@@)@,'@,'<br />
:`.`-..____..=:.-':@@@@@.@@@@@_,@@,'<br />
,'\ ``--....-)=' `._,@@\ )@@@'``._<br />
/@_@`. (@) /@@@@@) ; / \ \`-.'<br />
(@@@`-:`. `' ___..'@@_,-' |/ `.)<br />
`-. `.`.``-----``--,@@.'<br />
|/`.\`' ,',');<br />
` (/ (/<br />
'''<font color=red>(</font><font color=green>user@host</font><font color=red>)-(</font><font color=green>10:10 AM Wed Dec 22</font><font color=red>)'''--(</font><font color=green>~</font>)<font color=red>)---></font><br />
<br />
===ASCII Historical Calendar===<br />
To install [http://www.openbsd.org/cgi-bin/man.cgi?query=calendar&sektion=1 calendar] files in your {{Filename|~/.calendar}} directory:<br />
$ mkdir -p ~/.calendar<br />
$ curl -o calendar.rpm http://download.fedora.redhat.com/pub/epel/5/x86_64/calendar-1.25-4.el5.x86_64.rpm<br />
$ rpm2cpio calendar.rpm | bsdtar -C ~/.calendar --strip-components=4 -xf - ./usr/share/c*<br />
<br />
This will then print out the calendar items<br />
$ sed -n "/$(date +%m\\/%d\\\|%b\*\ %d)/p" $(find ~/.calendar /usr/share/calendar -maxdepth 1 -type f -name 'c*' 2>/dev/null);<br />
<br />
==Resources==<br />
* [http://tldp.org/LDP/abs/html/ Advanced Bash Scripting Guide] - Very good resource regarding shell scripting using bash<br />
* [http://www.gnu.org/software/bash/manual/bashref.html Bash Reference Manual] - Official reference (654K)<br />
* [http://www.ibm.com/developerworks/linux/library/l-bash.html Bash Scripting by Example]<br />
* [http://www.caliban.org/bash Completion Guide]<br />
* [http://wooledge.org/mywiki/BashFaq Greg's Wiki] - Highly recommended<br />
* [http://www.gnu.org/software/bash/manual/bash.html man page]<br />
* [http://tiswww.case.edu/php/chet/readline/rluserman.html Readline Guide]<br />
* [http://www.grymoire.com/Unix/Quote.html Quote Tutorial]<br />
* irc://irc.freenode.net#bash - Active and friendly Internet Relay Chat channel for Bash.</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Bash&diff=163974Bash2011-10-04T18:01:55Z<p>Rnabioullin: Added alternative completion behavior option</p>
<hr />
<div>[[Category:Command shells (English)]] <br />
{{i18n|Bash}}<br />
{{Article summary start}}<br />
{{Article summary text|Improving Bash over its default capabilities.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Color Bash Prompt}}<br />
{{Article summary wiki|Core Utilities}}<br />
{{Article summary wiki|Zsh}}<br />
{{Article summary wiki|Heirloom}}<br />
{{Article summary end}}<br />
'''Bash''' (Bourne-again Shell) is a shell/programming language by the [[GNU Project]]. Its name is a homaging reference to its predecessor: the long-deprecated Bourne shell. Bash can be run on most UNIX-like operating systems, including GNU/Linux. Arch copiously uses Bash throughout its init-scripts.<br />
<br />
==Configuration==<br />
* {{Filename|/etc/profile}}<br />
* {{Filename|~/.bash_profile}}<br />
* {{Filename|~/.bash_login}}<br />
* {{Filename|~/.profile}}<br />
* {{Filename|/etc/bash.bashrc}} (''Non-standard'': only some distros, Arch included)<br />
* {{Filename|~/.bashrc}}<br />
* {{Filename|~/.bash_logout}}<br />
These files are sourced by bash in different circumstances. When an interactive and login shell is started, it will source {{Filename|/etc/profile}}, and the first of {{Filename|~/.bash_profile}}, {{Filename|~/.bash_login}} and {{Filename|~/.profile}} that exists and is readable. Bash will source {{Filename|~/.bash_logout}} upon exit. However, when a non-login interactive shell is started, it will only source {{Filename|/etc/bash.bashrc}} and {{Filename|~/.bashrc}}. Examples of the user dotfiles can be found in {{Filename|/etc/skel/}}.<br />
<br />
An overview of the commonly used configuration files:<br />
====/etc/profile====<br />
{{Filename|/etc/profile}} is sourced by all Bourne-compatible shells upon login. It sets up an environment upon login and loads application-specific ({{Filename|/etc/profile.d/*.sh}}) settings.<br />
<br />
====.profile====<br />
This file is read and sourced by bash when an interactive login shell is started.<br />
<br />
====.bashrc====<br />
The file {{Filename|~/.bashrc}} is read and sourced by bash when a non-login interactive shell is started, for example, when you open a virtual console from the desktop environment. This file is useful for setting up a user-specific shell environment.<br />
<br />
===Shell and environment variables===<br />
<br />
Environment variables are used to store useful values such as command search directories, or which browser to use. When a new shell or script is launched it inherits its parent's variables, thus starting with an internal set of shell variables[http://www.kingcomputerservices.com/unix_101/understanding_unix_shells_and_environment_variables.htm ].<br />
<br />
These shell variables can be exported in order to become environment variables:<br />
VARIABLE=content<br />
export VARIABLE<br />
<br />
Environment variables are conventionally placed in {{Filename|~/.profile}} or {{Filename|/etc/profile}} so that all bourne-compatible shells can use them.<br />
<br />
See [[Environment Variables]] for more general information.<br />
<br />
====Examples====<br />
{{Moveto|Environment Variables}}<br />
<!-- not specific to bash. zsh/$SHELL users would benefit too. --><br />
=====BROWSER=====<br />
The web browser. Helpful to set in an interactive shell configuration file so that it may be dynamically altered depending on the availability of a graphic environment, such as [[X]]:<br />
<pre><br />
if [ -n "$DISPLAY" ]; then<br />
BROWSER=firefox<br />
else<br />
BROWSER=links<br />
fi<br />
</pre><br />
<br />
=====EDITOR=====<br />
Should point to a lightweight text editor, such as ''ed'' or ''ex''. Convenient for editing SCM commit logs that do not require a whole lot of features from the application. ex has more features, but it will clear the whole screen, while ed does not.<br />
<br />
=====FTP and HTTP proxy=====<br />
FTP and HTTP proxy server, respectively:<br />
<pre><br />
ftp_proxy="ftp://192.168.0.1:21"<br />
http_proxy="http://192.168.0.1:80"<br />
</pre><br />
<br />
=====MAIL=====<br />
The location of incoming email. The traditional setting is {{Filename|/var/spool/mail/$LOGNAME}}.<br />
<br />
=====PAGER=====<br />
The pager called by [[man]] and other applications; for example, ''less'', or ''more''.<br />
<br />
=====PATH=====<br />
The '''PATH''' variable is a string delimited by colons (:) which specifies the directories to search for when users enter a command name without an explicit path preface. If the command is found in the directories specified in PATH, the program is executed.<br />
PATH=$PATH:/path/to/directory<br />
{{Note|It's advised not to include the current working directory (.) into your PATH for security reasons, as it may trick the user to execute vicious commands.}}<br />
<br />
=====VISUAL=====<br />
Regards full-fledged editors that are used for more demanding tasks, such as editing mail; e.g., ''vi'', [[vim]], [[emacs]], etc.<br />
<br />
==Tips and tricks==<br />
===Prompt customization===<br />
The bash prompt is governed by the variable $PS1. To colorize the bash prompt, first comment out the default $PS1:<br />
#PS1='[\u@\h \W]\$ '<br />
Then add the following line:<br />
PS1='\[\e[0;31m\]\u\[\e[m\] \[\e[1;34m\]\w\[\e[m\] \[\e[0;31m\]\$ \[\e[m\]\[\e[0;32m\] '<br />
This $PS1 is useful for a root bash prompt, with red designation and green console text. For details on customizing your bash prompt, see [[Color Bash Prompt]].<br />
<br />
===Aliases===<br />
An Alias substitutes a word with a user-defined string, this is useful for creating abbreviations of a command or adding default arguments to a command.<br />
<br />
For example, to make rm prompt before every removal:<br />
alias rm='rm -i'<br />
or once before removing more than three files and when removing recursively<br />
alias rm='rm -I'<br />
To make cp and mv prompt for overwrite:<br />
alias cp='cp -i'<br />
alias mv='mv -i'<br />
To use vi instead of nano (to force someone to learn vi):<br />
alias nano='vi'<br />
<br />
===Auto-completion===<br />
It is useful to have the auto-complete feature (pressing {{Keypress|Tab}} key twice on the keyboard) after you type some command like sudo.<br />
<br />
To do this add a line in this format to your {{Filename|~/.bashrc}} file:<br />
complete -cf your_command<br />
<br />
For example, to enable auto-complete after sudo and man:<br />
complete -cf sudo<br />
complete -cf man<br />
<br />
====Advanced completion====<br />
Despite Bash's native support for basic file name, command, and variable auto-completion, there are ways of improving and extending its reach.<br />
<br />
The {{Package Official|bash-completion}} package extends functionality by adding auto-completion to a wide range of commands and their options. Enabling advanced bash completion is quite simple, just install the following package:<br />
# pacman -S bash-completion<br />
Start a new shell and it will be automatically enabled thanks to {{Filename|/etc/bash.bashrc}}.<br />
<br />
====Faster completion====<br />
By appending the following into the readline initialization file ({{Filename|~/.inputrc}} or {{Filename|/etc/inputrc}} by default):<br />
set show-all-if-ambiguous on<br />
it is no longer necessary to hit {{Keypress|Tab}} (default binding) twice to produce a list of all possible completions (either when a partial completion is possible or no completion is possible), as a single key-press will suffice. Alternatively, to produce such a list only when a completion is not possible (i.e., not when a partial completion is possible), append the following command in lieu of the previous one:<br />
set show-all-if-unmodified on<br />
<br />
===History search===<br />
See [[Readline#History]].<br />
==== Avoid duplicates ====<br />
If you repeat the same command several times, they will all be appended in your history. To prevent this, add to your {{Filename|~/.bashrc}}:<br />
export HISTCONTROL=ignoredups<br />
<br />
==== Avoid whitespaces ====<br />
To disable logging blank commands add this to your {{Filename|~/.bashrc}}:<br />
export HISTCONTROL=ignorespace<br />
If your {{Filename|~/.bashrc}} already contains <br />
export HISTCONTROL=ignoredups<br />
replace it with<br />
export HISTCONTROL=ignoreboth<br />
<br />
=== Disable Ctrl-Z in terminal===<br />
You can disable {{Keypress|Ctrl}}+{{Keypress|Z}} (pauses/closes your CLI application) feature for you CLI by wrapping your command in this script<br />
#!/bin/bash<br />
trap "" 20<br />
/path_to_your_application/<br />
example:<br />
#!/bin/bash<br />
trap "" 20<br />
/usr/bin/adom<br />
<br />
With this example script, when you accidentally press {{Keypress|Ctrl}}+{{Keypress|Z}} instead of {{Keypress|Shift}}+{{Keypress|Z}} or some other key combo while playing Adom(game) your game will not end. Nothing will happen because {{Keypress|Ctrl}}+{{Keypress|Z}} will be ignored.<br />
<br />
===Disabling control echo===<br />
Due to an update to {{Package Official|readline}}, the terminal now echoes {{Codeline|^C}} after {{Keypress|Ctrl}}+{{Keypress|C}} is pressed. For users who wish to disable this, simply add the following to {{Filename|~/.inputrc}}:<br />
set echo-control-characters off<br />
<br />
===Readline macros===<br />
Readline also supports binding keys to keyboard macros. For simple example, run this command in Bash:<br />
bind '"\ew":"\C-e # macro"'<br />
<br />
or add the part within single quotes to inputrc:<br />
"\ew":"\C-e # macro"<br />
<br />
Now type a line and press {{Keypress|Alt}}+{{Keypress|W}}. Readline will act as though {{Keypress|Ctrl}}+{{Keypress|E}} (end-of-line) had been pressed, appended with '{{codeline| # macro}}'.<br />
<br />
Use any of the existing keybindings within a readline macro, which can be quite useful to automate frequently used idioms. For example, this one makes {{Keypress|Ctrl}}+{{Keypress|Alt}}+{{Keypress|L}} append "| less" to the line and run it ({{Keypress|Ctrl}}+{{Keypress|M}} is equivalent to {{Keypress|Enter}}:<br />
"\e\C-l":"\C-e | less\C-m"<br />
<br />
The next one prefixes the line with 'yes |' when pressing {{Keypress|Ctrl}}+{{Keypress|Alt}}+{{Keypress|Y}}, confirming any yes/no question the command might ask:<br />
"\e\C-y":"\C-ayes | \C-m"<br />
<br />
This example wraps the line in {{Codeline|su -c &#39;&#39;}}, if {{Keypress|Alt}}+{{Keypress|S}} is pressed:<br />
"\es":"\C-a su -c '\C-e'\C-m"<br />
<br />
As a last example, quickly send a command in the background with {{Keypress|Ctrl}}+{{Keypress|Alt}}+{{Keypress|B}}, discarding all of its output:<br />
"\e\C-b":"\C-e > /dev/null 2>&1 &\C-m"<br />
<br />
===Command-line editing===<br />
As stated above, bash is readline-powered. Therefore you may find the readline instructions in the [http://www.gnu.org/software/bash/manual/html_node/Readline-Interaction.html#Readline-Interaction GNU Bash manual] or the shortcuts table at [http://www.bigsmoke.us/readline/shortcuts www.bigsmoke.us] very useful.<br />
<br />
If you are a [[vi]] or vim user, you may want to put the following line to your {{Filename|~/.bashrc}} to enable vi-like keybindings:<br />
set -o vi<br />
Taken from [http://www.catonmat.net/blog/bash-vi-editing-mode-cheat-sheet/ www.catonmat.net]<br />
<br />
===Startup files===<br />
There are different possibilities:<br />
* if login shell → {{Filename|/etc/profile}} then the first readable of {{Filename|~/.bash_profile}}, {{Filename|~/.bash_login}}, and {{Filename|~/.profile}}<br />
* if interactive + non-login shell → {{Filename|/etc/bash.bashrc}} then {{Filename|~/.bashrc}}<br />
* if login shell + legacy mode → {{Filename|/etc/profile}} then {{Filename|~/.profile}}<br />
<br />
But, in Arch, by default:<br />
* {{Filename|/etc/profile}} (indirectly) sources {{Filename|/etc/bash.bashrc}}<br />
* {{Filename|/etc/skel/.bash_profile}} which users are encouraged to copy to {{Filename|~/.bash_profile}}, sources {{Filename|~/.bashrc}}<br />
which means that {{Filename|/etc/bash.bashrc}} and {{Filename|~/.bashrc}} will be executed for all interactive shells, whether they are login shells or not.<br />
<br />
{{Note|legacy mode is when invoked with the name {{Codeline|sh}}}}<br />
<br />
===Clear the screen after logging out===<br />
To clear the screen after logging out on a virtual terminal, append the following lines to {{Filename|~/.bash_logout}}:<br />
clear<br />
reset<br />
<br />
===ASCII art, fortunes and cowsay===<br />
Along with a colors, system info and ASCII symbols, BASH can be made to display a piece of ASCII art on login. ASCII images can be found online and pasted into a text file, or generated from scratch. To set the image to display in a terminal on login, place the string <code> cat /path/to/text/file</code> at the top of {{filename|~/.bashrc}}.<br />
<br />
Random poignant, inspirational, silly or snide phrases can also be shown. To see an example, install the [http://www.archlinux.org/packages/?sort=&arch=&repo=&q=fortune-mod&maintainer=&last_update=&flagged=&limit=50/ fortune-mod] package from the extra repository.<br />
<br />
{{cli|1=<br />
'''<font color=red>(</font><font color=green>user@host</font><font color=red>)-(</font><font color=green>10:10 AM Wed Dec 22</font><font color=red>)'''<br />
--(</font><font color=green>~</font><font color=red>)---> </font> fortune <br/> <br />
It is Texas law that when two trains meet each other at a railroad crossing,<br />
each shall come to a full stop, and neither shall proceed until the other<br />
has gone.}}<br />
<br />
To have a random phrase displayed when logging into a terminal, just set <code>command fortune</code> as the top line in {{filename|~/.bashrc}}.<br />
<br />
{{Note|By default, <code>fortune</code> displays quotes and phrases that are rather inoccuous. However, the package does contain a set of comments some will find offensive, located in {{filename|/usr/share/fortune/off}}. See the man page for more info on these.}}<br />
<br />
These two features can be combined, using the program [http://www.archlinux.org/packages/?sort=&arch=&repo=&q=cowsay&maintainer=&last_update=&flagged=&limit=50/ cowsay.] Modify the line at the top of {{filename|~/.bashrc}} to read <code>command cowsay $(fortune)</code>or <code> command cowthink $(fortune).</code><br />
<br />
<br />
The earth is like a tiny grain of sand, <br />
only much, much heavier. <br />
----------------------------------------- <br />
\ ^__^<br />
\ (oo)\_______<br />
(__)\ )\/\<br />
||----w |<br />
|| ||<br />
<br />
The ASCII images are generated by {{filename|.cow}} text files located in {{filename|/usr/share/cows}}, and all themes can be listed with the command <code>cowsay -l</code> These files can be edited to the user's liking; custom images can also be created from scratch or found on the net. The easiest way create a custom cow file from an image found online would be to open an existing {{filename|.cow}} file in a text editor, copy-and-paste the image from a browser and save the file as a different name. Test the custom file using<br />
<br />
# cowsay -f {{filename|cowfile}} $(fortune)<br />
<br />
This can produce some nice eye candy, and the commands used can be more complex. For a specialized example, take a look [http://bambambambam.wordpress.com/2009/07/04/futurama-ascii-with-slashdot-header-quotes-in-your-terminal/ here.]<br />
<br />
________________________________________ <br />
( Fry: I must be a robot. Why else would )<br />
( human women refuse to date me? )<br />
---------------------------------------- <br />
o<br />
o<br />
o <br />
,'``.._ ,'``.<br />
:,--._:)\,:,._,.:<br />
:`--,''@@@:`...';\ <br />
`,'@@@@@@@`---'@@`. <br />
/@@@@@@@@@@@@@@@@@:<br />
/@@@@@@@@@@@@@@@@@@@\<br />
,'@@@@@@@@@@@@@@@@@@@@@:\.___,-.<br />
`...,---'``````-..._@@@@|:@@@@@@@\<br />
( )@@@;:@@@@)@@@\ _,-.<br />
`. (@@@//@@@@@@@@@@`'@@@@\<br />
: `.//@@)@@@@@@)@@@@@,@;<br />
|`. _,'/@@@@@@@)@@@@)@,'@,'<br />
:`.`-..____..=:.-':@@@@@.@@@@@_,@@,'<br />
,'\ ``--....-)=' `._,@@\ )@@@'``._<br />
/@_@`. (@) /@@@@@) ; / \ \`-.'<br />
(@@@`-:`. `' ___..'@@_,-' |/ `.)<br />
`-. `.`.``-----``--,@@.'<br />
|/`.\`' ,',');<br />
` (/ (/<br />
'''<font color=red>(</font><font color=green>user@host</font><font color=red>)-(</font><font color=green>10:10 AM Wed Dec 22</font><font color=red>)'''--(</font><font color=green>~</font>)<font color=red>)---></font><br />
<br />
===ASCII Historical Calendar===<br />
To install [http://www.openbsd.org/cgi-bin/man.cgi?query=calendar&sektion=1 calendar] files in your {{Filename|~/.calendar}} directory:<br />
$ mkdir -p ~/.calendar<br />
$ curl -o calendar.rpm http://download.fedora.redhat.com/pub/epel/5/x86_64/calendar-1.25-4.el5.x86_64.rpm<br />
$ rpm2cpio calendar.rpm | bsdtar -C ~/.calendar --strip-components=4 -xf - ./usr/share/c*<br />
<br />
This will then print out the calendar items<br />
$ sed -n "/$(date +%m\\/%d\\\|%b\*\ %d)/p" $(find ~/.calendar /usr/share/calendar -maxdepth 1 -type f -name 'c*' 2>/dev/null);<br />
<br />
==Resources==<br />
* [http://tldp.org/LDP/abs/html/ Advanced Bash Scripting Guide] - Very good resource regarding shell scripting using bash<br />
* [http://www.gnu.org/software/bash/manual/bashref.html Bash Reference Manual] - Official reference (654K)<br />
* [http://www.ibm.com/developerworks/linux/library/l-bash.html Bash Scripting by Example]<br />
* [http://www.caliban.org/bash Completion Guide]<br />
* [http://wooledge.org/mywiki/BashFaq Greg's Wiki] - Highly recommended<br />
* [http://www.gnu.org/software/bash/manual/bash.html man page]<br />
* [http://tiswww.case.edu/php/chet/readline/rluserman.html Readline Guide]<br />
* [http://www.grymoire.com/Unix/Quote.html Quote Tutorial]<br />
* irc://irc.freenode.net#bash - Active and friendly Internet Relay Chat channel for Bash.</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Rxvt-unicode&diff=162578Rxvt-unicode2011-09-27T03:33:00Z<p>Rnabioullin: Added link for the tmux ICCCM bindings</p>
<hr />
<div>[[Category:Terminal emulators (English)]]<br />
{{DISPLAYTITLE:rxvt-unicode}}<br />
[[fr:urxvt]]<br />
{{i18n|Rxvt-unicode}}<br />
<br />
[http://software.schmorp.de/pkg/rxvt-unicode.html rxvt-unicode] is a highly customizable [[Wikipedia:Terminal emulator|terminal emulator]] forked from [[Wikipedia:Rxvt|rxvt]]. Commonly known as {{Codeline|urxvt}}, rxvt-unicode can be [[daemon]]ized to run clients within a single [[Wikipedia:Process (computing)|process]] in order to minimize the use of system resources. Developed by Marc Lehmann, some of the more outstanding features of rxvt-unicode include international language support through [[Wikipedia:Unicode|Unicode]], the ability to display multiple font types and support for [[Wikipedia:Perl|Perl]] extensions.<br />
<br />
==Installation==<br />
<br />
{{Package Official|rxvt-unicode}} is available in [extra] and includes 256 color support:<br />
<br />
# pacman -S rxvt-unicode<br />
<br />
{{Package AUR|rxvt-unicode-patched}} is available in the [[AUR]] and includes a fix for the font width bug and adds support for ignoring window size hints (lock the window size to n_columns * column_width, etc.) without dead space.<br />
<br />
==Configuration==<br />
See the [http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.1.pod rxvt-unicode reference page] for the complete list of available setting and values.<br />
<br />
===Creating ~/.Xresources===<br />
The look, feel and function of rxvt-unicode is controlled by command-line arguments and/or [[Wikipedia:X resources|X resources]]. X resources can be set using {{Filename|~/.Xresources}} and xrdb, see the [[Xresources|wiki page]] for details.<br />
<br />
{{Note|Command-line arguments override and take precedence over the resource settings established in this file.}}<br />
<br />
===True transparency===<br />
<br />
To use true transparency you need to be using a window manager that supports compositing or a separate compositor.<br />
<br />
From the command-line:<br />
<br />
$ urxvt -depth 32 -bg rgba:3f00/3f00/3f00/dddd<br />
<br />
Using the configuration file:<br />
<br />
{{File|name=~/.Xresources|content=<br />
URxvt.depth: 32<br />
URxvt.background: rgba:1111/1111/1111/dddd<br />
}}<br />
<br />
===Scrollbar===<br />
The look of the scrollbar can be chosen through this entry in {{Filename|~/.Xresources}}:<br />
<br />
<pre><br />
! scrollbar style - rxvt (default), plain (most compact), next, or xterm<br />
URxvt*scrollstyle:rxvt<br />
</pre><br />
<br />
The scrollbar can also be completely deactivated like so:<br />
<br />
<pre><br />
URxvt.scrollBar: off<br />
</pre><br />
<br />
===Font Declaration Methods===<br />
URxvt.font: 9x15<br />
is the same as:<br />
URxvt.font: -misc-fixed-medium-r-normal--15-140-75-75-c-90-iso8859-1<br />
and:<br />
URxvt.font: 9x15bold<br />
is the same as:<br />
URxvt.font: -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1<br />
<br />
The complete list of short names for X core fonts can be found in {{Filename|/usr/share/fonts/misc/fonts.alias}} (there's also some fonts.alias files in some of the other subdirectories of {{Filename|/usr/share/fonts/}}, but as they are packaged separately from the actual fonts, they may list fonts you don't actually have installed). It is worth noting that these short aliases select for ISO-8859-1 versions of the fonts rather than ISO-10646-1 (Unicode) versions, and 75 DPI rather than 100 DPI versions, so you're probably better off avoiding them and choosing fonts by their full long names instead.<br />
<br />
{{Note|The above paragraph is only for bitmap fonts. Xft fonts can be specified using the following format:}}<br />
<br />
URxvt.font: xft:monaco:size=10<br />
<br />
Or<br />
<br />
URxvt.font: xft:monaco:bold:size=10<br />
<br />
==Perl extensions==<br />
===Clickable URLs===<br />
You can make URLs in the terminal clickable using the matcher extension. For example, to open links in [[Firefox]] add the following to {{Filename|.Xresources}}:<br />
URxvt.perl-ext-common: default,matcher<br />
URxvt.urlLauncher: /usr/bin/firefox<br />
URxvt.matcher.button: 1 <br />
<br />
===Yankable URLs (No Mouse)===<br />
In addition, you can select and open URLs in your web browser without using the mouse.<br />
<br />
Install the {{Package Official|urxvt-url-select}} package from the [community] repo and adjust your {{Filename|.Xresources}} as necessary. An example is shown below:<br />
URxvt.perl-ext: default,url-select<br />
URxvt.keysym.M-u: perl:url-select:select_next<br />
URxvt.urlLauncher: firefox<br />
URxvt.underlineURLs: true<br />
<br />
{{Note|This extension replaces the Clickable URLs extension mentioned above, so {{Codeline|matcher}} can be removed from the {{Codeline|URxvt.perl-ext}} list.}}<br />
<br />
'''Key commands:'''<br />
<br />
{{Keypress|Alt}} + {{Keypress|U}} Enter selection mode. The last URL on your screen will be selected. You can repeat {{Codeline|Alt+u}} to select the next upward URL.<br />
<br />
{{Keypress|k}} Select next upward URL<br />
<br />
{{Keypress|j}} Select next downward URL<br />
<br />
{{Keypress|Return}} Open selected URL in browser and quit selection mode<br />
<br />
{{Keypress|o}} Open selected URL in browser without quitting selection mode<br />
<br />
{{Keypress|y}} Copy (yank) selected URL and quit selection mode<br />
<br />
{{Keypress|Esc}} Cancel URL selection mode<br />
<br />
===Tabs===<br />
To add tabs to urxvt, add the following to your {{Filename|~/.Xresources}}:<br />
<pre><br />
URxvt.perl-ext-common: default,tabbed<br />
</pre><br />
<br />
To control tabs use:<br />
<br />
{{Keypress|Shift}} + {{Keypress|↓}} new tab<br />
<br />
{{Keypress|Shift}} + {{Keypress|←}} go to left tab<br />
<br />
{{Keypress|Shift}} + {{Keypress|→}} go to right tab<br />
<br />
{{Keypress|Ctrl}} + {{Keypress|←}} move tab to the left<br />
<br />
{{Keypress|Ctrl}} + {{Keypress|→}} move tab to the right<br />
<br />
{{Keypress|Ctrl}} + {{Keypress|d}}: close tab <br />
<br />
You can change tabs' colors with the following:<br />
<pre><br />
URxvt.tabbed.tabbar-fg: 2<br />
URxvt.tabbed.tabbar-bg: 0<br />
URxvt.tabbed.tab-fg: 3<br />
URxvt.tabbed.tab-bg: 0<br />
</pre><br />
<br />
For named tabs, see {{Package AUR|urxvt-tabbedex}}, (Shift+Up: names a tab).<br />
<br />
==Colors==<br />
Colors must be specified using color indexes: 0 to 15 correspond with the colors from the rxvt manual "Colors and Graphics" Section.<br />
<pre>COLORS AND GRAPHICS<br />
<br />
If graphics support was enabled at compile-time, rxvt can be queried with ANSI escape sequences and can address individual pixels instead of text<br />
characters. Note the graphics support is still considered beta code.<br />
<br />
In addition to the default foreground and background colours, rxvt can display up to 16 colours (8 ANSI colours plus high-intensity bold/blink<br />
versions of the same). Here is a list of the colours with their rgb.txt names.<br />
<br />
color0 (black) = Black<br />
color1 (red) = Red3<br />
color2 (green) = Green3<br />
color3 (yellow) = Yellow3<br />
color4 (blue) = Blue3<br />
color5 (magenta) = Magenta3<br />
color6 (cyan) = Cyan3<br />
color7 (white) = AntiqueWhite<br />
color8 (bright black) = Grey25<br />
color9 (bright red) = Red<br />
color10 (bright green) = Green<br />
color11 (bright yellow) = Yellow<br />
color12 (bright blue) = Blue<br />
color13 (bright magenta)= Magenta<br />
color14 (bright cyan) = Cyan<br />
color15 (bright white) = White<br />
foreground = Black<br />
background = White<br />
<br />
It is also possible to specify the colour values of foreground, background, cursorColor, cursorColor2, colorBD, colorUL as a number 0-15, as a<br />
convenient shorthand to reference the colour name of color0-color15.<br />
<br />
Note that -rv ("reverseVideo: True") simulates reverse video by always swapping the foreground/background colours. This is in contrast to xterm(1)<br />
where the colours are only swapped if they have not otherwise been specified. For example,<br />
<br />
rxvt -fg Black -bg White -rv<br />
would yield White on Black, while on xterm(1) it would yield Black on White. <br />
</pre><br />
<br />
==Improving Performance==<br />
*Avoid the use of Xft fonts. If Xft fonts must be used, append {{Codeline|<nowiki>:antialias=false</nowiki>}} to the setting value.<sup>[http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.pod#Can_I_speed_up_Xft_rendering_somehow]</sup><br />
<br />
*Build rxvt-unicode with disabled support for unnecessary features, {{Codeline|--disable-xft}} and {{Codeline|--disable-unicode3}} in particular.<sup>[http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.pod#Rxvt_unicode_uses_gobs_of_memory_how]</sup><br />
<br />
*Limit the number of {{Codeline|saveLines}} (option {{Codeline|-sl}}) in the scrollback buffer to reduce memory usage.<sup>[http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.pod#Isn_t_rxvt_unicode_supposed_to_be_sm]</sup><br />
<br />
*Consider running {{Codeline|urxvtd}} as a daemon accepting connections from {{Codeline|urxvtc}} clients.<br />
<br />
==Cut and Paste==<br />
{{Note|With the use of a VDT multiplexer, urxvt (or any VDT emulator) {{Codeline|CLIPBOARD}} integration will not be effective, since it will not be possible to select all of the desired text in a straightforward fashion or at all, in some cases (e.g., when the active multiplexed terminal is changed to another one and then back to the original one, and one selects text beyond what is visible, which causes text from the other terminal to be displayed). Obviously this is due to the fact that the VDT emulator lacks the ability to distinguish between multiplexed terminals. Therefore, it would be effectively redundant for one who always uses a VDT multiplexer capable of maintaining a scrollback buffer and integrating with {{Codeline|CLIPBOARD}} (e.g., [[tmux]] with [[tmux#ICCCM Selection Integration|customized key bindings]]) to integrate {{Codeline|CLIPBOARD}} with urxvt.}}<br />
<br />
For users unfamiliar with [[Xorg]] data transfer methods, the exchange of information to and from rxvt-unicode can become a burden. Suffice to say that rxvt-unicode uses cut buffers which are typically loaded into the current {{Codeline|PRIMARY}} selection by default.<sup>[http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.1.pod#THE_SELECTION_SELECTING_AND_PASTING_]</sup> Users are urged to review [[Wikipedia:X Window selection]] for additional information.<br />
<br />
====Clipboard Management====<br />
* [http://parcellite.sourceforge.net/ Parcellite] is a GTK+ clipboard manager which can also run in the background as a daemon.<br />
<br />
* [http://www.nongnu.org/autocutsel/ autocutsel] provides command line and daemon interfaces to synchronize PRIMARY, {{Codeline|CLIPBOARD}} and cut buffer selections.<br />
<br />
* [http://glipper.sourceforge.net/ Glipper] is a [[GNOME]] panel applet with older versions available for use in environments other than GNOME.<br />
<br />
* [http://goodies.xfce.org/projects/panel-plugins/xfce4-clipman-plugin Clipman] (xfce-clipman-plugin) is a GUI clipboard manager plugin for the [[Xfce]] panel (xfpanel).<br />
<br />
* [http://sourceforge.net/projects/xclip/ xclip] is a lightweight, command-line based interface to the clipboard.<br />
<br />
====Automatic Script Management====<br />
Skottish[http://bbs.archlinux.org/viewtopic.php?pid=506845#p506845] created a perl script to automatically copy any selection in urxvt to the X clipboard. Save the following as {{Filename|/usr/lib/urxvt/perl/clipboard}}:<br />
<pre><br />
#! /usr/bin/perl<br />
<br />
sub on_sel_grab {<br />
my $query=quotemeta $_[0]->selection;<br />
$query=~ s/\n/\\n/g;<br />
$query=~ s/\r/\\r/g;<br />
system( "echo -en " . $query . " | xsel -i -b -p" );<br />
}<br />
</pre><br />
<br />
Xyne has also created his own variation of Skottish's script (which is also [http://aur.archlinux.org/packages.php?ID=35526 available in the AUR]):<br />
<pre><br />
#! /usr/bin/perl<br />
<br />
sub on_sel_grab {<br />
my $query = $_[0]->selection;<br />
open (my $pipe,'|-','xsel -ibp') or die;<br />
print $pipe $query;<br />
close $pipe;<br />
}<br />
</pre><br />
<br />
It also requires {{Codeline|xsel}} and needs to be enabled in the {{Codeline|*perl-ext-common}} or {{Codeline|*perl-ext}} field in {{Filename|.Xresources}}. For example:<br />
URxvt.perl-ext-common: default,clipboard<br />
<br />
==Improved Kuake-like Behavior in Openbox==<br />
This was originally posted on the forum by Xyne<sup>[http://bbs.archlinux.org/viewtopic.php?pid=550380]</sup> and it relies on {{Codeline|xdotool}} which is available in the community repo.<br />
<br />
===Scriptlets===<br />
Save this scriptlet from the {{Codeline|urxvtc}} man page somewhere on your system as {{Filename|urxvtc}} (e.g., in {{Filename|~/.config/openbox}}):<br />
<pre><br />
#!/bin/sh<br />
urxvtc "$@"<br />
if [ $? -eq 2 ]; then<br />
urxvtd -q -o -f<br />
urxvtc "$@"<br />
fi<br />
</pre><br />
<br />
and save this one as {{Filename|urxvtq}}:<br />
<pre><br />
#!/bin/bash<br />
<br />
wid=$(xdotool search --classname urxvtq)<br />
if [ -z "$wid" ]; then<br />
/path/to/urxvtc -name urxvtq -geometry 80x28<br />
wid=$(xdotool search --classname urxvtq | head -1)<br />
xdotool windowfocus $wid<br />
xdotool key Control_L+l<br />
else<br />
if [ -z "$(xdotool search --onlyvisible --classname urxvtq 2>/dev/null)" ]; then<br />
xdotool windowmap $wid<br />
xdotool windowfocus $wid<br />
else<br />
xdotool windowunmap $wid<br />
fi<br />
fi<br />
</pre><br />
<br />
A previous version of xdotool introduced a bug which disabled recognition of visible windows and thus led some users to use the following scriptlet in place of the previous one. This is no longer necessary as xdotool>=1.20100416.2809, but it has been left here for future reference.<br />
<pre><br />
#!/bin/bash<br />
<br />
wid=$(xprop -name urxvtq | grep 'WM_COMMAND' | awk -F ',' '{print $3}' | awk -F '"' '{print $2}')<br />
if [ -z "$wid" ]; then<br />
/path/to/urxvtc -name urxvtq -geometry 200x28<br />
wid=$(xprop -name urxvtq | grep 'WM_COMMAND' | awk -F ',' '{print $3}' | awk -F '"' '{print $2}')<br />
xdotool windowfocus $wid<br />
xdotool key Control_L+l<br />
else<br />
if [ -z "$(xprop -id $wid | grep 'window state: Normal' 2>/dev/null)" ]; then<br />
xdotool windowmap $wid<br />
xdotool windowfocus $wid<br />
else<br />
xdotool windowunmap $wid<br />
fi<br />
fi<br />
</pre><br />
<br />
Make sure that you change {{Filename|/path/to/urxvtc}} to the actual path to the {{Filename|urxvtc}} scriptlet that you saved above. We'll be using {{Filename|urxvtc}} to launch both regular instances of {{Codeline|urxvt}} and the kuake-like instance.<br />
<br />
===urxvtq with tabbing===<br />
If you want to have tabs in your kuake-like {{Filename|urxvtc}} (here called {{Filename|urxvtq}}) just replace the third line in your {{Filename|urxvtq}}:<br />
wid=$(xdotool search --name urxvtq)<br />
with:<br />
wid=$(xdotool search --name urxvtq | grep -m 1 "" )<br />
<br />
To activate the tab support, you can either replace the fifth line of your {{Filename|urxvtq}}:<br />
/path/to/urxvtc -name urxvtq -geometry 80x28<br />
with:<br />
/path/to/urxvtc -name urxvtq -pe tabbed -geometry 80x28<br />
or replace this line of your {{Filename|.Xresources}}:<br />
URxvt.perl-ext-common: default,matcher<br />
with<br />
URxvt.perl-ext-common: default,matcher,tabbed<br />
<br />
====Tab control====<br />
<SHIFT>-Left: Switch to the tab left of current one<br />
<br />
<SHIFT>-Right: Switch to the tab right of current one<br />
<br />
<SHIFT>-Down: Create a new tab<br />
<br />
You can also use your mouse to switch the tabs by clicking the wished one and create a new tab by clicking on ''[NEW].\\''<br />
<br />
To close a tab just enter 'exit' like you'll close a terminal.<br />
<br />
===Openbox configuration===<br />
Now add the following lines to the {{Codeline|<applications>}} section of {{Filename|~/.config/openbox/rc.xml}}:<br />
<pre><br />
<application name="urxvtq"><br />
<decor>no</decor><br />
<position force="yes"><br />
<x>center</x><br />
<y>0</y><br />
</position><br />
<desktop>all</desktop><br />
<layer>above</layer><br />
<skip_pager>yes</skip_pager><br />
<skip_taskbar>yes</skip_taskbar><br />
<maximized>Horizontal</maximized><br />
</application><br />
</pre><br />
<br />
and add these lines to the {{Codeline|<keyboard>}} section:<br />
<pre><br />
<keybind key="W-t"><br />
<action name="Execute"><br />
<command>/path/to/urxvtc</command><br />
</action><br />
</keybind><br />
<keybind key="W-grave"><br />
<action name="Execute"><br />
<execute>/path/to/urxvtq</execute><br />
</action><br />
</keybind><br />
</pre><br />
<br />
Here too you need to change the {{Filename|/path/to/*}} lines to point to the scripts that you saved above. Save the file and then reconfigure Openbox. You should now be able to launch regular instances of urxvt with the Windows/Super key + "'''t'''", and toggle the kuake-like console with Windows/Super+grave ('''`''').<br />
<br />
===Further configuration===<br />
The advantage of this configuration over the urxvt kuake perl script is that Openbox provides more keybinding options such as modifier keys. The kuake script hijacks an entire physical key regardless of any modifier combination. Review the [http://icculus.org/openbox/index.php/Help:Bindings Openbox bindings documentation] for the full range or possibilities.<br />
<br />
The [http://icculus.org/openbox/index.php/Help:Applications Openbox per-app settings] can be used to further configure the behavior of the kuake-like console (e.g. screen position, layer, etc). You may need to change the "geometry" parameter in the {{Filename|urxvtq}} scriptlet to adjust the height of the console.<br />
<br />
===Related scripts===<br />
*hbekel has posted a generalized version of the {{Filename|urxvtq}} [http://bbs.archlinux.org/viewtopic.php?pid=550380#p550380 here] which can be used to toggle any application using {{Codeline|xdotool}}.<br />
<br />
*http://www.jukie.net/~bart/blog/20070503013555 - A script for opening url's with your keyboard instead of mouse with urxvt.<br />
<br />
==Troubleshooting==<br />
===Transparency not working after upgrade to V9.09===<br />
The rxvt-unicode devs removed compatibility code for a lot of non standard wallpaper setters with this update. Using a non compatible wallpaper setter will break transparency support. Recommended wallpaper setters:<br />
* [[feh]]<br />
* hsetroot<br />
* esetroot<br />
<br />
To make true transparency work, make sure to comment urxvt*tintColor and urxvt*inheritPixmap.<br />
<br />
===Remote Hosts===<br />
If you are logging into a remote host, you may encounter problems when running text-mode programs under rxvt-unicode. This can be fixed by copying {{Filename|<br />
/usr/share/terminfo/r/rxvt-unicode}} from your local machine to your host at {{Filename|~/.terminfo/r/rxvt-unicode}}.<br />
<br />
===Using rxvt-unicode as gmrun terminal===<br />
Unlike some other terminals, urxvt expects the arguments to -e to be given separately, rather than grouped together with quotes. This causes trouble with gmrun, which assumes the opposite behavior. This can be worked around by putting an "eval" in front of gmrun's "Terminal" variable in {{Filename|.gmrunrc}}:<br />
<br />
Terminal = eval urxvt<br />
TermExec = ${Terminal} -e<br />
<br />
(gmrun uses {{Filename|/bin/sh}} to execute commands, so the "eval is understood here.) The "eval" has the side-effect of "breaking up" the argument to -e in the same way $@ does in bash, making the command intelligible to urxvt.<br />
<br />
=== My numerical keypad acts weird and generates differing output? (e.g. in vim) ===<br />
<br />
Some Debian GNU/Linux users seem to have this problem, although no specific details were reported so far. It is possible that this is caused by the wrong TERM setting, although the details of whether and how this can happen are unknown, as TERM=rxvt should offer a compatible keymap. See the answer to the previous question, and please report if that helped.<br />
<br />
However, using ''xmodmap'' program you can re-map your numpad keys back.<br />
<br />
1. Check the keycode that your numerical keypad (numpad) generates using ''xev'' program.<br />
:* Start ''xev'' program<br />
:* Press your numpad keys and looks for ''... keycode xxx ...'' in ''xev'' output. For example, numpad 1 in my keyboard is also "End" key, that have a ''''keycode 87''''.<br />
<br />
2. Create or modify your xmodmap file, usually {{Filename|~/.Xmodmap}}, with the content representing your keycode.<br />
<br />
:Example of xmodmap file with numpad keycode,<br />
<pre><br />
keycode 63 = KP_Multiply<br />
keycode 79 = Home KP_7<br />
keycode 80 = Up KP_8<br />
keycode 81 = Prior KP_9<br />
keycode 82 = KP_Subtract<br />
keycode 83 = Left KP_4<br />
keycode 84 = KP_5<br />
keycode 85 = Right KP_6<br />
keycode 86 = KP_Add<br />
keycode 87 = End KP_1<br />
keycode 88 = Down KP_2<br />
keycode 89 = Next KP_3<br />
keycode 90 = Insert KP_0<br />
keycode 91 = Delete KP_Decimal<br />
keycode 112 = Prior<br />
keycode 117 = Next<br />
</pre><br />
<br />
3. Load your xmodmap file at X session start-up.<br />
<br />
:For example, in {{Filename|~/.xinitrc}} file add,<br />
...<br />
xmodmap ~/.Xmodmap<br />
...<br />
<br />
==External resources==<br />
*[http://software.schmorp.de/pkg/rxvt-unicode.html rxvt-unicode] - Official site<br />
*[http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.pod rxvt-unicode FAQ] - Official FAQ<br />
*[http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.1.pod rxvt-unicode Reference] - Official manual page<br />
*[http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/src/urxvt.pm urxvtperl] - Official Perl extension reference<br />
*{{Codeline|man urxvt}}</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Persistent_block_device_naming&diff=160844Persistent block device naming2011-09-20T19:29:05Z<p>Rnabioullin: Added smartmontools persistent naming information</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:Hardware detection and troubleshooting (English)]]<br />
{{i18n|Persistent block device naming}}<br />
{{Article summary start}}<br />
{{Article summary text|An overview of persistent block device naming; the preferred method of referencing block devices.}}<br />
{{Article summary heading|Related articles}}<br />
{{Article summary wiki|fstab}}<br />
{{Article summary wiki|LVM}}<br />
{{Article summary wiki|SMART}}<br />
{{Article summary end}}<br />
<br />
This article describes how to use persistent names for your block devices. This has been made possible by the introduction of udev and has some advantages over bus-based naming. If your machine has more than one SATA, SCSI or IDE disk controller, the order in which their corresponding device nodes are added is random. This may result in device names like {{Filename|/dev/'''sda'''}} and {{Filename|/dev/'''sdb'''}} switching around randomly on each boot, culminating in an unbootable system, kernel panic, or a block device disappearing. Persistent naming solves these issues. '''Note''' that if you are using [[LVM|LVM2]], this article is not relevant as LVM takes care of this automatically.<br />
<br />
==Persistent naming methods==<br />
<br />
There are four different schemes for persistent naming: by-label, by-uuid, by-id and by-path. The following sections describes what the different persistent naming methods are and how they are used. <br />
<br />
===By-label===<br />
<br />
Almost every filesystem type can have a label. All your partitions that have one are listed in the {{Filename|/dev/disk/by-label}} directory. This directory is created and destroyed dynamically, depending on whether you have partitions with labels attached.<br />
<br />
{{Command|name=ls -lF /dev/disk/by-label|output=<nowiki><br />
total 0<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 data -> ../../sdb2<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 data2 -> ../../sda2<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 fat -> ../../sda6<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 home -> ../../sda7<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 root -> ../../sda1<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 swap -> ../../sda5<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 windows -> ../../sdb1<br />
</nowiki>}}<br />
<br />
The labels of your filesystems can be changed, but note that they have to be unambiguous to prevent any possible conflicts. Following are some methods for changing labels on common filesystems:<br />
<br />
; swap :<br />
# mkswap -L <label> /dev/XXX<br />
{{Warning|This command will destroy your running swap.}} If your swap is mounted, run {{Codeline|swapoff /dev/XXX}} before and {{Codeline|swapon /dev/XXX after}}.<br />
; ext2/ext3/ext4 :<br />
# e2label /dev/XXX <label><br />
; reiserfs :<br />
# reiserfstune -l <label> /dev/XXX<br />
; jfs :<br />
# jfs_tune -L <label> /dev/XXX<br />
; xfs :<br />
# xfs_admin -L <label> /dev/XXX<br />
; fat/vfat (mtools package) :<br />
# mlabel -i /dev/XXX ::<label><br />
; ntfs (ntfsprogs package) :<br />
# ntfslabel /dev/XXX <label><br />
{{Tip|Labels can be up to 16 characters long.}}<br />
<br />
===By-uuid===<br />
<br />
[http://en.wikipedia.org/wiki/UUID UUID] is a mechanism to give each filesystem a unique identifier. It is designed so that collisions are unlikely. All GNU/Linux filesystems (including swap) support UUID. FAT and NTFS filesystems do not support UUID, but are still listed in {{Filename|/dev/disk/by-uuid}} with a unique identifier:<br />
<br />
{{Command|name=ls -lF /dev/disk/by-uuid/|output=<nowiki><br />
total 0<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 2d781b26-0285-421a-b9d0-d4a0d3b55680 -> ../../sda1<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 31f8eb0d-612b-4805-835e-0e6d8b8c5591 -> ../../sda7<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 3FC2-3DDB -> ../../sda6<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 5090093f-e023-4a93-b2b6-8a9568dd23dc -> ../../sda2<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 912c7844-5430-4eea-b55c-e23f8959a8ee -> ../../sda5<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 B0DC1977DC193954 -> ../../sdb1<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 bae98338-ec29-4beb-aacf-107e44599b2e -> ../../sdb2<br />
</nowiki>}}<br />
<br />
As you can see, the FAT and NTFS partitions (''fat'' and ''windows'' labels above) have shorter names, but are still listed. The advantage about using the UUID method is that it is less likely that you have name collisions than with labels. The disadvantage is that UUIDs lose any readability advantage.<br />
<br />
===By-id and by-path===<br />
<br />
by-id creates a unique name depending on the hardware serial number. by-path creates a unique name depending on the shortest physical path (according to sysfs). Both contain strings to indicate which subsystem they belong to (i.e. "-ide-", for 'by-path', and "ata-" for 'by-id') and thus are not suitable for solving the problems mentioned in the beginning of this article. They won't be discussed any further here.<br />
<br />
==Using persistent naming==<br />
<br />
There are various applications that can be configured using persistent naming. Following are some examples of how to configure them.<br />
<br />
===[[Fstab]]===<br />
<br />
To enable persistent naming in {{Filename|/etc/fstab}} replace the device kernel name in the first column with the persistent name path as follows:<br />
<br />
/dev/disk/by-label/home ...<br />
/dev/disk/by-uuid/31f8eb0d-612b-4805-835e-0e6d8b8c5591 ...<br />
<br />
or directly specify the persistent name type using a prefix:<br />
<br />
LABEL=home ...<br />
UUID=1f8eb0d-612b-4805-835e-0e6d8b8c5591 ...<br />
<br />
===Boot managers===<br />
<br />
To use persistent names in your boot manager, the following prerequisites must be met:<br />
<br />
* You are using a [[Configuring mkinitcpio|mkinitcpio]] initial RAM disk image<br />
* You have udev enabled in {{Filename|/etc/mkinitcpio.conf}}<br />
* When your initramfs image was generated, version '''101-3''' or greater of ''klibc-udev'' was installed ('''persistent naming is broken in any earlier version'''). If you are updating ''klibc-udev'' from an earlier version and want to use persistent naming, regenerate your initramfs image before you reboot.<br />
<br />
In the above example, {{Filename|/dev/sda1}} is the root partition. In the [[GRUB]] {{Filename|menu.lst}} file, the ''kernel'' line looks like this:<br />
<br />
kernel /boot/vmlinuz-linux root=/dev/sda1 ro quiet<br />
<br />
Depending on which naming scheme you would prefer, change it to one of the following:<br />
<br />
kernel /boot/vmlinuz-linux root=/dev/disk/by-label/root ro quiet<br />
<br />
or<br />
<br />
kernel /boot/vmlinuz-linux root=/dev/disk/by-uuid/2d781b26-0285-421a-b9d0-d4a0d3b55680 ro quiet<br />
<br />
If you are using [[LILO]], then do not try this with the {{Codeline|1=root=...}} configuration option; it will not work. Use {{Codeline|1=append="root=..."}} or {{Codeline|1=addappend="root=..."}} instead. Read the LILO man page for more information on ''append'' and ''addappend''.<br />
<br />
There is an alternative way to use the label embedded in the filesystem. For example if (as above) the filesystem in {{Filename|/dev/sda1}} is labeled "root", you would give this line to GRUB:<br />
<br />
kernel /boot/vmlinuz-linux root=LABEL=root ro quiet<br />
<br />
===smartmontools===<br />
<br />
See [[SMART#Automatically monitor your drives|SMART: Automatically monitor your drives]]</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=S.M.A.R.T.&diff=160841S.M.A.R.T.2011-09-20T19:13:15Z<p>Rnabioullin: Added persistent naming information</p>
<hr />
<div>[[Category:File systems (English)]]<br />
{{i18n|SMART}}<br />
Self-Monitoring, Analysis, and Reporting Technology, or [http://en.wikipedia.org/wiki/S.M.A.R.T. S.M.A.R.T.], is a monitoring system built on some computer hard disks that stores (and on some hard drives detects) various indicators (SMART Attributes) for the hard disks reliability. It does so in the attempt to detect/prevent anticipatory failures.<br />
<br />
SMART disks may either need software to update SMART Attributes on the hard drive or will include some built-in self tests to detect and protect the hard drive (see manufacturer details).<br />
<br />
This article describes how to install the package smartmontools and use its programs to monitor your hard disk(s).<br />
<br />
==Installing==<br />
For the command line version:<br />
{{Cli|# pacman -S smartmontools}}<br />
<br />
For the GUI version:<br />
{{Cli|# pacman -S gsmartcontrol}}<br />
<br />
==Disk support==<br />
Check if your disk(s) support SMART.<br />
<br />
IDE-disks:<br />
{{Cli|# smartctl -i /dev/hda}}<br />
<br />
SATA-disks:<br />
{{Cli|# smartctl -i -d ata /dev/sda}}<br />
<br />
If it is, you will see:<br />
"SMART support is: Available - device has SMART capability."<br />
"SMART support is: Enabled"<br />
<br />
If SMART is not enabled you can enable it by:<br />
<br />
IDE-disks:<br />
{{Cli|# smartctl -s on /dev/hda}}<br />
<br />
SATA-discs:<br />
{{Cli|# smartctl -s on -d ata /dev/sda}}<br />
<br />
==Test the hard drive==<br />
Your SMART hard disk may have built-in self-tests that do some checks to record the state of the hard disk and may optionally protect it from common problems (i.e. bad blocks). If you do not know for certain, have smartctl run tests to update the SMART Attributes on your hard disk.<br />
<br />
To know first which tests the device supports:<br />
{{Cli|# smartctl -c /dev/<your-hard-disk>}}<br />
<br />
To run the test:<br />
{{Cli|# smartctl -t offline /dev/<your-hard-disk>}}<br />
<br />
smartctl will tell you how long the test will take. When it is finished you can check the health status to see if there are any problems.<br />
<br />
{{Note| Most smartctl commands require the -d ata or -d sat options to identify drives that are not IDE.}}<br />
<br />
==Health status check==<br />
SMART hard disks keep a record of the hard disks health status that can be checked with:<br />
{{Cli|# smartctl -H /dev/sda}}<br />
<br />
If the hard drive status is healthy it will return the status as: 'PASSED'.<br />
<br />
If the device reports a failing health status, it means that the device has either already failed, or is predicting its own failure within the next 24 hours. Append the "-a" option to get more information.<br />
<br />
To see if the SMART sensor has detected any errors, look at the SMART Error Log:<br />
{{Cli|# smartctl -l error /dev/sda}}<br />
<br />
If "No Errors Logged" is printed, your hard drive is likely healthy. If there are a few errors this may or may not indicate a problem and you should investigate the matter further. Generally when a drive starts to fail it is best practice to backup its data and replace the hard drive.<br />
<br />
{{Note| See {{Codeline|man smartctl}} for other tests and more information.}}<br />
<br />
==Automatically monitor your drives==<br />
smartmontools includes a daemon that will check and update your hard disks status and can optionally mail you of any potential problems. The smart daemon can be edited for more exact configuration in {{Filename|/etc/smartd.conf}}.<br />
<br />
If the configuration is not edited, smartd will run tests periodically on ''all'' possible SMART Attributes on all devices it detects. The first non-commented entry in the configuration file (DEVICESCAN) will have smartd ignore the remaining lines in the configuration file, and will scan for devices. For devices with an [http://en.wikipedia.org/wiki/S.M.A.R.T.#S.M.A.R.T._information ATA Attachment], if no options are configured, the daemon will use the '-a' option by default (monitor all SMART properties) on all hard drives.<br />
<br />
In order to have the drives checked only when they are not in standby (hence avoid them to spin up unnecessarily), you may add the following options:<br />
DEVICESCAN -n standby,q -a<br />
<br />
To make a configuration for individual devices, you have to comment the line with DEVICESCAN and add a configuration line for every device. It is recommended to reference devices by the ID (which is derived from the device's model and serial number) rather than a udev name, since the latter is not guaranteed to refer to the same physical device across reboots. Here is an example:<br />
#DEVICESCAN<br />
/dev/disk/by-id/scsi-SATA_Hitachi_HTS5432090609FB22015CCNRD6A -a -m root@localhost<br />
<br />
This will monitor all attributes and send an email to root@localhost if a failure or new error occurs. To be able to send internal mail, you need a mail sender (like [[SSMTP]] or [[Msmtp]]) installed, or a mail server (MTA Message Transfer Agent) like sendmail or [[Postfix Local Mail]]. More examples are given in the configuration file.<br />
<br />
Once you can send mails out, you can change the root@localhost by your actual email address:<br />
DEVICESCAN -n standby,q -a -m myuser@gmail.com<br />
<br />
[[Daemon#Performing daemon actions manually|Start the smartd daemon]] and add smartd to your [[Daemons#Starting on Boot|DAEMONS array]] so it starts automatically on boot.<br />
<br />
Last but not least, if you used the -m option to get mail notifications, you should test that the mail alert works fine. To do so, simply add the '-M test' option to the configuration line and restart smartd daemon:<br />
DEVICESCAN -n standby,q -a -m myuser@gmail.com -M test<br />
<br />
To restart the daemon:<br />
{{Cli|# /etc/rc.d/smartd restart}}<br />
<br />
The mail test result can be seen in your mailbox (be a bit patient) but also in {{Filename|/var/log/daemon.log}} :<br />
Feb 1 20:07:11 localhost smartd[2306]: Monitoring 3 ATA and 0 SCSI devices<br />
Feb 1 20:07:11 localhost smartd[2306]: Executing test of mail to myuser@gmail.com ...<br />
Feb 1 20:07:14 localhost smartd[2306]: Test of mail to myuser@gmail.com: successful<br />
<br />
Once the test succeeded, do not forget to remove the '-M test' option.<br />
<br />
Smartd uses "mail" (mailx) to send messages, which expects sendmail to be installed. If you use [[Msmtp]], tell mail to use it:<br />
{{file|name=/etc/mail.rc|content=set sendmail=/usr/bin/msmtp}}<br />
<br />
==Other tips==<br />
Other tips that can help setup smartmontool programs<br />
<br />
===Get SMART details===<br />
You can get all SMART details of your drive with:<br />
<br />
IDE-disks:<br />
{{Cli|# smartctl -a /dev/hda}}<br />
<br />
SATA-discs:<br />
{{Cli|# smartctl -a -d ata /dev/sda}}<br />
<br />
== External links ==<br />
<br />
* [http://smartmontools.sourceforge.net/ Smartmontools Homepage]<br />
* [https://help.ubuntu.com/community/Smartmontools Smartmontools on Ubuntu Wiki]</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Tmux&diff=160648Tmux2011-09-19T02:11:17Z<p>Rnabioullin: </p>
<hr />
<div>{{i18n|Tmux}}<br />
[[Category:Software (English)]]<br />
Tmux is a "terminal multiplexer: it enables a number of terminals (or windows), each running a separate program, to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached." [http://tmux.sourceforge.net/]<br />
<br />
Tmux is notable as a BSD-licensed alternative to [[Screen Tips|GNU Screen]]. Although similar, there are many differences between the programs, as noted on the [http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ tmux FAQ page]. Most notably, tmux is currently under active development, in contrast to screen, which hasn't had a stable release since August 8, 2008.<br />
<br />
==Install==<br />
A stable version of tmux may be installed using [[pacman]]:<br />
# pacman -S tmux<br />
Alternatively, [https://aur.archlinux.org/packages.php?ID=35618 tmux-git] is available from the [[AUR]].<br />
<br />
==Configure==<br />
A user-specific configuration file should be located at {{filename|~/.tmux.conf}}, while a global configuration file should be located at {{filename|/etc/tmux.conf}}. Default configuration files can be found in {{Codeline|/usr/share/tmux/}}. <br />
<br />
===Key bindings===<br />
{| style="float:right;border:1px #cccccc solid;margin:5px;padding:5px;width:200px;"<br />
|+ ''Prefix all commands with'' {{Codeline|Ctrl-b}}<br />
!Cmd<br />
!Action<br />
|-<br />
|c<br />
|Create a new window<br />
|-<br />
|n<br />
|Change to next window<br />
|-<br />
|p<br />
|Change to previous window<br />
|-<br />
|"<br />
|Split pane horizontally<br />
|-<br />
|%<br />
|Split pane vertically<br />
|-<br />
|,<br />
|Rename current window<br />
|-<br />
|o<br />
|Move to next pane<br />
|}<br />
<br />
By default, command key bindings are prefixed by Ctrl-b. For example, to vertically split a window type {{Codeline|Ctrl-b %}}.<br />
<br />
After splitting a window into multiple panes, you can resize a pane by the hitting prefix key (i.e. {{Codeline|Ctrl-b}}) and, while continuing to hold Ctrl, press Left/Right/Up/Down. Swapping panes is achieved in the same manner, but by hitting ''o'' instead of a directional key.<br />
<br />
{{Tip|To mimic screen key bindings copy {{filename|/usr/share/tmux/screen-keys.conf}} to either of the configuration locations.}}<br />
<br />
Key bindings may be changed with the bind and unbind commands in {{filename|tmux.conf}}. For example, you can change the prefix key (i.e. {{Codeline|Ctrl-b}}) to {{Codeline|Ctrl-a}} by adding the following commands in your configuration file:<br />
unbind C-b<br />
set -g prefix C-a<br />
<br />
Additional ways to move between windows include:<br />
Ctrl-b l (Move to the previously selected window)<br />
Ctrl-b w (List all windows / window numbers)<br />
Ctrl-b <window number> (Move to the specified window number, the default bindings are from 0 – 9)<br />
Ctrl-b q (Show pane numbers, when the numbers show up type the key to goto that pane)<br />
<br />
What if you have 10+ windows open? Tmux has a find-window option & keybinding. <br />
Ctrl-b f <window name> (Search for window name)<br />
Ctrl-b w (Select from interactive list of windows)<br />
<br />
===Browsing URL's===<br />
To browse URL's inside tmux you must have urlview installed and configured:<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; run-shell "$TERMINAL -e 'cat /tmp/tmux-buffer | urlview'"<br />
<br />
=== Setting the correct term===<br />
If you are using a 256 colour terminal, you will need to set the correct term in tmux. You can do this in either the {{filename|tmux.conf}}:<br />
<br />
set -g default-terminal "screen-256color" <br />
<br />
or in your {{filename|.bashrc}} with a test like:<br />
<br />
# for tmux: export 256color<br />
[ -n "$TMUX" ] && export TERM=screen-256color<br />
<br />
==Session initialization==<br />
You can have tmux open a session with preloaded windows by including those details in your .tmux.conf<br />
<br />
new -n WindowName Command<br />
neww -n WindowName Command<br />
neww -n WindowName Command<br />
<br />
To start a session with split windows (multiple panes), include the splitw command below the neww you would like to split; thus:<br />
<br />
new -s SessionName -n WindowName Command<br />
neww -n foo/bar foo<br />
splitw -v -p 50 -t 0 bar<br />
selectw -t 1 <br />
selectp -t 0<br />
<br />
would open 2 windows, the second of which would be named foo/bar and would be split vertically in half (50%) with foo running above bar. Focus would be in window 2 (foo/bar), top pane (foo).<br />
<br />
{{Note|Numbering for sessions, windows and panes starts at zero, unless you have specified a base-index of 1 in your {{filename|.conf}} }}<br />
<br />
To manage multiple sessions, source separate session files from your conf file:<br />
<br />
# initialize sessions<br />
bind F source-file ~/.tmux/foo<br />
bind B source-file ~/.tmux/bar<br />
<br />
==Scrolling issues==<br />
If you have issues scrolling with Shift-PageUp/Shift-PageDown in your terminal, try this:<br />
<br />
set -g terminal-overrides 'xterm*:smcup@:rmcup@'<br />
<br />
==Split window and remain current directory==<br />
Create a excutable file as follows, for example ~/mbin/split-tmux:<br />
#!/usr/bin/env bash<br />
PWD=`pwd`<br />
tmux split-window $1<br />
tmux send-keys " cd $PWD;clear"<br />
tmux send-keys "Enter"<br />
<br />
and change the configure from:<br />
bind v split-window -h<br />
bind n split-window -v<br />
to<br />
bind v send-keys " ~/mbin/split-tmux -h" \; send-keys "Enter"<br />
bind n send-keys " ~/mbin/split-tmux -v" \; send-keys "Enter"<br />
(However, this trick doesn't work when you are using vim.)<br />
<br />
==ICCCM Selection Integration==<br />
It is possible to copy a tmux paste buffer to an ICCCM selection, and vice-versa, by defining a shell command which interfaces tmux with an X11 selection interface. The following tmux config file snippet effectively integrates {{Codeline|CLIPBOARD}} with the current tmux paste buffer using xclip:<br />
<br />
{{File|name=~/.tmux.conf|content=<br />
...<br />
##CLIPBOARD selection integration<br />
##Requires prefix key before the command key<br />
#Copy tmux paste buffer to CLIPBOARD<br />
bind C-c run "tmux show-buffer <nowiki>|</nowiki> xclip -i -selection clipboard"<br />
#Copy CLIPBOARD to tmux paste buffer and paste tmux paste buffer<br />
bind C-v run "tmux set-buffer \"$(xclip -o -selection clipboard)\"; tmux paste-buffer"<br />
}}<br />
<br />
==Tips & tricks!==<br />
To start tmux when you login to a standard terminal, simply add the following line of bash code to your .bashrc before your aliases..<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
Example .bashrc:<br />
#<br />
# ~/.bashrc<br />
#<br />
<br />
# If not running interactively, don't do anything<br />
&#91;&#91; $- != *i* &#93;&#93; && return<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
# Irrelevant from here on, but does show that things here are working from within tmux..<br />
alias svile="sudo vile"<br />
alias updatedb="sudo updatedb"<br />
alias nopaste="curl -F 'sprunge=<-' http://sprunge.us"<br />
pacman() {<br />
case $1 in<br />
-S | -S[^sih]* | -R* | -U*)<br />
/usr/bin/sudo /usr/bin/pacman-color "$@" ;;<br />
*) /usr/bin/pacman-color "$@" ;;<br />
esac<br />
}<br />
<br />
{{note|At first you may read screen as if we were using screen and not tmux, but tmux also uses screen for the TERM enviroment variable..}}<br />
<br />
This snippet does the same thing, but also checks tmux is installed before trying to launch it. It also tries to reattach you to an existing tmux session at logout, so that you can shut down every tmux session quickly from the same terminal at logout.<br />
# TMUX<br />
if which tmux 2>&1 >/dev/null; then<br />
# if no session is started, start a new session<br />
if test -z ${TMUX}; then<br />
tmux<br />
fi<br />
# when quitting tmux, try to attach<br />
while test -z ${TMUX}; do<br />
tmux attach || break<br />
done<br />
fi<br />
<br />
==See also==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=84157&p=1 Tmux topic on Arch forums]<br />
* [[Screen|GNU Screen]]<br />
* [http://www.openbsd.org/faq/faq7.html#tmux Tmux tutorial from OpenBSD FAQ]<br />
* [http://www.dayid.org/os/notes/tm.html Tmux/Screen cheat sheet]<br />
* [http://www.jeffstory.org/wordpress/?p=132 Tmux tutorial]</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Tmux&diff=160647Tmux2011-09-19T02:05:47Z<p>Rnabioullin: Added ICCCM Integration Procedure</p>
<hr />
<div>{{i18n|Tmux}}<br />
[[Category:Software (English)]]<br />
Tmux is a "terminal multiplexer: it enables a number of terminals (or windows), each running a separate program, to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached." [http://tmux.sourceforge.net/]<br />
<br />
Tmux is notable as a BSD-licensed alternative to [[Screen Tips|GNU Screen]]. Although similar, there are many differences between the programs, as noted on the [http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ tmux FAQ page]. Most notably, tmux is currently under active development, in contrast to screen, which hasn't had a stable release since August 8, 2008.<br />
<br />
==Install==<br />
A stable version of tmux may be installed using [[pacman]]:<br />
# pacman -S tmux<br />
Alternatively, [https://aur.archlinux.org/packages.php?ID=35618 tmux-git] is available from the [[AUR]].<br />
<br />
==Configure==<br />
A user-specific configuration file should be located at {{filename|~/.tmux.conf}}, while a global configuration file should be located at {{filename|/etc/tmux.conf}}. Default configuration files can be found in {{Codeline|/usr/share/tmux/}}. <br />
<br />
===Key bindings===<br />
{| style="float:right;border:1px #cccccc solid;margin:5px;padding:5px;width:200px;"<br />
|+ ''Prefix all commands with'' {{Codeline|Ctrl-b}}<br />
!Cmd<br />
!Action<br />
|-<br />
|c<br />
|Create a new window<br />
|-<br />
|n<br />
|Change to next window<br />
|-<br />
|p<br />
|Change to previous window<br />
|-<br />
|"<br />
|Split pane horizontally<br />
|-<br />
|%<br />
|Split pane vertically<br />
|-<br />
|,<br />
|Rename current window<br />
|-<br />
|o<br />
|Move to next pane<br />
|}<br />
<br />
By default, command key bindings are prefixed by Ctrl-b. For example, to vertically split a window type {{Codeline|Ctrl-b %}}.<br />
<br />
After splitting a window into multiple panes, you can resize a pane by the hitting prefix key (i.e. {{Codeline|Ctrl-b}}) and, while continuing to hold Ctrl, press Left/Right/Up/Down. Swapping panes is achieved in the same manner, but by hitting ''o'' instead of a directional key.<br />
<br />
{{Tip|To mimic screen key bindings copy {{filename|/usr/share/tmux/screen-keys.conf}} to either of the configuration locations.}}<br />
<br />
Key bindings may be changed with the bind and unbind commands in {{filename|tmux.conf}}. For example, you can change the prefix key (i.e. {{Codeline|Ctrl-b}}) to {{Codeline|Ctrl-a}} by adding the following commands in your configuration file:<br />
unbind C-b<br />
set -g prefix C-a<br />
<br />
Additional ways to move between windows include:<br />
Ctrl-b l (Move to the previously selected window)<br />
Ctrl-b w (List all windows / window numbers)<br />
Ctrl-b <window number> (Move to the specified window number, the default bindings are from 0 – 9)<br />
Ctrl-b q (Show pane numbers, when the numbers show up type the key to goto that pane)<br />
<br />
What if you have 10+ windows open? Tmux has a find-window option & keybinding. <br />
Ctrl-b f <window name> (Search for window name)<br />
Ctrl-b w (Select from interactive list of windows)<br />
<br />
===Browsing URL's===<br />
To browse URL's inside tmux you must have urlview installed and configured:<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; run-shell "$TERMINAL -e 'cat /tmp/tmux-buffer | urlview'"<br />
<br />
=== Setting the correct term===<br />
If you are using a 256 colour terminal, you will need to set the correct term in tmux. You can do this in either the {{filename|tmux.conf}}:<br />
<br />
set -g default-terminal "screen-256color" <br />
<br />
or in your {{filename|.bashrc}} with a test like:<br />
<br />
# for tmux: export 256color<br />
[ -n "$TMUX" ] && export TERM=screen-256color<br />
<br />
==Session initialization==<br />
You can have tmux open a session with preloaded windows by including those details in your .tmux.conf<br />
<br />
new -n WindowName Command<br />
neww -n WindowName Command<br />
neww -n WindowName Command<br />
<br />
To start a session with split windows (multiple panes), include the splitw command below the neww you would like to split; thus:<br />
<br />
new -s SessionName -n WindowName Command<br />
neww -n foo/bar foo<br />
splitw -v -p 50 -t 0 bar<br />
selectw -t 1 <br />
selectp -t 0<br />
<br />
would open 2 windows, the second of which would be named foo/bar and would be split vertically in half (50%) with foo running above bar. Focus would be in window 2 (foo/bar), top pane (foo).<br />
<br />
{{Note|Numbering for sessions, windows and panes starts at zero, unless you have specified a base-index of 1 in your {{filename|.conf}} }}<br />
<br />
To manage multiple sessions, source separate session files from your conf file:<br />
<br />
# initialize sessions<br />
bind F source-file ~/.tmux/foo<br />
bind B source-file ~/.tmux/bar<br />
<br />
==Scrolling issues==<br />
If you have issues scrolling with Shift-PageUp/Shift-PageDown in your terminal, try this:<br />
<br />
set -g terminal-overrides 'xterm*:smcup@:rmcup@'<br />
<br />
==Split window and remain current directory==<br />
Create a excutable file as follows, for example ~/mbin/split-tmux:<br />
#!/usr/bin/env bash<br />
PWD=`pwd`<br />
tmux split-window $1<br />
tmux send-keys " cd $PWD;clear"<br />
tmux send-keys "Enter"<br />
<br />
and change the configure from:<br />
bind v split-window -h<br />
bind n split-window -v<br />
to<br />
bind v send-keys " ~/mbin/split-tmux -h" \; send-keys "Enter"<br />
bind n send-keys " ~/mbin/split-tmux -v" \; send-keys "Enter"<br />
(However, this trick doesn't work when you are using vim.)<br />
<br />
==ICCCM Selection Integration==<br />
It is possible to copy a tmux paste buffer to an ICCCM selection, and vice-versa, by defining a shell command which interfaces tmux with an X11 selection interface. The following tmux config file snippet effectively integrates {{Codeline|CLIPBOARD}} with the current tmux paste buffer using xclip:<br />
<br />
{{File|name=~/.tmux.conf|content=<br />
...<br />
##CLIPBOARD selection integration<br />
##Requires prefix key before the command key<br />
#Copy tmux paste buffer to CLIPBOARD verbatim<br />
bind C-c run "tmux show-buffer <nowiki>|</nowiki> xclip -i -selection clipboard"<br />
#Copy CLIPBOARD to tmux paste buffer and paste tmux paste buffer<br />
bind C-v run "tmux set-buffer \"$(xclip -o -selection clipboard)\"; tmux paste-buffer"<br />
}}<br />
<br />
==Tips & tricks!==<br />
To start tmux when you login to a standard terminal, simply add the following line of bash code to your .bashrc before your aliases..<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
Example .bashrc:<br />
#<br />
# ~/.bashrc<br />
#<br />
<br />
# If not running interactively, don't do anything<br />
&#91;&#91; $- != *i* &#93;&#93; && return<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
# Irrelevant from here on, but does show that things here are working from within tmux..<br />
alias svile="sudo vile"<br />
alias updatedb="sudo updatedb"<br />
alias nopaste="curl -F 'sprunge=<-' http://sprunge.us"<br />
pacman() {<br />
case $1 in<br />
-S | -S[^sih]* | -R* | -U*)<br />
/usr/bin/sudo /usr/bin/pacman-color "$@" ;;<br />
*) /usr/bin/pacman-color "$@" ;;<br />
esac<br />
}<br />
<br />
{{note|At first you may read screen as if we were using screen and not tmux, but tmux also uses screen for the TERM enviroment variable..}}<br />
<br />
This snippet does the same thing, but also checks tmux is installed before trying to launch it. It also tries to reattach you to an existing tmux session at logout, so that you can shut down every tmux session quickly from the same terminal at logout.<br />
# TMUX<br />
if which tmux 2>&1 >/dev/null; then<br />
# if no session is started, start a new session<br />
if test -z ${TMUX}; then<br />
tmux<br />
fi<br />
# when quitting tmux, try to attach<br />
while test -z ${TMUX}; do<br />
tmux attach || break<br />
done<br />
fi<br />
<br />
==See also==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=84157&p=1 Tmux topic on Arch forums]<br />
* [[Screen|GNU Screen]]<br />
* [http://www.openbsd.org/faq/faq7.html#tmux Tmux tutorial from OpenBSD FAQ]<br />
* [http://www.dayid.org/os/notes/tm.html Tmux/Screen cheat sheet]<br />
* [http://www.jeffstory.org/wordpress/?p=132 Tmux tutorial]</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Rxvt-unicode&diff=160644Rxvt-unicode2011-09-19T01:31:47Z<p>Rnabioullin: Clarified the Necessity of CLIPBOARD Integration</p>
<hr />
<div>[[Category:Terminal emulators (English)]]<br />
{{DISPLAYTITLE:rxvt-unicode}}<br />
[[fr:urxvt]]<br />
{{i18n|Rxvt-unicode}}<br />
<br />
[http://software.schmorp.de/pkg/rxvt-unicode.html rxvt-unicode] is a highly customizable [[Terminal Emulator|terminal emulator]] forked from [[Wikipedia:Rxvt|rxvt]]. Commonly known as {{Codeline|urxvt}}, rxvt-unicode can be [[daemon]]ized to run clients within a single [[Wikipedia:Process (computing)|process]] in order to minimize the use of system resources. Developed by Marc Lehmann, some of the more outstanding features of rxvt-unicode include international language support through [[Wikipedia:Unicode|Unicode]], the ability to display multiple font types and support for [[Wikipedia:Perl|Perl]] extensions.<br />
<br />
==Installation==<br />
<br />
{{Package Official|rxvt-unicode}} is available in [extra] and includes 256 color support:<br />
<br />
# pacman -S rxvt-unicode<br />
<br />
{{Package AUR|rxvt-unicode-patched}} is available in the [[AUR]] and includes a fix for the font width bug and adds support for ignoring window size hints (lock the window size to n_columns * column_width, etc.) without dead space.<br />
<br />
==Configuration==<br />
See the [http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.1.pod rxvt-unicode reference page] for the complete list of available setting and values.<br />
<br />
===Creating ~/.Xresources===<br />
The look, feel and function of rxvt-unicode is controlled by command-line arguments and/or [[Wikipedia:X resources|X resources]]. X resources can be set using {{Filename|~/.Xresources}} and xrdb, see the [[Xresources|wiki page]] for details.<br />
<br />
{{Note|Command-line arguments override and take precedence over the resource settings established in this file.}}<br />
<br />
===True transparency===<br />
<br />
To use true transparency you need to be using a window manager that supports compositing or a separate compositor.<br />
<br />
From the command-line:<br />
<br />
$ urxvt -depth 32 -bg rgba:3f00/3f00/3f00/dddd<br />
<br />
Using the configuration file:<br />
<br />
{{File|name=~/.Xresources|content=<br />
URxvt.depth: 32<br />
URxvt.background: rgba:1111/1111/1111/dddd<br />
}}<br />
<br />
===Scrollbar===<br />
The look of the scrollbar can be chosen through this entry in {{Filename|~/.Xresources}}:<br />
<br />
<pre><br />
! scrollbar style - rxvt (default), plain (most compact), next, or xterm<br />
URxvt*scrollstyle:rxvt<br />
</pre><br />
<br />
The scrollbar can also be completely deactivated like so:<br />
<br />
<pre><br />
URxvt.scrollBar: off<br />
</pre><br />
<br />
===Font Declaration Methods===<br />
URxvt.font: 9x15<br />
is the same as:<br />
URxvt.font: -misc-fixed-medium-r-normal--15-140-75-75-c-90-iso8859-1<br />
and:<br />
URxvt.font: 9x15bold<br />
is the same as:<br />
URxvt.font: -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1<br />
<br />
The complete list of short names for X core fonts can be found in {{Filename|/usr/share/fonts/misc/fonts.alias}} (there's also some fonts.alias files in some of the other subdirectories of {{Filename|/usr/share/fonts/}}, but as they are packaged separately from the actual fonts, they may list fonts you don't actually have installed). It is worth noting that these short aliases select for ISO-8859-1 versions of the fonts rather than ISO-10646-1 (Unicode) versions, and 75 DPI rather than 100 DPI versions, so you're probably better off avoiding them and choosing fonts by their full long names instead.<br />
<br />
{{Note|The above paragraph is only for bitmap fonts. Xft fonts can be specified using the following format:}}<br />
<br />
URxvt.font: xft:monaco:size=10<br />
<br />
Or<br />
<br />
URxvt.font: xft:monaco:bold:size=10<br />
<br />
==Perl extensions==<br />
===Clickable URLs===<br />
You can make URLs in the terminal clickable using the matcher extension. For example, to open links in [[Firefox]] add the following to {{Filename|.Xresources}}:<br />
URxvt.perl-ext-common: default,matcher<br />
URxvt.urlLauncher: /usr/bin/firefox<br />
URxvt.matcher.button: 1 <br />
<br />
===Yankable URLs (No Mouse)===<br />
In addition, you can select and open URLs in your web browser without using the mouse.<br />
<br />
Install the {{Package Official|urxvt-url-select}} package from the [community] repo and adjust your {{Filename|.Xresources}} as necessary. An example is shown below:<br />
URxvt.perl-ext: default,url-select<br />
URxvt.keysym.M-u: perl:url-select:select_next<br />
URxvt.urlLauncher: firefox<br />
URxvt.underlineURLs: true<br />
<br />
{{Note|This extension replaces the Clickable URLs extension mentioned above, so {{Codeline|matcher}} can be removed from the {{Codeline|URxvt.perl-ext}} list.}}<br />
<br />
'''Key commands:'''<br />
<br />
{{Keypress|Alt}} + {{Keypress|U}} Enter selection mode. The last URL on your screen will be selected. You can repeat {{Codeline|Alt+u}} to select the next upward URL.<br />
<br />
{{Keypress|k}} Select next upward URL<br />
<br />
{{Keypress|j}} Select next downward URL<br />
<br />
{{Keypress|Return}} Open selected URL in browser and quit selection mode<br />
<br />
{{Keypress|o}} Open selected URL in browser without quitting selection mode<br />
<br />
{{Keypress|y}} Copy (yank) selected URL and quit selection mode<br />
<br />
{{Keypress|Esc}} Cancel URL selection mode<br />
<br />
===Tabs===<br />
To add tabs to urxvt, add the following to your {{Filename|~/.Xresources}}:<br />
<pre><br />
URxvt.perl-ext-common: default,tabbed<br />
</pre><br />
<br />
To control tabs use:<br />
<br />
{{Keypress|Shift}} + {{Keypress|↓}} new tab<br />
<br />
{{Keypress|Shift}} + {{Keypress|←}} go to left tab<br />
<br />
{{Keypress|Shift}} + {{Keypress|→}} go to right tab<br />
<br />
{{Keypress|Ctrl}} + {{Keypress|←}} move tab to the left<br />
<br />
{{Keypress|Ctrl}} + {{Keypress|→}} move tab to the right<br />
<br />
{{Keypress|Ctrl}} + {{Keypress|d}}: close tab <br />
<br />
You can change tabs' colors with the following:<br />
<pre><br />
URxvt.tabbed.tabbar-fg: 2<br />
URxvt.tabbed.tabbar-bg: 0<br />
URxvt.tabbed.tab-fg: 3<br />
URxvt.tabbed.tab-bg: 0<br />
</pre><br />
<br />
For named tabs, see {{Package AUR|urxvt-tabbedex}}, (Shift+Up: names a tab).<br />
<br />
==Colors==<br />
Colors must be specified using color indexes: 0 to 15 correspond with the colors from the rxvt manual "Colors and Graphics" Section.<br />
<pre>COLORS AND GRAPHICS<br />
<br />
If graphics support was enabled at compile-time, rxvt can be queried with ANSI escape sequences and can address individual pixels instead of text<br />
characters. Note the graphics support is still considered beta code.<br />
<br />
In addition to the default foreground and background colours, rxvt can display up to 16 colours (8 ANSI colours plus high-intensity bold/blink<br />
versions of the same). Here is a list of the colours with their rgb.txt names.<br />
<br />
color0 (black) = Black<br />
color1 (red) = Red3<br />
color2 (green) = Green3<br />
color3 (yellow) = Yellow3<br />
color4 (blue) = Blue3<br />
color5 (magenta) = Magenta3<br />
color6 (cyan) = Cyan3<br />
color7 (white) = AntiqueWhite<br />
color8 (bright black) = Grey25<br />
color9 (bright red) = Red<br />
color10 (bright green) = Green<br />
color11 (bright yellow) = Yellow<br />
color12 (bright blue) = Blue<br />
color13 (bright magenta)= Magenta<br />
color14 (bright cyan) = Cyan<br />
color15 (bright white) = White<br />
foreground = Black<br />
background = White<br />
<br />
It is also possible to specify the colour values of foreground, background, cursorColor, cursorColor2, colorBD, colorUL as a number 0-15, as a<br />
convenient shorthand to reference the colour name of color0-color15.<br />
<br />
Note that -rv ("reverseVideo: True") simulates reverse video by always swapping the foreground/background colours. This is in contrast to xterm(1)<br />
where the colours are only swapped if they have not otherwise been specified. For example,<br />
<br />
rxvt -fg Black -bg White -rv<br />
would yield White on Black, while on xterm(1) it would yield Black on White. <br />
</pre><br />
<br />
==Improving Performance==<br />
*Avoid the use of Xft fonts. If Xft fonts must be used, append {{Codeline|<nowiki>:antialias=false</nowiki>}} to the setting value.<sup>[http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.pod#Can_I_speed_up_Xft_rendering_somehow]</sup><br />
<br />
*Build rxvt-unicode with disabled support for unnecessary features, {{Codeline|--disable-xft}} and {{Codeline|--disable-unicode3}} in particular.<sup>[http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.pod#Rxvt_unicode_uses_gobs_of_memory_how]</sup><br />
<br />
*Limit the number of {{Codeline|saveLines}} (option {{Codeline|-sl}}) in the scrollback buffer to reduce memory usage.<sup>[http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.pod#Isn_t_rxvt_unicode_supposed_to_be_sm]</sup><br />
<br />
*Consider running {{Codeline|urxvtd}} as a daemon accepting connections from {{Codeline|urxvtc}} clients.<br />
<br />
==Cut and Paste==<br />
{{Note|With the use of a VDT multiplexer, urxvt (or any VDT emulator) {{Codeline|CLIPBOARD}} integration will not be effective, since it will not be possible to select all of the desired text in a straightforward fashion or at all, in some cases (e.g., when the active multiplexed terminal is changed to another one and then back to the original one, and one selects text beyond what is visible, which causes text from the other terminal to be displayed). Obviously this is due to the fact that the VDT emulator lacks the ability to distinguish between multiplexed terminals. Therefore, it would be effectively redundant for one who always uses a VDT multiplexer capable of maintaining a scrollback buffer and integrating with {{Codeline|CLIPBOARD}} (e.g., [[tmux]] with customized bindings) to integrate {{Codeline|CLIPBOARD}} with urxvt.}}<br />
<br />
For users unfamiliar with [[Xorg]] data transfer methods, the exchange of information to and from rxvt-unicode can become a burden. Suffice to say that rxvt-unicode uses cut buffers which are typically loaded into the current {{Codeline|PRIMARY}} selection by default.<sup>[http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.1.pod#THE_SELECTION_SELECTING_AND_PASTING_]</sup> Users are urged to review [[Wikipedia:X Window selection]] for additional information.<br />
<br />
====Clipboard Management====<br />
* [http://parcellite.sourceforge.net/ Parcellite] is a GTK+ clipboard manager which can also run in the background as a daemon.<br />
<br />
* [http://www.nongnu.org/autocutsel/ autocutsel] provides command line and daemon interfaces to synchronize PRIMARY, {{Codeline|CLIPBOARD}} and cut buffer selections.<br />
<br />
* [http://glipper.sourceforge.net/ Glipper] is a [[GNOME]] panel applet with older versions available for use in environments other than GNOME.<br />
<br />
* [http://goodies.xfce.org/projects/panel-plugins/xfce4-clipman-plugin Clipman] (xfce-clipman-plugin) is a GUI clipboard manager plugin for the [[Xfce]] panel (xfpanel).<br />
<br />
* [http://sourceforge.net/projects/xclip/ xclip] is a lightweight, command-line based interface to the clipboard.<br />
<br />
====Automatic Script Management====<br />
Skottish[http://bbs.archlinux.org/viewtopic.php?pid=506845#p506845] created a perl script to automatically copy any selection in urxvt to the X clipboard. Save the following as {{Filename|/usr/lib/urxvt/perl/clipboard}}:<br />
<pre><br />
#! /usr/bin/perl<br />
<br />
sub on_sel_grab {<br />
my $query=quotemeta $_[0]->selection;<br />
$query=~ s/\n/\\n/g;<br />
$query=~ s/\r/\\r/g;<br />
system( "echo -en " . $query . " | xsel -i -b -p" );<br />
}<br />
</pre><br />
<br />
Xyne has also created his own variation of Skottish's script (which is also [http://aur.archlinux.org/packages.php?ID=35526 available in the AUR]):<br />
<pre><br />
#! /usr/bin/perl<br />
<br />
sub on_sel_grab {<br />
my $query = $_[0]->selection;<br />
open (my $pipe,'|-','xsel -ibp') or die;<br />
print $pipe $query;<br />
close $pipe;<br />
}<br />
</pre><br />
<br />
It also requires {{Codeline|xsel}} and needs to be enabled in the {{Codeline|*perl-ext-common}} or {{Codeline|*perl-ext}} field in {{Filename|.Xresources}}. For example:<br />
URxvt.perl-ext-common: default,clipboard<br />
<br />
==Improved Kuake-like Behavior in Openbox==<br />
This was originally posted on the forum by Xyne<sup>[http://bbs.archlinux.org/viewtopic.php?pid=550380]</sup> and it relies on {{Codeline|xdotool}} which is available in the community repo.<br />
<br />
===Scriptlets===<br />
Save this scriptlet from the {{Codeline|urxvtc}} man page somewhere on your system as {{Filename|urxvtc}} (e.g., in {{Filename|~/.config/openbox}}):<br />
<pre><br />
#!/bin/sh<br />
urxvtc "$@"<br />
if [ $? -eq 2 ]; then<br />
urxvtd -q -o -f<br />
urxvtc "$@"<br />
fi<br />
</pre><br />
<br />
and save this one as {{Filename|urxvtq}}:<br />
<pre><br />
#!/bin/bash<br />
<br />
wid=$(xdotool search --classname urxvtq)<br />
if [ -z "$wid" ]; then<br />
/path/to/urxvtc -name urxvtq -geometry 80x28<br />
wid=$(xdotool search --classname urxvtq | head -1)<br />
xdotool windowfocus $wid<br />
xdotool key Control_L+l<br />
else<br />
if [ -z "$(xdotool search --onlyvisible --classname urxvtq 2>/dev/null)" ]; then<br />
xdotool windowmap $wid<br />
xdotool windowfocus $wid<br />
else<br />
xdotool windowunmap $wid<br />
fi<br />
fi<br />
</pre><br />
<br />
A previous version of xdotool introduced a bug which disabled recognition of visible windows and thus led some users to use the following scriptlet in place of the previous one. This is no longer necessary as xdotool>=1.20100416.2809, but it has been left here for future reference.<br />
<pre><br />
#!/bin/bash<br />
<br />
wid=$(xprop -name urxvtq | grep 'WM_COMMAND' | awk -F ',' '{print $3}' | awk -F '"' '{print $2}')<br />
if [ -z "$wid" ]; then<br />
/path/to/urxvtc -name urxvtq -geometry 200x28<br />
wid=$(xprop -name urxvtq | grep 'WM_COMMAND' | awk -F ',' '{print $3}' | awk -F '"' '{print $2}')<br />
xdotool windowfocus $wid<br />
xdotool key Control_L+l<br />
else<br />
if [ -z "$(xprop -id $wid | grep 'window state: Normal' 2>/dev/null)" ]; then<br />
xdotool windowmap $wid<br />
xdotool windowfocus $wid<br />
else<br />
xdotool windowunmap $wid<br />
fi<br />
fi<br />
</pre><br />
<br />
Make sure that you change {{Filename|/path/to/urxvtc}} to the actual path to the {{Filename|urxvtc}} scriptlet that you saved above. We'll be using {{Filename|urxvtc}} to launch both regular instances of {{Codeline|urxvt}} and the kuake-like instance.<br />
<br />
===urxvtq with tabbing===<br />
If you want to have tabs in your kuake-like {{Filename|urxvtc}} (here called {{Filename|urxvtq}}) just replace the third line in your {{Filename|urxvtq}}:<br />
wid=$(xdotool search --name urxvtq)<br />
with:<br />
wid=$(xdotool search --name urxvtq | grep -m 1 "" )<br />
<br />
To activate the tab support, you can either replace the fifth line of your {{Filename|urxvtq}}:<br />
/path/to/urxvtc -name urxvtq -geometry 80x28<br />
with:<br />
/path/to/urxvtc -name urxvtq -pe tabbed -geometry 80x28<br />
or replace this line of your {{Filename|.Xresources}}:<br />
URxvt.perl-ext-common: default,matcher<br />
with<br />
URxvt.perl-ext-common: default,matcher,tabbed<br />
<br />
====Tab control====<br />
<SHIFT>-Left: Switch to the tab left of current one<br />
<br />
<SHIFT>-Right: Switch to the tab right of current one<br />
<br />
<SHIFT>-Down: Create a new tab<br />
<br />
You can also use your mouse to switch the tabs by clicking the wished one and create a new tab by clicking on ''[NEW].\\''<br />
<br />
To close a tab just enter 'exit' like you'll close a terminal.<br />
<br />
===Openbox configuration===<br />
Now add the following lines to the {{Codeline|<applications>}} section of {{Filename|~/.config/openbox/rc.xml}}:<br />
<pre><br />
<application name="urxvtq"><br />
<decor>no</decor><br />
<position force="yes"><br />
<x>center</x><br />
<y>0</y><br />
</position><br />
<desktop>all</desktop><br />
<layer>above</layer><br />
<skip_pager>yes</skip_pager><br />
<skip_taskbar>yes</skip_taskbar><br />
<maximized>Horizontal</maximized><br />
</application><br />
</pre><br />
<br />
and add these lines to the {{Codeline|<keyboard>}} section:<br />
<pre><br />
<keybind key="W-t"><br />
<action name="Execute"><br />
<command>/path/to/urxvtc</command><br />
</action><br />
</keybind><br />
<keybind key="W-grave"><br />
<action name="Execute"><br />
<execute>/path/to/urxvtq</execute><br />
</action><br />
</keybind><br />
</pre><br />
<br />
Here too you need to change the {{Filename|/path/to/*}} lines to point to the scripts that you saved above. Save the file and then reconfigure Openbox. You should now be able to launch regular instances of urxvt with the Windows/Super key + "'''t'''", and toggle the kuake-like console with Windows/Super+grave ('''`''').<br />
<br />
===Further configuration===<br />
The advantage of this configuration over the urxvt kuake perl script is that Openbox provides more keybinding options such as modifier keys. The kuake script hijacks an entire physical key regardless of any modifier combination. Review the [http://icculus.org/openbox/index.php/Help:Bindings Openbox bindings documentation] for the full range or possibilities.<br />
<br />
The [http://icculus.org/openbox/index.php/Help:Applications Openbox per-app settings] can be used to further configure the behavior of the kuake-like console (e.g. screen position, layer, etc). You may need to change the "geometry" parameter in the {{Filename|urxvtq}} scriptlet to adjust the height of the console.<br />
<br />
===Related scripts===<br />
*hbekel has posted a generalized version of the {{Filename|urxvtq}} [http://bbs.archlinux.org/viewtopic.php?pid=550380#p550380 here] which can be used to toggle any application using {{Codeline|xdotool}}.<br />
<br />
*http://www.jukie.net/~bart/blog/20070503013555 - A script for opening url's with your keyboard instead of mouse with urxvt.<br />
<br />
==Troubleshooting==<br />
===Transparency not working after upgrade to V9.09===<br />
The rxvt-unicode devs removed compatibility code for a lot of non standard wallpaper setters with this update. Using a non compatible wallpaper setter will break transparency support. Recommended wallpaper setters:<br />
* [[feh]]<br />
* hsetroot<br />
* esetroot<br />
<br />
To make true transparency work, make sure to comment urxvt*tintColor and urxvt*inheritPixmap.<br />
<br />
===Remote Hosts===<br />
If you are logging into a remote host, you may encounter problems when running text-mode programs under rxvt-unicode. This can be fixed by copying {{Filename|<br />
/usr/share/terminfo/r/rxvt-unicode}} from your local machine to your host at {{Filename|~/.terminfo/r/rxvt-unicode}}.<br />
<br />
===Using rxvt-unicode as gmrun terminal===<br />
Unlike some other terminals, urxvt expects the arguments to -e to be given separately, rather than grouped together with quotes. This causes trouble with gmrun, which assumes the opposite behavior. This can be worked around by putting an "eval" in front of gmrun's "Terminal" variable in {{Filename|.gmrunrc}}:<br />
<br />
Terminal = eval urxvt<br />
TermExec = ${Terminal} -e<br />
<br />
(gmrun uses {{Filename|/bin/sh}} to execute commands, so the "eval is understood here.) The "eval" has the side-effect of "breaking up" the argument to -e in the same way $@ does in bash, making the command intelligible to urxvt.<br />
<br />
=== My numerical keypad acts weird and generates differing output? (e.g. in vim) ===<br />
<br />
Some Debian GNU/Linux users seem to have this problem, although no specific details were reported so far. It is possible that this is caused by the wrong TERM setting, although the details of whether and how this can happen are unknown, as TERM=rxvt should offer a compatible keymap. See the answer to the previous question, and please report if that helped.<br />
<br />
However, using ''xmodmap'' program you can re-map your numpad keys back.<br />
<br />
1. Check the keycode that your numerical keypad (numpad) generates using ''xev'' program.<br />
:* Start ''xev'' program<br />
:* Press your numpad keys and looks for ''... keycode xxx ...'' in ''xev'' output. For example, numpad 1 in my keyboard is also "End" key, that have a ''''keycode 87''''.<br />
<br />
2. Create or modify your xmodmap file, usually {{Filename|~/.Xmodmap}}, with the content representing your keycode.<br />
<br />
:Example of xmodmap file with numpad keycode,<br />
<pre><br />
keycode 63 = KP_Multiply<br />
keycode 79 = Home KP_7<br />
keycode 80 = Up KP_8<br />
keycode 81 = Prior KP_9<br />
keycode 82 = KP_Subtract<br />
keycode 83 = Left KP_4<br />
keycode 84 = KP_5<br />
keycode 85 = Right KP_6<br />
keycode 86 = KP_Add<br />
keycode 87 = End KP_1<br />
keycode 88 = Down KP_2<br />
keycode 89 = Next KP_3<br />
keycode 90 = Insert KP_0<br />
keycode 91 = Delete KP_Decimal<br />
keycode 112 = Prior<br />
keycode 117 = Next<br />
</pre><br />
<br />
3. Load your xmodmap file at X session start-up.<br />
<br />
:For example, in {{Filename|~/.xinitrc}} file add,<br />
...<br />
xmodmap ~/.Xmodmap<br />
...<br />
<br />
==External resources==<br />
*[http://software.schmorp.de/pkg/rxvt-unicode.html rxvt-unicode] - Official site<br />
*[http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.pod rxvt-unicode FAQ] - Official FAQ<br />
*[http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.1.pod rxvt-unicode Reference] - Official manual page<br />
*[http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/src/urxvt.pm urxvtperl] - Official Perl extension reference<br />
*{{Codeline|man urxvt}}</div>Rnabioullinhttps://wiki.archlinux.org/index.php?title=Network_Time_Protocol_daemon&diff=159310Network Time Protocol daemon2011-09-11T21:45:13Z<p>Rnabioullin: Corrected chroot procedure</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:Daemons and system services (English)]]<br />
{{i18n|Network Time Protocol daemon}}<br />
[[fr:ntp]]<br />
<br />
This article describes how to set up and run NTPd (Network Time Protocol daemon), the most common method to synchronize the [[Time|software clock]] of a GNU/Linux system with internet time servers using the [[Wikipedia:Network Time Protocol|Network Time Protocol]]; if set up correctly, NTPd can make your computer act as a time server itself.<br />
<br />
==Installation==<br />
{{Package Official|ntp}} is available from the [extra] repository.<br />
<br />
==Configuration==<br />
The first thing you define in your {{Filename|/etc/ntp.conf}} is the servers your machine will synchronize to.<br />
NTP servers are classified in a hierarchical system with many levels called ''strata'': the devices which are considered independent time sources are classified as ''stratum 0'' sources; the servers directly connected to ''stratum 0'' devices are classified as ''stratum 1'' sources; servers connected to ''stratum 1'' sources are then classified as ''stratum 2'' sources and so on.<br />
<br />
It has to be understood that a server's stratum cannot be taken as an indication of its accuracy or reliability. Typically, stratum 2 servers are used for general synchronization purposes: if you do not already know the servers you are going to connect to, you should use the [http://www.pool.ntp.org/ pool.ntp.org] servers ([http://support.ntp.org/bin/view/Servers/NTPPoolServers alternate link]) and choose the server pool that is closest to your location.<br />
<br />
The following lines are just an example:<br />
<br />
server 0.pool.ntp.org iburst<br />
server 1.pool.ntp.org iburst<br />
server 2.pool.ntp.org iburst<br />
server 3.pool.ntp.org iburst<br />
<br />
The ''iburst'' option is recommended, and sends a burst of packets if it cannot obtain a connection with the first attempt. The ''burst'' option always sends a burst of packets, even on the first attempt. The ''burst'' option should never be used without explicit permission and may result in blacklisting.<br />
<br />
If setting up an NTP server, you need to add [http://www.ntp.org/ntpfaq/NTP-s-refclk.htm#Q-LOCAL-CLOCK ''local clock''] as a server, so that, in case it loses internet access, it will continue serving time to the network; add ''local clock'' as a stratum 10 server (using the ''fudge'' command) so that it will never be used unless internet access is lost:<br />
<br />
server 127.127.1.0<br />
fudge 127.127.1.0 stratum 10<br />
<br />
Next, define the rules that will allow clients to connect to your service (''localhost'' is considered a client too) using the ''restrict'' command; you should already have a line like this in your file:<br />
<br />
restrict default nomodify nopeer noquery<br />
<br />
This restricts everyone from modifying anything and prevents everyone from querying the status of your time server: "nomodify" prevents reconfiguring your ntpd (with ''ntpq'' or ''ntpdc''), and "noquery" prevents dumping status data from your ntpd (also with ''ntpq'' or ''ntpdc'').<br />
<br />
You can also add other options:<br />
<br />
restrict default kod nomodify notrap nopeer noquery<br />
<br />
{{Note|This still allows other people to query your time server. You need to add '''noserve''' to stop serving time.}}<br />
<br />
Full docs for the "restrict" option are in {{Codeline|man ntp_acc}}. See http://support.ntp.org/bin/view/Support/AccessRestrictions for detailed instructions.<br />
<br />
Following this line, you need to tell ''ntpd'' what to allow through into your server; the following line is enough if you are not configuring an NTP server:<br />
<br />
restrict 127.0.0.1<br />
<br />
If you want to force DNS resolution to the IPv6 namespace, write -6 before the IP address or host name (-4 forces IPv4 instead), for example:<br />
<br />
restrict -6 default kod nomodify notrap nopeer noquery<br />
restrict -6 ::1 # ::1 is the IPv6 equivalent for 127.0.0.1<br />
<br />
Lastly, specify the drift file (which keeps track of your clock's time deviation) and optionally the log file location:<br />
<br />
driftfile /var/lib/ntp/ntp.drift<br />
logfile /var/log/ntp.log<br />
<br />
A very basic configuration file will look like this ('''all comments have been stripped out for clarity'''):<br />
<br />
{{File|name=/etc/ntp.conf|content=<br />
server 0.pool.ntp.org iburst<br />
server 1.pool.ntp.org iburst<br />
server 2.pool.ntp.org iburst<br />
server 3.pool.ntp.org iburst<br />
<br />
restrict default kod nomodify notrap nopeer noquery<br />
restrict -6 default kod nomodify notrap nopeer noquery<br />
<br />
restrict 127.0.0.1<br />
restrict -6 ::1 <br />
<br />
driftfile /var/lib/ntp/ntp.drift<br />
logfile /var/log/ntp.log<br />
}}<br />
<br />
{{Note|Defining the log file is not mandatory, but it is always a good idea to have feedback for ''ntpd'' operations.}}<br />
<br />
In conclusion, never forget man pages: {{Codeline|man ntp.conf}} is likely to answer any doubts you could still have (see also the related man pages: {{Codeline|man <nowiki>{ntpd|ntp_auth|ntp_mon|ntp_acc|ntp_clock|ntp_misc}</nowiki>}}).<br />
<br />
{{Gentoo|NTP}}<br />
<br />
==Running as a daemon==<br />
===Starting ntpd===<br />
ntpd sets 11 minute mode, which syncs the system clock to hardware every 11 minutes. The hwclock daemon measures hardware clock drift and syncs it, which conflicts with ntpd.<br />
<br />
Stop the hwclock daemon (if it is running):<br />
<br />
{{Cli|# rc.d stop hwclock}}<br />
<br />
Start the ntpd daemon:<br />
{{Cli|# rc.d start ntpd}}<br />
<br />
Add ntpd to your DAEMONS array so it starts automatically on boot and make sure hwclock is disabled:<br />
{{File|/etc/rc.conf|content=DAEMONS=(... !hwclock '''ntpd''' ...)}}<br />
<br />
===NetworkManager===<br />
{{Note|ntpd should still be running when the network is down if the hwclock daemon is disabled, so you should not use this.}}<br />
''ntpd'' can be brought up/down along with a network connection through the use of [[NetworkManager#Network Services with NetworkManager Dispatcher|NetworkManager's dispatcher scripts]]. You can install the needed script from [community]:<br />
<br />
{{cli|# pacman -S networkmanager-dispatcher-ntpd}}<br />
<br />
===Running as non-root user===<br />
When compiled with ''--enable-linux-caps'', ntp can be run as a non-root user for increased security (the vanilla Arch Linux package has this enabled).<br />
<br />
{{Note|Before attempting this, make sure ntp has already created {{Filename|/var/lib/ntp/ntp.drift}}.}}<br />
<br />
Create ''ntp'' group and ''ntp'' user:<br />
<br />
{{Cli|<nowiki># groupadd ntp<br />
# useradd -r -d /var/lib/ntp -g ntp -s /bin/false ntp</nowiki>}}<br />
<br />
Change ownership of the ntp directory to the ntp user/group:<br />
<br />
{{cli|# chown -R ntp:ntp /var/lib/ntp}}<br />
<br />
Edit {{Filename|/etc/conf.d/ntp-client.conf}} and change<br />
<br />
NTPD_ARGS="-g"<br />
<br />
to<br />
<br />
NTPD_ARGS="-g -u ntp:ntp"<br />
<br />
Finally, restart the daemon:<br />
<br />
{{cli|# rc.d restart ntpd}}<br />
<br />
===Running in a chroot===<br />
{{Note|Before attempting this, complete the previous section on running as non-root, since chroots are relatively useless at securing processes running as root.}}<br />
<br />
Edit {{Filename|/etc/conf.d/ntp-client.conf}} and change<br />
<br />
NTPD_ARGS="-g -u ntp:ntp"<br />
<br />
to<br />
<br />
NTPD_ARGS="-g -i /var/lib/ntp -u ntp:ntp"<br />
<br />
Then, edit {{Filename|/etc/ntp.conf}} to change the driftfile path such that it is relative to the chroot directory, rather than to the real system root. Change:<br />
<br />
driftfile /var/lib/ntp/ntp.drift<br />
<br />
to<br />
<br />
driftfile /ntp.drift<br />
<br />
Create a suitable chroot environment so that getaddrinfo() will work by creating pertinent directories and files (as root):<br />
<br />
{{Cli|<nowiki># mkdir /var/lib/ntp/etc /var/lib/ntp/lib /var/lib/ntp/proc<br />
# touch /var/lib/ntp/etc/resolv.conf /var/lib/ntp/etc/services</nowiki>}}<br />
<br />
and by bind-mounting the aformentioned files:<br />
<br />
{{File|name=/etc/fstab|content=<br />
...<br />
#ntpd chroot mounts<br />
/etc/resolv.conf /var/lib/ntp/etc/resolv.conf none bind 0 0<br />
/etc/services /var/lib/ntp/etc/services none bind 0 0<br />
/lib /var/lib/ntp/lib none bind 0 0<br />
/proc /var/lib/ntp/proc none bind 0 0<br />
}}<br />
<br />
{{cli|# mount -a}}<br />
<br />
Finally, restart the daemon again:<br />
<br />
{{cli|# rc.d restart ntpd}}<br />
<br />
It is relatively difficult to be sure that your driftfile configuration is actually working without waiting a while, as ntpd does not read or write it very often. If you get it wrong, it will log an error; if you get it right, it will update the timestamp. If you do not see any errors about it after a full day of running, and the timestamp is updated, you should be confident of success.<br />
<br />
==Syncing the clock without running the daemon==<br />
If what you want is just synchronize your system clock at boot time without running ''ntpd'' as a daemon, you can add this line to your {{Filename|/etc/rc.local}}:<br />
<br />
ntpd -qg &<br />
<br />
This behavior mimics that of the ''ntpdate'' program, which is now deprecated.<br />
<br />
{{Note|In order for this method to work you have to make sure that, when {{Filename|rc.local}} is executed, the network connection has already been initialized (for example you should not background essential network-related daemons in {{Filename|/etc/rc.conf}})}}<br />
{{Warning|<br />
* Using this method is highly discouraged on servers and in general on machines that need to run continuously for more than 2 or 3 days, as the system clock will be updated only once at boot time.<br />
* Running "{{Codeline|ntpd -qg}}" as a ''cron'' event is to be completely avoided, unless you are perfectly aware of how your running applications would react to instantaneous system time changes.<br />
}}<br />
<br />
Check that the DAEMONS array in {{Filename|/etc/rc.conf}} includes ''hwclock'', to ensure the hardware clock is periodically updated:<br />
<br />
{{File|name=/etc/rc.conf|content=<br />
...<br />
<br />
DAEMONS=(... hwclock ...)<br />
}}<br />
<br />
{{Warning|If something other already takes care of updating the hardware clock, for example another operating system in dual boot, you should avoid starting ''hwclock''.}}<br />
<br />
==Alternatives==<br />
An available alternative to NTPd is [[OpenNTPD]], part of the OpenBSD project and currently not maintained for Linux.<br />
<br />
==See also==<br />
* [[Time]] (for more information on computer timekeeping)<br />
<br />
==External links==<br />
* http://www.ntp.org/<br />
* http://support.ntp.org/<br />
* http://www.pool.ntp.org/<br />
* http://www.eecis.udel.edu/~mills/ntp/html/index.html<br />
* http://www.akadia.com/services/ntp_synchronize.html</div>Rnabioullin